1025 replies to this topic

[alacran]

For people running 7 that have USB 3.0 ports from more than one OEM, I suggest them to check this topic

 

alacran

[antonino61]

I tested vhd_wimboot with an original install.wim and added drivers to it. It was perfect, even better than winntsetup. the only drawback relative to winntsetup is that the order of drives cannot be preserved. If wimb added something ..., or else I will do it thru drive management.

Getting back to drivers, how do I recognize the video card ones for deletion, as it is better to install them afresh?

[wimb]

I tested vhd_wimboot with an original install.wim and added drivers to it. It was perfect, even better than winntsetup. the only drawback relative to winntsetup is that the order of drives cannot be preserved. If wimb added something ..., or else I will do it thru drive management.

Getting back to drivers, how do I recognize the video card ones for deletion, as it is better to install them afresh?

 

I have never used and I think it is not possible to use VHD_WIMBOOT to Apply original install.wim. You can only use Captured WIM files.

Anyway I think the order of drives is not dependant on WinNTSetup  or VHD_WIMBOOT, it is just determined by the Fresh Windows Setup.

I think original install.wim does not contain NVIDIA or ATI drivers, so there is nothing to delete in case of Fresh install.wim

[antonino61]

no wimb, I did try a fresh install and added drivers to it and it did the initial boot and had all drivers preinstalled. it works perfectly. u take a fresh install wim and tick the add drivers box, and it will install with the drivers too. the drivers come from another install of course, but it is a way of saving time, and it is perfect.

as for drives, winntsetup does let u keep the same order as the install u r installing from, whereas vhd_wimboot does not. I am talking of the latest version of vhd_wimboot, where u added boxes to tick or not to tick. one of them is add drivers, for that matter, and it works perfectly. I am puzzled at ur not knowing it. 

it is correct that fresh installs do not contain nvidia drivers, but the driverstore that one places in the add drivers subfolder does.

[wimb]

I think your install.wim file does not come straight from downloaded Win10x64 ISO e.g. from TechBench

Such fresh install.wim is not accepted by VHD_WIMBOOT, but can be used by WinNTSetup also combined with additional drivers for Fresh Install of Win10x64.

This install.wim still contains several Editions .....

 

Your install.wim file must have another history .....It was processed in some way ....

 

The order of drives is determined by MountedDevices registry which is generated during Fresh Windows Setup and is not present in original install.wim  ....

[antonino61]

a single one of them was extracted by ntlite but it was not refused. wimboot only gave a scrupulous warning just in case anything went wrong, but nothing did and everything went perfectly, with all drivers installed. 

as for the drive order, if I do the same thing with winntsetup and with wimboot, the earlier does keep the order, whereas the latter does not. what this is due to, I do not know. BTW, what is the purpose of having an add-drivers box to tick or leave unticked?

[wimb]

a single one of them was extracted by ntlite but it was not refused. wimboot only gave a scrupulous warning just in case anything went wrong, but nothing did and everything went perfectly, with all drivers installed. 

as for the drive order, if I do the same thing with winntsetup and with wimboot, the earlier does keep the order, whereas the latter does not. what this is due to, I do not know. BTW, what is the purpose of having an add-drivers box to tick or leave unticked?

 

Yes when you process WIm as to have only one Index (Edition) then that install.wim is accepted by VHD_WIMBOOT.

However, Install with WinNTSetup is preferred since besides the drivers folder you can Install unattended and with selectable Tweaks and can select the Edition.

Both cases WinNTSetup and VHD_WIMBOOT should result in the same drive order, since the drive order is determined by MountedDevices registry generated during Windows Setup.

 

The purpose of the Add Drivers checkbox in VHD_WIMBOOT is to allow the User to Add some driver for new later added hardware,

but it is preferred to use WinNTSetup first to Export the non-Microsoft drivers and then use this export folder in next fresh WinNTSetup.

[antonino61]

in fact, wimb, ur vhd_wimboot installs svbus perfectly, whereas winntsetup, in the same way, does not install it at all. at least this is what I get here. your software must like me more than winntsetup, apparently.

 

btw, I have just discovered that the bitlocker stuff can be taken out as well.

[alacran]

@ wimb

 

Well my friend in order to make our VHDs capables to Ramboot on MBR and also on UEFI, it is better to make them with 2 partitions, this approach has worked fine for me:

• VHD MBR inicialized.
• First primary FAT-32 0C active Partition 64 MB, (for boot files/folders only)
• Second NTFS pimary partition, for the OS.

 

So far I was able to UEFI Ramboot a Mini-10x64.vhd Wimboot installed on a 800 MB VHD, without any issue.

 

For more info see: http://reboot.pro/to...e-4#entry217176

 

alacran

[wimb]

Well my friend in order to make our VHDs capables to Ramboot on MBR and also on UEFI, it is better to make them with 2 partitions, this approach has worked fine for me:

• VHD MBR inicialized.
• First primary FAT-32 0C active Partition 64 MB, (for boot files/folders only)
• Second NTFS pimary partition, for the OS.

 

So far I was able to UEFI Ramboot a Mini-10x64.vhd Wimboot installed on a 800 MB VHD, without any issue.

 

For more info see: http://reboot.pro/to...e-4#entry217176

 

 

Good to know that MBR VHD with two partitions FAT32 + NTFS can be used

 

for UEFI Ramboot a Mini-10x64.vhd Wimboot installed on a 800 MB VHD.

 

This configuration is certainly worthwhile to be tested.

 

Main problem is that menu.lst does not appear.

 

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

 

[alacran]

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

• 

[alacran]

This is my menu.lst 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)

During some of my tests with previous version I found if it was not on a folder then it can't be found.  That was the reason to put it into VHD folder.

 

alacran

[alacran]

Main problem is that menu.lst does not appear.

 

It works fine if located on: EFI\grub\menu.lst as said on my previous post.

 

EDIT: It is its right location starting from 2020-11-26 version, which is good as this lets us have the MBR menu.lst on the root and this way they do not interfere each other.

 

alacran

[wimb]

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

 

Very Good, this is the first time we see that UEFI Grub4dos can be used for booting VHD from RAMDISK using SVBus driver 

[gbrao]

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

How much memory is installed in your PC?

[alacran]

This has 8 Gb but I have Rambooted the 2.3 Gb VHD on MBR mode on this one and also on a 4 GB Ram PC, so I assume there is an imposed limit of 2 GB for loading on RAM on the UEFI version.

 

alacran

[gbrao]

Not sure about this, but it might have something to do with the 'chipset memory hole'.

 

Ref : http://reboot.pro/to...e-3#entry206679

[wimb]

 

Well my friend in order to make our VHDs capables to Ramboot on MBR and also on UEFI, it is better to make them with 2 partitions, this approach has worked fine for me:

• VHD MBR inicialized.
• First primary FAT-32 0C active Partition 64 MB, (for boot files/folders only)
• Second NTFS pimary partition, for the OS.

 

So far I was able to UEFI Ramboot a Mini-10x64.vhd Wimboot installed on a 800 MB VHD, without any issue.

 

For more info see: http://reboot.pro/to...e-4#entry217176

 

 

I have made a Mini10_SV.vhd with MBR and two partitions FAT32 + NTFS as you described and located in folder VHD

- the Mini10_SV.vhd is booting fine as FILEDISK in UEFI mode when launched from Windows Boot Manager menu

- booting with UEFI grub4dos and menu.lst in /EFI/grub folder does not present Grub4dos menu and there is Out of Memory message

  manually I can load the Mini10_SV.vhd into RAM, but on trying to boot I get boot_image_handle not found

 

So for me UEFI Ramboot of VHD still fails ....

[alacran]

@ wimb

 

What's the size of the Mini10_SV.vhd? If less than 2 GB it should boot fine.

 

I'm booting directly to grub4dos for UEFI so Secure Boot is disabled and CSM too.

 

If booting first to grub2 and chainloading to grub4dos for UEFI, I got the Out of memory message even on the 2046 MB VHD

 

alacran

[wimb]

What's the size of the Mini10_SV.vhd? If less than 2 GB it should boot fine.

 

I'm booting directly to grub4dos for UEFI so Secure Boot is disabled and CSM too.

 

If booting first to grub2 and chainloading to grub4dos for UEFI, I got the Out of memory message even on the 2046 MB VHD

 

 

Thanks for giving details.

 

Mini10_SV.vhd has Size 3.9 GB and I am booting first to grub2 and chainload to bootx64_g4d.efi (UEFI Grub4dos)

I need to use grub2 first since it allows UEFI Secure booting, because I cannot switch off Secure booting.

Nevertheless, the first version of UEFI Grub4dos was booting fine with menu.lst,

whereas the last version failed to present menu.lst and gives Out of Memory message.

Latest version of UEFI Grub4dos allows me to map the 3.9 GB VHD which is loaded into memory fine, but then fails to boot.

[alacran]

Well my friend only idea I have is try making a Wimboot install of the Mini-10 on a  1 or 1.5 GB VHD with same 2 partitions  and lets see if it is capable to UEFI Ramboot.

 

alacran

[wimb]

Wait .... while writing my previous post  I discovered my error ....

 

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

 

my menu.lst was on wrong location, it was located as  \grub\menu.lst whereas it should be \EFI\grub\menu.lst

 

Now latest grub4dos-0.4.6a_for_UEFI-2020-12-05.7z is presenting menu.lst fine located as \EFI\grub\menu.lst

 

3.9 GB VHD is loading fine into memory, but fails to boot - boot_image_handle not found ....

 

== 

[alacran]

Forgot to comment I also found it is better to not select any resolution or colors on the menu.lst, if booting first with grub2 because when chainloading to G4E I had issues with the screen, there was no way to see the menu.lst, it was just a green colored screen and no letters, but as Win10XPE_x64.ISO is the first and default item on the menu it just booted after 10 seconds and let me try several options until I got tired of testing this and decided to just use a simple menu for now.

 

This is my actual menu.lst

 

 

timeout 10
default 0

title Start Win10XPE_x64.ISO
find --set-root /Isos/Win10XPE_x64.ISO
map /Isos/Win10XPE_x64.ISO (0xff)
chainloader (0xff)

title Start /Isos/pcunlocker.iso
find --set-root /Isos/pcunlocker.iso
map --mem /Isos/pcunlocker.iso (0xff)
chainloader (0xff)

title Start /Isos/AcronisTrueImage.iso.gz
find --set-root /Isos/AcronisTrueImage.iso.gz
map --mem /Isos/AcronisTrueImage.iso.gz (0xff)
chainloader (0xff)

title Start /CD/linuxmint-19.3-cinnamon-64bit.iso
set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso
find --set-root %iso_path%
map %iso_path% (0xff)
root (0xff)
kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash --
initrd /casper/initrd.lz

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)

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

title Microsoft EFI Boot Manager - /EFI/Microsoft/Boot/bootmgfw.efi
find --set-root /EFI/Microsoft/Boot/bootmgfw.efi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi

title Microsoft EFI Boot Manager - /EFI/Boot/bootx64_win.efi
find --set-root /EFI/Boot/bootx64_win.efi
chainloader /EFI/Boot/bootx64_win.efi

title Grub2 - /EFI/Boot/BOOTX64.EFI   >>> This do not work
find --set-root /EFI/Boot/BOOTX64.EFI
chainloader /EFI/Boot/BOOTX64.EFI

title grubfm x64 EFI Boot Manager of a1ive - /EFI/Boot/grubfmx64.efi
find --set-root /efi/boot/grubfmx64.efi
chainloader /efi/boot/grubfmx64.efi

title command line
commandline

title Exit grub4dos
exit_g4d

title restart
reboot

title shutdown
halt
 

 

If booting from grub2 the exit_g4d take you back to grub2 (so I assume it remains loaded on Ram), halt do not shutdown, it makes the PC reboot.

 

alacran

[alacran]

@ wimb

 

It is good to know you found the cause of the lack of menu.

 

alacran

[wimb]

Wait .... while writing my previous post  I discovered my error ....

 

my menu.lst was on wrong location, it was located as  \grub\menu.lst whereas it should be \EFI\grub\menu.lst

 

Now latest grub4dos-0.4.6a_for_UEFI-2020-12-05.7z is presenting menu.lst fine located as \EFI\grub\menu.lst

 

3.9 GB VHD is loading fine into memory, but fails to boot - boot_image_handle not found ....

 

UEFI_Grub4dos_IMG_20201205_134633.jpg == UEFI_Grub4dos_IMG_20201205_134610.jpg

 

To test if a size limit of 2 GB would be causing the issue, I decided to repeat the experiment with VHD size 2048 MB with 64 MB FAT32 as first partition and rest NTFS

I used wimlib-clc to Apply to NTFS of VHD and made EFI boot files manually.

 

The result is the same as for the 3.9 GB VHD.

 

VHD is loading fine into memory, but fails to boot - boot_image_handle not found ....