grub4dos icon indicating copy to clipboard operation
grub4dos copied to clipboard

Can't load to Ram an item bigger than 2 GB

Open Taviruni opened this issue 4 years ago • 67 comments
trafficstars

Hi, First I want to say this is a FANTASTIC version. Thanks very much for all your effort and time to make it for us. I liked a lot it is also capable to boot *.gz and *.lz4 files just as the MBR version as I have tested.

This is the issue I found: It seems something is wrong as grub4dos for UEFI do not let me load on Ram more than 2 GB, I got this message:

(hd0,1) Out of memory boot_image_handle not found

Press any key to continue....

I'm using grub4dos-0.4.6a_for_UEFI-2020-12-05 and can't load my 2.30 GB Mini-10x64.vhd on Ram in order to Ramboot from it (it has SVBus driver installed), the PC has 8 GB so this should no be a problem, as using the grub4dos MBR version it is loaded to Ram and Ramboots very fine, the VHD has a 64 MB FAT-32 ID: 0C, Primary Partition Active (to let me boot as MBR or UEFI), and a second partition NTFS where the Mini-10 is installed on Compact LZX mode used espace on this partition is 1.70 GB, if I made a 2046 MB VHD with same partions layout it Ramboots fantastic. It seems something is wrong as grub4dos for UEFI do not let me load on Ram more than 2 GB, The VHD file is located on a NTFS partition into a folder named VHD:

This is my menu.lst entry on EFI\grub\menu.lst

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

For additional info see this post please: http://reboot.pro/topic/22400-grub4dos-for-uefi/page-4#entry217176, also I opened a topic on MSFN forum as reboot.pro forum has been failing very frequently: https://msfn.org/board/topic/182107-grub4dos-for-uefi/ My Mini-10x64 was made with the info on my Topic: http://reboot.pro/topic/22383-reducing-win10-and-older-oss-footprint/ but readapted to use a VHD with 2 partitions.

Thanks in advance, and once again this is fantastic improvement to grub4dos my prefered boot loader.

Your friend

alacran

Taviruni avatar Dec 05 '20 10:12 Taviruni

Please execute the following command: displaymem -a

a1ive avatar Dec 06 '20 02:12 a1ive

I executed the code and made picture with the celphone, they are 5 big size pictures, I will move them to the PC and upload them, in the meantime take a look to this: a lot of virtual floppies, CDs and VHs are created on the VHD loaded on Ram. UEFI SVBus VHD-3 SVBus VHD-4 Ram

alacran

Taviruni avatar Dec 07 '20 11:12 Taviruni

This are the images of the displaymem -a command:

WhatsApp Image 2020-12-07 at 5 42 21 AM WhatsApp Image 2020-12-07 at 5 44 16 AM WhatsApp Image 2020-12-07 at 5 44 18 AM WhatsApp Image 2020-12-07 at 5 44 24 AM WhatsApp Image 2020-12-07 at 5 44 30 AM WhatsApp Image 2020-12-07 at 5 44 38 AM WhatsApp Image 2020-12-07 at 5 44 46 AM

alacran

Taviruni avatar Dec 07 '20 11:12 Taviruni

have a try. title 10x64-UEFI.vhd (2046 MB) SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/10x64-UEFI.vhd map --mem --top /VHD/10x64-UEFI.vhd (hd) chainloader (hd-1) BOOTX64.rar.txt

yaya2007 avatar Dec 08 '20 10:12 yaya2007

Thanks very much, this solved the issue on this PC. It took me some time as I had to made a new VHD, but finaly after testing this new version it is Rambooting very fine.

title Mini-10-UEFI.vhd (2360 MB 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)

Once again thanks for this fantastic UEFI version, now it is working great.

alacran (from reboot.pro)

Taviruni avatar Dec 08 '20 16:12 Taviruni

The problem is solved. Good. This program has been modified several times. In order to determine which part of the program works, I hope you can test it again. Thank you. title Mini-10-UEFI.vhd (2360 MB MB) SVBus RAMDISK UEFI boot from HD find --set-root /VHD/Mini-10-UEFI.vhd map --mem /VHD/Mini-10-UEFI.vhd (hd) chainloader (hd-1)

yaya2007 avatar Dec 09 '20 00:12 yaya2007

Sorry, I didn't saw your comment until now. I'm using currently the version released in 2020-12-10 and it is working very fine in all my tests using map --mem --top

Do you still want me to test using only the map --mem command with this new version? or is not necessary anymore. I'm ready to run all tests you want to help you improve this fantastic version for UEFI.

By the way I saw on your program topic on wuyou.net that liuzhaoyzz was finally able to run 10x64 from Ram, with the new version, but now has some troubles trying to run 7x64 from Ram, which is not fully compatible with recent versions of UEFI firmware, only older versions support it. Just let me know if you want me to make some tests, here or on reboot.pro topic or on MSFM if reboot.pro is offline.

alacran (from reboot.pro)

Taviruni avatar Dec 10 '20 21:12 Taviruni

yes,test it.

yaya2007 avatar Dec 10 '20 22:12 yaya2007

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)

Taviruni avatar Dec 11 '20 05:12 Taviruni

Is this image installed in memory above 4GB or below? Is it the same computer as the screenshot above? If not, please check the memory distribution of this computer.

yaya2007 avatar Dec 11 '20 07:12 yaya2007

Is this image installed in memory above 4GB or below? I don't know but haven't changed the setting on the firmware, it has being always set to Enabled which is the preset option, MB is an old Asus B 75 8 GB Ram. Same Pc, just new G4E version.

Memory Remap Feature

alacran (from reboot.pro)

Taviruni avatar Dec 11 '20 08:12 Taviruni

As on some cases when a previous RamOS do not load or boot fine, on next successful boot I have found ghost virtual Floppies, CDs and VHDs, it could be good if you can show me or tech me a command to delete those ghost virtual drives, this could be useful to run more accurate tests, don't having them potentially interfering with results of next test, it wouldn't be a problem if they appear only in the RamOS that didn't boot fine, the problem is they appear when booting any other VHD.

I read this Post: http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=422652&pid=4191192

But the idea of making a copy is not very useful when I have 4 or 5 VHDs for testing, same applies for the defragmenting option, especially now that I started running tests with the files located on a USB 3.0 device and those ghost images were seen when Rambooting any VHD on internal HD or USB device.

alacran (from reboot.pro)

Taviruni avatar Dec 11 '20 13:12 Taviruni

Memory Remap Feature cannot be opened

yaya2007 avatar Dec 11 '20 21:12 yaya2007

After disabled Memory Remap Feature, none of the VHDs are loaded to memory with or without --top, and after enabling it again same thing, now I can't load any of the VHDs to Ram, I get allways same message on all of them:

Memory Remap

Also grub2 new version from Wintofllash (or a1ve on reboot.pro) do not load the VHDs on Ram and before changing this setting it was working very fine too.

alacran (from reboot.pro)

Taviruni avatar Dec 12 '20 00:12 Taviruni

I can't open the link here. "disabled Memory Remap Feature",How to achieve this ?

yaya2007 avatar Dec 12 '20 02:12 yaya2007

have a try. BOOTX64.rar.txt

yaya2007 avatar Dec 12 '20 08:12 yaya2007

"disabled Memory Remap Feature",How to achieve this ? I did it in the firmware/Bios on Memory Remap Feature option

Just fixed the PC problem: went back to firmware/Bios, loaded Optimized Settings, made my personal settings as language, etc, as they were before, and saved (F10), after reboot all is back to normal, tested again the 2.3 GB VHD and it loaded fine to Ram and also booted fine again with or without --top parameter. Also a1ive new grub2 version is working fine again.

I assume there is a bug in the PC firmware and the setting was not re-enabled right, but loading Optimized Settings fixed the issue.

Just downloaded your file on previous message, and will test it and report back. Do you want me to test something especifically or just test loading and booting from RAM VHDs? A little more info about version changes/improvements could be good to let me be more accurate on testing certain features.

By the way it seems there is an issue on map command, when mapping WinPE ISO file and also mapping VHD files, mam --mem and map --mem --top are wotking fine, for more info please see this post on reboot.pro: http://reboot.pro/topic/22400-grub4dos-for-uefi/page-7#entry217302

See you latter my friend. alacran (from reboot.pro)

Taviruni avatar Dec 12 '20 10:12 Taviruni

In this version, the floppy disk image is removed to see if it works properly.

yaya2007 avatar Dec 12 '20 10:12 yaya2007

v2020-12-12 Test Report

Locations of files used to test: MBR NTFS Formated (hd0,4)/Isos/Win10XPE_x64.ISO MBR FAT-32 Formated (hd1,0)/VHD/Mini-10x64-2004-2.vhd

Commands tested: map; map --mem, and map --mem --top

All booted fine, not a single issue. No more issues when using command map alone.

Tests Done: title Start Win10XPE_x64.ISO as FILEDISK UEFI boot from HD find --set-root /Isos/Win10XPE_x64.ISO map /Isos/Win10XPE_x64.ISO (0xff) chainloader (0xff)

title Start Win10XPE_x64.ISO as RAMDISK UEFI boot from HD (no --top) find --set-root /Isos/Win10XPE_x64.ISO map --mem /Isos/Win10XPE_x64.ISO (0xff) chainloader (0xff)

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

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)

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

No more issues when using command map alone.

Taviruni avatar Dec 12 '20 11:12 Taviruni

thank you

yaya2007 avatar Dec 12 '20 12:12 yaya2007

You are welcome my friend.

In this version, the floppy disk image is removed to see if it works properly.

Just some comments, related to the successful tests:

Since you released this UEFI version all my VHDs UEFI bootables are MBR formated (2 partitions), First 64 to 100 MB Primary FAT-32 Active Partition ID:0C + a Secondary NTFS partition, were the OS with SVBus driver installed resides. The FAT-32 partition contains only boot files/folders to MBR/CSM and UEFI boot.

I think it was a good decision to remove the floppy disk image, and what about the CD image?, What is the use of it?

alacran (from reboot.pro)

Taviruni avatar Dec 12 '20 15:12 Taviruni

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi Test Report

Mini-10x64-2004.vhd >>> Single partition NTFS Active booted very fine >>> 2004 - release.191206-1406

Booted very fine.

title Mini-10x64-2004.vhd (2360 MB only NTFS) as RAMDISK UEFI boot from HD load /EFI/grub/ntfs_x64.efi find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd map --mem --top /Mini-10x64-2004.vhd (hd) chainloader (hd-1)

alacran (reboot.pro)

Taviruni avatar Dec 17 '20 04:12 Taviruni

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi (from Rufus) Test Report

Mini-10x64-2004.vhd >>> Single partition NTFS Active booted very fine >>> 2004 - release.191206-1406

The VHD fail to boot:

title Mini-10x64-2004.vhd (2360 MB) Rufus as RAMDISK UEFI boot from HD NTFS load /EFI/grub/ntfs_x64-R.efi find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd map --mem --top /Mini-10x64-2004.vhd (hd) chainloader (hd-1)

Used ntfs_x64.efi from Akeo (Rufus) renamed to ntfs_x64-R.efi: https://efi.akeo.ie/...64/ntfs_x64.efi

The VHD was loaded to Ram but I got the message: Boot_image_handle not found, so this driver do not work fine with G4E

alacran (reboot.pro)

Taviruni avatar Dec 17 '20 05:12 Taviruni

Grub4dos-for_UEFI-2020-12-15 + ntfs_x64.efi (from Rufus) Test Report

Mini-10x64-2004.vhd >>> Single partition NTFS Active booted very fine >>> 2004 - release.191206-1406

The VHD fail to boot:

title Mini-10x64-2004.vhd (2360 MB) Rufus as RAMDISK UEFI boot from HD NTFS load /EFI/grub/ntfs_x64-R.efi find --ignore-floppies --ignore-cd --set-root /Mini-10x64-2004.vhd map --mem --top /Mini-10x64-2004.vhd (hd) chainloader (hd-1)

Used ntfs_x64.efi from Akeo (Rufus) renamed to ntfs_x64-R.efi: https://efi.akeo.ie/...64/ntfs_x64.efi

The VHD was loaded to Ram but I got the message: Boot_image_handle not found, so this driver do not work fine with G4E

alacran (reboot.pro)

this driver doesn't work on my PC, and is not caused by grub.

a1ive avatar Dec 17 '20 06:12 a1ive

@ aive

Thanks my friend, I was aware it didn't work on your PC, you commented it on a post on reboot.pro, just wanted to test the more recent version and this one also don't work, I don't mean the failure is caused by grub4dos, what I mean is it can't be used for our purpose.

alacran (reboot.pro)

Taviruni avatar Dec 18 '20 21:12 Taviruni

From my post: http://reboot.pro/topic/22400-grub4dos-for-uefi/page-10#entry217481

I ran some tests to measure the times required to load to RAM a VHD:

UEFI grub4dos 2020-12-15 and last version of grub2 from a1ive were used on following tests.

Of course your times will be different as your VHDs will be different and your CPU, HD and Ram speeds will be also different but at least this can help to give an idea to what you can expect on your own tests.

My old Asus B75M-A MB 8 GB Ram DDR3 1333 MHz (AMI UEFI firmware) have several options to set the CSM: Auto, Enabled and Disabled. Also it allows to disable Secure Boot.

All tests are with the VHDs located into a partition on second HDD:

`Secure Boot = Disabled; CSM = Auto

Mini-10-UEFI-WB.vhd (FAT-32+NTFS) 1330 MB Grub2 >>> 28.94 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS) 1330 MB Grub2 + grub4dos >>> 15.08 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS) 1330 MB grub4dos >>> 15.00 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS) 1330 MB Grub2 + grub4dos >>> 4.28 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS) 1330 MB grub4dos >>> 4.31 sec.`

I will take both as 4.30 sec., as the difference may be just my finger response.

Here the lz4 compression helps a lot to improve the time as the Wimboot VHD has a lot of free space.

`Secure Boot = Disabled; CSM = Disabled

Mini-10-UEFI.vhd (NTFS) 2046 MB Grub2 >>> 44.53 sec.

Mini-10-UEFI.vhd (NTFS) 2046 MB Grub2 + grub4dos >>> Do not work

Mini-10-UEFI.vhd (NTFS) 2046 MB grub4dos >>> 22.76 sec.

Mini-10-UEFI.vhd.lz4 (NTFS) 2046 MB grub4dos >>> 21.16 sec.`

If booting from grub2 and chainloading to grub4dos the biggest VHD capable to boot is 1.3 GB as just tested too. There is something interfering to let boot bigger size VHDs in this case.

Here the lz4 compression do not help improve so much the time as the VHD has very small free space.

`Secure Boot = Disabled; CSM = Disabled

Mini-10x64-2004-2.vhd (FAT-32+NTFS) 2.3 GB Grub2 >>> 50.89 sec.

Mini-10x64-2004-2.vhd (FAT-32+NTFS) 2.3 GB Grub2 + grub4dos >>> Do not work

Mini-10x64-2004-2.vhd (FAT-32+NTFS) 2.3 GB grub4dos >>> 26.30 sec.

Mini-10x64-2004-2.vhd.lz4 (FAT-32+NTFS) 2.3 GB grub4dos >>> 22.85 sec.`

As on previous set of tests: If booting from grub2 and chainloading to grub4dos the biggest VHD capable to boot is 1.3 GB as just tested too. There is something interfering to let boot bigger size VHDs in this case.

Here the lz4 compression helps improve a few the time as the VHD has more free space than in previous set of tests.

Conclusions:

  1. The best times required to load to Ram a VHD are got using UEFI grub4dos and lz4 compression.
  2. The second best times to load to Ram a VHD are got booting with UEFI grub2 and chainloding to grub4dos and lz4 compression.
    
  3. **Having 8 GB of Ram and booting with UEFI grub2 and chainloading to grub4dos, do not work for files bigger than 1.3 GB.**
    
  4. Unfortunatelly booting directly to UEFI grub4dos is not possible on only UEFI new MBs, so the users are forced to boot to UEFI grub2 first.
    

I think our very appreciated friends a1ive and yaya should try to find the cause of this issue, as this is inconceivable those VHDs boot very fine when loaded without chainloading from UEFI grub2 to UEFI grub4dos, something on the code of one of them (or maybe both) loaders is creating this issue when chainloading to the second loader.

I'm aware of the hard work (for free) of both of you, and I appreciate it a lot, but this issue is making me crazy. Sorry if my words could sound as a demand, please don't take it that way, take it as a very respectful and kindly request.

alacran (reboot.pro)

Taviruni avatar Dec 25 '20 19:12 Taviruni

Unfortunatelly booting directly to UEFI grub4dos is not possible on only UEFI new MBs, so the users are forced to boot to UEFI grub2 first.

I tried to say:

New PCs are only UEFI, and Secure Boot can't be dissabled, then we are forced to boot to UEFI grub2 and chainload to UEFI grub4dos.

And then the 2.30 GB VHDs can't be loaded to Ram, as you can see on my previous tests.

alacran (reboot.pro)

Taviruni avatar Dec 26 '20 00:12 Taviruni

Please use the test version published in today's worry free forum to test.

yaya2007 avatar Dec 26 '20 05:12 yaya2007

After gtub2 goes to G4e, take a look at the number of $grub4dos between 0-0x9ffff. Is svbus used?

yaya2007 avatar Dec 26 '20 05:12 yaya2007

I located the file on your post: http://bbs.c3.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=422652&pid=4203355 But I can't download it, I got a Message:

Sorry, you do not have permission to download this attachment 抱歉,您没有权限下载本附件

Could you share it here?

After grub2 goes to G4e, take a look at the number of $grub4dos between 0-0x9ffff. Do I use displaymem -a command? Or you can give me a better command to use?

Is svbus used? Yes, of course, same files boot fine when booting directly to UEFI grub4dos, but when booting to grub2 and chainloading to UEFI grub4dos, and trying to boot with the usuall commands:

title Boot /VHD/Mini-10-UEFI.vhd (NTFS) UEFI RAMDISK 2 GB >>> IT DO NOT LOAD TO RAM load /EFI/grub/ntfs_x64.efi find --set-root --ignore-floppies --ignore-cd /VHD/Mini-10-UEFI.vhd map --mem --top /VHD/Mini-10-UEFI.vhd (hd) chainloader (hd-1)

title Boot /VHD/Mini-10x64-2004-2.vhd (FAT+NTFS) UEFI RAMDISK 2.3 GB >>> IT DO NOT LOAD TO RAM find --set-root --ignore-floppies --ignore-cd /VHD/Mini-10x64-2004-2.vhd map --mem --top /VHD/Mini-10x64-2004-2.vhd (hd) chainloader (hd-1)

Also tried without --top and same result.

alacran (reboot.pro)

Taviruni avatar Dec 26 '20 10:12 Taviruni