Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
421 replies to this topic

#251 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 January 2021 - 01:03 AM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 January 2021 - 10:58 PM

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

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 03 January 2021 - 01:44 AM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 January 2021 - 01:59 AM

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

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 03 January 2021 - 02:12 AM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 January 2021 - 02:51 AM

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

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 03 January 2021 - 02:58 AM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 January 2021 - 03:49 AM

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

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 03 January 2021 - 04:29 AM

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



#260 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 03 January 2021 - 06:46 AM

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 Wincontig.

 

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 January 2021 - 02:49 AM

@ 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
  • 51 posts
  •  
    China

Posted 04 January 2021 - 07:03 AM

@ 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, 04 January 2021 - 07:07 AM.

  • alacran likes this

#263 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 January 2021 - 12:40 PM

@ 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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 04 January 2021 - 02:33 PM

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
  • 16066 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 January 2021 - 07:30 PM


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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 January 2021 - 11:54 PM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 12 January 2021 - 12:29 AM

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
  • 299 posts

Posted 12 January 2021 - 03:03 PM

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.  Disk partition style : GPT

grub4dos UEFI commands :

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

Many thanks to the developers of grubdos for UEFI.



#269 wimb

wimb

    Platinum Member

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

Posted 12 January 2021 - 03:19 PM

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

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 13 January 2021 - 08:45 PM

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

#271 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 January 2021 - 08:54 PM

New grub4dos for UEFI version on: http://grub4dos.chen...ories/for-UEFI/

 

grub4dos-for_UEFI-2021-01-13.7z new version is also working fine here.

 

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

 

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

#272 wimb

wimb

    Platinum Member

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

Posted 20 January 2021 - 07:32 AM

New grub4dos for UEFI version on: http://grub4dos.chen...ories/for-UEFI/

 

grub4dos-for_UEFI-2021-01-13.7z new version is also working fine here.

 

 

Is this the same as announced in Chinese forum as grub4dos-for_UEFI-2021-01-16.7z or is 16 a newer version yet to come  ?



#273 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 20 January 2021 - 10:42 PM

Is this the same as announced in Chinese forum as grub4dos-for_UEFI-2021-01-16.7z or is 16 a newer version yet to come  ?

 

I can't download the grub4dos-for_UEFI-2021-01-16.7z, (which is not released yet), so I can't compare both, but based on the dates I don't think they are the same.

 

Anyway after reading all new posts on wuyou.net it seems they are having compilation problems with the software used for this on github, and chenall is trying to find the solution to this issue, Also some members there, are mentioning they have had troubles to boot a Win10XPE ISO with all G4E January versions.

 

NOTE: My Win10XPE_x64.ISO is booting fine as filedisk using grub4dos-for_UEFI-2021-01-13 version.

 

title Win10XPE - Find images/Win10XPE_x64.ISO
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

Additionally yaya posted a new test version for differential VHD (NOT for VHDX), but not released yet.

 

alacran


  • wimb likes this

#274 wimb

wimb

    Platinum Member

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

Posted 21 January 2021 - 06:07 AM

*
POPULAR

New GitHub Release of grub4dos for UEFI version grub4dos-for_UEFI-2021-01-21.7z is available ....and is working OK  :)


  • alacran, liuzhaoyzz and fi-zilal like this

#275 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 24 February 2021 - 12:17 AM

JFYI

 

There are some interesting new improvements on grub4dos-for_UEFI made during the last months, I will comment the last improvements made during 2021, from the info on grub4dos-for_UEFI-2021-02-10, (usual functions are already included on last version of wimb's programs).

 

This is new changelog_UEFI.txt file translated to English, remarked in blue new 2021 improvements:

 

Spoiler

 

The more relevant improvemets are:

 

Start bootmgfw.efi fine. since 2021-01-09 version.

Correct external commands, since 2021-01-12 version.

Support loading multiple initrd files since 2021-01-12 version.

Support to start a differential VHD has been added since 2021-01-31 version.

Now it shuts down fine (and does not make a false shut down, just to reboot again in a few seconds), since 2021-02-10

 

And this is new Sample menu.lst translated to English.

 

Spoiler

 

There is not a sample to boot differential VHD on the previous Sample menu.lst

 

Now ntloader can be loaded as an external command to boot WIM and VHD files, using following sample commands:

 

#Use external command ntloader
#Assuming WIM or VHD is located in (hdx,y), the path is /path/to/winpe.wim
title Start Windows WIM/VHD
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID% file=/path/to/winpe.wim
initrd /initrd.lz1

#Use external command ntloader
#Assuming the system folder is located at (hdx,y)
title Start Windows system
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID%
initrd /initrd.lz1

But I assume we need to have the ntloader external command available, as it do not seems to be embeded in G4E

 

@ a1ive and/or @ liuzhaoyzz:

 

Please give us some more info about boot differential VHD, and the use of ntloader external command in G4E.

 

I remember I read (on wuyou.net forum) a1ive made, (from his version of ntloader used on a1ive's grub2), a new ntloader modified version to be used on G4E.

 

Also there is now an ext folder into grub4dos-for_UEFI-2021-02-10.7z download, with several files into it, and I would like to know better what is their use?

 

Thanks in advance.

 

alacran


  • wimb likes this




3 user(s) are reading this topic

0 members, 3 guests, 0 anonymous users