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

[Taviruni]

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

[yaya2007]

@alacran Happy new year, my friend! You are right. Version 2020-12-31 has solved the problem that VHD larger than 1.3GB cannot be loaded into memory. Compression VHD, using read file mode, so normal. Uncompressed VHD uses read sector mode, so it is abnormal. But liuzhaoyzz test, 8GB uncompressed VHD, is very fast, only 41% of the time of the old version. I don't know why you failed here.

Now upload a all read file mode, you can do all kinds of tests, you can load compressed and uncompressed VHD larger than 1.3GB. BOOTX64_ok.rar.txt

At the same time, uploading an uncompressed VHD is read sector mode. You can test uncompressed VHD, Test only one step: map --mem --top /VHD/Mini-10-UEFI-WB.vhd (hd)

BOOTX64-test.rar.txt

[Taviruni]

Happy new year to you too!

Thanks for the explanation my friend, now it makes sense to me why with Version 2020-12-31 I got different results in my case depending if the VHD was compressed or uncompressed.

Just downloaded both files, I will test them and report back.

See you latter alacran (reboot.pro)

[Taviruni]

Test report:

The "ok version" works fantastic, I was able to boot a RamOS from a uncompressed 2.5 GH VHD, NOTE: It is internally LZX compressed as it was installed in Compact mode.

Loading the VHD.jpeg.txt

The "test version" do not load even the 1.3 GB VHD, (where the OS is installed on Wimboot mode), I copied it to another location to type a few less in G4E command line.

If this approach that uses read sector mode is similar to a1ive's grub2 -l (or --blocklist), I have tested it extensively too, and it is not capable to load a internally compressed VHD or a VHD installed on Wimboot mode, In fact it is only only capable to boot a RamOS that was installed without any compression.

I tested it with Wimboot, Compact mode and also when using NTFS compression when installing the OS into the VHD, all not externally compressed, and it wasn't able to load any of them to Ram.

See this quote from a post of a1ive on reboot.pro (made a little late after all my tests): From: http://reboot.pro/topic/22429-a1ives-grub-2/#entry217523

blocklist does not support any kind of compression, including all formats of compressed files and NTFS compression. I don't know what vhd-wimboot or vhd-compact is, but the following two things must be met to convert to blocklist disks.

1. the VHD file cannot be compressed.
2. the file system where the VHD file is located cannot have any kind of compression.

If this is the case, best option could be, use the ok version approach as the standard and general use version, as it is capable to load and boot all kind of VHD, and you may include an additional optional parameter to let the user use the read sector mode, only to be used on the especific case of a non compressed (internally and/or externally) VHD.

But as I already know you are a very smart guy, I'm almost sure you already thought in doing it this way.

Your friend alacran (reboot.pro)

[Taviruni]

Using your "OK VERSION" I was able to boot from a RamOS installed in "Compact LZX mode" on a two partitions 3GB VHD, booting first with a1ve's grub2 and chainloading to G4E to load and boot the VHD, it is working fantastic.

3GB-VHD.png.txt

Your very grateful friend alacran (reboot.pro)

[yaya2007]

I want to know, on your computer with 8GB memory, is there any difference between loading 3gb VHD and using or not using the -- top parameter? Can it be started successfully?

[Taviruni]

Not with "OK VERSION", even the 2.3 GB don't load to Ram, I get the message:

out of map memory: 8000000000000009 and keyboard is dead and I have to reboot.

Tested chainloading from a1ive's grub2 to G4E and also booting directly to G4E and same thing in both cases.

But a previous version used on https://github.com/chenall/grub4dos/issues/248#issuecomment-742981691 was able to boot the 2.3 GB VHD without --top if booting directly to G4E

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 (reboot.pro)

[yaya2007]

Oh, I see. It has been said that UEFI firmware will not automatically allocate more than 4GB of memory.Must be forced to load to 4GB or more memory. It seems that this view is wrong .

[Taviruni]

Remember the firmware of my Asus MB has an option called Memory Remap Feature to allow to enable remapping the memory above 4GB and it is set by default as enabled. Maybe some other brand don't have it and then from there came that idea.

https://github.com/chenall/grub4dos/issues/248#issuecomment-743040374

alacran (reboot.pro)

[Taviruni]

I decided to make a single partition VHD of 3 GB, to test the time required to load it in Ram, and booting first with a1ve's grub2 and chainloading to G4E to load and boot the VHD:

10x64-LZX-3.vhd (NTFS) 3GB Grub2 + grub4dos >>> 33.82 sec.

10x64-LZX-3.vhd.lz4 (NTFS) 3GB Grub2 + grub4dos >>> 25.43 sec.

NOTE: I used the "ok version"

alacran (reboot.pro)

[Taviruni]

title Boot /VHD/10x64-35.vhd - UEFI Grub4dos SVBus RAMDISK - 3.5 GB find --set-root --ignore-floppies --ignore-cd /VHD/10x64-35.vhd map --mem --top /VHD/10x64-35.vhd (hd) chainloader (hd-1)

NOTE: Same WIM file applied on Compact LZX mode too, this time it is a 2 partitions VHD.

Also booted fine booting to G2 and chainloadig to G4E "ok version"

alacran (reboot.pro)

[liuzhaoyzz]

BOOTX64_ok.rar.txt，without --top，I got the same error like alacran.Most of my vhds are larger than 4GB.The --top parameter is necessory.It's hard for g4e/grub2 to handle it automatically.We have proved this before.

out of map memory: 8000000000000009 and keyboard is dead and I have to reboot.

Tested chainloading from a1ive's grub2 to G4E and also booting directly to G4E and same thing in both cases.

But a previous version used on #248 (comment) was able to boot the 2.3 GB VHD without --top if booting directly to G4E

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)

[Taviruni]

Test booting a RamOS on a 3.8 GB VHD (Not compressed):

I was able to Ramboot a 3.8 GB VHD NTFS single partition, on same PC with 8 GB of Ram, in this case this is a normal (uncompressed) installation, and it booted fine.

As in previous case booted first to a1ive's grub2 and chainloaded to UEFI grub4dos, "ok-version"

a1ive asked me to test a new version of his grub2 and this are the results:

please use this grubx64.efi to load vhd: https://drive.google.com/file/d/1ut-WZBz8ImZ8mwUy_XIIPLciCvY5V1U-/view?usp=sharing

Tested following menuentries:

menuentry "Boot /VHD/Mini-10-UEFI.vhd -l (NTFS) UEFI RAMDISK 2 GB" "/VHD/Mini-10-UEFI.vhd" { efiload /EFI/grub/ntfs_x64.efi search --no-floppy --set --file $2 map --mem --rt -l $2 }

menuentry "Boot /VHD/Mini-10-UEFI.vhd (NTFS) UEFI RAMDISK 2 GB" "/VHD/Mini-10-UEFI.vhd" { efiload /EFI/grub/ntfs_x64.efi search --no-floppy --set --file $2 map --mem --rt $2 }

First with -l do not work Second without -l works fine

The VHD file has a single NTFS partition, and was installed on Compact mode (LZX compressed), and it is located on a standard MBR uncompressed NTFS partition.

Also tested following menuentries:

menuentry "Boot /VHD/10x64-38.vhd - UEFI Grub2 SVBus RAMDISK - 3.8 GB" { efiload /EFI/grub/ntfs_x64.efi search --file --set=vhd_drive --no-floppy /VHD/10x64-38.vhd map --mem --rt ($vhd_drive)/VHD/10x64-38.vhd boot }

menuentry "Boot /VHD/10x64-38.vhd -l UEFI Grub2 SVBus RAMDISK - 3.8 GB" { efiload /EFI/grub/ntfs_x64.efi search --file --set=vhd_drive --no-floppy /VHD/10x64-38.vhd map --mem --rt -l ($vhd_drive)/VHD/10x64-38.vhd boot }

In this case this is a normal (uncompressed) install on a 3.8 GB VHD, single NTFS partition VHD.

The first menuentry without -l booted fine. The second menuentry with -l do not load to Ram.

alacran (reboot.pro)

[Taviruni]

Test booting a RamOS on a 4000 MB (3.9 GB) VHD (Not compressed):

Just to test the limits I ran this test.

I was able to Ramboot a 4000 MB VHD NTFS single partition, on same PC with 8 GB of Ram, in this case this is same normal (uncompressed) installation, and it booted fine.

To test this, I increased the VHD size in command line and latter just expanded the single NTFS partition and edited the menu.lst, the VHD was not fragmented when cheked with Winconting.

As in previous case, booted first to a1ive's grub2 and chainloaded to UEFI grub4dos.

I don't think it is a good idea to go further as the memory above 4 GB available on this PC, is 4 GB or 4096 MB.

Then I can conclude with this "ok-version" of UEFI grub4dos, we can make use of all the memory available on the PC above 4 GB, without any issue.

alacran (reboot.pro)

[yaya2007]

What good news!

[Taviruni]

Just to report grub4dos-for_UEFI-2021-01-10 new version is working fine here too.

No problem when loading to Ram and booting (externally uncompressed) VHDs installed on Wimboot or Compact mode.

Also if they are (externally) lz4 compressed they are loaded fine to Ram and boot fine too.

NOTE: As in previous case, booted first to a1ive's grub2 and chainloaded to UEFI grub4dos to load and boot the VHD

alacran (reboot.pro)

[Taviruni]

Reporting grub4dos-for_UEFI-2021-01-12 new version is working fine here too. Tested with MBR single partition and MBR 2 partitions VHD. No problem when loading to Ram and booting (externally uncompressed) VHDs installed on Wimboot or Compact mode.

Also if they are (externally) lz4 compressed they are loaded fine to Ram and boot fine.

As in all previous cases, booted first to a1ive's grub2 and chainloaded to grub4dos for UEFI to load and boot the VHD files.

alacran (reboot.pro)

[Taviruni]

Reporting grub4dos-for_UEFI-2021-01-13 new version is also working fine here.

Tested with MBR single NTFS partition, and MBR 2 partitions (FAT-32+NTFS) VHDs.

No problem when loading to Ram and booting (externally uncompressed) VHDs installed on Wimboot or Compact mode.

Also if they are (externally) lz4 compressed they are loaded fine to Ram and boot fine.

As in all previous cases, booted first to a1ive's grub2 and chainloaded to grub4dos for UEFI to load and boot the VHD files.

alacran (reboot.pro)