grub4dos for UEFI

[alacran]

JFYI

There is a new version of grub4dos for UEFI, made by yaya, this is his third version: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a_for_UEFI-2020-11-26/

yaya's post on http://bbs.wuyou.net/forum.php?mod=viewthread&tid=422652

Please remember this is a work in progress so it is an experimental version.

This new grub4dos for UEFI was developed by yaya, so in no way I'm involved on it's development, but I think this thread deserves to be on this section of the forum just because the relevance of the subject. I made that desition because unfortunately the author hasn't opened a topic on this forum.  Hope this desition is fine with forum admins.

On this topic we will talk about the experiences with this new version, as not all the usual commands work on this version.

So far our fellow wimb was able to sucessfully UEFI boot Win10XPE_x64.ISO, from internal HD and also from a USB device, hope he will share his experiences with all of us.

alacran

Edited November 26, 2020 by alacran
Updated to the last current version

[wimb]

Good to start here at MSFN discussion about grub4dos for UEFI.

The English download location for latest grub4dos-0.4.6a_for_UEFI-2020-11-26.7z is found at GitHub grub4dos Releases

Edited November 26, 2020 by wimb

[alacran]

NOTE: First post was updated with new version released today a few hours ago.

ChangeLog_UEFI.txt translated to English with Google Translate for your convenience, also attached:

Quote

Release Notes:
2020-11-26 (yaya)
  Merged i386 and x86_64 source code.
  Fix the hotkey and exit_g4d functions.

2020-11-19 (a1ive)
  Support to use the kernel and initrd commands to start the linux kernel.
2020-11-18 (yaya)
  1. Change the menu directory to: /efi/grub/menu.lst
  2. Support physical CD, hard disk boot.
  3. When there are multiple CDs, adjust the boot CD to the first CD to suit windows.
  4. Add the function exit_g4d to exit GRUB4DOS.
  5. Batch changes:
     The function subscript remains unchanged, and the parameter is changed from 32 bits to 64 bits. (Fn. subscript parameter 1 parameter 2 ...)
     The variable address is changed from 0x8304 to 0x8308, from 32 bits to 64 bits.
     Reading general memory value is still ‘read memory address’, while reading GRUB4DOS internal value, use ‘read *memory address’ (eg read *0x8308).
     Add else function to batch processing. Added {script set} notation.
     Such as:
     if condition
     {
       Script set
       if condition {
         Script set}
       else {
         Script set}
     }
     else if condition
     {
       Script set
     }
     else
     {
       Script set
     }
     note:
     1. The curly brace must be the end of a line.
     2. The script set can be written in multiple lines.
     3. The braces can be nested inside.

2020-10-29 (yaya)
  GRUB4DOS for UEFI environment.
 
  This is a huge project, almost all the code has been stroked. Modified console keyboard input and output, console screen output, memory control,
  Drive control, get date and time, pause control, graphics mode and Unicode font implementation, PXE net start, etc.
 
  During the development process, the GRUB2 source code was referenced. For the mapping, refer to the source code of wintoflash.
 
  1. You can start efi files.
  2. You can start iso and img files.
  3. Built-in hot key function. Example: setmenu --hotkey parameter
 
  Differences from the old version:
  1. You can view the graphics modes supported by the system through the graphicsmode command.
  2. Mount after the map function is executed. There is no need to execute the --hook command.
  3. Cancel the --hook, --unhook, --rehook, --unmap=, --floppies=, --harddrives= commands.
  4. In the UEFI environment, you can boot from a disk other than 0x80, so there is no need to swap disk operations, such as map (hd0) (hd1).
  5. Cancel the delete disk function, such as map (hd1) (hd1).
  6. Currently, PXE Netstart only supports tftp.

And this is a sample menu.lst translated to English with Google Translate for your convenience, also attached:

Quote

# This is a sample menu.lst file. You should make some changes to it.
    # It must be UTF-8 encoding to support multiple languages.
    # The font should be in unifont.hex format.

    #Set countdown (seconds)
    timeout 30

    #Set the first item as the default value
    default 1

    #Set the character color (the upper 32 bits are the background color, and the lower 32 bits are the foreground color)
    color normal=0xff9933 highlight=0xffff00 helptext=0xff00ff heading=0x66ff00

    #Set graphics mode (you can use graphicsmode to detect graphics modes supported by the system)
    graphicsmode -1 800

    #Load background image
    splashimage /efi/grub/splashimage.jpg || splashimage /boot/grub/splashimage.bmp

    #Load font (if it is not a 16*16 font, add parameters, such as --font-high=24)
    font /efi/grub/unifont.hex.gz

    #Settings menu box
    setmenu --box x=4 w=60 y=6 h=9 l=2
    #Set Chinese menu button help
    setmenu --lang=zh
    #Set automatic menu number
    setmenu --auto-num-on
    #Set string information
    setmenu --string=80=2=0x0000000000ffff="G4D maintenance menu"
    #Set date and time
    #setmenu --string=s=1=0x8800000000ffff="date&time=yyyy-MM-dd HH:mm:ss"
    #Set countdown
    setmenu --timeout=90=2=0x88000000ffff

    title starts efi file
    chainloader /efi/boot/grub2x64.efi

    title Start virtual CD
    find --set-root /cdrom.iso
    map /cdrom.iso (0xff)
    chainloader (0xff)

    title Start virtual CD (loaded into memory)
    find --set-root /cdrom.iso
    map --mem /cdrom.iso (0xff)
    chainloader (0xff)

    title Start the existing CD (cd0)
    chainloader (cd0)

    title Start virtual hard disk
    find --set-root /boot/hdd.img
    map /boot/hdd.img (hd)
    chainloader (hd-1)

    title Start virtual hard disk (loaded into memory)
    find --set-root /boot/hdd.img
    map --mem /boot/hdd.img (hd)
    chainloader (hd-1)

    title starts the existing hard disk (hd0)
    chainloader (hd0)

    title starts other menus
    configfile /efi/grub/menu2.lst

    title Start Linux Porteus 5.0 x86_64 openbox
    kernel /porteus/vmlinuz copy2ram
    initrd /porteus/initrd.xz

    title command line
    commandline

    title Exit grub4dos
    exit_g4d

    title restart
    reboot

    title shutdown
    halt

 

alacran

ChangeLog_UEFI-Eng.txt Sample-menu-Eng.lst

Edited November 26, 2020 by alacran

[Atari800XL]

Alacran, thank you for starting this topic on MSFN.

This might be a dumb question, but I'll ask it anyways, maybe others wonder about this as well:

- Is it possible do do "hd multibooting" with Grub4UEFI? Like it is with Grub4Dos on MBR/BIOS systems?

Or have you read anything about this being developed for future versions? I can't wrap my head around this at the moment, but maybe something similar to Terabyte's BootItUEFI, or as I said, the "old" Grub4Dos? I guess this would involve hiding some partitions, etc.?

Thanks for your reply.

 

[jaclaz]

Sure it can be done.

It is not *another* boot manager, it is grub4dos extended to support UEFI (as opposed to BIOS).

A number of commands (see the post by Alacran) have been removed (as they have been made unneeded by the re-writing of some other commands) AND at the moment a number of grub4dos commands have not yet been implemented, while some concepts may have become obsolete because of different features of UEFI (as compared to BIOS), only as an example, chainloading a volume bootsector makes not any sense anymore, as to boot in UEFI you need to execute a (UEFI) loader.

You should consider it as "beta" or "experimental" and "in evolution".

jaclaz

[alacran]

My testing results with the grub4dos-0.4.6a_for_UEFI-2020-11-26:

I created a fixed size 2.3 GB VHD (unformated) on a partition of my internal HD, initialized it as MBR, then formated as Win 6.x MBR, first partition is 128 MB FAT-32 0C Active, and second is NTFS (the rest of the espace), by means of wimlib-clc I installed (on Compact LZX mode) the Mini-10-x64 on NTFS partition and created manually the Boot Files/folders on the FAT-32 partition, and edited both BCDs with BootIce, See attached pictures), latter made a new  Ramboot entry on old menu.lst (for grub4dos for MBR) as usuall for the VHD located on internal HD:

title 10x64-UEFI.vhd - SVBus  RAMDISK - 2.3 GB - map as (hd) for MBR boot
find --set-root --ignore-floppies /10x64-UEFI.vhd
map --top --mem /10x64-UEFI.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr

It booted very fine, not a single issue, so this confirms a VHD with 2 partitions (having boot files/folders on FAT-32 partition) is capable to Ramboot very fine (at least when MBR booting).

So far I have being able to UEFI boot Win10XPE_x64.ISO from internal HD or USB, this is my very simple menu.lst (good to start testing with the minimum features):

Quote

timeout 10
default 0

title Start Win10XPE_x64.ISO - UEFI boot
find --set-root /images/Win10XPE_x64.ISO
map /images/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title 10x64-UEFI.vhd SVBus  RAMDISK - UEFI boot
find --set-root /10x64-UEFI.vhd
map --mem /10x64-UEFI.vhd (hd)
chainloader (hd-1)

title start Grub2 menu
find --set-root /EFI/Boot/BOOTX64.EFI
chainloader /EFI/Boot/BOOTX64.EFI

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt

NOTE-1: CSM and Secure Boot are disabled, menu.lst is located on: \EFI\grub\menu.lst; \images\Win10XPE_x64.ISO is on FAT-32 partition; 10x64-UEFI.vhd is on the root of a NTFS partition, BOOTX64.EFI from grub4dos for UEFI was renamed to g4ex64.efi and copied to: \EFI\Boot\g4ex64.efi and an alternative UEFI boot option pointing to it was created on UEFI using BootIce, used when booting from internal HD, not required when booting from USB

Win10XPE_x64.ISO boots very fine with no issues from USB or internal HD

10x64-UEFI.vhd do not boot from USB or internal HD, even if using (hd0,1), (hd1,1) or (hd2,1)/10x64-UEFI.vhd, it looks like the NTFS partitions can't be accessed/readen by grub4dos for UEFI.

NOTE-2: This were all MBR partitions, but also tried making a GPT partitioned USB device and botting from it got same results, 10x64-UEFI.vhd is not found on the GPT NTFS of this USB.

Also noticed the entry:

title shutdown
halt

Makes the PC reboot not shutdown

alacran

 

Edited December 2, 2020 by alacran

[Atari800XL]

Alacran,

If you have any idea for me to test HD multibooting (eg. several Windows 10 installs on separate partitions) on a GPT disk, please let me know. I have a spare laptop for testing.

I really only tested Terabyte BootItUEFI on GPT once (didn't really like complicated setup), but from this test I learned that I only need one FAT32 EFI system partition, then as many NTFS partitions as I wanted for multibooting.

If you find any menu.lst entries for that anywhere (on this or the other forums), I would be happy to test.

 

[alacran]

Hi my friend, nice to see you around.

Excuseme but I don't see how grub4dos for UEFI may be required for that pourpose, to start it is not Secure Boot capable.

To do what you want IMHO you may try just creating first all the required NTFS partitions and use WinNTSetup to install the OS on each partion and let it create or edit (as required) the BCD entries for each location, also BootIce could be usefull to edit those entries names to easy diferenciate each one. When you run WinNTSetup the Hidden and with no letter ESP partition is then visible as Z: and then you can use BootIce to edit the Z:\EFI\Microsoft\Boot\BCD, before close WinNTSetup, other option is PartitionGuru which let you assing a temporary letter to the Hidden ESP partition.

Or even easier just make VHDs or VHDXs with different names and use WinNTSetup to install the OS on each one and let it create or edit (as required) the BCD entries for each location.

alacran

Edited November 29, 2020 by alacran

[alacran]

I decided to run another test, this time the VHD is located into VHD folder on the root of the second (MBR) NTFS primary partition of the second internal HD.

Using this menu.lst entries (usefull also to check if Gziped files can be loaded to Ram as in the MBR version).

Quote

timeout 10
default 0

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

title 10x64-UEFI.vhd.gz SVBus  RAMDISK for UEFI boot from HD -1
find --set-root /VHD/10x64-UEFI.vhd.gz
map --mem /VHD/10x64-UEFI.vhd.gz (hd)
chainloader (hd-1)

title 10x64-UEFI.vhd SVBus  RAMDISK for UEFI boot from HD -2
find --set-root /VHD/10x64-UEFI.vhd
map --mem /VHD/10x64-UEFI.vhd (hd)
chainloader (hd-1)

title grubfm x64 EFI Boot Manager of a1ive
find --set-root /efi/boot/grubfmx64.efi
chainloader /efi/boot/grubfmx64.efi

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt

No luck, with any of both options for the VHD, I got this message (See attached picture):

(hd0,1)

Out of memory

boot_image_handle not found

Press any key to continue....

My comments about the message:

(hd0,1) Seems OK, this means the VHD was located, since I'm booting from the only valid UEFI device and the VHD is located then on (hd0,1).

Out of memory this is not possible, something is wrong here, this PC has 8 GB of Ram and the VHD is only 2.3 GB

boot_image_handle not found I don't understand the meaning of this message.

NOTE: Sorry for the photo quality, it was made with the celphone.

alacran

Edited November 29, 2020 by alacran

[Atari800XL]

Thank you for your reply, Alacran.

I understand the points you made, but to me it would still be useful if Grub4UEFI could support my scenario on GPT, similar to the way I use Grub4DOS on MBR now (and have done for years). I like to have a few Windows operating systems on seperate (indepentant/ hidden) partitions. For example: one for "work", one for dev, one for testing, etc. I also liked the Grub4Dos/ GFXCustomizer boot menus (as I've mentioned before).

I would also like to reverse the question: "Why would Grub4UEFI -not- support it?".

When the different OS's are independent and invisible from each other, it's easier to make OS image backups (Terabyte, etc.).

Thanks again for your reply, I know you're more interested in the VHD approach, but I hope that if you ever find some hints to my desired solutions, you will share it with us in this or other topics, as I'm sure you will. I hope you're having fun booting!

[Tripredacus]

I have a different question and perhaps I am just mixing up terms. Would this allow DOS to boot in UEFI?

[jaclaz]

31 minutes ago, Tripredacus said:

I have a different question and perhaps I am just mixing up terms. Would this allow DOS to boot in UEFI?

No.

DOS needs BIOS services/interrupts (like "conventional" grub4dos).

jaclaz

[alacran]

On 11/30/2020 at 9:15 AM, Tripredacus said:

I have a different question and perhaps I am just mixing up terms. Would this allow DOS to boot in UEFI?

No, this is only valid to run under UEFI environment, so to try to run something, it has to be UEFI capable. And as jaclaz just said DOS is not UEFI capable.

On 11/30/2020 at 9:48 AM, jaclaz said:

No.

DOS needs BIOS services/interrupts (like "conventional" grub4dos).

jaclaz

IMHO in fact the name is not really appropiate, also many people on wuyou.net forum think same way, some of them have suggested to rename it to grub4efi or grub4uefi.

Almost all code has being rebuild and many features do not exists anymore, some because they do not apply on UEFI environment and other because haven't being developed yet, as an example it lacks map --mem --top command, very useful to Ramboot VHDs (having SVbus driver installed) on MBR/CSM machines; from the author on Release Notes:

Quote

2020-10-29 (yaya)
  GRUB4DOS for UEFI environment.
 
  This is a huge project, almost all the code has been stroked. Modified console keyboard input and output, console screen output, memory control,
  Drive control, get date and time, pause control, graphics mode and Unicode font implementation, PXE net start, etc.
 
  During the development process, the GRUB2 source code was referenced. For the mapping, refer to the source code of wintoflash.
 
  1. You can start efi files.
  2. You can start iso and img files.
  3. Built-in hot key function. Example: setmenu --hotkey parameter
 
  Differences from the old version:
  1. You can view the graphics modes supported by the system through the graphicsmode command.
  2. Mount after the map function is executed. There is no need to execute the --hook command.
  3. Cancel the --hook, --unhook, --rehook, --unmap=, --floppies=, --harddrives= commands.
  4. In the UEFI environment, you can boot from a disk other than 0x80, so there is no need to swap disk operations, such as map (hd0) (hd1).
  5. Cancel the delete disk function, such as map (hd1) (hd1).
  6. Currently, PXE Netstart only supports tftp.

Basically I think there isn't any technical reason to keep using the name grub4dos since almost all code is totally different.  So far the only commands (shared with MBR version) I have tested are: find --set-root, map, map --mem, commandline, reboot and halt.

Keep using the grub4dos name creates a lot of confussion, also some people has suggested to rename the menu.lst config file to menu.efi. or efi.menu, but just putting it on \EFI\grub\menu.lst lets us avoid confussion in this case.

This UEFI version can't be installed on MBR or PBR, do not require to use the grld file, also there is not a file grldr.mbr file which allowed us to run grub4dos from the MS  bootmgr on MBR/CSM machines, and the grub.exe file that was used to run grub4dos from grub2 do not exists anymore.

On the UEFI version only the BOOTX64.EFI (on \EFI\Boot\BOOTX64.EFI [which I renamed to g4ex64.efi to let it coexists with the MS bootx64.efi]) and the menu.lst files located on a FAT-32 partition are required.

To run it from grub2 on UEFI environment I use:

if [ "${grub_platform}" == "efi" ]; then

    if [ -e "/efi/boot/g4ex64.efi" ]; then
    menuentry "grub4dos for UEFI" {
      chainloader /efi/boot/g4ex64.efi
    }
    fi

And to go back to grub2 we can use:

exit_g4d

alacran

Edited December 2, 2020 by alacran

[jaclaz]

Still, in a perfect world, it is in theory possible to emulate BIOS in UEFI, not entirely unlike what CSM does on most "dual" UEFI/BIOS firmwares, at least for the basic functions that DOS requires.

A sort of "reversed" Clover.

The whole point that the Intel (and associates) guys used to sell us[1] the stupid EFI/UEFI crap[2] was that it was essentially an operating system on chip and that *everything* was possible in this environment.

Now, more than 10 (ten) years have passed (actually almost 15),  and we evolved from a very limited boot environment that could only execute a bunch of assembler, consisting ONLY of MBR code, PBR code and bootloader/bootmanagers to a powerful environment that can run *anything* BUT for which essentially only bootloaders/bootmanagers exist (and was it not for our friend PBatard - Author of Rufus among other things - we would also be limited to FAT32 ):

https://github.com/pbatard/uefi-ntfs

In a nutshell, the possibilities are out there, and hopefully - before or later - someone will take the challenge.

jaclaz

 

[1] please read a "force down our throats"  
[2] not only crap in itself, crap worsened by arbitrary overlays of uneeded complications and limitations, the perfect example of "committee design" worsened by the de facto monopolistic power of some of the components of the committee

[alacran]

The UEFI version is also capable to load to Ram files compressed as *.gz or *.lz4, same as the MBR version does, just tested with the following menu.lst entries:

Quote

title Start Win10XPE_x64.ISO.gz
find --set-root /images/Win10XPE_x64.ISO.gz
map --mem /images/Win10XPE_x64.ISO.gz (0xff)
chainloader (0xff)

title Start Win10XPE_x64.ISO.lz4
find --set-root /images/Win10XPE_x64.ISO.lz4
map --mem /images/Win10XPE_x64.ISO.lz4 (0xff)
chainloader (0xff)

title Start /Isos/pcunlocker.iso.gz   >>> This boots by means of a WinPE, it is originaly located on first MBR HD partition 4 (first logical partition) (hd0,4)
find --set-root /Isos/pcunlocker.iso.gz 
map --mem /Isos/pcunlocker.iso.gz (0xff)
chainloader (0xff)

title Start /Isos/AcronisTrueImage.iso.gz  >>> This is based on a Linux, and it is originaly located on second MBR HD partition 4 (first logical partition) (hd1,4)
find --set-root /Isos/AcronisTrueImage.iso.gz
map --mem /Isos/AcronisTrueImage.iso.gz (0xff)
chainloader (0xff)

The grub4dos for UEFI \EFI\Boot\BOOTX64.EFI (renamed to g4ex64.efi) is located on MBR (hd1, 0) which has a FAT-32 0C Primary partition where the EFI files/folders reside, of course during UEFI booting the HDs order is swap and becomes (hd0,0) as it is the only UEFI capable (seen then as first HD).

All of them were loaded to Ram and booted very fine.

But linuxmint-19.3-cinnamon-64bit.iso didn't boot fine, I used this entry to try to boot it:

Quote

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso   >>> Originaly located on second MBR HD partition 4 (first logical partition) (hd1,4)
find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso
map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso
chainloader (0xff)

alacran