Jump to content











Photo
- - - - -

Reducing wimboot source wim file using LZX Compression, and VHD using gzip or LZ4 Compression, to save room, and also load faster on RAM

wimboot ramboot lzx gzip lz4 vhd

Best Answer alacran , 26 March 2019 - 10:05 PM

We could say that this thread is a continuation of: Making the smallest Win10 install (Wimboot mode) on 512 MB VHD

 

It was necessary to run some additional test using the info from cdob post No. 95: http://reboot.pro/to...e-4#entry210231

 

 

lz4.exe -12  --content-size --favor-decSpeed e:\win.vhd e:\win.vhd.lz4

 

LZ4 compression is better and faster than using GZ, or any other option, it gave me the faster loading to Ram times, also noticed that when loading from an slow device (as my MicroSD) it has the best efect.

 

All test ran on same I3 3225, 3.3 GHZ, 8 GB Ram at 1333 MHZ, Rambooting from SSD Adata SU650 into Adata XPG enclosure 3.0 USB.

 

This are my findings:

 

Speed:

VHD								Time to load on RAM

1 - 10x64-WB.vhd Ramboot using g4d  grub4dos-0.4.6a-2018-12-23		12 seconds

2 - 10x64-WB.vhd.gz Ramboot using g4d  grub4dos-0.4.6a-2018-12-23	7 seconds

3 - 10x64-WB-EXP.vhd Ramboot using g4d  0.4.5c Modd by kyrionix		4 seconds

4 - 10x64-WB.vhd.lz4 Ramboot using g4d  grub4dos-0.4.6a-2019-03-25	3.67 seconds

Saved espace:

VHD				Used	Saved espace

10x64-WB.vhd			1536 MB	0 % saved espace

10x64-WB.vhd Expandable		480 MB	68.75 % saved espace

10x64-WB.vhd.gz			233 MB	84.83 % saved espace

10x64-WB.vhd.lz4		135 MB	91.21 % saved espace

It is very possible I am getting close of maximum loading speed possible for this PC and this is influencing results.

 

On a single test I ran from my MicroSD, the 10x64-WB.vhd.lz4 loaded to Ram on 14.68 seconds wich is really a very good time for that device, and it was plugged to USB 2.0

 

Conclusions:

 

If Rambooting from a fast device as an SSD use expandable VHDs, they have very good speed and a resonable saved espace, do no require any additional compression, they are capable to Ramboot and also can be booted from Windows bootmanager, so it is not a big issue if they can't boot as Filedisk using grub4dos.

 

If Rambooting from a not so fast device as an SSD, we have the alternative to use LZ4 compressed VHDs, wich are the faster option and also save more espace than any other option, but they are only usefull for Rambooting, we can not boot them as Filedik using grub4dos or from Windows Bootmanager, this limitations also apply to GZ compression.

 

Thanks to all members of the forum who collaborated with this thread with info and suggestions, for the realization of all this tests:

 

antonino61, Wonko the sane, karyonix, tinybit, cdob and yaya for fast fixing grub4dos-0.4.6a-2019-03-25

 

 

Just to make a summary of all we have learned/tested/proved/improve on this thread:

From previous Post: http://reboot.pro/to...e-4#entry210209

 

LZX compressed wim files for Wimboot VHDs do not fail anymore during boot or Ramboot. See: http://reboot.pro/to...am/#entry210021

 

With this hight compression I have found If we don't add those items on [PrepopulateList], especially the first two we will have troubles during Ramboot

 

Saving 20 % espace using LZX compressed wim files. See: http://reboot.pro/to...am/#entry210021

 

Only things we have to do in a different way to reduce about 20 % the size of our source win file is: ..........

 

Tested GZ compresed VHDs and found they load faster on Ram (almost about 1/2 time).See: http://reboot.pro/to...am/#entry210031

 

I compressed 10x64-WB.vhd with 7-zip GZ Ultra as 10x64-WB.vhd.gz , it took 15 min, but file is now 233 MB

 

Saving about 85 % espace if using GZ compresed VHDs, See. http://reboot.pro/to...am/#entry210031

 

....but file is now 233 MB so it reduced a lot the size 84.83 %,......

 

Improved speed using GZ compression on VHDs See: http://reboot.pro/to...am/#entry210031

 

So there is a big improvement in time to load in Ram (43.75 % less time)

 

Testing expandable VHDs Ramboot capability, and found it was failing.See: http://reboot.pro/to...e-2#entry210068

 

It fail to load on Ram, still verifiying to try to find if I made a mistake before say it do not work,

 

Detect the last grub4dos 0.46a version capable to Ramboot expandable VHDs. See: http://reboot.pro/to...e-2#entry210089

 

grub4dos-0.4.6a-2017-12-20 is last version capable of Ramboot dynamic VHDs, the next version grub4dos-0.4.6a-2017-12-23 Fails.

 

Thanks to karionix who detected where was exactly the two lines disabled on grub4dos 0.46a after 2017-12-20, See: http://reboot.pro/to...e-2#entry210101

 

The codes to read hard disk footer in line 185 and read dynamic disk header in line 209 were just "disabled".

 

Improved again time to load on Ram , using Expandable VHDs. See: http://reboot.pro/to...e-2#entry210074

	VHD							Time to load on ram

1 - 10x64-WB.vhd Ramboot using g4d  v0.46a Dic 2018            		12 seconds

2 - 10x64-WB.vhd.gz Ramboot using g4d  v0.46a Dic 2018            	7 seconds

3 - 10x64-WB-EXP.vhd Ramboot using g4d  0.4.5c Modd by kyrionix		4 seconds

Saved espace using expandable VHDs compared to 1.5 GB fixed size VHDs. See http://reboot.pro/to...e-3#entry210115

VHD			Used	Saved espace

10x64-WB.vhd		480 MB	68.75 % saved espace

10x86-WB.vhd		360 MB	76.56 % saved espace

8x64-WB.vhd		416 MB	72.91 % saved espace

W864ESP1-WB.vhd		364 MB	76.30 % saved espace

Got the attention of tinybit and yaya (grub4dos development team) and thanks to it, get in about 2 days a new fixed release. See: http://reboot.pro/to...e-3#entry210171

 

yaya fixed it.

 

And this new posts related to LZ4 Compression:

 

karyonix info about LZ4, See: http://reboot.pro/to...e-4#entry210229

cdob info and commands for LZ4, See: http://reboot.pro/to...e-4#entry210231
 

Analyzing why the difference of speeds: http://reboot.pro/to...e-5#entry210265

 

Comparing the 2 options suggested by cdob for LZ4 Compression: http://reboot.pro/to...e-5#entry210278

 

When having x86 and x64 versions you can make a wimboot source wim file with multiple indexes to save espace, see: http://reboot.pro/to...am/#entry210406

 

And for all lazy people wimb just made a program to make almost all this, things not available on his program are compressions of VHDs and multi-index wimboot source wim files:

 

VHD_WIMBOOT - Apply and Capture of WIM Files for OS in VHD by wimb: http://reboot.pro/to...-for-os-in-vhd/

 

And finally now, there is also available this lz4_compressor GUI: http://reboot.pro/to...lz4-compressor/

 

I only hope this thread has helped some of us to learn something.

 

alacran

Go to the full post


  • Please log in to reply
165 replies to this topic

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 02:36 PM

Reducing wimboot source wim file using  LZX Compression, to save room.

 

We could say that this thread is a continuation of: Making the smallest Win10 install (Wimboot mode) on 512 MB VHD

 

For that reason it is better to read the mentioned thread first in order to don't ask unnecessary questions already answered.

 

I only recommend this if you have a good CPU on your rig and also if you are short of space on your Mass Storage device, since this saved space is on the source wim file, and do not improve the size of the VHD we want to Ramboot. And of course adds additional load to the CPU to decompress from a LZX compressed file.

 

This time we will go beyond MS specs for wimboot, thanks to JFX (WinNTSetup author) for finding the way to do it, to Eric Biggers for implementing JFX findings on wimlib-imagex and Retokener for implementing all wimlib-imagex features on wimlib-clc

 

Only things we have to do in a different way to reduce about 20 % the size of our source win file is:

 

During Capture procedure of the first VHD, for more info see: http://reboot.pro/to...hd/#entry209483

 

We select a strong compression (LZX) during wimboot Capture on wimlib-clc, see attached picture.

 

And also we use the attached Custom WimBootCompress-2019-03-18.ini, for more info see: http://reboot.pro/to...e-6#entry209949

 

Latter when Apply Wimboot Image to a 1.5 VHD, See: http://reboot.pro/to...hd/#entry209485

 

We may make it using wimlib-clc selecting wimboot option, as in attached picture.

 

We can do it also using WinNTSetup but for this we need to go to WinNTSetup3.9.3.1\Tools\ and edit WimBootCompress.ini adding the following on the right sections:

 

 Note: first two items are from wimb's idea, the other two are my idea.

[PrepopulateList]

\bootmgr
\Boot\BCD
\EFI\Microsoft\Boot\BCD

[ExclusionList]

\Recovery\*

With this hight compression I have found If we don't add those items on [PrepopulateList], especially the first two we will have troubles during Ramboot

 

\EFI\Microsoft\Boot\BCD <<<<<<<<<< Not usefull for Ramboot, but when UEFI_MULTI edits BCDs it is better to have it uncompressed if not VHD used space grow up.

 

\Recovery\* <<<<<<<< This is useless on the present wimboot install on VHD, so removing this saves about 300 or more MB on the source wim

 

And select Wimlib to make the install, see: http://reboot.pro/to...hd/#entry209568

 

Latter just follow the standard procedure and don't forget to verify/modify the BCD(s) as required.

 

Happy Rambooting

 

alacran

Attached Files



#2 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 21 March 2019 - 03:48 PM

when u say "we pretend to ramboot", I reckon you mean "we want to ramboot". We r not simulating, this is for sure.



#3 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 03:51 PM

You need IMHO to provide some more "practical" examples/use cases.

 

Once said that usually a filesystem to work properly should have at least 10-15% of free space, better if 20%, see also:

https://superuser.co...e-on-hdd-or-ssd

 

I wonder how much (expressed in MB) is the space saving you can achieve forcing this higher compression and how much (in seconds - i.e. in human noticeable units) does this slow down booting on a given rig with a given (fastish) CPU.

 

Mind you I do understand and appreciate the fun :) in making these experiments, and I do approve of them  :thumbsup:  but I want to understand if they can have any practical use. :dubbio:

 

:duff:

Wonko



#4 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 21 March 2019 - 03:58 PM

Dear Wonko, 

I have already answered this question about a week ago, with results on 3 machines. I posted them in the old thread. Your perplexity is sound.

the best of both worlds (optimal space&time trade-off) is express4k compression for the wim file and wimboot option for the vhd file. I have already given exact figures concerning the various compression combos.



#5 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 04:14 PM

@antonino61

 

when u say "we pretend to ramboot", I reckon you mean "we want to ramboot". We r not simulating, this is for sure.

 

Post is fixed now, thanks.

 

alacran



#6 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 04:16 PM

Dear Wonko, 

I have already answered this question about a week ago, with results on 3 machines. I posted them in the old thread. Your perplexity is sound.

the best of both worlds (optimal space&time trade-off) is express4k compression for the wim file and wimboot option for the vhd file. I have already given exact figures concerning the various compression combos.

Well, my question was directed at alacran.

 

But I missed the results of your experiments with the LZX compression procedure alacran posted only today, and - to be fair - in "the old thread" (whcih one? :dubbio:) you posted everything and (almost) the contrary of everything :w00t: (which is BTW normal when experimenting :)), if you have a link to the relevant post, it would be appreciated

 

:duff:

Wonko



#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 04:38 PM

@ Wonko

 

You need IMHO to provide some more "practical" examples/use cases.

 

Once said that usually a filesystem to work properly should have at least 10-15% of free space, better if 20%, see also:

https://superuser.co...e-on-hdd-or-ssd

 

I wonder how much (expressed in MB) is the space saving you can achieve forcing this higher compression and how much (in seconds - i.e. in human noticeable units) does this slow down booting on a given rig with a given (fastish) CPU.

 

Mind you I do understand and appreciate the fun :) in making these experiments, and I do approve of them  :thumbsup:  but I want to understand if they can have any practical use. :dubbio:

 

:duff:

Wonko

 

Yes, I have some numbers available for you:

 

Using XPRESS compression 4K during capture, (just by MS specs) my 10x64-WB.wim is 3.65 GB ([ExclusionList] \Recovery\* already applyed and reduced 300 MB)

 

Using LZX compression during capture, my 10x64-WB-LZX.wim is 2.92 GB.

 

Size reduction: 3.65 GB - 2.92 GB = 0.73 GB (or 747.52 MB)

 

(0.73 / 3.65) * 100 = 20 % reduction

 

By the way and before some one ask, if we compress for backup pourposes with 7-zip Utra my 1.5 GB 10x64-WB.vhd file, it will be a 10x64-WB.7z  file having 102 MB size, and reduction is 93.359375 % from original size (1.5 GB).

 

See attached picture.

 

EDIT: By the way about the extra load to the CPU, I didn't notice anything different on an old I3 3225 at 3.3 GHZ, with 8 GB Ram at 1333 MHZ. all Ramboots mentioned here are from internal HDD.

 

alacran

Attached Files



#8 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 05:01 PM

I don't understand the 7-zip reference.

The .vhd needs to remain uncompressed, I believe.

 

If I get this right you mean that the .vhd contents are highly compressible (but it is pointless since the file needs to remain uncompressed).

 

For RAMboot (NOT filedisk boot) it should be possible to .gz compress the .vhd. :unsure:

 

:duff:

Wonko



#9 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 05:04 PM

Info about VHD is only for backup pourposes, it needs to be uncompressed to boot.

 

I'll make it more clear on my previous post.

 

But yes *.gz file can be loaded on Ram using grub4dos, in fact I have some files I load this way.

 

I'll run some test and report back.

 

EDIT: It can be Compressed and Ramboot using gzip Utra with 7-zip, see: http://reboot.pro/to...am/#entry210031

 

alacran



#10 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 21 March 2019 - 05:28 PM

i did post everything in detail.

if u cannot see anything useful, I am sorry.

no contradiction at all

this is what I wrote at the time

no compression wim 8gb + lzh (alacran's or pamelo's does not matter, science is erga omnes not ad personam) 10gb vhd

no compression on both: wim same as above + 15gb vhd

no compression wim same as above + wimboot 0.720gb vhd

no compression wim same as above + express4k 11.5gb vhd

express compression wim 9.136 + lzx 10.4gb vhd

express compression wim same as above + no compression 15.8gb vhd

express compression wim same as above + wimboot 0.725gb vhd

express compression wim same as above + express4k 11.5gb vhd

boot time difference negligible

take it or leave it

my conclusion is the same as above 



#11 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 05:52 PM

Reducing VHD size using gzip Compression, to save room and also load faster on RAM.

 

I compressed 10x64-WB.vhd with 7-zip GZ Ultra as 10x64-WB.vhd.gz , it took 15 min, but file is now 233 MB so it reduced a lot the size 84.83 %, and obviously this will improve loading time to RAM.

 

Well, after testing both this are the facts (of course results will vary in each machine):

 

10x64-WB.vhd of 1.5 GB loads on Ram on 16 seconds.

 

10x64-WB.vhd.gz of 233 MB loads on Ram on 9 seconds.

 

So there is a big improvement in time to load in Ram (43.75 % less time)

 

This time is only to load the VHD on Ram, the rest of the process to boot is the same.

 

alacran



#12 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 06:25 PM

I compresed 10x64-WB.vhd with 7-zip GZ Ultra as 10x64-WB.vhd.gz , it took 15 min, but file is now 233 MB so it ireduced a lot the size 84.83 %, and obviously this will improve loading time to RAM.

 

Well, after testing both this are the facts (of course results will vary in each machine):

 

10x64-WB.vhd of 1.5 GB loads on Ram on 16 seconds.

 

10x64-WB.vhd.gz of 233 MB loads on Ram on 9 seconds.

Yep :), and (limited to RAMboot) it seems to me a non-trifling advantage on saving disk space, 1500-233=1267 MB saved, which is good both for (RAM) booting and for backup.

 

Of course the advantage will be greater the faster is the CPU you have and the slower the media where the .vhd.gz resides.

 

:duff:

Wonko



#13 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 06:47 PM

Well, if we are using a small USB device, and use both approach together:

 

We add the 747.52 MB saved on LZX Compressed source wim + 1267 MB on *.gz Compressed VHD (only valid for Ramboot) = 2011.52 MB = almost 2 GB (2048 MB).

 

I think put it this way, this is the best alternative to Ramboot.

 

In fact I'll use this approach on my MicroSD 32 GB.

 

alacran



#14 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 06:48 PM

i did post everything in detail.

if u cannot see anything useful, I am sorry.

no contradiction at all

this is what I wrote at the time

no compression wim 8gb + lzh (alacran's or pamelo's does not matter, science is erga omnes not ad personam) 10gb vhd

no compression on both: wim same as above + 15gb vhd

no compression wim same as above + wimboot 0.720gb vhd

no compression wim same as above + express4k 11.5gb vhd

express compression wim 9.136 + lzx 10.4gb vhd

express compression wim same as above + no compression 15.8gb vhd

express compression wim same as above + wimboot 0.725gb vhd

express compression wim same as above + express4k 11.5gb vhd

boot time difference negligible

take it or leave it

my conclusion is the same as above 

Yep, maybe I am blind :w00t:, all I see in your quoted post are unintelligible data-points, sometimes too much data means no data.

I cannot even understand one single line, let alone 8 of them.

 

What I would see as useful for a comparison would be a SAME build of size compatible BOTH with RAMbooting and Filedisk booting where you change the compression level of the  .wim capturing and (in the case of RAMbooting) also compress the .vhd to .vhd.gz.

 

After stating some info the hardware used, *like*:

 

 

 

CPU (type/speed)

RAM (amount)
Media where the files are stored (like internal disk, internal SSD, USB2 stick :w00t:, USB3 stick, etc. used in the experiment)

Fields should IMHO be (for each .wim capturing compression):

 

 

Size of .wim

Compression used for .wim capturing

Size of .vhd

Size of .vhd.gz (only for RAM booting)
Time for FileDisk booting (ENTIRE time, let's say up to a clickable desktop)
Time for RAMdisk booting (ENTIRE time, let's say up to a clickable desktop)

 

 

:duff:

Wonko



#15 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 21 March 2019 - 07:29 PM

26/27seconds (not the ramloading, which is almost instant here)

the gz I havent tried yet

your bias in reading my data is only psychological



#16 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 21 March 2019 - 08:04 PM

Well, I must admit that the advantage is considerable, not so much in the preramloading stage, at least here, as in the remnant stage of the booting. For Wonko's info, My processor is I9, my ram is 64gb, my video card is geforce 1970, etc.

Will it get any better if I compress the wim file too?

btw, as filedisk, no dice yet, it says too many fragments



#17 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 3041 posts
  • Location:Nantes - France
  •  
    France

Posted 21 March 2019 - 08:28 PM

..., My processor is I9, my ram is 64gb, my video card is geforce 1970, etc.

 

 

I want your computer :)

You meant geforce 1070 right?



#18 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 21 March 2019 - 08:45 PM

your bias in reading my data is only psychological

I have no bias in reading your data, I have difficulties in understanding them (as said) so I prefer to ignore them for the moment and ask you for clarifications or for new data coming from a more properly defined experiment and in a form that allows no mis-interpretation..

 

:duff:

Wonko



#19 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 21 March 2019 - 09:08 PM

 

Will it get any better if I compress the wim file too?

 

No, you don't.



#20 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 22 March 2019 - 12:08 AM

ok ultimate test, my gz is 800mb and it is fast, not only at loading in ram just a few seconds (if it is 1 or 2 or 3, honestly I cant make that out; if u dont believe me, just time flies and see), but also at getting to the interface (faster that it has been so far). the meter I have says 23secs, but it means loading everything even what the user does not see, so the interface appears earlier than when this meter considers booting procedure complete. I hope I have made myself understood, otherwise I will explain away, as long as it takes. for the ignorers, more luck to them. I have another existential framework that tells me to take advantage of everything, just because it may be useful. but of course, so many ppl are so sure as to what to ignore. 



#21 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 22 March 2019 - 02:22 AM

I didn't recompress the source wim images but this have little to no influence on boot time, and as it was the easier/faster to test only compressed the VHDs and then rebooted the PC, 10x64-WB.vhd.gz, 10x86-WB.vhd.gz and W864ESP1-WB.vhd.gz were loaded from the 32 GB MicroSD + USB 3.0 Adapter on Ram on 19 to 20 seconds and it took to them 29 to 30 seconds to boot, faster was 10x86 with a total time to reach desktop of 48 seconds.

 

CPU I3 3225 at 3.3 MHZ, 8 GB Ram at 1333 MHZ, 2 HDD, files located on 32 GB Kingston Canvas U1 80 R MicroSD + USB 3.0 Adapter.

 

Of course my CPU is old (but still working as when it was new), and a new faster CPU with a very much faster Ram and loading files from a USB 3.0 or 3.1 SSD can do it in a fraction of this time.

 

alacran



#22 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 22 March 2019 - 06:55 AM

that makes sense. one more piece of info: my 800mb vhd (165mg gz) is still tourquoise (it has not turned red (bulgy, low free space warning) since last night).

btw, do u think i can boot it thru conventional bootmgr (menu.lst-less) as well if I erase .gz from its name?



#23 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 22 March 2019 - 07:09 AM

my usual thinking out loud: no, u can't fool bootmgr into thinking that it is a plain vhd when in fact it is a masked gz (BSOD with the infamous "cannot find winload.exe"). only grub4dos can boot it, to the best of my knowledge and belief. it will be a little pain when it comes to modifying it as filedisk, i guess, but it has proven to be worth the pain as ramdisk so far. btw, the ramdisk freespace goes from 264mb right at boot thru 175mb right now to 165mb after some time. hope I won't have to expand and recompress it.

nino



#24 antonino61

antonino61

    Gold Member

  • Advanced user
  • 1525 posts
  •  
    Italy

Posted 22 March 2019 - 09:57 AM

had to expand vhd to 1024mb and recompress it. 2 good pieces of news, though: 1) no failure to recognize either winload.exe or driver signature at boot; 2) gz still retaining ca. the previous size (164mb).



#25 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 22 March 2019 - 01:37 PM

@antonino61

 

Since you have a big amount of Ram (64 GB), you can make your VHD of a bigger size, maybe try 3 GB or 5 GB VHD size to start testing, when you compress it as .gz it will be very close to your actual .gz since all you added is basically empty espace.

 

This way you will have a good/fast load in RAM and also once Rambooted plenty of room on running OS, try this approach and let us know if it works better in your case having so many free Ram.

Don't forget to take note of time during loading in Ram, the time from that moment to first seen desktop should be the same.

 

It will be good info for every body if you can test the VHD times not only the VHD.gz times, that's something I can't do on my PC.

 

alacran





Also tagged with one or more of these keywords: wimboot, ramboot, lzx, gzip, lz4, vhd

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users