GRUB4DOS for UEFI

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

So you have also the write grub4dos message !!!!

I am booting in UEFI Secure mode and you in UEFI mode.

May be that is the reason that in your case the failed to allocate memory does not appear

And in your case UEFI Grub4dos is working OK, whereas in my case I get boot_image_handle not found ....

Hello,

I tested a1ive's new grubx64.efi on a Vmware system. Using grubx64.efi and SVBus, I was able boot a complete Windows 10 64-bit to RAM ( 24 Gb RAM, 18 Gb .vhd file ) My GPT vhd drive has two partitions, a small FAT32 partition ( EFI ) and the second one is an NTFS volume hosting the operating system.

The purpose of my second test was to boot the same Vhd as filedisk but I received the error message INACCESSIBLE BOOT DEVICE on a blue screen.  Attached are the screenshots. I also tested the option map (hd0,gpt3)/Win10.vhd. Same result.

Many thanks to a1ive for his hard work.

Hello,

a1ve's grub2 file manager can boot the same vhd but grub4dos for UEFI is very good for automation.

@ wimb

It seems to me write grub4dos drive map slot is part of normal procedure, not an issue, and reporting 99% should be fine as if you remember grub4dos for MBR always gives a message about the size reported is not the size got by grub4dos (or somethig with same meaning) and there is always some bytes of difference, but it never has being a problem.  I think this difference is caused because grub4dos do not care about VHD header footer so it do not exist for it.

EDIT: On fixed size VHD it is footer not header, our fellow Wonko let me know about my mistake on Post No. 134

But I 'm sure our good friend a1ive could give us more acurate info about this.

alacran

I tested a1ive's new grubx64.efi on a Vmware system. Using grubx64.efi and SVBus, I was able boot a complete Windows 10 64-bit to RAM ( 24 Gb RAM, 18 Gb .vhd file ) My GPT vhd drive has two partitions, a small FAT32 partition ( EFI ) and the second one is an NTFS volume hosting the operating system.

 

The purpose of my second test was to boot the same Vhd as filedisk but I received the error message INACCESSIBLE BOOT DEVICE on a blue screen.  Attached are the screenshots. I also tested the option map (hd0,gpt3)/Win10.vhd. Same result.

My Mini10_SV.vhd (MBR FAT32+NTFS) booting OK as RAMDISK also fails to boot as FILEDISK when using New UEFI Grub2 and menuentry

menuentry "Mini10_SV.vhd as FILEDISK" {
  map --rt (hd0,gpt2)/VHD/Mini10_SV.vhd
  boot
}

But that VHD can easily be booted as FILEDISK in UEFI Secure mode using straight or chainloaded Windows Boot Manager

Hi wimb,

But that VHD can easily be booted as FILEDISK in UEFI Secure mode using straight or chainloaded Windows Boot Manager

 

Do you add the VHD to the boot menu?

https://docs.microso...o-the-boot-menu

If not, could you kindly share your method?

Do you add the VHD to the boot menu?

 

https://docs.microso...o-the-boot-menu

 

If not, could you kindly share your method?

In case of VHD (MBR with single NTFS partition) then you can use simply UEFI_MULTI-50 to Add to or Create UEFI Windows Boot Manager menu

Your case of VHD (GPT FAT32 + NTFS partions) does not fit for this procedure.

But Manually you can add such VHD by using in Admin Command Window:

mountvol Z: /s
bcdboot Q:\Windows /s Z: /f UEFI

where Q: is the NTFS drive of the mounted VHD

and Z: is the hidden EFI partition as mounted by mountvol command Or mounted by launching first WinNTSetup_x64.exe Or UEFI_MULTI_x64.exe

More Info: and VHD_WIMBOOT.pdf

... grub4dos for MBR always gives a message about the size reported is not the size got by grub4dos (or somethig with same meaning) and there is always some bytes of difference, but it never has being a problem.  I think this difference is cause because grub4dos do not care about VHD header so it do not exist for it.

Test report Rambooting Mini-10x64-2004-2.vhd 2.3 GB from USB device.

I want to comment that tested Rambooting Mini-10x64-2004-2.vhd 2.3 GB from USB device, it booted fine using grub4dos for UEFI (in this test used the Dic/8th version mentioned on this post as it was the last available when testing).

This are the commands used, as you can see they are the same used when booting from internal HD:

The VHD file is located into folder MyVHD on second partition (hd0,1) NTFS formated of the USB device.

title Mini-10x64-2004-2.vhd SVBus RAMDISK for UEFI boot from USB
find --set-root /MyVHD/Mini-10x64-2004-2.vhd
map --mem --top /MyVHD/Mini-10x64-2004-2.vhd (hd)
chainloader (hd-1)

Another comment is on the link on previous post from a1ive there is also a new x64 version too.

alacran

 
 
Fixed vhd's have not a header, they have a footer, one sector in size, so the vhd is exactly 512 bytes longer than the same RAW file.

The warning message that grub4dos provides is about having 1 sector less than the size of the image accessible (as being it a footer it is outside the RAW image, past its end).


Wonko

Thanks for correcting me, I will fix that post and  will make a note with a link to your post to avoid confusion for future readers.

alacran

Test report Rambooting Wimboot Mini-10-UEFI-WB.vhd 1.06 GBGB from USB device.

Tested Rambooting Mini-10-UEFI-WB.vhd, Wimboot mode installed on 1.06 GB VHD (1088 MB) from USB device, it booted fine using the last grub4dos for UEFI version.

Commands used are:

title Mini-10-UEFI-WB.vhd SVBus RAMDISK for UEFI Wimboot from USB
find --set-root /WB/Mini-10-UEFI-WB.vhd
map --mem --top /WB/Mini-10-UEFI-WB.vhd (hd)   >>>  See Note.
chainloader (hd-1)

NOTE: For all of us that have being MBR/CSM Rambooting Wimboot VHDs from USB devices for long time: We already know and have proven when Rambooting a Wimboot VHD from USB on MBR mode this DO NOT WORK, and if we use (hd-1) (as karyonix suggested) then it Ramboots fine, but when Rambooting a Wimboot VHD on UEFI that setting we have being using on MBR mode for long time do not work. And using the typical (hd) works fine on this case.

alacran

Thanks for correcting me, I will fix that post and  will make a note with a link to your post to avoid confusion for future readers.

 

alacran

Good.

Also add a link to this post by karyonix (half of the people on the internet uses complex methods to convert VHD to RAW and viceversa), while it is simple and it takes no time:

http://reboot.pro/to...ges/#entry83781

and to the other tool by erwan.l:
http://reboot.pro/fi...le/116-vhd2img/

Wonko

Thanks, for the good info.

I don't need them right now, but just downloaded both and they are now on my tool box.

alacran

This is a known bug and we don't have a solution for it at the moment.

Hi a1ive,

Testing the latest grub4dos for UEFI ( 10 December 2020 ), I found this solution :

Replacing the line :

chainloader  /EFI/Microsoft/Boot/-bootmgfw.efi

only with this statement :

chainloader

boots the real Windows 10 installation.

Hello,

Another test :

find --set-root /Win10.vhd
map /Win10.vhd (hd)
chainloader (hd-1)

This one boots again the real Windows 10 system, not the VHD as filedisk.

Replacing chainloader (hd-1) with chainloader (hd) displays the error message boot_image_handle not found.

@Vortex

(hd) essentially means "next" free (hdn) or, if you prefer, the n that doesn't yet exists (but that I want to create with map)

(hd-1) essentially means "last" (existing) (hdn)

When it works, it is handy, but on a normal PC with only one disk:

find --set-root /Win10.vhd
map /Win10.vhd (hd1)
chainloader (hd1)

is the same.

In normal grub4dos - which can as well use (hd) and (hd-1) - usually the 

geometry [TAB]

and/or

root [TAB]

to check how many disks are visible in the environment before and after the map command.

Wonko

I have being using the map --mem --top command since it is available (3 days ago) and this let me load to Ram VHD files bigger than 2 GB and boot fine.

Yaya asked me to test if same VHD was able to boot using only map --mem, tested this using grub4dos-0.4.6a_for_UEFI-2020-12-10 and the result was successful.

From: https://github.com/c...4dos/issues/248

 

Done, it booted fine using following commands:

 

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

 

alacran (from reboot.pro)

Before this test, I read on wuyou.net topic a post from yaya saying the mapping on Ram has being improved using a different parameter, here: http://bbs.wuyou.net...652&pid=4191620

Translated using Google translate:

 

Original | Posted at 15:18 the day before yesterday | Just look at the author

 

The memory type is determined by GRUB_EFI_RUNTIME_SERVICES_DATA Modified to GRUB_EFI_PERSISTENT_MEMORY, the virtual machine test, the allocation was unsuccessful. Modified to GRUB_EFI_RESERVED_MEMORY_TYPE, the virtual machine test, the allocation is successful.

@ wimb

I suggest you to try this version (with and without --top), maybe it fits better to your PC firmware.

alacran

JFYI

From: http://bbs.wuyou.net...652&pid=4192861

 

2011yaya2007777
To
771#
  The original poster| Posted 1 hour ago From Mobile | Only this author

A CD image is loaded, and there is also a floppy disk image, which is the boot partition, or boot floppy disk.

Then it is important to keep our VHD FAT-32 boot partition the smallest possible, this will reduce the used Ram, so far I'm using 64 MB for it and all is working fine, will see if I can reduce it a few more.

When using the older versions, when I didn't get a sucess boot this remained on Ram, this are the ghost Floppies and CDs I saw on future successful boots, and the ghost VHDs ovbiously was the VHD failed intents loaded on Ram, as I thought.

alacran

 

I suggest you to try this version (with and without --top), maybe it fits better to your PC firmware.

 

Thanks alacran 

I have tested this new version of UEFI Grub4dos and booting from RAMDISK fails (with and without --top) with boot_image_handle not found.

I am quite happy with UEFI Grub2 of a1ive which also supports UEFI booting from RAMDISK and is working OK for me.

The write grub4dos drive map ....failed to allocate memory message is still present, but nevertheless booting from RAMDISK works OK.

I plan to implement both in my programs and have already made some progress ...., but as you know UEFI booting from RAMDISK requires VHD with two partitions.

And creating the menu entries for UEFI Grub2 and UEFI Grub4dos for booting from RAMDISK requires more new code ....

At the moment the UEFI Grub2 and Grub4dos are auto installed and Menu's appear.

Also I can make the correct VHD's with two partitions.

So the main work to be done is auto create the UEFI menu entries for booting the VHD from RAMDISK ....

Two days ago there was a spectacular twin birth for UEFI booting from RAMDISK and now we need to take care of the 2 new babies ....

It's a shame G4E don't work fine on your PC, but there are some other users on wuyou.net forum with same issue, that message seems to be related to bootmgfw.efi wihich can't be loaded and or it can't find or read the BCD, in fact after loading the VHD to Ram and translate the SVBus mapped info to UEFI readable info, a floppy with a copy of boot files/folders from FAT-32 partition is used as Hardwarevendor info, and by means of a MS UEFI feature (I don't remember the name) it is loaded and the PC boots from it.  I can tell you they are actively working to solve that subject.

On usuall PC booting Hardwarevendor is used by OEMs to show their Logos, Messages, etc, AFAIK this espace is limited (???) and is loaded just before bootmgfw.efi.

Now my theory about this issue:

If there is not enough contiguous space on Ram.  >>>  The virtual floppy is loaded partially or not loaded.

or

If already exists Hardwarevendor info on a PC (loaded from the firmware) >>> This may cause a collision and new info (on the virtual floppy) is loaded partially or not loaded.

When no loaded then the message boot_image_hande not found appears.

When partially loaded, we may get the same message or the PC could try to start booting and fail on different steps of the process depending on the info that wasn't loaded.

When I got the ghost floppies (that where created for previous failed intents to boot 2+ GB VHDs with G4E older versions) on all cases I tried to open them, usually they where not readable, but on one case I was able to open one of them and I saw a folder and only bootmgfw.efi file into it, but nothing else, BCD file was not available.

So far this theory sound plausible, but we have an exception to it:

Why a1ive modded grub2 is capable to make boot same PC that fails using G4E?  >>>  It may be doing something slightly different.

alacran

In case my theory on previous post sounds worthy of some tests:

What we could do on our side to try to solve the issue, running some tests?

• Make the FAT-32 partiton the smaller possible.
• Copy to FAT-32 only strictly required files/folders (only your language files), using the /l <locale> option, see this MS page for more info.
• Make the VHD size smaller, at least for testing pourposes.

alacran

JFYI

From: http://bbs.wuyou.net...652&pid=4193064

 

Posted 4 hours ago | Only this author This post was last edited by liuzhaoyzz at 2020-12-11 18:23

 

good news! g4e/grub2+svbus+win8.1RAMOS started successfully! The vhd also uses the activated FAT32+NTFS partition dual partition scheme, the single partition scheme just doesn't work! WIN10 single partition is fine, evil! 32GB RAM = 6GB occupied by vhd + 1.6GB used by Windows + 24.3GB remaining available

NOTE: On a previous post from liuzhaoyzz he commented his PC firmware is capable to boot Win10 OS from boot files/folders located on a NTFS partition, because it has on its firmware also the required drivers to make it possible, but older OS installed on single NTFS VHD didn't boot.

This confirms the approach of VHD with 2 partitions (MBR formatted with FAT-32 Active + NTFS) we have being using during our tests is the best option and can be used in a more general way, As it allows us to boot from MBR/CSM and UEFI.

alacran

This confirms the approach of VHD with 2 partitions (MBR formatted with FAT-32 Active + NTFS) we have being using during our tests is the best option and can be used in a more general way, As it allow us to boot from MBR/CSM and UEFI.

 

Yes, VHD with MBR (100 MB FAT32 + rest NTFS) is now in VHD_WIMBOOT realised and first menu entries for UEFI Grub2 SVBus RAMDISK in first testing are working OK for me.

Also title in UEFI Grub4dos menu.lst is made by the program but does not boot in my case, but will be useful in your case.

Is UEFI Grub2 SVBus RAMDISK for booting Mini10 VHD working for you ?

VHD_WIMBOOT and UEFI_MULTI and USB_FORMAT Programs can be expected to arrive early next week ....

Yes, VHD with MBR (100 MB FAT32 + rest NTFS) is now in VHD_WIMBOOT realised and first menu entries for UEFI Grub2 SVBus RAMDISK in first testing are working OK for me.

Also title in UEFI Grub4dos menu.lst is made by the program but does not boot in my case, but will be useful in your case.

 

Is UEFI Grub2 SVBus RAMDISK for booting Mini10 VHD working for you ?

 

VHD_WIMBOOT and UEFI_MULTI and USB_FORMAT Programs can be expected to arrive early next week ....

Fine, sounds good to me, and yes so far I have tested booting directly to a1ive new grub2 version grubx64.efi (on EFI folder) and/or grub4dos for UEFI (by F8), and also boot first to grub2 SuperUEFI (by F8) and then call any of them (grubx64_a1ive.efi or bootx64_g4d.efi), and both work very fine.

So it seems I'm lucky, here all options work fine, of course if the user has a UEFI only PC and NO option to disable Secure Boot, then the options are more limited.

It is good a1ve made his new grub2 version, very useful for the cases when grub4dos for UEFI don't work, as in your case.

Then my friend we can say we found the (PC equivalent to) Holy Grail as you named it when we were talking of Rambooting on UEFI not so log ago.

alacran