Jump to content











Photo
- - - - -

Ultimately Stop c:\ used space bulging from torquoise to red (or almost)


  • Please log in to reply
47 replies to this topic

#26 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 October 2019 - 02:04 AM

Dear Alacrán, thanks for answering so promptly and clearly. wimbooting deprecated? pls propose a valid substitute both in terms of space and time and I pledge to go for it. is its only convenient use rambooting? well that is what I am doing most of the time. what u say about new files or files that get written to is exactly what I get here now and then - that is why I re-wimboot my combo anytime I do make a change (mainly new drivers), and it takes as little as a couple of minutes here (I am probably on my 50th edition starting from the same wim+vhd, which has been getting changed either way (well, more often by making another wim from the same vhd than the other way round)). For the rest, as u have noticed from my previous posts, since I redirected $$* and *.etl files to a ramdisk, I have hardly had any used space changes. Like u, I have also managed to shrink my vhd to half a gig (used space 250), but in order to be sure to have all pics and videos thumbnailed properly, I have been on the safest side with 1.5gig total size, and 1gig from a couple of days ago onwards. In both cases used space has been about half as much. everything is running fine, no freezing even with the most extreme compression I have found, which is 

compact /c /s /a /i /exe:lzx "h:\*" 

or 

compact /c /s /a /i /exe:lzx "v:\*"

If u tell me how to keep my vhd to half a gig and still be able to see my pics and videos thumbnailed properly (no blank thumbnails) when I open their folders, I see no other reason for enlarging it to  1 or 1 and a half gigs.

U also mentioned wimlib. Did u have wimlib in mind when u thought of a valid replacement for wimboot or was it another tool?

winlib poses more problems to newbies, I can never get around all those options without making crucial mistakes, but if u say it is worth it, I will give it a try, provided it does something substantially better than wimboot, lest it should be deprecated as well.

nino



#27 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 14 October 2019 - 03:32 AM

The substitute to Wimboot mode (8.1 Udate 1) was Compact mode on Win10, no other substitute exist. When I said deprecated it means no more updating the feature but it exist even on Win 10 Dism untill now

 

Wimlib-clc is the front end (GUI) for wimlib-imagex (command line), used for capture and deploy the OSs (has wimboot capavilities on capture and deploy), it is the best tool for wimboot tasks, also you can get small size .wim or .esd image files from it and faster than Win Tools as Dism.

 

I always make my Wimboot VHDs of 1.5 GB since I decided to use that size upto now, and I suggest you should do the same, having a PC with a lot of Ram as yours I don't see a logical reazon to go to a smaller size, unsuded Ram is just wasted Ram (and money of course).

 

alacran



#28 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 14 October 2019 - 12:10 PM

so, the only possible alternatives u might envisage are: wimbooting with wimlib or extracting wim to full vhd with wimlib. if I am correct, what are the most favorable settings to save space that I can apply in wimlib?



#29 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 October 2019 - 03:25 AM

That is only in the case you want to do it manualy, but since you have been using VHD_WIMBOOT from wimb, and your VHDs are working fine, just do it the same way you already know very well now, and that don't give you any troubles.

 

If you read again my previous post I was comparing Dism and wimlib saying wimlib is a better option.

 

If you open VHD_WIMBOOT folder you will see into it wimlib_x64 and wimlib_x86 folders, so the program uses wimlib in an automatic mode internally (by means of is internal code). So you have been using wimlib all the time without knowing it.

 

Y ya no le busques chiches a las gallinas, Ja, Ja, Ja.

 

alacran



#30 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 15 October 2019 - 06:15 AM

hhahah, I noticed winlib there all the time, but I was wondering was there any alternative setting to the automatic one to improve compression?



#31 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 October 2019 - 07:02 AM

No, wimb did an excellent work developing his program, all is optimized.

 

He is very friendly and always hears (good) suggestions to improve his programs, in fact i suggested one or two minor things and he included them.



#32 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 16 October 2019 - 10:43 PM

Any further shrinking of vhd and also wim can be performed if u take a look at the services, perhaps with a little help from this list u can find attached here. To be on the safest side, first make a copy of the vhd (and maybe of the related wim as well), then proceed the wonko way (by disabling 5 by 5 or 10 by 10), with successive reboots and consequent copying of the successful vhd over the already existing copy. then rebake by wimboot. For instance, that is exactly what I am doing now.

Attached Files



#33 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 05:45 AM

On my builds it was done since long time ago, and it was suggested to YOU long time ago too.



#34 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 October 2019 - 11:28 AM

right u r. thanx for pointing it out. i wish I'd had a more detailed feedback at the time than just doing it by trial and error right now, though.

 

BTW, further cleaning and debloating can be carried out by running the following on powershell

 

iex ((New-Object System.Net.WebClient).DownloadString('https://git.io/debloat'))



#35 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 11:39 AM

But let me clarify all stopped services only make consuming less Ram when you boot, they DO NOT reduce VHD size since they are only POINTERS, (empty files [its real size is zero] used only as hard links), to the source .wim

 

alacran



#36 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 October 2019 - 01:12 PM

they reduce the wim size though. It is also an attempt to cut down the burden to the system.



#37 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 05:53 PM

No, unless you delete the files/folders involved on the services, which usually are very small and I don't think they occupy a big size on the .wim once compressed, also you may need them on the future, anyway I never delete them.

 

alacran



#38 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 17 October 2019 - 06:03 PM

i have deleted them after exporting a services.reg file thru regedit.



#39 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 26 October 2019 - 06:13 AM

here is new partially tested version of Alacrán's wimbootcompress.ini

 

no msocache, recovery, windows\boot\dvd, windows\boot\efi, hyberfile, pagefile, windows\system32\drivers\*.sys lines in the various lists,

 

with the purpose of squeezing a few hundred megs of free space on the vhd, in the case of non portable systems.

I said partially tested because I have just baked a new wim+vhd combo and I have not yet seen if everything is ok, nor have I had Alacrán's learned opinion about it. I am still not sure that, under nonportability conditions, any other lines can be erased from the various lists to the same end and purpose.

 

nino

 

P.S.: Alacrán told me the attached file was wrong, so I deleted it.



#40 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 26 October 2019 - 04:41 PM

The custom WimBootCompress.ini (modified by wimb and myselt after several test) we are using in our builds has been modified to allow improve portability when booting on different hardward (sacrifiying not compressing driver files and some boot files), but also excluding many other big files (as the Office install cache file wich is usually bigger than 300 MB and the Recovery big file too) to be added onto the sorce.wim and also to the VHD.

 

If your goal is different better don't use any modified WimBootCompress.ini and then the internal one that is located on all Windows installs (after 8.1 U1) on Windows\System32 folder will be used during Capture and Install. (this contains the general and safest options according to MS)

 

I suggest you better delete the attached file on your previous post to avoid confuse other people, because it is basically wrong.

 

All you deleted under [ExclusionList] on your list, (if exists on first install before wimboot capture) now will be added to the source.wim and the VHD.

 

Just to give you an example: you deleted this line \Windows\Temp\* then all files/folders located on Temp folder will be added to the source.wim and also (as pointers) to the VHD (that line is in our modiffied list and also on the original WimBootCompress.ini), same applies to Office install cache and Recovery file, so this means you do NOT have any idea of what you are doing with your modifications/deletions.

 

alacran


  • wimb likes this

#41 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 26 October 2019 - 05:04 PM

Forgot to explain how WimbootCompress.ini works:

 

All under [CompressionExclusionList] will be copied to the source.wim during wimboot capture but uncompressed.

 

All under [PrepopulateList] will be added (compressed) to the source.wim as usuall, but during wimboot install/apply to the target will be as real files not pointers to the source.wim

 

All under [ExclusionList] will not be added (copied) to the source.wim when making a wimboot capture, then obviously will not be copied in any form during wimboot install/apply.

 

alacran



#42 wimb

wimb

    Platinum Member

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

Posted 26 October 2019 - 05:06 PM

I have added file makebt\WimBootCompress-W10X.ini to version 2.7 of VHD_WIMBOOT.

 

That file can be used as WimBootCompress.ini in case you don't need VHD WIMBOOT as portable OS and want to have a minimal used space in your VHD.

That WimBootCompress.ini file corresponds almost to the one given by Microsoft, but essental extra entries as \bootmgr and \Boot\BCD were added to the [PrepopulateList] Section.

 

 

Download:  VHD_WIMBOOT



#43 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 27 October 2019 - 12:39 AM

Dear Alacrán and Wimb,

thank u ever so much!!! Where would I go without u?!?!?! 

Well, all I can say is ... it takes one mistake to avoid another.

BTW, if some file or directory I do not have in my system (e.g. recovery, msoffice), is listed for compression exclusion, prepopulation or exclusion, shall I

1) leave it listed?

2) delete it if it is found on one of the lists but not on another?

3) delete it anyway? 



#44 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 27 October 2019 - 01:20 AM

My Dear friends and all, 

after putting a foot on my mouth, I can assure all of u that wimb's version of wimbootcompress.ini (WimBootCompress-W10X.ini in the most recent vhd_wimboot (2.7)) works superfine!!!

Attaboy!!!!


  • wimb likes this

#45 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 27 October 2019 - 10:24 AM

@wimb

BTW, what is in the pinning folder list for? wimboot does not recognize it as a valid list? shall I move the items someplace else?

nino



#46 wimb

wimb

    Platinum Member

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

Posted 27 October 2019 - 03:16 PM

BTW, what is in the pinning folder list for? wimboot does not recognize it as a valid list? shall I move the items someplace else?

 

The [PinningFolderList] section is not recognized by wimlib and will then give wimlib WARNING Unrecognized Section, which is safe to ignore

 

Some more Info about [PinningFolderList] section is given by JFX and presented here ..... :unsure:

 

I guess the most essential files for booting the system will get a special storage class .....



#47 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 28 October 2019 - 07:31 PM

given the latest uncertainties around wimbootcompression and wimboot's erratic behavior mentioned by some of u in the jfx forum, I decided to give it a try with the following wimbootcompress.ini

 

[CompressionExclusionList]
ntoskrnl.exe
 
[PrepopulateList]
\bootmgr
\Boot\BCD
*winload.*
 
[ExclusionList]
 
[CompressionFolderList]
 
the result was a wim file about the same size as those I had before + a 577mb vhd which does not yet seem to be willing to bulge (Shall I be glad!). 
now the technicalities whereby it works when it should not, I honestly ignore totally and thoroughly. 
If anyone has discovered that it could work all the better or become all the smaller if one populates the above lists (even empty ones) above with other items, I am willing to abide by their suggestions.


#48 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 06 November 2019 - 06:05 AM

Moreover, I have just discovered that if u change the name of the default vhd resulting from the wimboot apply procedure, without updating it from the tool, the vhd is practically unlikely to "bulge to red" even if it is just 539MB (lz4'd to 83MB). its free space has stayed 138MB without issues or hindrances for the past 2 days. It is vital that u do not pre-compress it with lzx.exe, though.

The funny thing is that if u update the renamed vhd from the tool after applying the wim to a default vhd, the resulting vhd bulges to red in minutes, so don't update it if u want the free space to stay the same.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users