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

#26 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 22 March 2019 - 03:49 PM

 

 

 

@alacrán and whomever else it may concern

 

Since I have a big amount of ram (64 GB), I can and did make my VHD bigger, surely tried 3 GB and 5 GB VHD coming down from 25gb, mind you, to start testing, when I compressed it as .gz it was already in the order of 1.5-2gb and was not so close as my present .gz, but to ur 300, which you published in some previous post of yours. empty space or no empty space. Throughout this time, believe it or not, I have had the opportunity of comparing the various situations and options, so I am, believe it or not, in a position to tell you that the present one is the best of all possible worlds, and it is as follows:  wim (in my case) 6.something gb + vhd 1048mb (perhaps having to be expanded to 1.5gb in a half-day or so, no need to go any further up) which would be 240mb to 300mb as .gz. the .gz was the real innovation in terms of space, time and speed. it is so fast that it takes 1-3 seconds to load in ram. the remnant time, up to the interface is sensibly longer, but still shorter that it has ever been before the .gz "era". As for taking note, no sooner have I tried to do so than the system is already loaded in ram. I think I said this already, but, what can I do if wonko will not understand the usefulness of my posts on account of the presumed unscientificness of my attitude and behavior? FYI, "the time from that moment to first seen desktop" IS NOT the same, at least in my case, which is probably due to the fact that I also have 2 tv tuners, one digital sat and the other terrestrial digital which are outdated and may slow things down.

And yes, if u give me, or recommend, a timer that tells me how long it has taken the system to "first seen desktop" and does not go any further in the counting, I will certainly be able to tell you exactly how long it has been, which will of course be different from the usual 26-27secs which appears 1 minute later or so than "first seen desktop" and it is obviously unreal.

I really hope from the bottom of my heart that I was intelligible, otherwise I will really write the same in Spanish, or Italian.

nino 



#27 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 04:41 PM

All those programs to measure time alter the results in some way, I use my cell phone watch option for measure time, put the cell phone close/near to keyboard and press Intro key and one touch to start both at the same time, and latter one touch to stop time count. The simpler the better.

 

alacran



#28 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 March 2019 - 05:02 PM

 I think I said this already, but, what can I do if wonko will not understand the usefulness of my posts on account of the presumed unscientificness of my attitude and behavior?

Maybe try a more scientific attitude and behaviour? :unsure:

 

For the record Wonko stated how he cannot understand the contents of some of your reports and that (and only) that is the reason why (in his not-so-humble opinion) those reports are not useful to make a comparison between them (and also against other booting ways).

 

@alacran

Also a cronometer (watch) would do nicely, or recording a video of the booting sequence and then have a look at the timestamps of the relevant frames, more or less anything would do, there is no real need for tenths or hundredth of seconds accuracy.

 

The issue is that we must agree on a SAME "stop" event (the "start" is banally the moment you push the power switch button).

 

The problem is that one build might be extremely fast in the initial booting phase and then lag until the desktop appears or even in a later phase (in the old times I remember having a 2K install that for *some reasons*, I suspected at the time an issue with a scanner driver, we are talking stiil of a machine with a SCSI disk (and SCSI scanner), but didn't have time/occasion to fully troubleshoot it, was very fast in booting up to the desktop BUT when you clicked on the "Start" button and clicked on "My Computer", the Explorer was not yet capable of accessing any drive and it lagged there for several seconds.

 

For the same reasons (and like antonino61 just reported) some other connected device may slow down earlier parts of the booting, so ideally the tests should be made on a "bare" machine, possibly even disconnected from the network (or with a fixed IP, still as a semi-random data point, I have seen networks where the DHCP server was simply extremely slow in serving the IP to clients and that slowed down the client boot time noticeably, because there were a number of services set to start at boot that needed a connection).

 

:duff:

Wonko



#29 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 22 March 2019 - 05:22 PM

yes, wonko, but the tests have been made on the same machine, so the results might as well be absolutely personal, but they are necessarily accurate and reliable from the relative point of view (viz. it is not to say that I plug the tuner before one test and unplug it before another. in that case you would be dead right!). since i leave the machine intact and identical in all four cases of mine, the behavior of the various booting ways is accurately discernible and should not be ruled out, still according to the scientific criteria normally advocated here.

so, my 4 tests were the following:

 

1) conventional windows bootmgr

2) grub4dos filedisk

3) grub4dos ramdisk compressed (.gz)

4) grub4dos ramdisk uncompressed (.vhd)

 

which featured the following booting times

 

1) 24secs

2) 27secs

3) 30secs

4) 31secs

 

respectively.

 

now everybody enjoy and do not make me lose my willingness to sound scientific!

nino



#30 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 22 March 2019 - 05:25 PM

if u want my opinion, in one thing wonko is right. no need to be peaky about fractions of seconds, and this is the case. do u see much difference between all the above alternatives? I honestly don't. i can promise u that I carried out the tests with both pointing fingers simultaneously, right one on the keyboard and left one on the stopwatch. so that was accurate as well. as I was simultaneous.

Oh, another thing, before I forget. Wonko's point whereby a pc might give different perceptions of speed between, let's say, booting time and start menu snappiness, I can inform u that everything but the boooting is snappy here and working perfectly. the pc is responsive all thru. the booting, I repeat is relatively the slowest thing here.



#31 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 March 2019 - 05:45 PM

Good. :)

 

Now let me introduce something else.

 

The .vhd's used till now are static ones, right? :unsure:

 

If yes, what happens with dynamic ones?

 

Karyonix extended grub4dos making it capable of (RAM boot ONLY) of loading dynamic .vhd's:

http://reboot.pro/to...mic-vhd-to-ram/

 

cannot remember  :blush:  if the modification became part of the "official" branch of grub4dos, but the Karyonix version should be anyway recent enough (2015) to be worth an attempt.

 

:duff:

Wonko



#32 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 05:58 PM

AFAIK v0.46a (don't ask me since when) is capable to boot expandable VHDs too, I have been thinking since last night in test this or not, since I assume the full expanded size will need to be loaded on Ram and I have only 8 GB.

 

I will make an expandable upto 4 GB and see how it works, to satisfy our curiosity.

 

All my test are without anything additional conected to PC, USB Wifi is pluged but I haven't typed password to conect to Internet.

 

alacran



#33 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 22 March 2019 - 06:05 PM

this is new and unprecedented for me. I have always used fixed vhds thruout. but should there be a feasible advantage in going dynamic, just count me in.

AFAICS, it would solve space problems, I am not sure it would fare better than fixed time and speedwise, as u would (as Alacran might have implied) still take time to gage the happy size of this vhdx. in vhd terms, I do not see any point in expanding one any further than 2gb, as I noticed that in my case used space won't grow any further, this is also to answer alacran that there is no point in having huge vhds.

My wife's laptop is funny, it has bulging used space problems with a 2gb vhd, which I will now have to expand to 2.50, as free space is getting dangerously low. she has fewer apps and programs than I have, but... that is what happens on her machine.



#34 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 06:36 PM

It fail to load on Ram, still verifiying to try to find if I made a mistake before say it do not work, but I remember a post from Agni talking about grub4dos 0.46a was capable to load expandable VHDs, maybe THE FINDER, can hel me find this post, to see if I didn't missinterpreted somethig.

 

EDIT: found the post, it was not from Agni, but he was on the talk, It was from Camiel, see:

 

 

Added a new grub4dos entry (supports loading dynamic VHDs for some time now)

 

Source: http://reboot.pro/to...e-4#entry205083

 

alacran



#35 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 March 2019 - 07:56 PM

As posted above the version surely (hopefully) working is the one by karyonix.

 

His proposed patch has been included in 0.4.6a, according to this:

https://github.com/c...b4dos/issues/40

 

But it seemingly has not been tested extensively, and - though there is a much later note by yaya fixing a "visual" bug (Google translate):

 

 

2016-12-08(yaya)
   Fix lz4, vhd does not display the decompression progress indication. Increase lzma decompression progress indication.

 

But nothing excludes that more recent version include (or do not include) any kind of "regression bug".

 

Unfortunately both chenall and yaya :worship:  are not particularly "verbose" when it comes to documenting new features or updating the ChangeLog_chenall.txt (besides it being in Chinese and we all know how Google Translate may additionally distort the meanings).

 

:duff:

Wonko



#36 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 07:58 PM

It seems there are no mistakes on the creation of  expandable 10x64-WB-EXP.vhd Max. size 4 GB or on BCDs and menu.lst

 

During loading to Ram only four hundred and something MB were loading (EDIT: I assume only used part of the 4 GB), not the full size as usually, and after that got this black screen, see attached picture.

 

alacran

Attached Files



#37 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 10:32 PM

Just for curiosity tryed this grub4dos 0.4.5c modified by kyrionix, from Woko post: http://reboot.pro/to...e-2#entry210062
 

 

Karyonix extended grub4dos making it capable of (RAM boot ONLY) of loading dynamic .vhd's:

    http://reboot.pro/to...mic-vhd-to-ram/

 

This time I used USB 3.0 SSD to run this test.

 

It is fast as a lightning.

In order to be capable to boot 10x64-WB-EXP.vhd Max. size 4 GB, let me tell you I have never seen anythig so fast, it detected the full size of 4096 MB (4 GB), but during loading just jumped to the booting process, I had to Ramboot twice to be able to press the stop on the Cel phone Cronometer on time, it loaded to Ram in only between 4 to 4.5 seconds, the clock stopen on 4.5 but I'm sure I was slow to press stop.

The commands need to be as it used to be before, I mean, without the --top:

iftitle [if exist (hd0,1)/10x64-WB-EXP.vhd] (hd0,1)/10x64-WB-EXP.vhd - SVBus  RAMDISK  - 4096 MB Max. - map as (hd-1) for WIMBOOT
map --mem (hd0,1)/10x64-WB-EXP.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

This is the faster I have ever seen, with this version of grub4dos there is no need of GZ compression to improve  loading on Ram speed.

Maybe our good friend steve6375 who has been in contact with grub4dos developers of v0.46a can ask them to fix this on it.

alacran


  • wimb likes this

#38 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 22 March 2019 - 11:29 PM

Just to have a comparative of loading to Ram times from my USB 3.0 SSD:

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

1 - The usuall fixed size 1.5 GB.

 

2 - Same VHD as in 1 but .gz Max. Compressed

 

3 - New dynamic VHD created from same source wim file (1.5 GB Max. size)

 

CPU I3 3225 at 3.3 GHZ, 8 GB of RAM at 1333 MHZ.

 

There is no doubt g4d 0.4.5c Mod by karyonix is the faster, unfortunately it is a very old version wich lacks some new features available on v0.46a Dic 2018. As the capability to directly map fragmented files. AFAIR that was not a problem if map --mem is used.

 

alacran

 

@ steve6375 Could you ask v0.46a developers to fix this, since thre are reports it was working some time ago?

 

@ karyonix, Could you mod v0.46a Dic 2018 same way, during we wait for an official version?

 

alacran



#39 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 23 March 2019 - 12:37 AM

here:

2048mb vhd

24secs conventional bootmgr

30secs ramdisk g4d  0.4.5c --top --mem

30secs ramdisk g4d  0.4.5c --mem

 

top mem or mem no difference

i will try 1024mb and c if anything will have changed.


#40 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 March 2019 - 07:25 AM

Just for curiosity tryed this grub4dos 0.4.5c modified by kyrionix, from Woko post: http://reboot.pro/to...e-2#entry210062
 

...

 

It is fast as a lightning.

In order to be capable to boot 10x64-WB-EXP.vhd Max. size 4 GB, let me tell you I have never seen anythig so fast, it detected the full size of 4096 MB (4 GB), but during loading just jumped to the booting process, I had to Ramboot twice to be able to press the stop on the Cel phone Cronometer on time, it loaded to Ram in only between 4 to 4.5 seconds, the clock stopen on 4.5 but I'm sure I was slow to press stop.

...

This is the faster I have ever seen, with this version of grub4dos there is no need of GZ compression to improve  loading on Ram speed.
...

 

Q.E.D.  :smiling9: 

 

@alacran

You could try the version around 2016-12-08.

 

:duff:

Wonko 



#41 antonino61

antonino61

    Frequent Member

  • Advanced user
  • 399 posts
  •  
    Italy

Posted 23 March 2019 - 07:45 AM

no need, ok, but would it if u did it?

nino

or do u mean it is not worth the trouble?



#42 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 23 March 2019 - 10:59 AM

Decompression of lz4 should be faster than decompression of gz.

LZ4 command line tool can be found here. https://github.com/lz4/lz4/releases
compression command example:

fast compression : lz4 -1 --content-size filename filename.lz4
high compression : lz4 -9 --content-size filename filename.lz4
--content-size is required for GRUB4DOS decompression


My developing environment for GRUB4DOS is not ready.
It will take some time to setup if I decide to do.
  • alacran likes this

#43 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 23 March 2019 - 02:14 PM

I have been thinking, in the mean time v046a is fixed by developers, or at least moded by our friend karyonix, I would like to have at least the option to switch from one to the other, selecting karyonix version exclusively for Rambooting dynamic VHDs.

 

Well, I think I found a way to acomplish this, extract grldr.mbr and grldr from karyonix version, edit internal menu to look for karyo, not for grld, and rename them to karyo.mbr and karyo, make a new real mode entry on BCD, replace grldr.mbr with karyo.mbr and to keep things separate make on your menu.lst a call to a new menu with all our commands to load our dynamic VHDs

 

For now the easier part is the new menu:

 

Commands to call our new menu for Dynamic VHDs

 

title Dynamic VHDs menu using grub4dos 0.4.5c mod by karyonix
find --set-root /vhds.lst
configfile /vhds.lst
 

 

Suggested first title on Dynamic VHDs menu

 

title Go back to previous menu
find --set-root /menu.lst
configfile /menu.lst

 

iftitle [if exist (hd0,1)/10x64-WB-EXP.vhd] (hd0,1)/10x64-WB-EXP.vhd - SVBus  RAMDISK  - 1536 MB Max. - map as (hd-1) for WIMBOOT
map --mem (hd0,1)/10x64-WB-EXP.vhd (hd-1)
map --hook
root (hd-1,0)
chainloader /bootmgr

 

Then I will try to modify internal menu on grldr.mbr and come back to comment.

 

alacran



#44 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 23 March 2019 - 03:38 PM

Q.E.D.  :smiling9:

 

@alacran

You could try the version around 2016-12-08.

 

:duff:

Wonko 

 

Followed this suggestion first, (I have to admit I was forgoten it), and after testing grub4dos-0.4.6a-2016-12-12, I can say with no doubt it can boot Dynamic (expandable) VHDs, it loaded a 1.5 GB max. size dynamic VHD on 4 seconds, and same time too for a 4 GB max. size dynamic VHD, boot made from same wimboot source LZX compressed.

 

This is the fastest option for Ramboot, I didn't test Filedisk but it should work too, but even in the remote case it fails Windows bootmanager can boot without a problem any Dynamic (expandable) disk.

 

EDIT: From: http://reboot.pro/to...am/#entry210159
 

 

After finally testing Filedisk booting from an expandable VHD using grub4dos I can confirm, no matter the version (upto today) it will not boot.

 

So just to make it clear and simple, the faster option for Ramboot is:

 

1 - Use grub4dos-0.4.6a-2016-12-12 (not the last one but not so old).

 

2 - Make dynamic VHDs, they load faster.

 

Of course having this option, and getting same time to load, and with a newer version than the one moded by karyonix, I didn't continue with the idea mentioned on previous post.

 

Edit: grub4dos-0.4.6a-2017-12-20 is last version capable of Ramboot dynamic VHDs

 

alacran


  • wimb likes this

#45 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 March 2019 - 06:29 PM

Good :) ,

now it would be time to test various versons posr 2016-12-12.

 

The fact that the above works confirms that the karyonix patch has been inserted in the "main" tree.

 

Almost surely the regression bug you found with latest-latest has been introduced much later than December 2016.

 

If I were you I would try the 2017-08-30 ;)

http://reboot.pro/to...on-of-grub4dos/

 

:duff:

Wonko



#46 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 23 March 2019 - 06:33 PM

Already done.

 

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.

 

alacran



#47 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 March 2019 - 07:09 PM

Already done.

 

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.

 

alacran

Good :).

... and there are no entries around that date in Changelog_chenall.txt ...  :frusty:

... there is a "hole" between 2017-12-05(yaya) and 2018-03-15(yaya) ...

Looking at commits:

https://github.com/c.../commits/0.4.6a

(and related issues) there seems to be nothing changed *around* that feature. :dubbio:

 

:duff:

Wonko



#48 alacran

alacran

    Silver Member

  • .script developer
  • 983 posts
  •  
    Mexico

Posted 23 March 2019 - 07:44 PM

This is all info I found  about  grub4dos-0.4.6a-2017-12-23: https://github.com/c...a75a58ca74c485a

 

And also noticed link to grub4dos-0.4.6a-2018-02-20.7z do not work, see: http://dl.grub4dos.c...a-2018-02-20.7z

 

Says: error: "Document not found", but fortunatelly this is not related to actual problem, since the fail started on a version before this one.

 

alacran



#49 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 23 March 2019 - 07:46 PM

2017-12-23

vs.

2018-02-20

:w00t:

 

Ah, wait, I understand now, the issue with the 2018-02-20 is a completely separate issue that you happened to find casually while checking each download  :)

 

 

:duff:

Wonko



#50 karyonix

karyonix

    Frequent Member

  • Advanced user
  • 472 posts
  •  
    Thailand

Posted 23 March 2019 - 07:48 PM

Already done.
 
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.
 
alacran

 
 

Good :).
... and there are no entries around that date in Changelog_chenall.txt ...  :frusty:
... there is a "hole" between 2017-12-05(yaya) and 2018-03-15(yaya) ...
Looking at commits:
https://github.com/c.../commits/0.4.6a
(and related issues) there seems to be nothing changed *around* that feature. :dubbio:
 
:duff:
Wonko

See the diff of stage2/dec_vhd.c in 2017-12-23.
https://github.com/c...2dc585d418454e3
The codes to read hard disk footer in line 185 and read dynamic disk header in line 209 were just "disabled".
  • alacran likes this



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