I decided to make a single partition VHD of 3 GB, to test the time required to load it in Ram (using the UEFI grub4dos from previous post), 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.
10x64-LZX-3.vhd.lz4 is 1.67 GB, it is an improvement of 8.39 seconds in the time used to load it on Ram (24.8 % less time), but it is not so notorious as on this case, when testing a RamOS (installed on Wimboot mode) using same WIM file, and UEFI grub4dos 2020-12-15, that was last version at the time of testing:
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 (71.48 % less time) as the Wimboot VHD has a lot of free space.
We can conclude lz4 compression makes a big difference on the time required to load on Ram a Wimboot VHD (installed on Wimboot mode), but not so much on a Compact LZX VHD (installed on Compact LZX mode). 71.48 % vs. 24.8 % less time.
I was able to Ramboot a 3.5 GB VHD 2 partitions, on same PC with 8 GB of Ram, this time for testing pourposes I used VHD_WIMBOOT-45 to create the VHD and apply the WIM file on Compact LZX mode.
Booted to a1ive's grub2 (using the last version of this post for testing pourposes) and chainloaded to UEFI grub4dos (using the same version as on previous post, located here).
In this case as a1ive's grub2 usually looks for the grub.cfg on \Boot\grub\grub.cfg, I just copied it there.
Menu entry on menu.lst, made by VHD_WIMBOOT-45 is:
interesting! Apparently, the greater the free space, the faster the bootup time. It would be interesting to find out the trade in, ie, how much greater should the free space be relative to the amount of ram available. Me, I noticed that, in terms of space, compressed lz4 (or for that matter gz) sizes stop being smaller at a certain point of enlarging free space (making the vhd larger, so to speak).
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.
I created the VHD manually and installed the OS with wimlib-clc, and latter made the respective entries to boot with UEFI_MULTI v5.3, and also copied the grub.cfg on \Boot\grub\grub.cfg,
Sorry Alacrán, let me get my head together, pls. I am still booting the old way - one partition only, no-uefi, just the traditional conventional bios way, even with the new editions of vhd_wimboot. is using uefi any faster or more convenient than just
title vhd1.vhd - SVBus RAMDISK - 2.0 GB - map as (hd) for WIMBOOT
find --set-root --ignore-floppies /vhd1.vhd
map --top --mem /vhd1.vhd (hd)
map --hook
root (hd-1,0)
chainloader /bootmgr
?
NB: my g4d is still the non-uefi one. then again, is the newest uefi one any better? I saw u used one partition only with uefi stuff preloading - anything worthwhile trying?
I'm testing this because more sooner than latter, there will not be an option to actvate the CSM on the new MBs, but IMHO as long as you can boot using CSM + grub4dos for MBR, there is no real or practical need to change to the UEFI environment, I don't see yet any advantage for you in doing it, in your present case.
Unless your motivation is experimenting, Why you want to complicate your life unnecessarily?
1) because I would like to help and learn. I have good pc resources and I was reading ur posts on a1ive. As I have good pc architecture, I think I'm gonna cooperate with testing, That is why I was reading and waiting for ur answer.
2) can I still go on using the traditional vhd config and trying the new way with the new version of g4u?
3) when u talk of loading times, u still refer to preloading into ram, paying no mind to the time it takes to further reach the desktop, as u have no power on that part of the process, right?
2) To answer this you need to check your Bios/firmware options CAREFULLY, and it may be possible, but to start, booting only from Win without all your additional programs that always create unnecesary troubles during this testing phase, if not you will not help, and only will bring additional complications.
In my case this PC has 2 HD, both are MBR formated the first HD is the one I use for every day, its first primary active partition is NTFS, good to boot on MBR/CSM mode. The second HD also MBR formated primary partition is FAT-32 where all UEFI boot files/folders are, on that same disk on second partition are the VHDs for experimenting.
Going back to the Bios/firmware options, on this PC I have Secure Boot permanently disabled to make things easier, and the CSM has 3 options: Auto, Enabled and disabled, I have it usually on Auto, and by means of BootIce I made 2 additional entries on UEFI, to boot from Grub2 and or to boot from UEFI grub4dos that I can make available during boot with F8 key. (but not all MB brands have a key for this).
In case your PC do not have the Auto option for CSM on the Bios/firmware you may try, but I'm not shure if this will let you boot on UEFI mode. too.
3) Yes I'm measuring allways the time required to load on Ram my Mini-10x64 only, the rest of the time do not have anything to do with grub2 or UEFI grub4dos, as then Win + SVBus driver are in charge of the process, and that is another subject for now, there are some people on chinese forums experimenting with other drivers (apart from SVBus driver) to make Win read/write faster on the Ramdisk once loaded on Ram but that's another subject as I said. Latter we could try the other alternatives, but better not for now.
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 Wincontig.
liuzhaoyzz
To
949#
Posted 6 days ago | Only this author
This post was last edited by liuzhaoyzz at 2020-12-29 13:34
On December 29, 2020, the report is good news, UEFI-RAMOS has been completely overcome:
1. In the case of abandoning ntfs_x64.efi, grub2+ntboot has completed the WIN7 8 10 single mirror and dual mirror:
1. ntboot successfully started WIN7 8.1 10+ vhd based on svbus driver to memory.
2. ntboot successfully started WIN7 8.1 10+ RAMOS based on primo driver, including single mirror and dual mirror modes.
WIN7 8.1 10 dual mirror mode supports no compression, compact compression, and wimboot compression. There is a problem with the English version of win7, but I suspect that the system may be broken. I will verify it later when I have time.
2. In the case of keeping ntfs_x64.efi, the map of g4e/grub2 has been completed to kill WIN7 8 10 single mirror and dual mirror:
1. Map --mem starts WIN7 8.1 10+ vhd based on svbus driver to memory successfully.
2. Directly map to start WIN7 8.1 10+ RAMOS based on primo driver successfully, including single mirror and dual mirror modes.
WIN7 8.1 10 dual mirror mode supports no compression, compact compression, and wimboot compression. There is a problem with the English version of win7, but I suspect that the system may be broken. I will verify it later when I have time.
I would like to express my heartfelt thanks to Wintoflash, 2011yaya2007777, sunsea, etc., all the great gods for such a long time!
NOTE: The problem with the English version was solved reinstalling it as he commented later on another post, it seems maybe the OS was damaged.
I think not only me, but all members and readers here on reboot.pro will appreciate a lot if you give us a more detailed explanation of the procedure, that may let us also make use of your findings related to ntboot and Primo driver.
NOTE: The problem with the English version was solved reinstalling it as he commented later on another post, it seems maybe the OS was damaged.
I think not only me, but all members and readers here on reboot.pro will appreciate a lot if you give us a more detailed explanation of the procedure, that may let us also make use of your findings.
Thanks in advance my friend.
alacran
Compatibility and stability of ntfs_x64.efi is a bit problematic, as wintoflash said. Based on grub2-ntboot scheme, this unstable driver is completely abandoned. http://wuyou.net/for...&fromuid=298214
Usage of grub2-ntboot:
menuentry "SX70211.vhd-svbus-ntboot-l" "/VHD/SX70211.vhd" {
search --no-floppy --set --file $2
map --mem --rt -l $2
ntboot --win --efi=(vd0,1)/EFI/Microsoft/Boot/bootmgfw.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}
Based on many technologies and experiences accumulated in the successful process of svbus-RAMOS, UEFI-RAMOS based on primo drive has also achieved success under the exploration of everyone. primo drive is very complex, including single mirror mode and double mirror mode. primo drive is the crystallization of wisdom of many RAMOS predecessors. Compared with RAMOS based on svbus drive, RAMOS driven by primo is faster. RAMOS with primo double mirror mode and C disk are equal to the total memory size, which can install a lot of software and have a lot of available memory. Memory and hard disk can be converted and dynamically allocated, which is better than RAMOS driven by svbus in all aspects. Actually speaking, I basically can't use RAMOS based on svbus driver, but I always use RAMOS based on primo driver, but primo driver is a commercial software of romex Company, which is a charging software, and there is a cracked version on the Internet (which may also be available abroad). y7y007 of wuyou.net Forum has compiled a batch for online production of primo-RAMOS based on the cracked version of primo server5.6. I have made many improvements and translated it into
Starting with V4.0.0 (there is no English version for the time being), I removed the cracked version of primo software in one-button V3.8.7, and did not pack any cracked software. In this way, there was no copyright dispute, and if I bought genuine primo software, I could use it.
RAMOS driven by primo, this is really a long, long story. It is unclear in a few words. If you are interested, you can read the following related posts:
(We can't visit the wuyou.net Forum recently, so we are helpless)
The world's first WIN7 8.1 10UEFI-RAMOS single image based on primo single driver +grub2/g4e was successfully produced-RAMOS http://wuyou.net/for...23&extra=page=1
Thank for your detailed info my friend, for now I think I will prefer free software in this case.
I understand Primo driver is faster and has other advantages on the way it uses the memory too, but as Win 10 is changing so much and so frequently there is a high possibility Primo driver may stop working to boot a RamOS in the future. and so far SVBus does a very decent work for free.
Nevertheless I will read the procedure to use Primo driver, to know better how it could be used in case I decide to buy it later.
About ntboot, I was worry about the resolution but it seems our fellow wimb just found the way to change resolution
Translated for readers convenience:
After adding the --highest=no parameter, the resolution is normal, thanks!
About ntboot for grub4dos, this link I found on one of steve6375pages takes me to Chenall site, but the link there for download ntboot, is not working anymore.
Location:The Outside of the Asylum (gate is closed)
Italy
Posted 04 January 2021 - 07:30 PM
About ntboot for grub4dos, this link I found on one of steve6375pages takes me to Chenall site, but the link there for download ntboot, is not working anymore.
Report on testing grub4dos-for_UEFI-2021-01-12.7z. Finally, I managed to boot my vhd, a complete Win10 64-bit installation hosted by Vmware. Following the suggestion of alacran, the first partition is FAT32 ( MBR ) and the second is NTFS. Memory adjusted to 15 Gb. The size of the VHD is 11 Gb. Disk partition style : GPT
Is this the same as announced in Chinese forum as grub4dos-for_UEFI-2021-01-16.7z or is 16 a newer version yet to come ?
I can't download the grub4dos-for_UEFI-2021-01-16.7z, (which is not released yet), so I can't compare both, but based on the dates I don't think they are the same.
Anyway after reading all new posts on wuyou.net it seems they are having compilation problems with the software used for this on github, and chenall is trying to find the solution to this issue, Also some members there, are mentioning they have had troubles to boot a Win10XPE ISO with all G4E January versions.
NOTE: My Win10XPE_x64.ISO is booting fine as filedisk using grub4dos-for_UEFI-2021-01-13 version.
There are some interesting new improvements on grub4dos-for_UEFI made during the last months, I will comment the last improvements made during 2021, from the info on grub4dos-for_UEFI-2021-02-10, (usual functions are already included on last version of wimb's programs).
This is new changelog_UEFI.txt file translated to English, remarked in blue new 2021 improvements:
Spoiler
Release Notes:
2021-02-10 (a1ive)
Use ACPI first to shut down.
2021-01-31 (yaya)
Support to start a differential VHD mirroring.
2021-01-12 (a1ive)
Support loading multiple initrd files.
2021-01-12 (yaya)
Increase the variable @uefi. The value is 64/32, used to determine whether the system is 64/32 bits.
Correct external commands.
2021-01-09 (yaya)
Start bootmgfw.efi.
Correct graphicsmode and displaymem functions.
New internal variables: 0x8272 (1 byte) UEFI boot environment (32/64 bit).
2020-12-15 (a1ive)
Add load command to load EFI driver.
2020-12-14 (yaya)
Compile both 32-bit and 64-bit versions at one time.
2020-12-10 (yaya)
Use "./build i386" to compile BOOTIA32.EFI.
You can use the parameter "--top" to force the image to be loaded into a memory above 4Gb.
Modify the color display of character strings, modify the read and write of mapped disks.
2020-11-26 (yaya)
Merged i386 and x86_64 source code.
Fix the hotkey and exit_g4d functions.
2020-11-19 (a1ive)
Support the use of kernel and initrd commands to start the linux kernel.
2020-11-18 (yaya)
1. Change the menu directory to: /efi/grub/menu.lst
2. Support physical CD, hard disk boot.
3. When there are multiple CDs, adjust the boot CD to the first CD to suit windows.
4. Add the function exit_g4d to exit GRUB4DOS.
5. Batch changes:
The function subscript remains unchanged, and the parameter is changed from 32 bits to 64 bits. (Fn. subscript parameter 1 parameter 2 ...)
The variable address is changed from 0x8304 to 0x8308, from 32 bits to 64 bits.
Reading general memory value is still ‘read memory address’, and reading GRUB4DOS internal value is ‘read *memory address’ (such as read *0x8308).
Add else function to batch processing. Added {script set} notation.
Such as:
if condition
{
Script set
if condition {
Script set}
else {
Script set}
}
else if condition
{
Script set
}
else
{
Script set
}
note:
1. The curly brace must be the end of a line.
2. The script set can be written in multiple lines.
3. The braces can be nested inside.
2020-10-29 (yaya)
GRUB4DOS used in UEFI environment.
This is a huge project, almost all the code has been stroked. Modified console keyboard input and output, console screen output, memory control,
Drive control, get date and time, pause control, graphics mode and Unicode font realization, PXE net start, etc.
During the development process, the GRUB2 source code was referenced. For mapping, refer to the source code of wintoflash.
1. The efi file can be launched.
2. Can start iso and img files.
3. Built-in hot key function. Example: setmenu --hotkey parameter
Differences from the old version:
1. You can view the graphics modes supported by the system through the graphicsmode command.
2. Mount after the map function is executed. There is no need to execute the --hook command.
3. Cancel --hook, --unhook, --rehook, --unmap=, --floppies=, --harddrives= commands.
4. In the UEFI environment, you can boot from a disk other than 0x80, so there is no need to swap disk operations, such as map (hd0) (hd1).
5. Cancel the delete disk function, such as map (hd1) (hd1).
6. Currently, PXE Netstart only supports tftp.
The more relevant improvemets are:
Start bootmgfw.efi fine. since 2021-01-09 version.
Correct external commands, since 2021-01-12 version.
Support loading multiple initrd files since 2021-01-12 version.
Support to start a differential VHD has been added since 2021-01-31 version.
Now it shuts down fine (and does not make a false shut down, just to reboot again in a few seconds), since 2021-02-10
And this is new Sample menu.lst translated to English.
Spoiler
# This is a sample menu.lst file. You should make some changes to it.
# It must be UTF-8 encoding to support multiple languages.
# The font should be in unifont.hex format.
#Set countdown (seconds)
timeout 30
#Set the first item as the default value
default 1
#Set the character color (the upper 32 bits are the background color, and the lower 32 bits are the foreground color. Run on the command line: echo -rrggbb to view the corresponding color.)
#color normal=0xff9933 highlight=0xffff00 helptext=0xff00ff heading=0x66ff00
#Set graphics mode (you can use graphicsmode to detect graphics modes supported by the system)
#graphicsmode -1 800 (horizontal pixels)
#Load background image
#splashimage /efi/grub/splashimage.jpg || splashimage /boot/grub/splashimage.bmp
#Load unifont font (if it is not a 16*16 font, add parameters, such as --font-high=24)
#font /efi/grub/unifont.hex.gz
#Settings menu box
#setmenu --box x=4 w=60 y=6 h=9 l=2
#Set Chinese menu button help
#setmenu --lang=zh
#Set automatic menu number
#setmenu --auto-num-on
#Set string information
#setmenu --string=x=y=color="string"
#Set date and time
#setmenu --string=x=y=color="date&time=yyyy-MM-dd HH:mm:ss"
#Set countdown
#setmenu --timeout=x=y=color
#More menu editing functions, animations, image menus, etc., please refer to http://bbs.wuyou.net...20&extra=page=3
title starts efi file
chainloader /efi/boot/grub2x64.efi
title start windows
chainloader /efi/microsoft/boot/bootmgfw.efi
title Start virtual CD
find --set-root /cdrom.iso
map /cdrom.iso (0xff)
chainloader (0xff)
title Start virtual CD (loaded into memory)
find --set-root /cdrom.iso
map --mem /cdrom.iso (0xff)
chainloader (0xff)
title Start the existing CD (cd0)
chainloader (cd0)
title Start virtual hard disk
find --set-root /boot/hdd.img
map /boot/hdd.img (hd)
chainloader (hd-1)
title Start virtual hard disk (loaded into memory)
find --set-root /boot/hdd.img
map --mem /boot/hdd.img (hd)
chainloader (hd-1)
title starts the existing hard disk (hd0)
chainloader (hd0)
title starts other menus
configfile /efi/grub/menu2.lst
title Start Linux Porteus 5.0 x86_64 openbox
kernel /porteus/vmlinuz copy2ram
initrd /porteus/initrd.xz
#Use external command ntloader
#Assuming WIM or VHD is located in (hdx,y), the path is /path/to/winpe.wim
title Start Windows WIM/VHD
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID% file=/path/to/winpe.wim
initrd /initrd.lz1
#Use external command ntloader
#Assuming the system folder is located at (hdx,y)
title Start Windows system
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID%
initrd /initrd.lz1
title command line
commandline
title Exit grub4dos
exit_g4d
title restart
reboot
title shutdown
halt
There is not a sample to boot differential VHD on the previous Sample menu.lst
Now ntloader can be loaded as an external command to boot WIM and VHD files, using following sample commands:
#Use external command ntloader
#Assuming WIM or VHD is located in (hdx,y), the path is /path/to/winpe.wim
title Start Windows WIM/VHD
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID% file=/path/to/winpe.wim
initrd /initrd.lz1
#Use external command ntloader
#Assuming the system folder is located at (hdx,y)
title Start Windows system
uuid (hdx,y)
kernel /ntloader uuid=%?_UUID%
initrd /initrd.lz1
But I assume we need to have the ntloader external command available, as it do not seems to be embeded in G4E
@ a1ive and/or @ liuzhaoyzz:
Please give us some more info about boot differential VHD, and the use of ntloader external command in G4E.
I remember I read (on wuyou.net forum) a1ive made, (from his version of ntloader used on a1ive's grub2), a new ntloader modified version to be used on G4E.
Also there is now an ext folder into grub4dos-for_UEFI-2021-02-10.7z download, with several files into it, and I would like to know better what is their use?