VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD

I love SwiftSearch, haven't seen anything faster, this is the tool page on sourceforge: https://sourceforge....ts/swiftsearch/

Only thing it lacks is searching in FAT, but on NTFS it is almost as fast as light speed.

alacran

Thank you Wonko, great infos in your post.

I think I mixed up terms: "option to pass a parameter" with "CMDLine option". So "want/need a command line tool" is not the case.

Piping SwiftSearch output to some external program is out of bounds for me, so I will stay with good old "Everything".

everything is better in dealing with folders and files together.

VHD_WIMBOOT capture and re-apply are made using wimlib-imagex.

If you use DISM + a custom WimBootCompress.ini for this tasks it faills, and some drivers will not be written properly, inducing a lot of potential problems, one of them is per sure you will not be able to Ramboot from the VHD, and maybe not even capable to filedisk boot from the VHD.

This is an example of wimlib-imagex code capturing (not in wimboot mode) partition EFI (K:) from a Ventoy USB device to F:\Ventoy\EFI.wim.

The Ventoy device was made using following link: http://reboot.pro/to...-10#entry214811

wimlib-imagex.exe capture K:\ F:\Ventoy\EFI.wim "EFI_200527_042422" "K:/"  --include-integrity  --threads=4

alacran

This is for Wimboot capture using LZX compression, where WimBootCompress-2019-03-31.ini is my custom WimBootCompress.ini:

wimlib-imagex.exe capture %VHD_DRIVE% C:\WIMBOOT\W10x64-WB.wim    --config=D:\WimBootCompress-2019-03-31.ini --include-integrity  --wimboot  --compress=LZX --threads=4

You can omit "--threads=4", and by default all threads will be used.
 

And this is for apply:

wimlib-imagex.exe apply C:\WIMBOOT\W10x64-WB.wim %VHD_DRIVE% --wimboot

As the captured WIM file has only one index there is no need to especify the index number.

alacran

And this is for apply:

 

wimlib-imagex.exe apply C:\WIMBOOT\W10x64-WB.wim %VHD_DRIVE% --wimboot

Thanks for your great help....

I think it will be nice to use WinNTSetup command for re-apply C:\WIMBOOT\Win10x64-WB.wim to %VHD_DRIVE% in WIMBOOT mode. This way both MBR BCD and UEFI BCD will also be updated in Boot Partition. So what WinNTSetup command will be equivalent to above re-apply command ?

NO, WinNTSetup uses Windows API same as DISM and as I told you two post back:

 

If you use DISM + a custom WimBootCompress.ini for this tasks it faills, and some drivers will not be written properly, inducing a lot of potential problems, one of them is per sure you will not be able to Ramboot from the VHD, and maybe not even capable to filedisk boot from the VHD.

some drivers = user added drivers as SVBus driver (required for Ramboot), diskmod (required on Win7 and 8.x to read/write to UDB sticks or Micro SD cards having more than one partition), etc.

alacran

wimlib-imagex.exe capture %VHD_DRIVE% C:\WIMBOOT\W10x64-WB.wim    --config=D:\WimBootCompress-2019-03-31.ini --include-integrity  --wimboot  --compress=LZX --threads=4

Can you mention D:\WimBootCompress-2019-03-31.ini which you are using in your setup ?

This is my WimBootCompress.ini very last version from 2020-05-18:
   

 

This two lines were added (this files belong to my Portable PartitionWizard free):

    \Windows\System32\pwdrvio.sys
    \Windows\System32\pwdspio.sys

    I made a portable version of PartitionWizard free, and if for any reason I run it from the VHD when booting as filedisk when adding drivers, before capturing it as Wimboot, this two files are added and if they are not on the WimBootCompress.ini they will be installed on the Wimboot VHD only as pointers and then the VHD will not boot as thay need to be loaded during boot process.

    Of course if you don't boot a portable or installed version of PartitionWizard free, or if you just deleted this two files on your OS install before capture, you will not have this issue and those two lines may be erased (as I decided first), but some time latter I had troubles again and decided to keep them on the list, if you let them remain in the list they will not cause any harm and you are playing on the safe side.

From: http://reboot.pro/to...e-9#entry214854

 2020-05-18.7z   1.23KB

alacran

NO, WinNTSetup uses Windows API same as DISM and as I told you two post back:

It's looking WinNTSetup command line support WIMBoot, wimlib and also CAPTURE ?

"%wpath%\WinNTSetup%pp%.exe" VHD-CREATE -file:"%FREEDRIVE%\WIMBOOT\Win10x64-WB.vhd" -size:1536MB -type:expandable -label:"Win10x64-WB"
"%wpath%\WinNTSetup%pp%.exe" VHD-ATTACH -file:"%FREEDRIVE%\WIMBOOT\Win10x64-WB.vhd"
"%wpath%\WinNTSetup%pp%.exe" NT6 -source:"%FREEDRIVE%\WIMBOOT\Win10x64-WB.wim" -wimindex:"1" -syspart:%SYSPART% -tempdrive:%VHD_DRIVE% -Sysletter:C -WIMBoot -compact:lzx -wimlib -wbc:wimbootcompressed.ini -setup -reboot -testSigning

Is there any hope to Capture VHD to WIM in WIMBoot mode and then re-apply WIMBooted WIM to VHD using WinNTSetup command line ? How I can get %VHD_DRIVE% letter of mounted VHD after ATTACH using WinNTSetup command line ? Any Idea ? Can we specify a Drive Letter for mounted VHD when attaching it using WinNTSetup command line ?

Please Help..

I think so in the latest version, if I am not mistaken

@ devdevadev

Wimboot is deprecated since 10 was released. Then the answer is NO, and never will be fixed. And this is JFX (WinNTSetup author last comment about the subject): https://msfn.org/boa...comment=1171109

alacran

I was talking of winntsetup in my previous post. anyway, as it is not the first time alacrán and other ppl have said wimboot is deprecated, what has replaced it? next question, I have been thru many posts about wimbootcompress.ini; I remember some saying it was designed and optimized for usb booting. is there any way whatever to get the optimal wimbootcompress.ini for normal drive booting?

wimlib-imagex.exe capture %VHD_DRIVE% C:\WIMBOOT\W10x64-WB.wim    --config=D:\WimBootCompress-2019-03-31.ini --include-integrity  --wimboot  --compress=LZX --threads=4
"%path%\WinNTSetup%pp%.exe" NT6 -source:"C:\WIMBOOT\Win10x64-WB.wim" -wimindex:"1" -syspart:%SYSPART% -tempdrive:%VHD_DRIVE% -Sysletter:C -WIMBoot -compact:lzx -wimlib -wbc:wimbootcompressed.ini -setup -reboot -testSigning

Why don't you try yourself, and come back to tell us your experience doing it?

alacran

Why don't you try yourself, and come back to tell us your experience doing it?
alacran

Since you never seem to be satisfy with the answers you get, and you always find a way to ask about same thing in a different way, only things I can tell you is:

You may solve all your dubts just by testing yourself and in the process you will also learn.

And who knows, maybe you can find a better, faster or easier way to make something and then come back to tell us your findings.

So I stronly suggest you to stop asking and start testing.

alacran

Dear alacran

Thank you for your kind words showing great patience.

Sincerely   T.

Update VHD_WIMBOOT Version 2.9

- Grub4dos version grub4dos-0.4.6a-2020-02-29

- Grub4dos Menu files

- WimBootCompress.ini and WimBootCompress-W10X.ini according to alacran given here and here

- UEFI detect improved needed for Win 10x64 version 2004

- improved code to create Boot folder and boot files on internal MBR harddisk

- WARNING when internal harddisk drive is selected as Boot drive

Thanks for your new version, haven't tested yet, just downloaded.

JFYI

During expanding it to the HD I noticed it still has inside the folder SVBus_V1.1_20181109.

Newest version is SVBus_V1.2_20200428 (haven't tested it mayself yet), see interesting info from the author here:

http://reboot.pro/to...e-5#entry214468

&

http://reboot.pro/to...e-5#entry214497

Download page: https://sourceforge....projects/svbus/

I don't think you need to reupload your program with new driver version, unless you prefer to do so, the users can download SVBus driver last version from given link and only add it to your program folder, but also for their convenience can download the attached .zip file and just run it to add new folder with version 1.2 build 20200428, to have it available when needed.
 

NOTE: To avoid any possible issue with some stupid AV during download attached file is encripted.

SVBus_v1.2.zip Password is: vhd

alacran

Newest version is SVBus_V1.2_20200428 (haven't tested it mayself yet), see interesting info from the author here:

 

Thank you for Info on SVBus_V1.2  

I have added SVBus_V1.2_20200428 folder and Uploaded again

Download:  VHD_WIMBOOT-29  Or from GitHub VHD_WIMBOOT-29

Manual Updated:

6.  Reboot and use F8 menu to Boot in BIOS mode with Portable SSD and Select that New VHD from Boot Manager Menu and boot as FILEDISK

     Install of SVBus driver will FAIL when booting in UEFI mode with testsigning off as always occurs for Win 10x64 version 2004

7.  BIOS mode Install of SVBus driver use R-mouse menu to Run as admin file instx64.exe of SVBus bin folder - Driver for booting RAMDISK 

EDIT: Just tested SVBus V1.2 and can confirm that Install of SVBus followed by Capture

and Apply in 4GB expandable VHD booting from RAMDISK using Grub4dos is working OK.

A big Bravo! to wimb and alacrán for providing software that works wonders. Me, despite having to add MS Teams for my job (relocated to d:\ and junctioned back to c:\, obviously), I have managed to squeeze the content of c:\ even further, and did so in the following way:

1) full vhd1.vhd capturing to install.wim and applying the wim to vhd.vhd

2) restarting vhd1.vhd and renaming install.wim to install1.wim (to momentarily detach it from vhd.vhd

3) mounting vhd.vhd and lzx'ing its content (it shrunk considerably, but its shrinking is to be considered ephemerous)

4) resizing vhd.vhd partition but not as much as it seems to allow (see above text in brackets); considering I want videos to show their thumbnails (and by the same token pics as well) and I want ms teams to open ok when launched instead of showing its insufficient space message (it wants over a hundred megs free space not to do so), I resized my vhd.vhd from 1024mb to 550mb, which is generally stable, at least here.

5) restore install1.wim to install.wim (optional) and update the wim+vhd combo on vhd_wimboot (compulsory); should the vhd used space inflate, do not lzx it again; use wof_compress by clicking the second alternative on left part of the mask (wof_compress tool, not the first one above), and it should return to its original used/free space ratio.

6) gzipping it the fastest 8-word-size way yields a 164mb vhd.gz in less than 10 secs and load into ram as fast as vhd.vhd (not sure it is worthwhile, but this is just an opinion). the rest is a fact UNTIL ANYONE PROVES ME WRONG.

 the rest is a fact UNTIL ANYONE PROVES ME WRONG.

You are a tad bit on the defensive side, aren't you?

I guess that everyone[1] believes you on your word   and very likely noone[2] is interested in disproving your reports, take it easy man.

Wonko

[1] both the very few that can understand what you report and the ones - like myself - that don't
[2] the very few that understand how exactly the whatever you report can be replicated AND that they are actually willing to replicate it