wimb

May be Size of Hidden FAT32 drive can be reduced to 100 MB for MBR - BIOS/UEFI and GPT - UEFI types of VHD. Now it is 500 MB which is relatively large and a waste when loading e.g. a 3 GB VHD to RAMDISK for booting with UEFI Grub2 or UEFI Grub4dos.

I don't think that VHD_WIMBOOT can reduce the build time on USB Flash Drive. I suggest to use Samsung Portable SSD T5 500 GB instead, so that your problem is gone ....

Until now no problems found Tested with Fixed 2 partition VHD type MBR - BIOS / UEFI with Mini 7/8/10 x64 UsedSize 2 GB for booting with UEFI Grub4dos or UEFI Grub2 from RAMDISK. Menu entries for Mini 7/8/10 x64 in VHD as UEFI RAMOS \EFI\grub\menu.lst title Boot /2MU_10.vhd - UEFI Grub4dos SVBus RAMDISK - 3 GB find --set-root --ignore-floppies --ignore-cd /2MU_10.vhd map --mem --top /2MU_10.vhd (hd) chainloader (hd-1) title Boot /2MU_7.vhd - UEFI Grub4dos SVBus RAMDISK - 3 GB find --set-root --ignore-floppies --ignore-cd /2MU_7.vhd map --mem --top /2MU_7.vhd (hd) chainloader (hd-1) title Boot /2MU_8.vhd - UEFI Grub4dos SVBus RAMDISK - 3 GB find --set-root --ignore-floppies --ignore-cd /2MU_8.vhd map --mem --top /2MU_8.vhd (hd) chainloader (hd-1) \grub\grub.cfg menuentry "Boot /2MU_10.vhd - UEFI Grub2 SVBus RAMDISK - 3 GB" { search --file --set=vhd_drive --no-floppy /2MU_10.vhd map --mem --rt ($vhd_drive)/2MU_10.vhd boot } menuentry "Boot /2MU_7.vhd - UEFI Grub2 SVBus RAMDISK - 3 GB" { search --file --set=vhd_drive --no-floppy /2MU_7.vhd map --mem --rt ($vhd_drive)/2MU_7.vhd boot } menuentry "Boot /2MU_8.vhd - UEFI Grub2 SVBus RAMDISK - 3 GB" { search --file --set=vhd_drive --no-floppy /2MU_8.vhd map --mem --rt ($vhd_drive)/2MU_8.vhd boot }

You are right, indeed the GPT - UEFI type VHD has 2 partitions with hidden FAT32. My remark was wrong and is removed by strikethrough. Indeed the MBR - BIOS / UEFI type is booting in MBR BIOS mode from Windows Boot Manager as FILEDISK. My remark was not clear, but I meant to say that this type of VHD does not boot with MBR Grub4dos from RAMDISK. The MBR - BIOS / UEFI type VHD is bootable with Grub4dos from RAMDISK when the menu.lst entry takes into account that file bootmgr is on second partition. It is my fault and this boot problem can be solved easily

Continued testing version 4.5.0 Beta 3 for booting Mini 10x64 in VHD as UEFI RAMOS MBR - BIOS Fixed and Dynamic VHD fail with UEFI Grub2 and UEFI Grub4dos as expected since VHD internal EFI folder is missing GPT - UEFI Fixed VHD booting OK with UEFI Grub2 and UEFI Grub4dos GPT- UEFI Dynamic VHD fail with UEFI Grub2, but booting OK with UEFI Grub4dos WinNTSetup GPT UEFI VHD's don't have internal EFI folder, but can boot UEFI RAMOS VHD_WIMBOOT GPT 1 Partition VHD have internal EFI folder which is required to boot UEFI RAMOS How come this difference ? GPT - UEFI type VHD has hidden FAT32 partition that contains EFI folder. The main difference is the number of Hidden Sectors which is 2048 in case of WinNTSetup created VHD and 128 in case of VHD_WIMBOOT VHD created with diskpart. (wrong conclusion strikethrough) WinNTSetup New type MBR - BIOS / UEFI Fixed VHD are quite interesting for MBR and UEFI RAMOS as having 2 Partitions layout given by MBR (NTFS + Hidden Active FAT32) Problem is that this type of VHD does NOT boot in MBR BIOS mode probably since FAT32 has partition type EF which should be 0C to be compatible with MBR booting Changing partition type to 0C is not enough, this VHD still does NOT boot in MBR BIOS mode with Grub4dos from RAMDISK. EDIT: Added Grub4dos from RAMDISK in: VHD still does NOT boot in MBR BIOS mode with Grub4dos from RAMDISK Sure this VHD with MBR - BIOS / UEFI type is booting in MBR BIOS mode from Windows Boot Manager Menu EDIT2: The MBR - BIOS / UEFI type VHD is bootable with Grub4dos from RAMDISK when the menu.lst entry takes account that file bootmgr is on second partition. So this boot problem can be solved easily VHD_WIMBOOT Fixed 2 Partition VHD has layout MBR ( Active FAT32 + NTFS) that can be used for booting with MBR Grub4dos and UEFI Grub4dos and UEFI Grub2 from RAMDISK In case drive Y: is used already then Create VHD fails to assign drive letter to the created VHD May be this can be improved by using other drive letter in case of conflict. In any case WinNTSetup 4.5.0 Beta 3 is very good program to create various types of VHD that can be used for UEFI RAMOS

Did already some tests with VHD new type MBR - BIOS/UEFI and Mini 10x64 UsedSize 2.1 GB as UEFI RAMOS - Fixed VHD booting OK with UEFI Grub2 and with UEFI Grub4dos - Dynamic VHD booting fails for UEFI Grub2 (loading into RAM stops at 82%) and booting is OK for UEFI Grub4dos Your program is so powerful that Microsoft Defender decides to remove it immediately when VHD Create finishes. (Trojan etc ...) Until now no problem with 0x0 error ...

Update VHD_WIMBOOT-50 Download: from wimb GitHub - VHD_WIMBOOT-50-E and SVBus-signed_2-E.zip Download File E = Encrypted PassWord = bootwimb and SVBus PassWord = reboot.pro Manual: VHD_WIMBOOT.pdf and More Info at reboot.pro USB_FORMAT Tool and UEFI_MULTI and VHD_WIMBOOT Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver !! otherwise wimlib and Boot errors will occur ..... - Update UEFI Grub2 and Grub2 FileManager - Update UEFI Grub4dos (= Grub4efi Or G4E) which adds support for GPT layout of VHD for UEFI RAMOS booting VHD with GPT layout is not compatible with MBR Grub4dos booting, which requires MBR Partitioning of VHD

Yes, indeed Fixed VHD with GPT layout as made with WinNTSetup works OK for all cases of UEFI RAMOS Booting of UEFI RAMOS tested with UEFI Grub2 or latest UEFI Grub4dos from internal SSD or from USB SSD. In this case there is no VHD internal EFI folder and this is working OK. GPT - UEFI type VHD has hidden FAT32 partition that contains EFI folder. VHD with GPT layout is not suitable for booting with MBR Grub4dos from RAMDISK using SVBus driver. Do you have a solution for the error that in some cases VHD Create fails to assign drive letter to the new Fixed type VHD ?

New official release of UEFI Grub4dos available ....

Thank you for the new version 4.5.0 Beta 2 In general one can say that WinNTSetup 4.5.0 Beta 2 in normal use is working OK now However in some cases VHD Create fails to assign drive letter to the new Fixed type VHD. Also I tried to use the New Created Fixed VHD's for booting in UEFI mode from RAMDISK using UEFI Grub2 Or UEFI Grub4dos and using signed SVBus driver. It turns out that the Fixed VHD's created and Applied with WinNTSetup are not compatible with UEFI RAMOS booting, probably since VHD internal EFI folder is missing ... For UEFI booting from RAMDISK the most compatible VHD is Fixed VHD with MBR 2 Partitions (Active FAT32 100 MB + NTFS) containing VHD internal Boot and EFI folder ONLY on FAT32. Fixed VHD with MBR 1 Partition NTFS can be used but must contain UnCompressed Boot and EFI folder for booting with MBR Grub4dos and UEFI Grub2 / UEFI Grub4dos. The WinNTSetup Created VHD has 4096 hidden sectors instead of 128 hidden sectors in case of VHD created with diskpart, The WinNTSetup Created VHD is compatible with VHD_WIMBOOT and after Apply in VHD_WIMBOOT then the VHD can be used for UEFI RAMOS booting.

Fragmentatition does not matter with SSD, but fragmentation can matter for booting when VHD file itself is fragmented .... UEFI RAMOS requires Fixed VHD.

I think Fixed VHD is preferred and should stay as recommended. - Dynamic VHD will as it grows gradually results in fragmentation of the VHD file itselves which is undesired behaviour. - Fixed VHD is needed for the very new UEFI booting from RAMDISK using UEFI Grub2 and UEFI Grub4dos

That is not the point that my remark was about. My point is: (probably due to the fact that my normal OS is running in VHD instead of partition) Just when I start WinNTSetup then the hidden EFI drive of GPT partitioned disk is Not automounted anymore as drive Z: and the Boot Drive is not autoselected as that drive Z: anymore. This has nothing to do with creating VHD. In my case I have OS in existing VHD located on GPT SSD with Hidden EFI drive as Boot Drive Also In Create VHD the Fixed size (recommended) option is not preselected as default option anymore.

Hidden EFI drive is not automounted anymore in 4.5.0 Beta 1 That means it is not easy to select the Boot Drive for install on GPT partitioned disk. Previous versions auto give Boot Drive is Z: as the automounted hidden EFI drive. In Create VHD the Fixed size (recommended) option is not preselected as default option anymore.

Update VHD_WIMBOOT-47 Download: from wimb GitHub - VHD_WIMBOOT-47-E and SVBus-signed_2-E.zip Download File E = Encrypted PassWord = bootwimb and SVBus PassWord = reboot.pro Manual: VHD_WIMBOOT.pdf and More Info at reboot.pro USB_FORMAT Tool and UEFI_MULTI and VHD_WIMBOOT Always Shut-Off AntVirus Software and Disable Windows Defender when working with signed SVBus driver !! otherwise wimlib and Boot errors will occur ..... - Update Grub2 to latest version - Added Checkbox Update G - Forces Update of UEFI Grub2 and UEFI Grub4dos and MBR Grub4dos Boot files given in UEFI_MAN and makebt folder - Added UEFI Grub2 menuentry using ntboot instead of efiload ntfs_x64.efi driver in case of 1 Partion VHD for RAMOS booting - Added WARNING in case FileSystem of existing VHD is not FAT32 + NTFS in case of 2 Partitions Or NTFS in case of 1 Partition VHD Preferred is to use default settings - Fixed VHD with MBR 2 Partitions (Active FAT32 100 MB + Rest NTFS) UEFI Grub2 ntboot SVBus - menuentry for 1 Partition VHD menuentry "Boot /1P_10_NT.vhd - UEFI Grub2 ntboot SVBus RAMDISK - 3.0 GB" { search --file --set=vhd_drive --no-floppy /1P_10_NT.vhd map --mem --rt ($vhd_drive)/1P_10_NT.vhd ntboot --win --highest=no --efi=(vd0,1)/EFI/Microsoft/Boot/bootmgfw.efi --winload=\\Windows\\System32\\winload.efi (vd0,1) }

Done ! Update USB_FORMAT-52 and UEFI_MULTI-52 and VHD_WIMBOOT-44 Download: from wimb GitHub USB_FORMAT-52 and UEFI_MULTI-52 and VHD_WIMBOOT-44 Download File E = Encrypted Password = bootwimb Manual: VHD_WIMBOOT.pdf reboot.pro is alive again ....

Yes you are right. Instead of grub2 of a1ve it is grub2 of a1ive ..... That mistake also occurs also quite often at reboot.pro

OK thank you for WOF Status report. removal of EFI folder requires Trusted Installer, but renaming of EFI folder as x-EFI can be done as Administrator. The EFI folder inside VHD is already created by WinNTSetup and cannot be removed simply. VHD_WIMBOOT Capture and Apply will prevent WOF Compression of EFI folder inside VHD when new WimBootCompress,ini is used as present in VHD_WIMBOOT-43 What I can do is to modify UEFI_MULTI and VHD_WIMBOOT so that in case of 2 Partition VHD that EFI folder is not made in NTFS partition and when present is renamed as x-EFI. I think this can solve the problems encountered with EFI folder in NTFS partition of 2 Partition VHD's Also new UEFI Grub4dos version will be used, but give me some time to realise it ..... May be reboot.pro will be a!ive soon .... I mean of course alive .... I see that you often speak of grub32.efi whereas it is grubia32.efi ......

Update USB_FORMAT-54 and UEFI_MULTI-55 plus the Addon-agFM files Download: from GitHub USB_FORMAT-54 and UEFI_MULTI-55 Download File E = Encrypted Password = bootwimb Manual: VHD_WIMBOOT.pdf - Added UEFI Grub4dos and a1ive UEFI Grub2 for UEFI booting VHD from RAMDISK - Use Super UEFI setting for UEFI Secure booting - Added signed SVBus driver for UEFI booting VHD from RAMDISK - Checkbox Add Grub2 System Folder (Often Unneeded - Unchecked saves Copy time and space for 1000 files 12 MB) - UEFI_MULTI - Added WofCompress of JFX to UnCompress EFI folder inside VHD when Making Boot entries - EFI folder in VHD needs to be UnCompressed in case of UEFI booting 1 Partition VHD from RAMDISK - UEFI grub4dos version 2020-12-26 - in case of 2 Partition VHD then EFI folder is not made in NTFS partition and when present is renamed as x-EFI In my case ntfs_x64.efi driver is not needed anymore for UEFI booting of 1 Partition VHD from RAMDISK using UEFI Grub2 Or UEFI Grub4dos The boot problem of 1 Partition VHD was entirely due to WOF Compression of EFI folder and this problem is solved now Credits and Thanks to: - a1ive for making UEFI Grub2 and Grub2 FileManager - yaya2007 and a1ive for making UEFI Grub4dos - alacran for help and support - liuzhaoyzz for help in solving boot_image_handle not found problem in case of UEFI Grub4dos More Info: at reboot.pro Forum VHD_WIMBOOT and Grub4dos for UEFI and USB_FORMAT and UEFI_MULTI ==

Update VHD_WIMBOOT Version 4.4 Download: from GitHub VHD_WIMBOOT-44 and Win_Reduce_Trusted-40 to make Mini 7/8/10 x64 in VHD with UsedSize about 2 GB Download File E = Encrypted Password = bootwimb Manual: VHD_WIMBOOT.pdf - Make fixed VHD with MBR and 2 Partitions (Active 100 MB FAT32 + rest NTFS) suitable for UEFI booting VHD from RAMDISK - Added UEFI Grub4dos and a1ive UEFI Grub2 for UEFI booting VHD from RAMDISK - Added signed SVBus driver for UEFI booting VHD from RAMDISK - Added WofCompress of JFX to UnCompress EFI folder inside VHD when Making Boot entries - EFI folder in VHD needs to be UnCompressed in case of UEFI booting 1 Partition VHD from RAMDISK - makebt\WimBootCompress.ini file adjusted so that entire EFI and Boot folder will be UnCompressed after Capture and Apply in Compact and WimBoot mode - UEFI grub4dos version 2020-12-26 - in case of 2 Partition VHD then EFI folder is not made in NTFS partition and when present is renamed as x-EFI In my case ntfs_x64.efi driver is not needed anymore for UEFI booting of 1 Partition VHD from RAMDISK using UEFI Grub2 Or UEFI Grub4dos The boot problem of 1 Partition VHD was entirely due to WOF Compression of EFI folder and this problem is solved now Credits and Thanks to: - a1ive for making UEFI Grub2 - yaya2007 for making UEFI Grub4dos - alacran for help and support - liuzhaoyzz for help in solving boot_image_handle not found problem in case of UEFI Grub4dos More Info: VHD_WIMBOOT and Grub4dos for UEFI ==

1. WinNTSetup - Fresh Install in 25 GB Fixed VHD located on internal SSD / Harddisk using Win10x64 ISO from TechBench 2. VHD_WIMBOOT - Capture WimBoot LZX and Apply in Compact LZX mode in Fixed VHD 10 GB - Offline Windows 3. Mount VHD with doubble-click and use Win_Reduce_Trusted on Offline Windows - Reduce in 1 minute gives Mini 10x64 VHD UsedSize = 1.79 GB - Capture WimBoot LZX WIM = 1.19 GB and Apply Compact LZX in 3.9 GB Fixed VHD with MBR 2 Partitions 4. Boot with 3.9 GB VHD as FILEDISK using Windows Boot Manager menu - Always use the supplied Firewall App Blocker and Enable WhiteList to Allow Internet Browser only - This is the easiest way to block unwanted internet traffic including Windows Update and prevents the growth of Used Size inside VHD 5. Install signed SVBus driver in running Windows of 3.9 GB VHD - needed for UEFI booting from RAMDISK - Install SVBus EVRootCA Registry Fix in runnung Windows - use SVBus-signed_2 folder - Install SVBus Driver as Admin - use R-mouse on instx64.exe in SVBus-signed_2 folder - Reboot VHD first as FILEDISK from Windows Boot Manager to make Install of SVBus driver effective - Reboot with your normal Win 10x64 operating System 6. USB_FORMAT - make portable USB SSD with MBR and 2 partitions (FAT32 + NTFS) 7. Copy 3.9 GB VHD to NTFS drive of USB prepared with USB_FORMAT 8. UEFI_MULTI - Select FAT32 Boot Drive and NTFS System Drive of USB - Select Super Grub2 as Boot Manager and Select the Mini 10x64 3.9 GB VHD copied to NTFS drive of USB - use GO to Add VHD 4x as Menu Entry for booting with UEFI Grub2 and UEFI Grub4dos and Windows Boot Manager (MBR Boot and UEFI) and MBR Grub4dos 9. Reboot and use F8 menu to Boot from USB in UEFI mode with Grub2 Or in MBR BIOS mode with Windows Boot Manager - Select to Boot Mini 10x64 VHD 3.9 GB from RAMDISK in UEFI mode using SVBus driver - Or chainload other menu's

New from a1ive UEFI Grub2 that can be used for booting Mini10 VHD from RAMDISK. Download: latest Grub2 of a1ive has support for svbus More Info: UEFI Grub2 at reboot.pro in Grub4dos for UEFI topic In Admin Command Window use Diskpart to make VHD which needs to have MBR and 2 partitions - 100 MB FAT32 + rest NTFS create vdisk file="D:\VHD\Mini10_SV.vhd" maximum=3900 type=fixed select vdisk file="D:\VHD\Mini10_SV.vhd" attach vdisk create partition primary size=100 format quick fs=fat32 label="EFI_VHD1" assign active create partition primary format quick fs=ntfs label="Mini10_SV_VHD2" assign list vol exit Signed SVBus driver from a1ive is needed to allow using grub.cfg menuentry - Password=reboot.pro otherwise grub2 commands must be used and allow unsigned SVBus driver by F8 menu UEFI grubx64.efi located in EFI\Boot expects as configfile \boot\grub\grub.cfg EFI\Boot folder according to UEFI_MULTI-50 with UEFI_MAN\efi\Boot where grubx64_real.efi is replaced by new a1ive UEFI Grub2 file Grub2 command to get menu configfile /boot/grub/grub.cfg Grub2 menuentry in grub.cfg menuentry "Mini10_SV.vhd from RAMDISK" { map --mem --rt (hd0,gpt2)/VHD/Mini10_SV.vhd boot }

Update VHD_WIMBOOT Version 4.0 Download: from GitHub VHD_WIMBOOT-40 and Win_Reduce_Trusted-40 to make Mini 7/8/10 x64 in VHD with UsedSize about 2 GB Manual: VHD_WIMBOOT.pdf - Modified base_winsxs_2.cmd of cdob so that hardlinks are created for \Windows\WinSxS\*_microsoft-windows-servicingstack* sevicingstack is needed for support of Adding Drivers by means of Dism.exe - Add Drivers 7/8/10 in Offline Windows by using Dism.exe - Not suitable to Install SVBus Driver for booting from RAMDISK Boot in MBR mode for Install of SVBus driver - use R-mouse menu to Run as admin file instx64.exe of SVBus bin folder - Update USB 7/8 Fix - Scan Offline Registry for USB3 Services as listed in file makebt\USB_78_Tweaks\Win78_USB3_Boot.ini When Service for Installed USB3 driver is found then make USB Controller Service setting Start=0 and BootFlags=4 and Group=System Bus Extender In this way more hardware is supported for booting Win 7/8 VHD from USB More Info on booting Win7/8 from USB given by cdob and info on how to get USB3 drivers

Good to start here at MSFN discussion about grub4dos for UEFI. The English download location for latest grub4dos-0.4.6a_for_UEFI-2020-11-26.7z is found at GitHub grub4dos Releases

Update VHD_WIMBOOT Version 3.7 Download: from GitHub VHD_WIMBOOT-37 and Win_Reduce_Trusted-37 - USB Fix 7/8 - registry tweak Win7 and UsbBootWatcher.conf for USB Boot Updated - Added Service Settings - Intel iusb3xhc and iusb3hub and ASMedia XHCI asmtxhci and asmthub3 - Start=0 and BootFlags=4 and Group=System Bus Extender UsbBootWatcher is useful also when booting from USB on other hardware to have the right USB service settings for that case. Win_Reduce_Trusted allows to modify Offline Windows 7/8/10 in VHD - General Post Install Modifications - Reduce UsedSize in VHD to about 2 GB - make Mini 7/8/10 x64 in VHD booting as FILEDISK from USB / SSD and booting from RAMSDISK using SVBus driver - Add Folders and Files and Registry Tweaks - e.g. Add FirewallAppBlocker and SwiftSearch - USB Fix 7/8 for booting 7/8 VHD from USB - run Custom Command for post install modifications