grub4dos for UEFI

[jaclaz]

10 hours ago, alacran said:

I'm also aware the internal menu.lst of grub4dos for MBR can be modiffied very easy with BootIce if required to point to find the external main menu.lst on other location or to a renamed *.lst file.

But as I have readen, to do same thing on the UEFI version it has to be done on the source code, and recompile it.

Which is good, but completely unrelated, since my note (and method) is NOT AT ALL about the "embedded" menu.lst in grub4dos, it is about embedding booting commands in the target .iso (or .vhd, or .img, etc.).

10 hours ago, alacran said:

Anyway IMHO we should respect the guidances from the author/developer about what commands are valid or not on this new version.

I think you are still missing the point (which is about compatibility), sure we should use the right commands, but by having a non-existing command produce a warning (and/or  a non-blocking error) the non-existing command can remain where it is.

jaclaz

[alacran]

Just made a 2046 MB VHD with same partition layout and installed on Compact LZX mode my Mini-10x64 on it and it Rambooted flawlessly on UEFI, This probes I was right when I said there is a 2 GB limit imposed to items loaded on Ram on versions grub4dos-0.4.6a_for_UEFI-2020-11-26 and 2020-12-05

I opened an issue on https://github.com/chenall/grub4dos/issues

Related to can't map --mem more than 2 GB on Ram: https://github.com/chenall/grub4dos/issues/248

alacran

[alacran]

It seems I found the possible cause of the issue:

Once Rambooting from a 2046 MB (just 2 MB smaller than 2 GB) VHD there are 3 virtual floppy drives (A:, B: and M:) + 2 virtual CDs (N: and O:) + 2 VHDs (they appear as un-inicialized) all of them related to SVBus, see attached pictures please.

I don't have any resolution set on my menu.lst, after Rambooting and once on desktop the OS resolution is very low and it can't be changed.

alacran

[alacran]

Just to make sure it was not an issue created by a possible mistake I committed, I deleted all the VHDs used for testing since 2020-11-26 version and created a new 900 MB Win10XPE_x64.vhd FAT-32 single partition VHD just extracting the ISO to it, and also a 1088 MB 2 partitions Mini-10-UEFI-WB.vhd (WimBoot VHD), both are booting fine but the virtual Floppies, CDs and VHDs are present too on this new Mini-10-UEFI-WB.vhd.

If Rambooting Mini-10-UEFI-WB.vhd on MBR all is fine (no virtual devices on it), then there is no dubt they are created by the UEFI version of grub4dos during loading to Ram.

And now I have a new issue, during this new tests I was UEFI booting from the Win10XPE_x64.ISO to make certain editions to the menu.lst and copying some files. etc, it was booting very fine more than 5 times until it do not fully load anymore, the loading line remains forever about 1/3 from the beginig and never moves, replaced it with the copy on my USB and same thing, tryed with and old version and then the classic message boot_image_handle not found, so now it can load any other ISO but not that one (from any partition, as tried several).

Also there is no way I can setup the resolution on this PC, If I put colors or set a resolution, then the screen is colored and with no letters on it.

At least now it is 1024x768 (just by itself) because it was 800x600 before, anyway once the WB VHD or the PE VHD boot, the resolution (1024x768) can't be changed, This 22 inches screen standard resolution is 1920x1080, but I usually have it set to 1600x900 on everyday use.

Also the halt commad makes the PC reboot.

Then I could say:

This new version is working better than previous, it is a great achievement to Ramboot by means of SVBus as I can confirm.

But there are still many things to fix, let's be patient, I'm sure in a few months the VHD Ramboot will be working as fine as the MBR version, yaya, a1ve, sunsea and many others including Ventoy author are actively posting comments and ideas on the topic on wuyounet forum.

In the mean time we could help testing every new version to give them feedback with our findings.

@ wimb

I suggest you to make a Win10XPE_x64.vhd FAT-32 single partition VHD (maybe 900 MB to 1 GB depending of the size of your ISO to start testing Ramboot, don't forget to delete the CDUsb.y file on the VHD or you will have problems during booting, this is just to make sure your PC UEFI firmware allows you to boot from it.

If this goes fine you should try latter a Mini-10 Wimboot install on a 1088 MB 2 partitions VHD wich is working fine on my PC. Maybe you are luckier and you don't get the extra virtual devices I get here.

alacran

[alacran]

Having the VHD attached, I created the boot files/folders with this command bcdboot L:\Windows /s K: /f ALL and latter edited the BCDs with BootIce.

alacran

 

Edited December 7, 2020 by alacran

[alacran]

New version working very fine.

Go to my issue Report: https://github.com/chenall/grub4dos/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 extrac the new version, he allready implemented the map -- mem --top and now it is possible to load files to the top memory just as on MBR version I just tested it Rambooting a 2 partition VHD of 2.3 GB and it booted very fine.

I assume it will be officially released very soon.

alacran

[wimb]

New from a1ive UEFI Grub2 that can be used for booting Mini10 VHD from RAMDISK.

Download:  latest Grub2 of a1ive has support for svbus

More Info: UEFI Grub2 at reboot.pro in Grub4dos for UEFI topic

In Admin Command Window use Diskpart to make VHD which needs to have MBR and 2 partitions - 100 MB FAT32 + rest NTFS

create vdisk file="D:\VHD\Mini10_SV.vhd" maximum=3900 type=fixed
select vdisk file="D:\VHD\Mini10_SV.vhd"
attach vdisk
create partition primary size=100
format quick fs=fat32 label="EFI_VHD1"
assign
active
create partition primary
format quick fs=ntfs label="Mini10_SV_VHD2"
assign
list vol
exit

Signed SVBus driver from a1ive is needed to allow using grub.cfg menuentry - Password=reboot.pro

otherwise grub2 commands must be used and allow unsigned SVBus driver by F8 menu

UEFI grubx64.efi located in EFI\Boot expects as configfile \boot\grub\grub.cfg

EFI\Boot folder according to UEFI_MULTI-50 with UEFI_MAN\efi\Boot where grubx64_real.efi is replaced by new a1ive UEFI Grub2 file

Grub2 command to get menu

configfile /boot/grub/grub.cfg

Grub2 menuentry in grub.cfg

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

   

Edited December 9, 2020 by wimb

[alacran]

Attached the Wof status, my incredulous friend.

alacran

 

WOF_Status_L_EFI_2020-12-29_04-46-37.7z

[wimb]

OK thank you for WOF Status report.

removal of EFI folder requires Trusted Installer, but renaming of EFI folder as x-EFI can be done as Administrator.

The EFI folder inside VHD is already created by WinNTSetup and cannot be removed simply.

VHD_WIMBOOT Capture and Apply will prevent WOF Compression of EFI folder inside VHD when new WimBootCompress,ini is used as present in VHD_WIMBOOT-43

What I can do is to modify UEFI_MULTI and VHD_WIMBOOT so that in case of 2 Partition VHD that EFI folder is not made in NTFS partition and when present is renamed as x-EFI.

I think this can solve the problems encountered with EFI folder in NTFS partition of 2 Partition VHD's

Also new UEFI Grub4dos version will be used, but give me some time to realise it .....

May be reboot.pro will be a!ive soon ....  I mean of course alive ....

I see that you often speak of grub32.efi whereas it is grubia32.efi  ......

Edited December 29, 2020 by wimb

[alacran]

Yes, that sound fine, I usually make the VHDs from Win10XPE_x64, as it boots as Trusted Installer, there is no problem to remove the x-Boot and x-EFI, but it's better if they are not created, in fact I deleted them and bootmgr and BOOTNXT files before make a new recaptured WIM file, but so far they were created and renamed every time I use VHD_WIMBOOT. It will be good if they are not recreated anymore, as in any future new version approach are also unnecessary.

Hope reboot.pro will be online soon.

EDIT:

Quote

I see that you often speak of grub32.efi whereas it is grubia32.efi  ......

Thanks for correcting me, I will take care of not commit that mistake again.

alacran

 

Edited December 30, 2020 by alacran

[alacran]

There is no rush my friend, take your time, and maybe better waith for new UEFI grub4dos version.

By the way as I read grub2 of a1ve do not have that problem since the begining because it is coded to find the EFI on FAT-32 first and FORCE to load it, only when it is not present there, it looks for it on NTFS partition. That's way you were able to boot from it and not from G4E when you had the compressed EFI on NTFS partition.

alacran

[wimb]

18 minutes ago, alacran said:

There is no rush my friend, take your time, and maybe better waith for new UEFI grub4dos version.

By the way as I read grub2 of a1ve do not have that problem since the begining because it is coded to find the EFI on FAT-32 first and FORCE to load it, only when it is not present there, it looks for it on NTFS partition. That's way you were able to boot from it and not from G4E when you had the compressed EFI on NTFS partition.

alacran

Yes you are right.

Instead of grub2 of a1ve it is grub2 of a1ive ..... That mistake also occurs also quite often at reboot.pro

[wimb]

2 hours ago, wimb said:

removal of EFI folder requires Trusted Installer, but renaming of EFI folder as x-EFI can be done as Administrator.

The EFI folder inside VHD is already created by WinNTSetup and cannot be removed simply.

VHD_WIMBOOT Capture and Apply will prevent WOF Compression of EFI folder inside VHD when new WimBootCompress,ini is used as present in VHD_WIMBOOT-43

What I can do is to modify UEFI_MULTI and VHD_WIMBOOT so that in case of 2 Partition VHD that EFI folder is not made in NTFS partition and when present is renamed as x-EFI.

I think this can solve the problems encountered with EFI folder in NTFS partition of 2 Partition VHD's

Also new UEFI Grub4dos version will be used, but give me some time to realise it .....

 

Done !

Update USB_FORMAT-52 and UEFI_MULTI-52 and VHD_WIMBOOT-44

Download:  from wimb GitHub USB_FORMAT-52 and UEFI_MULTI-52 and VHD_WIMBOOT-44

Download File E = Encrypted Password = bootwimb

Manual:  VHD_WIMBOOT.pdf

reboot.pro is alive again ....

 

Edited December 29, 2020 by wimb

[wimb]

New official release of UEFI Grub4dos available ....

 

[m041633n]

How do I pxe boot grub4dos uefi