GRUB4DOS for UEFI

New version working fantastic.

Go to my issue Report: https://github.com/c...4dos/issues/248

Almost at the very end of it you will find a message from yaya, download the BOOTX64.rar.txt, delete the .txt and extract the new version, he allready implemented the map -- mem --top and now it is possible to load files to the top memory like on MBR version, I just tested it Rambooting a 2 partitions VHD of 2.3 GB and it booted very fine.

I assume it will be officially released very soon.

alacran

@ wimb

On my PC firmware on Advanced Mode on the section Advanced >>> System Agent configuration is located Memory Remap Feature which allows to enable remaping the memory above 4 GB.  I think you should check your MB manual as in your case (if this feature exists) it could be on other location.

alacran

On my PC firmware on Advanced Mode on the section Advanced >>> System Agent configuration is located Memory Remap Feature which allows to enable remaping the memory above 4 GB.  I think you should check your MB manual as in your case (if this feature exists) it could be on other location.

 

Thanks alacran 

I found the Memory Remap option now and it was already Enabled in my case.

Nice to hear that latest UEFI Grub4dos version with the --top switch is working so well for you.

You know I thought already that the missing --top option could be part of the boot problem.

What occurs when you first boot with Grub2 and then chainload UEFI Grub4dos  ?

What occurs when you first boot with Grub2 and then chainload UEFI Grub4dos  ?

So far all my test with the new version were booting directly to G4E and with Secure Boot disabled. I'll do it and report back,

alacran

Booting to grub2 and chainloading to G4E:

It Rambooted the 2.3 GB VHD fine, just as before.

alacran

@ a1ve

On wuyou.net on this post: http://bbs.wuyou.net...652&pid=4189576

There is attached a signed version of SVBus v1.2, the file is SVBus_V1.2_20200428.rar. Could you share it with us, please?

Thanks in advance

alacran

JFYI

I found an interesting and usefull info on this post: http://bbs.wuyou.net...652&pid=4191192

It was translated to English using Google translate for your convenience:

 

liuzhaoyzz
To
699#
Posted on Yesterday 22:41 From Mobile Phone | Just look at the author

     A Jiangnan onion Published on 2020-12-8 20:51
     How to eliminate vhd fragments?


Method one, copy and paste the vhd, the copy is free of fragments, provided that the hard disk has enough free space for moving.

Method two, directly use wincontig to analyze and organize files. The premise is that the hard disk has enough free space.

Generally speaking, the above method is effective for mechanical hard drives. It is not necessarily effective for SSD, because SSD has an intermediate layer of FTL logic conversion circuit, and SSD directly copies files into the grid, which should be continuous.

I can confirm, making a copy of the VHD eliminated all the virtual Floppies, CD units and VHDs created into my VHD.

I haven't tested the defragmenting method yet. But I assume Defraggler should work too.

alacran

@ a1ve

 

On wuyou.net on this post: http://bbs.wuyou.net...652&pid=4189576

 

There is attached a signed version of SVBus v1.2, the file is SVBus_V1.2_20200428.rar. Could you share it with us, please?

 

Thanks in advance

 

alacran

https://drive.google...iew?usp=sharing

I have modified grub2 so that it also creates grub4dos drive map info, please test.

https://drive.google...iew?usp=sharing

map --mem --rt /xxx.vhd

 

https://drive.google...iew?usp=sharing

 

I have modified grub2 so that it also creates grub4dos drive map info, please test.

https://drive.google...iew?usp=sharing

map --mem --rt /xxx.vhd

Thanks for sharing the file my friend, but I can't download the SVBus-signed.zip file, Google Drive message says it is infected by a virus and only the owner can download it, very possible it's only a false positive, then please compress it with a Pasword to avoid this issue.

Just downloaded your modified grub2, thanks, If I understood fine this grubx64.efi version is now capable to Ramboot a VHD, am I right?

Only need some help to translate this entry from menu.lst to grub.cfg to test the modified grubx64.efi:

title Mini-10-UEFI.vhd (2360 MB) SVBus RAMDISK UEFI boot from HD
find --set-root /VHD/Mini-10-UEFI.vhd
map --mem --top /VHD/Mini-10-UEFI.vhd (hd)
chainloader (hd-1)

Is this the right sintax on new grubx64.efi?

if [ -e (hd0,msdos2)/VHD/Mini-10-UEFI.vhd ]; then
menuentry "Ramboot Mini-10-UEFI.vhd from (hd0,msdos2)/VHD/Mini-10-UEFI.vhd" {
 root (hd0,msdos2)

 map --mem --rt /VHD/Mini-10-UEFI.vhd (hd)
  chainloader (hd-1)
}
fi

Or I need to modify it?

alacran

Thanks for sharing the file my friend, but I can't download the SVBus-signed.zip file, Google Drive message says it is infected by a virus and only the owner can download it, very possible it's only a false positive, then please compress it with a Pasword to avoid this issue.

 

Just downloaded your modified grub2, thanks, If I understood fine this grubx64.efi version is now capable to Ramboot a VHD, am I right?

 

Only need some help to translate this entry from menu.lst to grub.cfg to test the modified grubx64.efi:

 

title Mini-10-UEFI.vhd (2360 MB) SVBus RAMDISK UEFI boot from HD
find --set-root /VHD/Mini-10-UEFI.vhd
map --mem --top /VHD/Mini-10-UEFI.vhd (hd)
chainloader (hd-1)

 

Is this the right sintax on new grubx64.efi?

 

if [ -e (hd0,msdos2)/VHD/Mini-10-UEFI.vhd ]; then
menuentry "Ramboot Mini-10-UEFI.vhd from (hd0,msdos2)/VHD/Mini-10-UEFI.vhd" {
 root (hd0,msdos2)

 map --mem --rt /VHD/Mini-10-UEFI.vhd (hd)
  chainloader (hd-1)
}
fi

 

Or I need to modify it?

 

alacran

https://drive.google...iew?usp=sharing

password: reboot.pro

Execute the following command in the grub2 terminal:

map --mem --rt /VHD/Mini-10-UEFI.vhd
boot

 

https://drive.google...iew?usp=sharing

password: reboot.pro

 

Execute the following command in the grub2 terminal:

map --mem --rt /VHD/Mini-10-UEFI.vhd
boot

Thanks, I will try it now and comment back.

alacran

Testing modified grub2 (grubx64.efi) Rambooting VHDs

The sugested commands:

map --mem --rt /VHD/Mini-10-UEFI.vhd
boot

Didn't work fist time as VHD/Mini-10-UEFI.vhd is located on the UEFI bootable HD, second partition, so it didn't found it.

To make things simple I copied it to UEFI bootable FAT-32 first partition root and used this command:

map --mem --rt /Mini-10-UEFI.vhd
boot

It Rambooted very fine, this was a 2,046 MB VHD, then copied to same drive the 2,360 MB (2.3 GB) version to VHD folder, and used following commands:

map --mem --rt /VHD/Mini-10-UEFI-2.vhd
boot

It also Rambooted fine, not a single issue.

I can confirm this modified grubx64.efi is capable to Ramboot a VHD just exactly as grub4dos for UEFI.  Congratulations my friend!!!!

I have 2 questions:

On my spanish keyboard some letters and simbols are located on diferent location, and also typing is very prone to commit mistakes, how can I create and run a pre-made config file for this version?

Note: Please see post No. 114 for additional info about this request.

As I want to be able to Ramboot the VHDs with both options, I need a few more info about this:

grub4dos for UEFI is capable to load on Ram *.gz and *.lz4 compresed files (or VHDs in this case), is your modified grubx64.efi capable to do that too?

Thanks for sharing with us your new grub2 version.

alacran

 

https://drive.google...iew?usp=sharing

password: reboot.pro

 

Execute the following command in the grub2 terminal:

map --mem --rt /VHD/Mini-10-UEFI.vhd
boot

Testing modified grub2 (grubx64.efi) Rambooting VHDs

 

I have modified grub2 so that it also creates grub4dos drive map info, please test.

https://drive.google...iew?usp=sharing

It works for me as well in Super UEFI Secure booting modified Grub2 and then Mini10_SV.vhd booting from RAMDISK using SVBus driver

I have tested it with the unsigned SVBus driver, so that I needed to use F8 to allow unsigned driver.

Next will be to use the signed SVBus driver.

Very Good a1ive   

To run previous test using the boot override key (F8) I booted to Grub2: \EFI\Boot\BOOTX64.EFI, taken from USB_FORMAT by wimb and adapted the grub.cfg to my preferences:

This is my current \grub\grub.cfg:

set timeout=30
set default=0

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

set prefix=($root)/grub

set iso_drive=""

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

	if [ -e "/efi/boot/bootx64_win.efi" ]; then
	menuentry "Windows EFI BootManager - efi/boot/bootx64_win.efi" {
	  chainloader /efi/boot/bootx64_win.efi
	}
	fi
	
	if [ -e "/efi/boot/grubx64.efi" ]; then
	menuentry "Terminal de grub2 modificado por a1ive - efi/boot/grubx64.efi" {
	  chainloader /efi/boot/grubx64.efi
	}
	fi
	
	if [ -e "/efi/boot/bootx64_g4d.efi" ]; then
	menuentry "UEFI Grub4dos efi/boot/bootx64_g4d.efi" {
	  chainloader /efi/boot/bootx64_g4d.efi
	}
	fi

	if [ -e "/efi/microsoft/boot/bootmgfw.efi" ]; then
	menuentry "Windows EFI BootManager efi/microsoft/boot/bootmgfw.efi" {
	  chainloader /efi/microsoft/boot/bootmgfw.efi
	}
	fi

	if [ -e "/efi/boot/grubfmx64.efi" ]; then
	menuentry "grubfm x64 EFI Boot Manager of a1ive" {
	  chainloader /efi/boot/grubfmx64.efi
	}
	fi
fi

if [ -e "/grub/glim/main.cfg" ] -a [ -e "($root)/iso" ];  then
menuentry "GRUB Live ISO Multiboot - ($root)/iso" {
  configfile "/grub/glim/main.cfg"
}
fi

if [ -e (hd0,msdos1)/images/Linux_ISOS.txt ]; then
menuentry "Linux ISO in (hd0,msdos1)/images - /grub/grub_Linux.cfg" {
  set iso_drive=(hd0,msdos1)
  export iso_drive
  configfile /grub/grub_Linux.cfg
}
fi

if [ -e (hd0,msdos2)/images/Linux_ISOS.txt ]; then
menuentry "Linux ISO in (hd0,msdos2)/images - /grub/grub_Linux.cfg" {
  set iso_drive=(hd0,msdos2)
  export iso_drive
  configfile /grub/grub_Linux.cfg
}
fi

if [ -e (hd1,msdos1)/images/Linux_ISOS.txt ]; then
menuentry "Linux ISO in (hd1,msdos1)/images - /grub/grub_Linux.cfg" {
  set iso_drive=(hd1,msdos1)
  export iso_drive
  configfile /grub/grub_Linux.cfg
}
fi

if [ -e (hd1,msdos2)/images/Linux_ISOS.txt ]; then
menuentry "Linux ISO in (hd1,msdos2)/images - /grub/grub_Linux.cfg" {
  set iso_drive=(hd1,msdos2)
  export iso_drive
  configfile /grub/grub_Linux.cfg
}
fi

if [ -e "/AIO/grub/grub.cfg" ]; then
menuentry "AIO Menu - /AIO/grub/grub.cfg" {
  set prefix=($root)/AIO/grub
  configfile /AIO/grub/grub.cfg
}
fi

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

	if [ -e "/efi/boot/org-bootx64.efi" ]; then
	menuentry "Original x64 EFI" {
	  chainloader /efi/boot/org-bootx64.efi
	}
	fi

	if [ -e "/efi/boot/grubfmia32.efi" ]; then
	menuentry "grubfm x86 EFI Boot Manager of a1ive" {
	  chainloader /efi/boot/grubfmia32.efi
	}
	fi

	if [ -e "/efi/boot/org-bootia32.efi" ]; then
	menuentry "Original x86 EFI" {
	  chainloader /efi/boot/org-bootia32.efi
	}
	fi
fi

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

	if [ -e "/grub.exe" ]; then
	menuentry "Grub4dos Menu" {
		linux /grub.exe
	}
	fi

	if [ -e (hd0,msdos1)/bootmgr ]; then
	menuentry "Windows Boot Manager 7/8/10 - (hd0,msdos1)/bootmgr on MBR harddisk" {
	  root=(hd0,msdos1)
	  ntldr (hd0,msdos1)/bootmgr
	}
	fi

	if [ -e (hd1,msdos1)/bootmgr ]; then
	menuentry "Windows Boot Manager 7/8/10 - (hd1,msdos1)/bootmgr on MBR harddisk" {
	  root=(hd1,msdos1)
	  ntldr (hd1,msdos1)/bootmgr
	}
	fi

	if [ -e (hd2,msdos1)/bootmgr ]; then
	menuentry "Windows Boot Manager 7/8/10 - (hd2,msdos1)/bootmgr on MBR harddisk" {
	  root=(hd2,msdos1)
	  ntldr (hd2,msdos1)/bootmgr
	}
	fi

	if [ -e (hd3,msdos1)/bootmgr ]; then
	menuentry "Windows Boot Manager 7/8/10 - (hd3,msdos1)/bootmgr on MBR harddisk" {
	  root=(hd3,msdos1)
	  ntldr (hd3,msdos1)/bootmgr
	}
	fi

	menuentry "Windows Boot Manager 7/8/10 - MBR BIOS mode search /bootmgr" {
	  search --no-floppy --file /bootmgr --set root
	  ntldr /bootmgr
	}

	menuentry "Reboot Main Menu" {
	  chainloader (hd0)+1
	}
fi


if [ "${grub_platform}" == "efi" ] -a [ -e "/EFI/BOOT/BOOTx64.EFI" ]; then
	menuentry "Reboot EFI Main Menu" {
	  chainloader /EFI/BOOT/BOOTx64.EFI
}
fi

menuentry "Power Off" {
  halt
}

menuentry "Reboot" {
  reboot
}

As you can see I added (as second) this menuentry on it (here translated to English for your convenience):

    if [ -e "/efi/boot/grubx64.efi" ]; then
    menuentry "Grub2 terminal by a1ive - efi/boot/grubx64.efi" {
      chainloader /efi/boot/grubx64.efi
    }
    fi

But no matter there is:

set timeout=30
set default=0

I don' see this menu and grubx64.efi boots directly on Grub2 terminal by a1ive.

What I would like is to call it on demand not automatically, and if possible make a grub.cfg for it, to let me add there the menuentries for my VHDs, maybe relocating it to some other folder, to avoid running it automatically.

Ideas/suggestions are wellcome.

alacran

the new grubx64.efi expects in EFI partition file \boot\grub\grub.cfg

In that case I get grub menu 

First let me tell you I'm glad the new grubx64.efi worked fine for you, I was terribly sorry the last G4E didn't work for you, maybe a1ive made certain adjustments/modifications to the code and the mapping on Ram is working better on his grubx64.efi then let's hope he comments this with yaya and that code can be adapted to G4E too.

Now talking about your previous post:

So you mean make \EFI\grub\grub.cfg just next to  \EFI\grub\menu.lst   WRONG

Thanks, I'll try this way, making a config file for the new grubx64.efi.

And will try to adapt/translate to grub2 the menu entries I have on the \EFI\grub\menu.lst to be consistent.

But what about call it on demand not automatically, do you have any ideas/suggestions for this?

alacran

No 

You need to have \boot\grub\grub.cfg as configfile for new grubx64.efi

No 

 

You need to have \boot\grub\grub.cfg as configfile for new grubx64.efi

Sorry to bother you so much with this, to make things more clear to me:

Attached a photo of my FAT-32 UEFI bootable partition, which also have everything to MBR boot too, as the idea is copy it latter on a USB device capable to boot as MBR or UEFI. Of course it is possible some things may need to be adapted to USB use.

On the root there is a Boot folder. >>>  Then \boot\grub\grub.cfg means into this folder where MS MBR boot files/folders are.

Also attached a photo of the EFI folder content, where there is also a Boot folder.  >>> As I understand \boot\grub\grub.cfg will not be located here.

alacran

Yes, you are right, this will give Grub2 Menu for new grubx64.efi

Bu I cannot use menuentry to boot Mini10_SV.vhd

I need to use Grub2 terminal command

@a1ive

In Grub2 terminal I can boot Mini10_SV.vhd from RAMDISK using command

map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd
boot

Note that there is also - interesting for you I think, but there is no problem in Grub2 booting

write grub4dos ...

failed to allocate memory

I cannot use menuentry in \boot\grub\grubcfg to boot Mini10_SV.vhd

I need to use Grub2 terminal command as given above and have added/replaced signed SVBus driver

==  == 

EDIT: removed (hd) in command

Yes, you are right, this will give Grub2 Menu for new grubx64.efi

 

Bu I cannot use menuentry to boot Mini10_SV.vhd

 

I need to use Grub2 terminal command

Thanks for confirming it.

Then the config menu is not very useful, and this means I will have to rename my VHD files with shorter and more precise names to identify and remember them easier, unless this new grubx64.efi is only a test version and will be re-coded latter to acept this new command from the menuentry.

For now I will use:

10.vhd >>> For the Mini-10x64

10WB.vhd >>> For the Wimboot Mini-10x64

10PE.vhd  >>>  For the Win10XPE_x64.vhd  >>> I have a modded LZX compact install on VHD.

10PE.iso>>> For the Win10XPE_x64.ISO  >>>  which by the way we haven't tested with this new command.

alacran

@a1ive

 

In Grub2 terminal I can boot Mini10_SV.vhd from RAMDISK using command

map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd (hd)
boot

Note that there is also - interesting for you I think, but there is no problem in Grub2 booting

write grub4dos ...

failed to allocate memory

 

I cannot use menuentry in \boot\grub\grubcfg to boot Mini10_SV.vhd

I need to use Grub2 terminal command as given above and have added/replaced signed SVBus driver

 

UEFI_Grub2_RAMDISK_IMG_20201209_093955.jpg == Mini10_SV_RAMDISK_2020-12-09_094334.jpg == Mini10_SV_UEFI_Grub2_RAMDISK_2020-12-09_111919.jpg

Good News, After adding Signed SVBus driver than I can use menuentry in grub.cfg

UEFI Grub2 Booting Mini10 VHD from RAMDISK is working OK from \boot\grub\grub.cfg menu when signed SVBus driver is used

menuentry "Mini10_SV.vhd from RAMDISK" {
  map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd
  boot
}

EDIT: removed (hd) in menuentry

@a1ive

 

In Grub2 terminal I can boot Mini10_SV.vhd from RAMDISK using command

map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd (hd)
boot

Note that there is also - interesting for you I think, but there is no problem in Grub2 booting

write grub4dos ...

failed to allocate memory

 

I cannot use menuentry in \boot\grub\grubcfg to boot Mini10_SV.vhd

I need to use Grub2 terminal command as given above and have added/replaced signed SVBus driver

 

UEFI_Grub2_RAMDISK_IMG_20201209_093955.jpg == Mini10_SV_RAMDISK_2020-12-09_094334.jpg == Mini10_SV_UEFI_Grub2_RAMDISK_2020-12-09_111919.jpg

this is not correct, no "(hd)".

map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd
boot

did you load grub2 from grub4dos? Using grub2/grub4dos nested under UEFI, the virtual disk created by "map" command may not be recognized by svbus and problems may occur.

I Rambooted manually using new grubx64.efi the Mini-10x64.vhd of 2.3 GB and this time I looked carefully the screen before running boot command, in my case there is no Failed to allocate on memory (as on wimb photo).

On allocating memory it reported 100% and latter on whrite grub4dos drive map slot it reported 99% but no failure reported.

NOTE: This PC has 8 GB of Ram.

I made another discovery since yesterday but talking about other things forgot to comment it, I'm stil using on this VHD the unsigned version 1.2 of SVBus driver and after first boot I found there is no need on future boots to keep enabled Test Mode (Testsigning) or No integrity checks or LoadOptionsString DISABLE_INTEGRITY_CHECKS on EFI BCD. See attached picture.

alacran

this is not correct, no "(hd)".

map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd
boot

did you load grub2 from grub4dos? Using grub2/grub4dos nested under UEFI, the virtual disk created by "map" command may not be recognized by svbus and problems may occur.

You are right, the (hd) should be removed from the Grub2 command

Repeated to boot without (hd) and the write grub4dos ....failed to allocate memory message is still present

UEFI Grub4dos is also as file EFI\Boot\bootx64_g4d.efi present which can be chainloaded from Grub2 menu, but is not used when booting Mini10_SV.vhd from Grub2

Strange that UEFI Grub4dos somehow interferes with Grub2 booting in this case ...

I presume the write grub4dos message must be somewhere in your Grub2 code ....

I don't load Grub2 from UEFI Grub4dos

I use Super UEFI Grub2 and then your grubx64.efi is renamed and used as grubx64_real.efi