Jump to content











Photo
- - - - -

GRUB4DOS for UEFI


  • Please log in to reply
421 replies to this topic

#76 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 03:30 AM

 

This new version is capable to UEFI Ramboot my 800MB Wimboot Mini-10x64 as VHD or as IMA:

 

A big thanks to yaya, a1ve, and all other developers involved on this great achievement.

 

 

 

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

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

 

But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file:

 

 

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

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

 

Message is still the same:

 

(hd0,1)
Out of memory
boot_image_handle not found

Press any key to continue....

 

NOTE: Both, the 800 MB Wimboot and the 2.3 GB Compact mode, where installed on NTFS second partition, and boot files/folders are on first 64 MB FAT-32 0C partition (active to also be MBR bootable) of the (MBR inicialized) VHD or IMA. See pictures of sample BCDs on this post.

 

From: http://reboot.pro/to...e-3#entry217174

 

In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB.

 

Then only issue remaining is:

Load to RAM VHD or IMA files bigger than 2 GB.

 

Edit: The new version is also available on: http://grub4dos.chen...EFI-2020-12-05/

 

alacran



#77 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 05 December 2020 - 04:23 AM

This new version was capable to UEFI Ramboot my 800MB Wimboot VHD or IMA:

 

 

But the 2.3 GB VHD did not boot as VHD or as IMA file:

 

 

Message is still the same:

 

(hd0,1)
Out of memory
boot_image_handle not found

Press any key to continue....

 

alacran

your computer may not have more than 2GB of continuous RAM.



#78 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 05:00 AM

It has 8 GB of Ram and it Ramboots that same file very fine on MBR, also same file can Ramboot on MBR on a 4 GB Ram machine too.

 

alacran



#79 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 05:36 AM

This issue started on grub4dos-0.4.6a_for_UEFI-2020-11-26 version, also wimb mentioned it on this post: http://reboot.pro/to...e-3#entry217128and as I remember he has 32 GB of Ram, also he mentioned on first version he saw the VHD loading on Ram but not booting see: http://reboot.pro/to...i/#entry216909, I don't know about grub4dos-0.4.6a_for_UEFI-2020-11-23 second version as I never tested it.

 

alacran



#80 wimb

wimb

    Platinum Member

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

Posted 05 December 2020 - 06:58 AM

Indeed latest version grub4dos-0.4.6a_for_UEFI-2020-11-26 is giving Out of memory and menu.lst does not appear,

 

whereas version grub4dos-0.4.6a_for_UEFI-2020-10-29 presents correctly menu.lst and VHD can be loaded into memory , but RAMDISK booting fails ....

 

attachicon.gifGrub4dos_UEFI_IMG_20201202_095648.jpg

 

Latest version grub4dos-0.4.6a_for_UEFI-2020-12-05.7z is giving Out of memory and menu.lst does not appear.

 

Grub4dos_UEFI_IMG_20201205_073213.jpg

 

EDIT: The location for menu.lst has changed and required is now \EFI\grub\menu.lst

 

2020-11-18 (yaya)

  1. Change the menu directory to: /efi/grub/menu.lst

 

When using new location then UEFI Grub4dos menu appears OK, but VHD booting from RAMDISK failsboot_image_handle not found ....

 

UEFI_Grub4dos_IMG_20201205_134633.jpg == UEFI_Grub4dos_IMG_20201205_134610.jpg


#81 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 08:15 AM

From my post: http://reboot.pro/to...-15#entry217183

 

 

Just made a 2046 MB VHD with that 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

 

alacran

 

 

 


 

 

Attached Thumbnails

  • UEFI Rambooting.png

  • wimb likes this

#82 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 05 December 2020 - 10:52 AM

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

 

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

 

alacran



#83 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 06 December 2020 - 12:54 AM

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

Attached Thumbnails

  • UEFI.png
  • SVBus VHD-3.png
  • SVBus VHD-4.png
  • Ram.png


#84 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 06 December 2020 - 01:05 AM

About setting resolution on menu.lst

 

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

 

graphicsmode -1 parameter 1 parameter 2 parameter 3


-1 means, it means to use vbe display mode. The parameter value is 0x12 or 0x6A, which means using vga display mode

Parameter 1 is to specify the resolution width, you can use a specific value or a range value.
Parameter 2 is to specify the resolution height. You can use a specific value or a range value.
Parameter 3 is the specified bit color, which can be a specific value or a range value.

If you want to get a screen resolution of 800*600, it should be written like this:
graphicsmode -1 800 600

If written like this: graphicsmode -1 100:1000 100:1000
Representative: Use the vbe mode, select the maximum value available in the range of resolution width from 100 to 1000, and select the maximum value available in the range of height from 100 to 1000
That is, you can choose 320×200, 320×400, 640×400, 640×480, 800×600 and other resolutions, and select the highest resolution available

 

AFAIR: Win10 minimum resolution is: 1024x768

 

Will try setting graphicsmode -1 1024 768 on my menu.lst to run some tests and report back.

 

alacran



#85 Vortex

Vortex

    Frequent Member

  • Advanced user
  • 299 posts

Posted 06 December 2020 - 11:29 AM

Hello,

 

On my system, /EFI/Microsoft/Boot/bootmgfw.efi is the renamed grub4dos UEFI loader.  /EFI/Microsoft/Boot/-bootmgfw.efi is original Windows boot manager.

 

Trying this option :

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

displays the output :

Booting command list

Press any key to continue...

How to chainload -bootmgfw.efi ? Any recommendations ?



#86 wimb

wimb

    Platinum Member

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

Posted 07 December 2020 - 09:58 AM

 

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.

 

All these SVBus related drives .... quite strange actually .... 

 

What can yaya  tell us about the mechanism of UEFI grub4dos for booting from RAMDISK with SVBus driver ? .....



#87 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 December 2020 - 11:08 AM

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


  • wimb likes this

#88 wimb

wimb

    Platinum Member

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

Posted 07 December 2020 - 01:03 PM

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

 

 

Win10XPE_x64 Flat in 1200 MB FAT32 VHD is booting fine in UEFI Secure mode with UEFI Grub4dos (chainloaded from Super Grub2)

I have tested map and map --mem and both menu entries are working fine.

title 10XPE.vhd (1200 MB) map vhd for UEFI boot from HD
find --set-root /10XPE.vhd
map /10XPE.vhd (hd)
chainloader (hd-1)

title 10XPE.vhd (1200 MB) - map --mem for UEFI boot from HD
find --set-root /10XPE.vhd
map --mem /10XPE.vhd (hd)
chainloader (hd-1)

So booting VHD from UEFI Grub4dos is working OK

 

Next will be VHD in WIMBOOT mode  .....


  • alacran and rfc647 like this

#89 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 December 2020 - 01:35 PM

JFYI

 

Just in case the forum goes offline again, I'm repeating on MSFN forum all the posts about the tests I have done, to let us continue this talk in case of troubles here, The topic is: grub4dos for UEFI

 

alacran



#90 wimb

wimb

    Platinum Member

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

Posted 07 December 2020 - 01:53 PM

Win10XPE_x64 Flat in 1200 MB FAT32 VHD is booting fine in UEFI Secure mode with UEFI Grub4dos (chainloaded from Super Grub2)

I have tested map and map --mem and both menu entries are working fine.

title 10XPE.vhd (1200 MB) map vhd for UEFI boot from HD
find --set-root /10XPE.vhd
map /10XPE.vhd (hd)
chainloader (hd-1)

title 10XPE.vhd (1200 MB) - map --mem for UEFI boot from HD
find --set-root /10XPE.vhd
map --mem /10XPE.vhd (hd)
chainloader (hd-1)

So booting VHD from UEFI Grub4dos is working OK

 

Next will be VHD in WIMBOOT mode  .....

 

VHD with MBR and 2 partitions FAT32 + NTFS - Apply Mini10 in WIMBOOT mode by using wimlib-clc - manually create boot + efi folder in FAT32 partition

 

VHD map and map --mem in UEFI Grub4dos Failed with boot_image_handle not found .....



#91 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 December 2020 - 02:48 PM

Attached pictures of my Mini-10 WB VHD, I would like to see yours, please.

 

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

Attached Thumbnails

  • WB-VHD.png
  • EFI-BCD.png


#92 wimb

wimb

    Platinum Member

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

Posted 07 December 2020 - 03:00 PM

Attached pictures of my Mini-10 WB VHD, I would like to see yours, please.

 

 

Here my Mini10_WB.vhd VHD

 

Mini10_WB_2020-12-07_155540.jpg == Mini10_WB_2020-12-07_155740.jpg



#93 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 07 December 2020 - 03:14 PM

I don't see applied the No Integrity Checks on it, unless you applied the LoadOptionsString: DISABLE_INTEGRITY_CHECKS on BootIce Professional Mode.



#94 wimb

wimb

    Platinum Member

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

Posted 07 December 2020 - 07:41 PM

I don't see applied the No Integrity Checks on it, unless you applied the LoadOptionsString: DISABLE_INTEGRITY_CHECKS on BootIce Professional Mode.

 

I have changed that setting and also tried LoadOptionsString: DISABLE_INTEGRITY_CHECKS, but the result is the same:

 

VHD WIMBOOT map and map --mem in UEFI Grub4dos Failed with boot_image_handle not found .....



#95 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 08 December 2020 - 04:00 AM

It would be good to know the logic used by grub4dos for UEFI to remap on memory the info gotten from SVBus driver, to make it accesible on UEFI environment and then make it readable by the OS installed into the VHD loaded on Ram, that would be now seen as a hard disk.

 

So far and with the limited or almost non info I have, as I see it, there are several factors that can influence the results of this approach:

  1. Quantity of Ram installed on the PC.
  2. Quantity of Ram shared with ghaphics and other devides, and their location on Ram
  3. Quantity of contiguous Ram available to let grub4dos for UEFI do its work.

Then all this variables have to be "friendly" to let us have a successful VHD (with SVBus installed) Ramboot on UEFI environment.

 

Looking to the pictures on my post No. 83 it seems the VHD is mapped twice.

 

I think in some scenario it could be possible it can be loaded to Ram once, but after doing it there is not enough contiguous Ram remaining on the preset location coded into grub4dos for UEFI for remaping it to make it readable on UEFI environment.

 

We could argue on MBR Rambooting with the grub4dos MBR version + SVBus driver we don't have that problem, I think this is because there is no need for the additional quantity of RAM required to remap on memory the info gotten from SVBus driver, to make it accesible on UEFI environment.

 

Following has a direct influence on where on the memory is located the Ram shared with ghaphics and/or other devides.

 

The way the memory is handled/managed remaping it above 4 GB depends of MBR chipset, this is done to avoid the memory hole, I wasn't able to find a more recent info, but this page let us have an idea of the usual procedure: Motherboard Chipsets and the Memory Map

 

A PC may have a lot of memory but it may be fragmented and then don't have enough Contiguous Ram available just exactly on the preset location coded into grub4dos for UEFI.

 

So far (at least on this PC) I have found a VHD SMALLER than 2 GB Ramboots fine. The 2046 MB (2 partitions) Mini-10 VHD (only 2 MB smaller than 2 GB) Ramboots fine when booting directly to grub4dos for UEFI with Secure Boot dissabled, but not when booting to grub2 and chainloading to grub4dos for UEFI.

 

EDIT: In some cases if having troubles, it could be good to switch off totally and better if we unplug the PC, and wait at least 30 to 45 seconds to let the Ram boards discharge all content and then run our test, just to avoid potential causes of issues.

 

alacran



#96 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 08 December 2020 - 04:06 AM

It would be good to know the logic used by grub4dos for UEFI to remap on memory the info, gotten from SVBus driver to make it accesible on UEFI environment and then make it readable by the OS installed into the VHD loaded on Ram, that would be now seen as a hard disk.

 

So far and with the limited or almost non info I have, as I see it, there are several factors that can influence the results of this approach:

  1. Quantity of Ram installed on the PC.
  2. Quantity of Ram shared with ghaphics and other devides, and their location on Ram
  3. Quantity of contiguous Ram available to let grub4dos for UEFI do its work.

Then all this variables have to be "friendly" to let us have a successful VHD (with SVBus installed) Ramboot on UEFI environment.

 

Looking to the pictures on my post No. 83 it seems the VHD is mapped twice, it could be possible it can be loaded to Ram once, but after doing it there is not enough contiguous Ram remaining (on the preset location coded into grub4dos for UEFI) for remaping it to make it readable on UEFI environment.

 

We could argue on MBR Rambooting with the grub4dos MBR version + SVBus driver we don't have that problem, I think this is because there is no need for the additional quantity of RAM required to remap on memory the info gotten from SVBus driver, to make it accesible on UEFI environment.

 

Following has a direct influence on where on the memory is located the Ram shared with ghaphics and/or other devides.

 

The way the memory is handled/managed remaping it above 4 GB depends of MBR chipset, this is done to avoid the memory hole, I wasn't able to find a more recent info, but this page let us have an idea of the usual procedure: Motherboard Chipsets and the Memory Map

 

We may have a lot of memory but it may be fragmented and then don't have enough Contiguous Ram available just exactly on the preset location coded into grub4dos for UEFI.

 

So far at least on this PC I have found a VHD SMALLER than 2 GB Ramboots fine. The 2046 MB (2 partitions) Mini-10 VHD (only 2 MB smaller than 2GB) boots fine.

 

alacran

I have found that many UEFI firmwares do not automatically allocate addresses higher than 4GB (or even 2GB).

Could you please provide a minimal ramos vhd for me to test?



#97 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 08 December 2020 - 04:09 AM

Hello,

 

On my system, /EFI/Microsoft/Boot/bootmgfw.efi is the renamed grub4dos UEFI loader.  /EFI/Microsoft/Boot/-bootmgfw.efi is original Windows boot manager.

 

Trying this option :

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

displays the output :

Booting command list

Press any key to continue...

How to chainload -bootmgfw.efi ? Any recommendations ?

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



#98 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 08 December 2020 - 04:42 AM

I have changed that setting and also tried LoadOptionsString: DISABLE_INTEGRITY_CHECKS, but the result is the same:

 

VHD WIMBOOT map and map --mem in UEFI Grub4dos Failed with boot_image_handle not found .....

 

The map --mem failing boot could be explained by my previous post, and seems confirmed by aive on this post: http://reboot.pro/to...e-4#entry217235

 

I have found that many UEFI firmwares do not automatically allocate addresses higher than 4GB (or even 2GB).

 

Have you checked on your PC firmware if there is an option to Remap memory to more than 4 GB, and it is enabled?

 

But the map failing sounds very strange to me, it doesn't make sence.

 

Unless chainloading from grub2 is also the cause for the issue, from: http://reboot.pro/to...e-4#entry217234

 

Mini-10 VHD (only 2 MB smaller than 2 GB) Ramboots fine when booting directly to grub4dos for UEFI with Secure Boot dissabled, but not when booting to grub2 and chainloading to grub4dos for UEFI.

 

I haven't tested map the VHD, as booting with MS UEFI bootmgr is more logical in this case, but I will try it and comment back.

 

Have you tested your VHD Rambooting on MBR/CSM mode?

 

alacran



#99 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 08 December 2020 - 06:12 AM

I have found that many UEFI firmwares do not automatically allocate addresses higher than 4GB (or even 2GB).

Could you please provide a minimal ramos vhd for me to test?

 

Not at the moment.

 

Only one I have UEFI bootable is a wimboot VHD 1.06 GB + 1.24 GB the linked WIM file + 1.20 GB WIM file of an additional Y: partition that needs to be installed, with some Directory juntioned programs and other Portable programs, it is 3.5 GB in total, and as you may know once the Wimboot VHD and the linked WIM file are relocated it is neccessary to rebuild the link between both, I don't think this shold be an obstacle for you but it is an Spanish for Mexico version (es-MX) which I guess will not be easy to read by you.

 

I think it will be easier and faster if you capture a Win10 install on your lang on Wimboot mode and latter deploy it on Wimboot mode to a 2 partition VHD to run your tests, you can download and use for capture and apply my wimlib-clc portable, It can run fine from a Win10XPE (it has English, Spanish and French langs) made from the wimlib-clc from Retokener, but my portable has allready integrated wimlib-imagex binaries. Usually it is better to make a new install on a VHD and install the SVBus driver before capture, If capturing an OS (with SVBus driver) installed on a partition, just don't run the latter created VHD on same PC or it will fail.

 

I deleted all previous VHDs to start from scratch as mentioned here:

 

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.

 

About your comment:

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

 

Yes, I have found this issue too, but as I have grub2 on /EFI/Boot/BOOTX64.EFI, I can call grub2 or just by running exit_g4d command, gru2 is loaded inmediately, and from it I can call /EFI/Microsoft/Boot/bootmgfw.efi.

 

EDIT: Forgot to mention my MBR is an old Asus B 75 with AMI firmware, it has an option to enable or dissable the Remap memory to more than 4 GB, I have it enabled.

 

alacran



#100 wimb

wimb

    Platinum Member

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

Posted 08 December 2020 - 10:12 AM

The map --mem failing boot could be explained by my previous post, and seems confirmed by aive on this post: http://reboot.pro/to...e-4#entry217235

 

Have you checked on your PC firmware if there is an option to Remap memory to more than 4 GB, and it is enabled?

 

But the map failing sounds very strange to me, it doesn't make sence.

 

Unless chainloading from grub2 is also the cause for the issue, from: http://reboot.pro/to...e-4#entry217234

 

I haven't tested map the VHD, as booting with MS UEFI bootmgr is more logical in this case, but I will try it and comment back.

 

Have you tested your VHD Rambooting on MBR/CSM mode?

 

 

On my ASUS Z170I PRO Gaming with 16 GB RAM I have not found option to Remap memory to more than 4 GB

 

The Mini 10x64 WIMBOOT VHD (MBR FAT32 + NTFS 2GB ) is booting fine in UEFI Secure mode straight from Windows Boot Manager

 

Also I have repeated my flat 10XPE but now in VHD 3.9 GB NTFS

and just as the FAT32 VHD with 10XPE,  it is booting fine in UEFI Grub4dos.

 

So the VHD Size and the FileSystem does not seem the cause for boot_image_handle not found issue encountered in case of Compact and WIMBOOT 10x64 VHD's

 

There is a new version of UEFI Grub4dos that has --top switch but in my case it did not solve the boot_image_handle not found issue ....






5 user(s) are reading this topic

0 members, 5 guests, 0 anonymous users