Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
269 replies to this topic

#251 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

I decided to make a single partition VHD of 3 GB, to test the time required to load it in Ram (using the UEFI grub4dos from previous post), and booting first with a1ve's grub2 and chainloading to G4E to load and boot the VHD:

 

10x64-LZX-3.vhd (NTFS) 3GB Grub2 + grub4dos >>> 33.82 sec.

10x64-LZX-3.vhd.lz4 (NTFS) 3GB Grub2 + grub4dos >>> 25.43 sec.

 

10x64-LZX-3.vhd.lz4 is 1.67 GB, it is an improvement of 8.39 seconds in the time used to load it on Ram (24.8 % less time),  but it is not so notorious as on this case, when testing a RamOS (installed on Wimboot mode) using same WIM file, and UEFI grub4dos 2020-12-15, that was last version at the time of testing:

 

From: http://reboot.pro/to...-10#entry217481

 

Secure Boot = Disabled        CSM = Auto

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB Grub2 >>> 28.94 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB Grub2 + grub4dos >>> 15.08 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB grub4dos >>> 15.00 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS)  1330 MB Grub2 + grub4dos >>> 4.28 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS)  1330 MB grub4dos >>> 4.31 sec.

 

I will take both as 4.30 sec., as the difference may be just my finger response.

 

Here the lz4 compression helps a lot to improve the time (71.48 % less time) as the Wimboot VHD has a lot of free space.

 

We can conclude lz4 compression makes a big difference on the time required to load on Ram a Wimboot VHD (installed on Wimboot mode), but not so much on a Compact LZX VHD (installed on Compact LZX mode).  71.48 % vs. 24.8 % less time.

 

alacran



#252 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

Test booting a RamOS on a 3.5 GB VHD:

 

I was able to Ramboot a 3.5 GB VHD 2 partitions, on same PC with 8 GB of Ram, this time for testing pourposes I used VHD_WIMBOOT-45 to create the VHD and apply the WIM file on Compact LZX mode.

 

Booted to a1ive's grub2 (using the last version of this post for testing pourposes) and chainloaded to UEFI grub4dos (using the same version as on previous post, located here).

 

In this case as a1ive's grub2 usually looks for the grub.cfg on \Boot\grub\grub.cfg, I just copied it there.

 

Menu entry on menu.lst, made by VHD_WIMBOOT-45 is:

 

title Boot  /VHD/10x64-35.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 3.5 GB
find --set-root --ignore-floppies --ignore-cd /VHD/10x64-35.vhd
map --mem --top /VHD/10x64-35.vhd (hd)
chainloader (hd-1)

alacran

Attached Thumbnails

  • 3.5GB-VHD.png

  • antonino61 likes this

#253 antonino61

antonino61

    Silver Member

  • Advanced user
  • 995 posts
  •  
    Italy

Posted A week ago

interesting! Apparently, the greater the free space, the faster the bootup time. It would be interesting to find out the trade in, ie, how much greater should the free space be relative to the amount of ram available. Me, I noticed that, in terms of space, compressed lz4 (or for that matter gz) sizes stop being smaller at a certain point of enlarging free space (making the vhd larger, so to speak). 



#254 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

Test booting a RamOS on a 3.8 GB VHD (Not compressed):

 

I was able to Ramboot a 3.8 GB VHD NTFS single partition, on same PC with 8 GB of Ram, in this case this is a normal (uncompressed) installation, and it booted fine.

 

I created the VHD manually and installed the OS with wimlib-clc, and latter made the respective entries to boot with UEFI_MULTI v5.3, and also copied the grub.cfg on \Boot\grub\grub.cfg,

 

Menu entry on menu.lst, made by UEFI_MULTI v5.3

 

title Boot  /VHD/10x64-38.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 3.8 GB
load /EFI/grub/ntfs_x64.efi
find --set-root --ignore-floppies --ignore-cd /VHD/10x64-38.vhd
map --mem --top /VHD/10x64-38.vhd (hd)
chainloader (hd-1)

As in previous case booted first to a1ive's grub2 and chainloaded to UEFI grub4dos.

 

alacran

Attached Thumbnails

  • 3.8GB-VHD-G4E.png


#255 antonino61

antonino61

    Silver Member

  • Advanced user
  • 995 posts
  •  
    Italy

Posted A week ago

Sorry Alacrán, let me get my head together, pls. I am still booting the old way - one partition only, no-uefi, just the traditional conventional bios way, even with the new editions of vhd_wimboot. is using uefi any faster or more convenient than just

 

title vhd1.vhd - SVBus  RAMDISK  - 2.0 GB - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /vhd1.vhd
map --top --mem /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

?

 

NB: my g4d is still the non-uefi one. then again, is the newest uefi one any better? I saw u used one partition only with uefi stuff preloading - anything worthwhile trying?



#256 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

I'm testing this because more sooner than latter, there will not be an option to actvate the CSM on the new MBs, but IMHO as long as you can boot using CSM + grub4dos for MBR, there is no real or practical need to change to the UEFI environment, I don't see yet any advantage for you in doing it, in your present case.

 

Unless your motivation is experimenting, Why you want to complicate your life unnecessarily?

 

alacran



#257 antonino61

antonino61

    Silver Member

  • Advanced user
  • 995 posts
  •  
    Italy

Posted A week ago

1) because I would like to help and learn. I have good pc resources and I was reading ur posts on a1ive. As I have good pc architecture, I think I'm gonna cooperate with testing, That is why I was reading and waiting for ur answer. 

2) can I still go on using the traditional vhd config and trying the new way with the new version of g4u?

3) when u talk of loading times, u still refer to preloading into ram, paying no mind to the time it takes to further reach the desktop, as u have no power on that part of the process, right?



#258 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

1) Then your motivation is experimenting.

 

2) To answer this you need to check your Bios/firmware options CAREFULLY, and it may be possible, but to start, booting only from Win without all your additional programs that always create unnecesary troubles during this testing phase, if not you will not help, and only will bring additional complications.

 

In my case this PC has 2 HD, both are MBR formated the first HD is the one I use for every day, its first primary active partition is NTFS, good to boot on MBR/CSM mode.  The second HD also MBR formated primary partition is FAT-32 where all UEFI boot files/folders are, on that same disk on second partition are the VHDs for experimenting.

 

Going back to the Bios/firmware options, on this PC I have Secure Boot permanently disabled to make things easier, and the CSM has 3 options: Auto, Enabled and disabled, I have it usually on Auto, and by means of BootIce I made 2 additional entries on UEFI, to boot from Grub2 and or to boot from UEFI grub4dos that I can make available during boot with F8 key. (but not all MB brands have a key for this).

 

In case your PC do not have the Auto option for CSM on the Bios/firmware you may try, but I'm not shure if this will let you boot on UEFI mode. too.

 

3) Yes I'm measuring allways the time required to load on Ram my Mini-10x64 only, the rest of the time do not have anything to do with grub2 or UEFI grub4dos, as then Win + SVBus driver are in charge of the process, and that is another subject for now, there are some people on chinese forums experimenting with other drivers (apart from SVBus driver) to make Win read/write faster on the Ramdisk once loaded on Ram but that's another subject as I said.  Latter we could try the other alternatives, but better not for now.

 

alacran



#259 antonino61

antonino61

    Silver Member

  • Advanced user
  • 995 posts
  •  
    Italy

Posted A week ago

ok I will check my mobo and let u know (it is an x99 gigabyte aorus ultra gaming pro).



#260 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

Test booting a RamOS on a 4000 MB (3.9 GB) VHD (Not compressed):

 

Just to test the limits I ran this test.

 

I was able to Ramboot a 4000 MB VHD NTFS single partition, on same PC with 8 GB of Ram, in this case this is same normal (uncompressed) installation, and it booted fine.

 

To test this, I increased the VHD size in command line and latter just expanded the single NTFS partition and edited the menu.lst, the VHD was not fragmented when cheked with Winconting.

 

Menu entry on menu.lst

 

title Boot  /VHD/10x64-39.vhd - UEFI Grub4dos  SVBus  RAMDISK  - 3.9 GB
load /EFI/grub/ntfs_x64.efi
find --set-root --ignore-floppies --ignore-cd /VHD/10x64-39.vhd
map --mem --top /VHD/10x64-39.vhd (hd)
chainloader (hd-1)

As in previous case, booted first to a1ive's grub2 and chainloaded to UEFI grub4dos.

 

I don't think it is a good idea to go further as the memory above 4 GB available on this PC, is 4 GB or 4096 MB.

 

Then I can conclude with this version of UEFI grub4dos, we can make use of all the memory available on the PC above 4 GB, without any issue.

 

alacran



#261 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

@ liuzhaoyzz

 

I saw your post http://bbs.c3.wuyou....652&pid=4205678

 

Translated here for other readers convenience:

Spoiler

 

I think not only me, but all members and readers here on reboot.pro will appreciate a lot if you give us a more detailed explanation of the procedure, that may let us also make use of your findings related to ntboot and Primo driver.

 

Thanks in advance my friend.

 

alacran



#262 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 45 posts
  •  
    China

Posted A week ago

@ liuzhaoyzz

I saw your post http://bbs.c3.wuyou....652&pid=4205678

Translated here for other readers convenience:

Spoiler


I think not only me, but all members and readers here on reboot.pro will appreciate a lot if you give us a more detailed explanation of the procedure, that may let us also make use of your findings.

Thanks in advance my friend.

alacran

Compatibility and stability of ntfs_x64.efi is a bit problematic, as wintoflash said. Based on grub2-ntboot scheme, this unstable driver is completely abandoned.
http://wuyou.net/for...&fromuid=298214
Usage of grub2-ntboot:
menuentry "SX70211.vhd-svbus-ntboot-l" "/VHD/SX70211.vhd" {
search --no-floppy --set --file $2
map --mem --rt -l $2
ntboot --win --efi=(vd0,1)/EFI/Microsoft/Boot/bootmgfw.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}

Based on many technologies and experiences accumulated in the successful process of svbus-RAMOS, UEFI-RAMOS based on primo drive has also achieved success under the exploration of everyone. primo drive is very complex, including single mirror mode and double mirror mode. primo drive is the crystallization of wisdom of many RAMOS predecessors. Compared with RAMOS based on svbus drive, RAMOS driven by primo is faster. RAMOS with primo double mirror mode and C disk are equal to the total memory size, which can install a lot of software and have a lot of available memory. Memory and hard disk can be converted and dynamically allocated, which is better than RAMOS driven by svbus in all aspects. Actually speaking, I basically can't use RAMOS based on svbus driver, but I always use RAMOS based on primo driver, but primo driver is a commercial software of romex Company, which is a charging software, and there is a cracked version on the Internet (which may also be available abroad). y7y007 of wuyou.net Forum has compiled a batch for online production of primo-RAMOS based on the cracked version of primo server5.6. I have made many improvements and translated it into

Starting with V4.0.0 (there is no English version for the time being), I removed the cracked version of primo software in one-button V3.8.7, and did not pack any cracked software. In this way, there was no copyright dispute, and if I bought genuine primo software, I could use it.

RAMOS driven by primo, this is really a long, long story. It is unclear in a few words. If you are interested, you can read the following related posts:
(We can't visit the wuyou.net Forum recently, so we are helpless)

1KRAMOS3.8.7-English-RAMOS
http://wuyou.net/for...read&tid=410849

http://wuyou.net/for...&fromuid=298214

The world's first WIN7 8.1 10UEFI-RAMOS single image based on primo single driver +grub2/g4e was successfully produced-RAMOS
http://wuyou.net/for...23&extra=page=1

RAMOS (Memory Operating System)-wuyou Encyclopedia (under improvement)-RAMOS
http://wuyou.net/for...74&extra=page=1

Primo Ramdisk - Powerful Disk Emulator to Create Ultra-Fast RAM-Disks
https://www.romexsof...disk/index.html

Primo Ramdisk:https://www.romexsof...k/purchase.html


Edited by liuzhaoyzz, A week ago.

  • alacran likes this

#263 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

@ liuzhaoyzz

 

Thank for your detailed info my friend, for now I think I will prefer free software in this case.

 

I understand Primo driver is faster and has other advantages on the way it uses the memory too, but as Win 10 is changing so much and so frequently there is a high possibility Primo driver may stop working to boot a RamOS in the future. and so far SVBus does a very decent work for free.

 

Nevertheless I will read the procedure to use Primo driver, to know better how it could be used in case I decide to buy it later.

 

About ntboot, I was worry about the resolution but it seems our fellow wimb just found the way to change resolution

 

Translated for readers convenience:

 

After adding the --highest=no parameter, the resolution is normal, thanks!

 

alacran



#264 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A week ago

About ntboot for grub4dos, this link I found on one of steve6375 pages takes me to Chenall site, but the link there for download ntboot, is not working anymore.

 

alacran



#265 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15576 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted A week ago


About ntboot for grub4dos, this link I found on one of steve6375 pages takes me to Chenall site, but the link there for download ntboot, is not working anymore.
 
alacran

Check the ntboot here:
https://www.easy2boo...download-sites/
https://tiny.cc/801hbz
 
Public->Archive
 
https://onedrive.liv...A0F146CC7416BA9
 
:duff:
Wonko
  • alacran likes this

#266 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted 3 days ago

Public->Archive
 
https://onedrive.liv...A0F146CC7416BA9
 
:duff:
Wonko

 

Thanks Wonko.

 

The file NTBOOT-2016-01-05.7z_ is located on the link quoted.

 

But it seems it is not able to work with 10 bootmgr as stated on this topic from steve6375: http://reboot.pro/in...20695&hl=ntboot

 

In fact during installing E2B, steve6375 uses 8 bootmgr downloaded with Get WAIK Tools from JFX

 

alacran



#267 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted 3 days ago

There is a new grub4dos for UEFI release on: https://github.com/c...ub4dos/releases

 

Just to report grub4dos-for_UEFI-2021-01-10.7z new version is working fine here too. 

No problem when loading to Ram and booting (externally uncompressed) VHDs installed on Wimboot or Compact mode.

Also if they are (externally) lz4 compressed they are loaded fine to Ram and boot fine.

 

As in previous cases, booted first to a1ive's grub2 and chainloaded to grub4dos for UEFI to load and boot the VHD files.

 

NOTE: This post has almost same content as my post on the VHD_WIMBOOT topic, reason for this is the links to posts are not working fine currently.

 

alacran


  • wimb and liuzhaoyzz like this

#268 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 271 posts

Posted 3 days ago

Report on testing grub4dos-for_UEFI-2021-01-12.7z. Finally, I managed to boot my vhd, a complete Win10 64-bit installation hosted by Vmware. Following the suggestion of alacran, the first partition is FAT32 ( MBR ) and the second is NTFS. Memory adjusted to 15 Gb. The size of the VHD is 11 Gb.

grub4dos UEFI commands :

find --set -root /win10.vhdmap --mem --top /win10.vhd (hd)chainloader (hd-1,0)

Many thanks to the developers of grubdos for UEFI.



#269 wimb

wimb

    Platinum Member

  • Developer
  • 3217 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 3 days ago

Yes the Releases of 2021-01-10 and 2021-01-12 are the first versions of UEFI Grub4dos that support VHD with GPT partitioning.



#270 alacran

alacran

    Gold Member

  • .script developer
  • 1877 posts
  •  
    Mexico

Posted A day ago

New grub4dos for UEFI version on: https://github.com/c...ub4dos/releases

 

Tested with MBR single NTFS partition, and MBR 2 partitions (FAT-32+NTFS) VHDs.

 

Reporting grub4dos-for_UEFI-2021-01-12.7z new version is working fine here too. 

No problem when loading to Ram and booting (externally uncompressed) VHDs installed on Wimboot or Compact mode.

Also if they are (externally) lz4 compressed they are loaded fine to Ram and boot fine.

 

As in all previous cases, booted first to a1ive's grub2 and chainloaded to grub4dos for UEFI to load and boot the VHD files.

 

alacran


  • wimb likes this




6 user(s) are reading this topic

0 members, 6 guests, 0 anonymous users