421 replies to this topic

[Vortex]

Hi wimb,

 

I tried your command and it added a second entry to the BCD record of the first FAT32 partition ( the partition inside the drive hosting the VHD )

bcdboot F:\Windows /s Z: /f UEFI

The result didn't change in the GPT disk layout. Yet another out of map memory error - RAM boot test.

Attached Thumbnails

• 

[wimb]

Hi wimb,

 

I tried your command and it added a second entry to the BCD record of the first FAT32 partition ( the partition inside the drive hosting the VHD )

bcdboot F:\Windows /s Z: /f UEFI

The result didn't change in the GPT disk layout. Yet another out of map memory error - RAM boot test.

 

Ok

And your VHD internal drive F: NTFS does it contain Boot or EFI folder ?

Boot and EFI in drive F: must be disabled as x-Boot and x-EFI or removed.

After Install of signed SVBus driver it is needed to Reboot VHD first as FILEDISK using Windows Boot Manager Menu

 

Otherwise I don't know what is causing your VHD Boot problem .....

[Vortex]

Hi wimb,

 

The F partition does not contain any folder like EFI and \ or boot hosting BCD records. No worries, thanks for all your help. Much appreciated.

[alacran]

alacran,

    Thank you for your translation.You can modify it with your own opinion.It doesn't matter.

 

If the ntfs_x64.efi driver work fine,VHD with 1 partition will be simpler than 2 partitions IMHO.

Because you must edit the BCD in the VHD and the BCD in the real disk carefully.If the BCD has fault,you will get some strange error like 0xc000000f,0xc000000e and so on.

 

I test ntfs_x64.efi driver work fine on 2 PCs.

 

Hi liuzhaoyzz

 

I did not modify anything on your tutorial, just translated it as it is, I have a high respect for your work, I also have tested the ntfs_x64.efi driver and it works fine on my PC too.

 

On the post I only expresed my opinion, having in maind that driver is from 2018 and it seems it 's not under development anymore, and with so many changes they do to Win10, it is very possible it may not work on future versions, so my conclusion was:

1. Use the ntfs_x64.efi driver on allready made single partition VHDs.
2. When creating new VHDs it is preferable to use the 2 partitions layout.

But it is also valid to take it the other way too:

1. Make single partition VHDs and use ntfs_x64.efi driver for as long as it works.
2. If in the future Win10 versions the driver stop working, then use the 2 partitions layout.

Of course always taking care of not have Boot and EFI folders on the NTFS partition when using the 2 partition scheme.

 

Anyway, it is very good to have both options booting fine, single or 2 partition VHD, and I celebrate this achievement, also in fact I'm using both ways.

 

alacran

[alacran]

@ a1ive

 

Hi my friend, would you share with us a compiled version of your grub2 capable to load the ntfs_x64.efi driver?

 

I would like to run some tests with grub2 and single partition VHDs, and so far I'm not able to do it.

 

When using 2 partitions, (I haven't measure the time to load on Ram a VHD to compare), but it seems your grub2 is faster than UEFI grub4dos in this case.

 

I'm trying to find which combination can give the faster time to load on Ram.

 

Thanks in advance

 

alacran

[a1ive]

@ a1ive

 

Hi my friend, would you share with us a compiled version of your grub2 capable to load the ntfs_x64.efi driver?

 

I would like to run some tests with grub2 and single partition VHDs, and so far I'm not able to do it.

 

When using 2 partitions, (I haven't measure the time to load on Ram a VHD to compare), but it seems your grub2 is faster than UEFI grub4dos in this case.

 

I'm trying to find which combination can give the faster time to load on Ram.

 

Thanks in advance

 

alacran

use 'efiload' command in grub2.

[alacran]

@ a1ve

 

From: https://github.com/a...rub/tree/latest.

 

README.md

a1ive's GRUB 2

Fork of GRUB 2 to add various features.

See the file INSTALL for instructions on how to build and install the GRUB 2 data and program files.

Extra modules: https://github.com/a1ive/grub-extras

Download: https://github.com/a1ive/grub/releases若下载速度慢，建议使用 gitd.cc 下载

Manual: 简体中文

 

It would be good if you add an additional line saying something like this: To create the grubia32.efi, grubx64.efi and core.img files just run the build_grub.bat file included into grub2-latest.tar.gz download.

 

Finally I decided to download the grub2-latest.tar.gz which at first seen seems related to Linux, as .tar.gz is very commonly used on it, and was able to create the core.img, grubia32.efi and grubx64.efi files, just running the build_grub.bat file included in the download,

 

I know this may seem obvious, but on that page and the download page, there is no mention to it, and the README.md very clearly says: See the file INSTALL for instructions on how to build and install the GRUB 2 data and program files, and this message only helped to create more confusion, because also in the INSTALL file there is no mention of build_grub.bat file.

 

alacran

[alacran]

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

[liuzhaoyzz]

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:


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.


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.


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:

• The best times required to load to Ram a VHD are got using UEFI grub4dos and lz4 compression.
• The second best times to load to Ram a VHD are got booting with UEFI grub2 and chainloding to grub4dos and lz4 compression.
• Having 8 GB of Ram and booting with UEFI grub2 and chainloading to grub4dos, do not work for files bigger than 1.3 GB.
• 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

Good test report！
What does new "MBs" mean？new MainBoard？
Why not upload a screenshot of g4e can't load as main osloader？
Do you have test map --mem --top？8GB RAM,1.3GBVHD biggest？Maybe lz4 need more memory to decompress.

Edited by liuzhaoyzz, 26 December 2020 - 07:05 AM.

[wimb]

UEFI Grub4dos indeed loads VHD about 2x faster into RAM as compared to UEFI Grub2

 

My Test on ASUS Z170I 16 GB RAM DDR4 1067 MHz and Samsung T5 500 GB USB SSD

Mini 10x64 Compact LZX in 3 GB Fixed 2 Partition VHD located on USB SSD NTFS 2nd partition and made with VHD_WIMBOOT-43 and Win_Reduce_Trusted-40

Booting from USB SSD FAT32 1st partition in UEFI Secure mode with Grub2 and chainloading UEFI Grub4dos

 

UEFI Grub2       entry to load 3 GB VHD into RAM = 75 sec

UEFI Grub4dos entry to load 3 GB VHD into RAM = 40 sec

 

Here no problem with VHD Size - 3 GB loads into RAM and is booting perfectly Mini 10x64 RAMOS in both cases UEFI Grub2 and UEFI Grub4dos

 

UEFI Secure booting from USB SSD with UEFI Grub2 file grubx64_real.efi and UEFI Grub4dos file bootx64_g4d.efi  USB_FORMAT-52 and UEFI_MULTI-52

 

==

[alacran]

Good test report！
What does new "MBs" mean？new MainBoard？
Why not upload a screenshot of g4e can't load as main osloader？
Do you have test map --mem --top？8GB RAM,1.3GBVHD biggest？Maybe lz4 need more memory to decompress.

 

To answer your questions:

New Mother Boards or Main Boards.

 

I didn't make a screen capture, but i will do it ASAP, but this do not happend if booting directly to UEFI grub4dos.

 

All tests were made using map --mem --top, the 1.3 GB VHD size, is maximum size I can load to Ram when booting to grub2 of a1ve and chainload to UEFI grub4dos to boot the VHDs.

 

lz4 compressed VHDs, boot very fine if booting directly to UEFI grub4dos and are loaded from it, even those of 2.3 GB

 

When booting to grub2 of a1ive and chainload to UEFI grub4dos never tried to boot a lz4 compressed VHD bigger than 1.3 GB.

 

To find the 1.3 GB VHD maximum size capable to boot when booting to grub2 of a1ive and chainload to UEFI grub4dos to load to Ram and boot the VHD, I used the Wimboot VHD of 1.06 GB that booted fine in this case, and using diskpart increased the VHD size to 1.2 GB, and latter running diskmgmt.msc increased the NTFS partition to ocupy all the available espace, and defragmented the VHD file located on my rotatory HDD before testing, it also booted fine, repited the same procedure and the 1.3 GB also booted fine, again repited the procedure and when testing the 1.4 GB UEFI grub4dos said there was not enough memory to load it, In all cases the PC rebooted to load first grub2 of a1ive and from it chainload to UEFI grub4dos to test the VHD.

 

EDIT: Image attached, sorry for the quality of the image, but message is:

 

out of map memory: 8000000000000009

boot_image_handle not found

 

Press any key to continue...

 

alacran

Attached Thumbnails

• 

[alacran]

@ liuzhaoyzz

 

Hi my friend, I was reading your last posts on Grub4dos for UEFI topic on wuyou.net/forum, thanks a lot for your interest in trying to help, asking to solve the issue, but it seems to me the main idea of my request was misinterpreted, I'm not asking to add lz4 capabilities to grub2 of a1ive.

 

In fact the main problem is why when chainloading from grub2 to UEFI grub4dos the maximum size of a VHD that can be loaded (on my 8 GB Ram) is only 1.3 GB, what is causing this?, because when booting directly to UEFI grub4dos it can load a 2.3 GB VHD perfectly fine.

 

This is really the issue what I would like to be investigated and solved, yaya already sended me a 2020-12-26 test version and asked me to run some tests, for more info see the last comments on: https://github.com/c...4dos/issues/248

 

About your last post: http://bbs.c3.wuyou....652&pid=4203687

Translated here for convenience of other readers:

 

liuzhaoyzz
To
936#
Posted on Yesterday 20:57 | Just look at the author

     wintoflash Posted on 2020-12-26 19:34
     The format of lz4 is not the mainstream, so how about a few seconds faster. The bottleneck that limits loading speed is disk I/O, not decompression speed. Just use xz. ...


Oh, that's it. If you have time, please reply to alacran. It seems that he is just new to grub2, and he doesn't know many things.
I completely forgot about xz, I feel that the xz compression ratio is very high.

 

I also forgot about xz compression which by the way I'm aware is very commonly used on several files on Linux distros, as said I'm not looking for booting on grub2 from a compressed VHD, but just for the curiosity I tested this menuentry:

 

menuentry "Mini-10x64-2004-2.vhd.xz" "/VHD/Mini-10x64-2004-2.vhd.xz" {
        search --no-floppy --set --file $2
        map --mem --rt $2
}

 

(I learned from you this menuentry)

 

The file was fully defragmented before testing, just in case.

 

Mini-10x64-2004-2.vhd.xz (FAT-32+NTFS) 2.3 GB Grub2 >>> time to load on Ram 70.63 seconds.

 

Just to compare:

 

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.

 

UEFI grub4dos is very fast to load on Ram a file, and without any compression it's almost 2 times faster than grub2, and 2.68 times faster if loading a xz compressed file on grub2.

 

alacran

[liuzhaoyzz]

927#,http://wuyou.net/for...&fromuid=298214

g4e-2020-12-26,will find and boot bootx64.efi in active MBR partition first.

If you have MBR+active FAT32+NTFS partition layout,you can try it.

Maybe you don't need to rename \EFI in NTFS partition.

It seems yaya didn't upload it to chenall.net,yet.

My vhds all have one partition,so I din't try it.

I like KISS.   KISS=Keep It Simple & Stupid.

 

And this version,maybe have improved the error "boot_image_handle not found."

 

I uploaded it:

链接: https://pan.baidu.co...EBFIpNpM0rMs-Nw 提取码: vche

https://liuzhaoyzz.lanzoux.com/b00o5ho7i

 

Which site above can you download from?

Edited by liuzhaoyzz, 28 December 2020 - 12:50 AM.

[liuzhaoyzz]

@ a1ive

 

Hi my friend, would you share with us a compiled version of your grub2 capable to load the ntfs_x64.efi driver?

 

I would like to run some tests with grub2 and single partition VHDs, and so far I'm not able to do it.

 

When using 2 partitions, (I haven't measure the time to load on Ram a VHD to compare), but it seems your grub2 is faster than UEFI grub4dos in this case.

 

I'm trying to find which combination can give the faster time to load on Ram.

 

Thanks in advance

 

alacran

\grub2\grub2-latest\arch\x64\builtin.txt in any version of grub2,you can add efiload mod to it and run build_grub.bat to customize your module by yourself.

 

all_video blocklist boot cat chain configfile cpio echo efi_gop exfat ext2 extcmd fat fb file font gfxmenu gfxterm gfxterm_background gfxterm_menu gzio halt help iso9660 jpeg linux linuxefi loadenv loopback ls lzopio map minicmd newc normal ntboot ntfs part_gpt part_msdos png probe progress reboot regexp sbpolicy search tar terminal terminfo test tga udf video video_colors video_fb videoinfo wimboot xzio efiload

 

 

You can have a look at build_grub.bat.

@echo off
cd /d "%~dp0"


echo i386-efi
set /p modules= < arch\ia32\builtin.txt
grub-mkimage.exe -d i386-efi -p /boot/grub -o grubia32.efi -O i386-efi %modules%


echo x86_64-efi
set /p modules= < arch\x64\builtin.txt
grub-mkimage.exe -d x86_64-efi -p /boot/grub -o grubx64.efi -O x86_64-efi %modules%


echo i386-pc
set /p modules= < arch\legacy\builtin.txt
grub-mkimage.exe -d i386-pc -p /boot/grub -o core.img -O i386-pc %modules%

Excuse me,alacran=Taviruni in github?

Edited by liuzhaoyzz, 28 December 2020 - 01:11 AM.

[alacran]

Hi liuzhaoyzz

 

Yes alacran in reboot.pro is = Taviruni in github, (alacran user name was already taken by another user).

 

I downloaded the file BOOTX642020-12-26.rar from: https://liuzhaoyzz.l...x.com/b00o5ho7i

 

To make things easier for other users I attached  it here too, it also can be downloaded from: https://github.com/c...mment-751346475

 

 Thanks for your explanation to include efiload on a1ive grub2, but the last version of a1ive grub2 I downloaded, already has included efiload in builtin.txt.

 

alacran

Attached Files

•  BOOTX642020-12-26.rar   136.8KB   1075 downloads

[alacran]

Hi liuzhaoyzz

 

Just saw your post: http://bbs.c3.wuyou....652&pid=4204596

Translated here for other readers convenience:

 

Is this version not pushed to github? I haven't seen chenall's website. I want foreign netizens to try whether the activated FAT32 partition can be booted first in the FAT32+NTFS dual partition mode. If possible, the EFI directory of the NTFS partition does not need to be renamed.

 

BOOTX64 2020-12-26 test:

 

I tested it having full Boot and EFI folders (not renamed or compressed or as pointers) on FAT-32 Active Partition and also on NTFS partition.

 

title Boot /VHD/Mini-10-UEFI-WB.vhd (FAT+NTFS) UEFI RAMDISK 1330 MB
find --set-root --ignore-floppies --ignore-cd /VHD/Mini-10-UEFI-WB.vhd
map --mem --top /VHD/Mini-10-UEFI-WB.vhd (hd)
chainloader (hd-1)
 

NOTE: This is a WimBoot intallation.

 

As expected this new BOOTX64 2020-12-26 is working very fine, it now finds first the boot files/folders on the FAT-32 partition and boot from them, no more boot_image_handle not found.

 

alacran

[liuzhaoyzz]

582#，http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=417233&pid=4205481&fromuid=298214

 

If there is no fragment in the file, you can add -l parameter and convert it into blocklist format to speed up reading. If the file is fragmented, it may or may not work.

wintoflash

 

I personally measured the parameter -l, and the 7gb vhd was loaded into memory. The results are as follows:

 

1. Put sx70211.vhd on sata ssd, and there is no fragment.

It takes 1 minute and 23 seconds from 0 to 100% without -l parameter.

menuentry "SX70211.vhd-svbus" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt $2

}

 

With the -l parameter, it takes 23 seconds.

menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt -l $2

}

 

2、 Put sx70211.vhd on the mechanical hard disk, wincontig shows four fragments, and under g4e, blocklist shows three fragments. It takes 1 minute and 13 seconds to change from 0 to 100% without -l parameter. Adding -l parameter from 0 to 100% takes 1 minute and 03 seconds. G4e took 1 minute and 11 seconds.

menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt -l $2

}

 

My conclusions:

1. If vhd has no fragments, adding -l parameter will greatly improve the reading speed.

2. If there are fragments in vhd, it is not too much to increase the reading speed by adding -l parameter, but it is accelerated by 10 seconds on the mechanical hard disk. After adding -l parameter, there is almost no difference between the reading speed and that of g4e (there may be card table error); The fragmented ssd has not been tested.

3. Whether there are fragments or not, whether it is direct map or map --mem with -l parameter is feasible.

Therefore, the final conclusion is that grub2' s map is best added with -l parameter.

 

Oh,er...This thread is talking about g4e，but I talk about grub2，it seems digress...

Edited by liuzhaoyzz, 29 December 2020 - 01:48 AM.

[alacran]

Thanks liuzhaoyzz

 

Good info and tests, improve the time to load to Ram is always welcome.

 

I will run some more tests myself and comment back.

 

About:

 

Oh,er...This thread is talking about g4e，but I talk about grub2，it seems digress...

 

I think any info related to both options, (G4E and grub2 from a1ive), to run a RamOS on UEFI environment is more than welcome for all of us.

 

EDIT: But I think you are right, and I decided to open a new topic to talk about a1ive Grub2

You can see the Resuls of my -l parameter tests on this Posts.

 

alacran

[alacran]

Good news:

 

Yaya just made a new test version which is now capable to chainload to bootmgfw.efi (the one of 1522 KB on 10 2004 version) and run it fine.

 

 

2011yaya2007777
To
942#
  The original poster | Posted on yesterday at 09:53 | Just look at the author
Finally got 1522Kb bootmgfw.efi! The investigation was very hard.

     BOOTX64.rar

     135.98 KB, Downloads: 22, Download cost: Worry-Free Coin -2

 

This is an extract of another post where he commented this:

 

The previous chainloader /efi/microsoft/boot/bootmgfw.efi, some can boot, but the 1522Kb one failed to boot.

 

The problem seems that was related to a misinterpretation of some info got from the documents of grub2 from a1ive.  But it is solved now on this test version.

 

It is sad we can't download it from that link.

 

@ a1ive

 

Could you share it with us?

 

alacran

[liuzhaoyzz]

Good news:

 

Yaya just made a new test version which is now capable to chainload to bootmgfw.efi (the one of 1522 KB on 10 2004 version) and run it fine.

 

 

This is an extract of another post where he commented this:

 

The problem seems that was related to a misinterpretation of some info got from the documents of grub2 from a1ive.  But it is solved now on this test version.

 

It is sad we can download it from that link.

 

@ a1ive

 

Could you share it with us?

 

alacran

2020-12-29

https://liuzhaoyzz.lanzoux.com/b00o5ho7i

[alacran]

2020-12-29

https://liuzhaoyzz.lanzoux.com/b00o5ho7i

Thanks liuzhaoyzz, just downloaded it, I will attach it to this post to make things easier for other readers.

 

alacran

Attached Files

•  BOOTX642020-12-29.rar   135.98KB   1067 downloads

[alacran]

Just tested BOOTX64 2020-12-29, renamed to bootx64_g4d.efi and using this menu entries on menu.lst:

 

title Windows EFI BootManager - bootmgfw.efi
chainloader /efi/microsoft/boot/bootmgfw.efi

title Windows EFI BootManager - bootx64_win.efi
chainloader /efi/boot/bootx64_win.efi

 

Both were executed fine, as expected.

 

alacran

[wimb]

Just tested BOOTX64 2020-12-29, renamed to bootx64_g4d.efi and using this menu entries on menu.lst:

 

 

Yes, I confirm this version of UEFI Grub4dos is OK to chainload Windows EFI BootManager

[alacran]

This are some useful tools we may add to our UEFI grub4dos:

 

ntfs_x64.efi (NTFS driver): From refind-cd-0.11.4.zip: https://sourceforge....d/files/0.11.4/

 

CrscreenshotDxe.efi (to make screenshots): https://github.com/L...CrScreenshotDxe

 

EfiGuardDxe.efi [to disable PatchGuard and Driver Signature Enforcement (DSE)]: https://github.com/Mattiwatti/EfiGuard

 

unifont.hex.gz (Colection of fonts): Taken from the very well known Easy to Boot (E2B) by steve6375 (hope he doesn't mind as E2B is free software)

 

For your convenience I put all on a Zip file attached, including a README.txt with some samples of use.

 

alacran

Attached Files

•  Useful tools.zip   693.69KB   1609 downloads

[alacran]

This are good news for people as myself with only 8GB of Ram, yaya2007 made a new test version named as BOOTX64_ok.rar.txt and uploaded it here.

 

This version allowed me to boot a 2.5 and also a 3 GB 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. So far I'm still testing it and will keep you informed of my tests results.

 

alacran

Attached Thumbnails

•