Jump to content











Photo
- - - - -

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

ramdisk svbus wimlib grub4dos windows 10 ssd usb wim wimboot vhd

  • Please log in to reply
202 replies to this topic

#151 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

and what u just said is the cause for my wimboot capturing and applying not working and my dism capturing and applying working - i don't mean to contest u, i simply mean that there must be a reason for the earlier not working and the latter working here, don't u think?

 

my wimbootcompress.ini is almost bare and it works; dism does take it into account and your wimlib does not, apparently. dism here yields a slightly bigger wim image (4.1 instead of 3.99) and allows for a better compression of the related vhd and boots ok. at least here the wimboot tool yields an incomplete vhd (for example, nvidia control panel missing from taskbar) which boots erratically.

 

of course, if there are any technical errors in the bare character of my wimbootcompress.ini, I am in no position to say. I can only state what happens here.  

 

But have you tried the former with the old version attempting to create a bigger vhd and a smaller wim re-applying the latter with the newer approach?[1]

 

 

 

:duff:

Wonko

 

[1] You see :), I am perfectly capable of writing incomprehensible and meaningless blurbs, but usually conversations - particularly on technical matters - require:
1) clarity
2) exactness

both completely missing in your late posts.

 

I understand you did a lot of experiments, but unless you detail, exactly, what you did and report, again, in detail and exactly the results, noone will be able to understand you, let alone try and assist you in finding the mistakes (if any) you did or suggest better or alternative methods/tools.
 



#152 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

wonko, you are talking of a bloody wim and a bloody vhd, expecting einstein-like clarity. pls. what do u expect to happen from a capturing of a system into a wim image and a consequent applying of the image into a wimboot vhd? the consistence (or consistency) which anyone would, that is to say what u find in the integral vhd logically matching the wimboot vhd. if the latter has less than the former in logical terms (of course not in physical ones, the wimboot vhd is rightly smaller) in one case and exactly the same as the former in another, this is enough of a difference - it means one tool does let u have the same content (still in logical terms) and the other does not (still in logical terms) - what other information do u need to understand? Anyway I think u missed exactly what u consider detailed - my wimbootcompress.ini content, which I apparently posted later than u replied.

 

; This is the inbox configuration file used for deploying or capture a
; WIMBoot system. Please do not remove this file because WIMCaptureImage 
; and WIMApplyImage will fail if WIM_FLAG_WIM_BOOT flag is specified.
 
[CompressionExclusionList]
ntoskrnl.exe
 
[PrepopulateList]
\bootmgr
\Boot\BCD
*winload.*
 
[ExclusionList]
 
[CompressionFolderList]


#153 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

Wonko, u dont detest me, u just loathe my wording.



#154 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

Sure I don't detest you. :)

 

I simply hate (personally) your use of abbreviations, often unmotivated, such as "u" instead of "you", or confusing, like having in the same sentence g4d, G4D and 4gb[1] and the lack of [CR+LF] or newline after the full stops (or periods) to parse easily sentences.

 

But I am not an English professor, let alone a literary critic, and, as long as the contents are understandable, all that is fine.

 

When the overall meaning of a post is undefined, unreferenced, apodictical or vague (and possibly also "wrong") there it starts the issue, like:

 

 

 


At least here, dism tool appears to be the most coherent tool for faithful capturing and applying, even if the wimboot tool deems it incompatible, or not so compatible (but then it does the wimboot job ok).

 

and, when Wimb noted the inconsistency, your original reply (not that after the added info it is much better as you added 1 (one) piece of info), your 

 

 

 


and what u just said is the cause for my wimboot capturing and applying not working and my dism capturing and applying working - i don't mean to contest u, i simply mean that there must be a reason for the earlier not working and the latter working here, don't u think?
 
my wimbootcompress.ini is almost bare and it works; dism does take it into account and your wimlib does not, apparently. dism here yields a slightly bigger wim image (4.1 instead of 3.99) and allows for a better compression of the related vhd and boots ok. at least here the wimboot tool yields an incomplete vhd (for example, nvidia control panel missing from taskbar) which boots erratically.
 
of course, if there are any technical errors in the bare character of my wimbootcompress.ini, I am in no position to say. I can only state what happens here.  

 

is assuming that everyone else know exactly which EXACT command(s) and parameter(s) you used, which EXACT source, which EXACT settings, etc., etc., i.e. the "standard litany":

https://jdebp.eu/FGA...ard-litany.html

 

We are in the (unpleasant) phase of "forcing everyone to spend one or more rounds of communication back and forth simply trying to wring the relevant information out of you".

 

You may have been doing this unknowingly, now you have been told.

https://jdebp.eu/FGA...oolishness.html

 

:duff:

Wonko

 

 

[1] it's ok, because you later mentioned 3.5gb and 0.5gb



#155 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

wonko, everybody is entitled to their own likes and dislikes, so I will not beg to differ.
 
as for 3.5 i dont know where u got it from. I simply said the dism capturing yielded a 4.1gb wim file, as opposed to the correspondent one yielded by the wimboot tool, which was a 3.9gb wim. 0.5gb is the size of the vhd that I obtain if I apply the 4.1gb wim image thru the wimboot tool. the options or scenarios being the following:
 
procedure number 1) os --> dism tool capturing --> 4.1gb wim
 
procedure number 2) os --> wimtool capturing --> 3.9gb wim
 
procedure number 3) 3.9gb wim --> non-wimboot wimtool applying --> 25gb vhd was not enough, had to resort to the 50gb option, at least here, the same issues as in procedure number 5)
 
procedure number 4) 4.1gb wim --> wimboot wimtool applying --> 0.5gb vhd (consistent, at least here, ---> lz4 ---> 0.18gb, working fine)
 
procedure number 5) 3.9gb wim --> wimboot wimtool applying --> 1.5gb vhd (inconsistent, incomplete, at least here, ---> lz4 ---> not even tried, too much of a nuisance to even go further)
 
I hope this is enough further info; if it is not, pls do not hesitate to ask, possibly without tachigraphic prejudice, which gets anybody nowhere (I do not work in a suit and tie). 


#156 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

 

as for 3.5 i dont know where u got it from. 

 


It is a pity not to invest further time and energy on a faultless 4gb version of windows. yes, 3.5gb for the wim and 0.5gb for the vhd (well, lz4'd, of course), but still nice, small and faultless, with all comforts. Now let us see if we are able to put our eggs in the right basket.
nino

 

You are welcome, I am sure :).

 

:duff:

Wonko



#157 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

Wonko, that was on a previous post, 3 or 4 wim+whd combos ago



#158 wimb

wimb

    Platinum Member

  • Developer
  • 2682 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 2 weeks ago

I have made in about 7 minutes a Win10XPE WIM file based on 1909 version of Windows 10 x64

 

Capture and Apply of WIM files with VHD_WIMBOOT is much faster in Win10XPE environment as compared to Win10 x64 environment.

 

More Info here Attached File  VHD_WIMBOOT.pdf   696.57KB   22 downloads

 

Win10XPE-2019-11-25_103854.png == Win10XPE-2019-11-25_103938.png == Win10XPE-2019-11-25_101637.png == Win10XPE-2019-11-25_102142.png  

 

:cheers:

 

EDIT:

The Windows Defender in Win10 x64 OS environment slows down the Capture and Apply of WIM files.

After swithing Defender Off then Win10 x64 OS results for Capure and Apply correspond quite well to Win10XPE x64 environment.

Thanks to ReTokener for indicating that defender might be the reason of the 4x higher Capture time in Win10 x64 OS environment. 



#159 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

Wonko, that was on a previous post, 3 or 4 wim+whd combos ago

It was 6 (six) days ago, and exactly where you seemed to start "going astray" (we use days as a unit of measure of time, not unreferenced wim+vhd builds), I expressly said "late posts" at a time where that post was your third last post.

 

 

Capture and Apply of WIM files with VHD_WIMBOOT is much faster in Win10XPE environment as compared to Win10 x64 environment.

Only to understand, is the Win10XPE also 64 bit or is it 32 bit? :unsure:

:duff:
Wonko



#160 alacran

alacran

    Gold Member

  • .script developer
  • 1174 posts
  •  
    Mexico

Posted 2 weeks ago

Yes, I can confirm making a capture/apply with DMS (Dism based) or a capture/apply with wimboot-clc (wimlib-imagex based) is faster from Win10XPE_x64.wim than from the full OS Win10x64 but in my case, I have been using 10 v1809 as OS and also as source for the WinPE.

 

Also for capture wimlib-imagex is faster and with small size of captured file at same compression level, the oposite happends during Apply the image, in this case Dism is faster, my scratch folder when using DMS during capture or apply from WinPE is always on a dir on phisical HD, I really don't know if this can make any influence  but just in case.

 

alacran



#161 wimb

wimb

    Platinum Member

  • Developer
  • 2682 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 2 weeks ago

Only to understand, is the Win10XPE also 64 bit or is it 32 bit? :unsure:

 

Win10XPE is made from ISO file Win10_1909_English_x64.iso

 

Booting with Win10XPE x64 WIM file size 867 MB installed by UEFI_MULTI as boot option on Internal SSD

is extremely fast - loading into RAMDISK in 3 seconds and total boottime 30 seconds.

 

Here are some measurements all based on Win10 x64 1909 and using VHD_WIMBOOT (=wimlib) in WIMBOOT mode

 

In Win10XPE x64 environment - wimlib Capture 150 sec and Apply 41 sec

In Win10 x64  OS environment - wimlib Capture 605 sec and Apply 60 sec - defender on

In Win10 x64  OS environment - wimlib Capture 150 sec and Apply 45 sec - defender off

 

EDIT:

The Windows Defender in Win10 x64 OS environment slows down the Capture and Apply of WIM files.

After swithing Defender Off then Win10 x64 OS results for Capure and Apply correspond quite well to Win10XPE x64 environment.

Thanks to ReTokener for indicating that defender might be the reason of the 4x higher Capture time in Win10 x64 OS environment. 



#162 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

wonko, I sometimes try 3 builds a day, while others 2, while others yet I keep 1 build for months. anyway u have good reason to trust or distrust whom u like to. I suggest u be more stochastic, but what can I do if u choose to be pseudo-deterministic. u miss out on a lot, believe me, but all in all, have it ur way.



#163 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 234 posts

Posted 2 weeks ago

 

wimb #161

In Win10XPE x64 environment - wimlib Capture 150 sec and Apply 41 sec

In Win10 x64  OS environment - wimlib Capture 605 sec and Apply 60 sec

could the capturing time be influenced by defender?


  • wimb likes this

#164 wimb

wimb

    Platinum Member

  • Developer
  • 2682 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 2 weeks ago

could the capturing time be influenced by defender?

 

You are right  :)

 

After switching off Windows Defender, then in Win10 x64 OS environment - wimlib Capture 150 sec

 

So the difference in wimlib Capture time is totally due to Defender  :huh:



#165 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

could the capturing time be influenced by defender?

Very good :thumbsup:.
 

You are right  :)
 
After switching off Windows Defender, then in Win10 x64 OS environment - wimlib Capture 150 sec
 
So the difference in wimlib Capture time is totally due to Defender  :huh:

 
All's Well That Ends Well. :)
 
@Antonino
Much Ado about Nothing :w00t:
As You Like It :frusty:

(Wonko sometimes simply loves using the Immortal Bard's titles and board emoticons to express himself)

:duff:
Wonko

#166 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

I can confirm that capturing with dism yields more consistent results than capturing with wimboot, at least here, have tried it again today. I would like to remind u all that my wimbootcompress.ini is almost bare, but still I do not see any difference in the results of the applying stage. No need to specify any further, unless otherwise asked, not unless otherwise pontificated against. I am still baking the consequent vhd. consequent means that it was caused by all the previous work that's is required; this further specification is purely ironic.



#167 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

Well, done, I can only corroborate what I said in my previous post. 3.9gb wim + 576mb vhd (lz4'd to 73mb) combo. here are the steps I have taken:

 

1) launching lzx.bat on my latest integral vhd os (whichever it is, it is the same all the way down the line, so it is intrinsically scientific);

2) restarting in order to make the effect of the overall compression settle into a workable deployment;

3) shrinking the vhd to the smallest workable measure, thus leaving 1.5gb free space for an overall vhd size of 6gb;

4) resizing it with vhd resizer;

5) making a copy of this vhd and capturing it with Dism tool (lzx) - the same with wimboot tool yields erratic results, today again;

6) optimizing the resulting wim (lzx:800) - it is the most extreme level that gives a substantial gain in space (no sense in trying any greater level);

7) now and only now using wimboot tool to apply it to a wimboot vhd (1gb, the least allowed by the software);

8) restarting with the original integral vhd (the one in 3 and 4);

9) launching lzx.bat on the wimboot vhd (the 1gb one)

10) restarting with the wimboot vhd in order to make the effect of the overall compression settle into a workable deployment;

11) shrinking the wimboot vhd to the fully smallest workable measure (579mb to be precise);

12) resizing it with vhd resizer;

13) launching lz4 compressor tool on it (parameters -150 --content-size, the best I could find) --> 73mb lz4 file

14) everything working ok (no free-space bulging, no issues).

 

BTW: I repeat, my wimbootcompress.ini all over the places (folders) concerned (system32, syswoa or whatever it is called and wimboot makebt:

 

; This is the inbox configuration file used for deploying or capture a
; WIMBoot system. Please do not remove this file because WIMCaptureImage 
; and WIMApplyImage will fail if WIM_FLAG_WIM_BOOT flag is specified.
 
[CompressionExclusionList]
ntoskrnl.exe
 
[PrepopulateList]
\bootmgr
\Boot\BCD
*winload.*
 
[ExclusionList]
 
[CompressionFolderList]

 

 

hope this is enough info now, but if it is not, i am willing to provide - no sense in ruling it all out, what good will it do?



#168 alacran

alacran

    Gold Member

  • .script developer
  • 1174 posts
  •  
    Mexico

Posted 2 weeks ago

@ wimb

 

Update VHD_WIMBOOT Version 2.8

 

- Added WimBoot Mode checkbox - when unchecked it enables Apply of Full Windows in VHD instead of WimBoot Mode

 

Download:  VHD_WIMBOOT and

 

 

If I may make a suggestion, with this option available now, it will be good to add an option to instal in Compact mode, available options on wimlib for compact mode are 4K, 8K, 16K and LZX.

 

4K is the default used by MS on Dism (and also on wimlib), and using this compress level the OS automatically compress all new info added (as far as it is compresible), as drivers, documents, or any other file/folder that has changed from its initial state.

 

If using a higher compression level the OS will not compress the added or modiffied files/folders automatically, the user then has to do it manually if desired, but running your WOF_Compress may do it safely using JFX WimBootReCompress.ini

 

The Compact mode can be used on fixed and expandable VHDs, and using both together I made manually (using wimlib-clc) on September a 10x64-EC4.vhd (Expandable, Compact 4K), max expanded size is 7 GB, used space is 4.57 GB and free space is 2.42 GB as you can see on attachment, in order to make the install minimal no additional drivers were installed, only Office 2003 + Compativily pack for Office 2007 and higher, and a few other programs as CCleaner and Defraggler, all other programs are portables located outside of the VHD on the root of the storage device.

 

If using Compact mode LZX (WIM files default compression) the expandable VHD size will be close to the size of the WIM used to install it, but as said before the used space will increase during use (but as also said can be recompressed when requiered), havent tested Compact LZX myself, I prefer to be conservative and use 4K and let the OS do the task, it is good to run from inside de VHD CCleaner to clean all garbage files and Defraggler to defragment the OS (preferable on a HDD) before copy it to our SS device.

 

As you already have a check box to select LZX and Compact 4K is default if giving only this 2 options you will need to add only a check box for Compact on the program screen (of course after making all required code).  8K and 16K do not improve very much the saved space, maybe only about 4 to 7 % more saving than 4K respectively, depending on compressivility of files/folders), LZX is the best on reducing used space (can't give a % as haven't made an install this way).

 

Hope this suggestion helps improve your great tool my friend.

 

alacran

Attached Thumbnails

  • 10x64-EC4.png


#169 wimb

wimb

    Platinum Member

  • Developer
  • 2682 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 2 weeks ago

@antonino

The procedure seems rather complicated and the extreme reduction in VHD size seems unneeded for your fast computer having 64 GB RAM.

 

@alacran

Compact Mode can be added to the program, but WIMBOOT remains the more interesting option.



#170 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

My dear wimb, what u said on my PC is true, so much so that I cannot notice any improvement in speed in uncompressed environments. The only improvement I can see with my architecture is the space I can save. An i9 does not even show u
its toil of compacting and uncompressing. This is why I set such great store on space. Conversely, if I occupy a lot of ram with a bulky vhd, chances are I run out of ram in heavy tasks. Don't forget I devote some of the ram to pagefile.sys and temps, so as to have the system have as little impact as possible on disks.

#171 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15106 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 2 weeks ago

Conversely, if I occupy a lot of ram with a bulky vhd, chances are I run out of ram in heavy tasks.

With 64 GB? :w00t:
Those must be very heavy tasks.
 

Don't forget I devote some of the ram to pagefile.sys and temps, so as to have the system have as little impact as possible on disks.

Pagefile in RAM ? :frusty:
 
And how big do you make it? :unsure:
And how much space do you have for temps?
 
Oooops, a couple links just fell out of my bag-o-links:
https://msfn.org/boa...comment=1101471
 
https://www.overcloc...e-ram-disk.html
 
:duff:
Wonko

#172 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

32gb conditional space, actual space 4gb swap + all it takes for temps, usually unnoticeable space occupied.

#173 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

Just Read ur links, no apparent issues of the kind



#174 alacran

alacran

    Gold Member

  • .script developer
  • 1174 posts
  •  
    Mexico

Posted 2 weeks ago


@alacran

Compact Mode can be added to the program, but WIMBOOT remains the more interesting option.

 

Hi wimb, I'm agree WIMBOOT is the more interesting option.

 

JFYI new experiment:

 

10x64-FCL.vhd (Fixed size, Compact LZX) made with wimlib-clc, 5.5GB, 3.57 GB used and 1.93 GB free, the mother WIM file is 2.90 GB.

 

Not booted yet.

 

alacran
 



#175 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 485 posts
  •  
    Italy

Posted 2 weeks ago

talking about pagefile in ram, wonko, it is just for the software that still believes it needs it, although only nominally. Chances are the system likes to believe there is one, even though it is of little or no value. in fact, it was not I who decided upon its size, it is system-managed on that "drive" (drive z:\, for that matter). one might as well forget it exists. just try it on a 64gb ram system, if u dont believe - negligible impact or no impact at all, or anyway less impact than its absence. as for the very heavy tasks, it is enough for u to think that a big *.rar file exhausts all the memory I have if I try picking its content with the mouse and drag it anywhere out, ending up not completing the task, whereas everything ok if i unpack it by clicking on extract. so first try it and then frown, if that be the case with a situation that wants frowning.







Also tagged with one or more of these keywords: ramdisk, svbus, wimlib, grub4dos, windows 10, ssd, usb, wim, wimboot, vhd

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users