Lzma compressed VHD's and anything else

i had an idea about booting with grub4dos . i have few vhds that i use as an os in ram ; so most of the time i read the vhd from a ssd . but i boot from a usb stick that has the same files but compressed with lzma . so my idea was to create a script that search for the vhd for ram mapping but in case the file is not found i would like that the script starts to search the lzma with the same name as the vhd . then when found on the usb starts to copy it in ram ..

how to write it in a menu.lst ?

i had an idea about booting with grub4dos . i have few vhds that i use as an os in ram ; so most of the time i read the vhd from a ssd . but i boot from a usb stick that has the same files but compressed with lzma . so my idea was to create a script that search for the vhd for ram mapping but in case the file is not found i would like that the script starts to search the lzma with the same name as the vhd . then when found on the usb starts to copy it in ram ..

how to write it in a menu.lst ?

What would uncompress the LZMA compressed .vhd?

Why should the "searching script" be in menu.lst? (a small grub4dos batch would be more suitable)

 

Anyway,

set fname=myniceimage

set fext=vhd

find --set-root /%fname%.%fext% || find --set-root /%fname%.lzma &; set fext=lzma

 

It is perplexing how you found suitable to make this vhd/lzma related post in a thread titled "Boot "any" ISO image or boot "all" ISO images ..."

 

JFYI there is one that has been re-named to "post here anything that crosses your mind about grub4dos":
http://reboot.pro/to...about-grub4dos/

 

 

Wonko

What would uncompress the LZMA compressed .vhd?

 

 

Wonko

 

grub4dos handles lzma , gzip , lz4

read  topic : http://reboot.pro/to...b4dos-supports/

your script wil search two files , no ?

 

i want that grub4dos searches one file : a vhd and if that fails then it fallbacks onto the lzma file .

grub4dos handles lzma , gzip , lz4

read  topic : http://reboot.pro/to...b4dos-supports/

I thought that support for lzma was still partial/experimental, good to know that it is tested and working.
 

your script wil search two files , no ?
 
i want that grub4dos searches one file : a vhd and if that fails then it fallbacks onto the lzma file .

Good.
Then write it yourself to suit what you want, simply remove the second "find --set-root".
 
The snippet I posted makes sure that the .lzma exists and sets root to where it is found, otherwise root will be undefined and oyou cannot be too sure if it actually exists, unless you set it beforehand (but then there is no need to look for either the .vhd or the .lzma file, as you would already know what is where).
 
... got try helping people ... 
 

Wonko

The special version of lzma encode/decode is included in E2B.

AFAIK, grub4dos has supported .gz and the special lzma for many years...

 

So you are loading a vhd.lzma file into memory? How exactly does that work with grub4dos and Windows?

I don't quite understand how you are going to use a compressed VHD?

So you are loading a vhd.lzma file into memory? How exactly does that work with grub4dos and Windows?

I don't quite understand how you are going to use a compressed VHD?

i use to load vhd no compressed from a hd because it is loaded in a minute but i boot with an usb that contains the same vhd that is on the disk but compressed with lzma . it takes quite long to load ;']

so i can reformat my hd or my raid without troubles : i reboot , load my win in ram and make a copy of the usb lzma extracted with 7 zip onto the hd ...

so i would like to boot on the vhd but if it is deleted then i would grub4dos to use the lzma vhd .

instead of two menu entry for the vhd & the lzma , i look for only one .

thanks for help

 

i use this script per file :

title Boot  Windows 10 x64 from Image cfirex6.vhd  
find --set-root --ignore-floppies /cfirex6.vhd
map --mem /cfirex6.vhd (hd0)
map --hook
root (hd0,0)
chainloader  /bootmgr
boot
 

 

the stick i make will be made with rufus : with a linux mint 18 install ; so i will edit the syslinux.cfg to load grub4dos and menu.lst .

mint is cool for delete of windows files . with the syslinux.cfg & menu.lst i will add avg avira kav iso linux plus paragon backup .

all should fit on a 8 Go stick

 

i found a tool that claims to install and boot everything [ and it does ...very well with linux [ not win7 ] ]

here are the scripts it made on the stick :

 

title avira rescue-system from partition 0
map --unmap=0:0xff
map --unhook && map --rehook
cat --hex --locate=PoLPu@ (md)0x3D0+0x130 > nul && echo Cannot continue if PLoP is active, please start this entry without loading PLoP first && echo && pause Press any key to return to the main menu && configfile /menu.lst
set /a dev=*0x8280&0xff
root (%dev%,0)
set ISO=/ISO/rescue-system.iso
ls %ISO% > nul || find --set-root --devices=hf /usbdrive.tag|| echo Error! Could not find usbdrive.tag && echo  && pause Press any key to return to the main menu && configfile /menu.lst
ls %ISO% > nul || find --set-root --devices=hf %ISO% || echo Error! Could not find %ISO% && echo  && pause Press any key to return to the main menu && configfile /menu.lst
map %ISO% (0xff) || map --heads=0 --sectors-per-track=0 %ISO% (0xff) || echo FATAL ERROR mapping %ISO%, please check if file is present and defragmented && pause Press any key to return to main menu && configfile /menu.lst
#http://reboot.pro/to...ge-2#entry88531
#http://www.rmprepusb...tutorials/tails
set /a dev=*0x82a0&0xff
debug 1
parttype (%dev%,3) | set check=
debug off
set check=%check:~-5,4%
if "%check%"=="0x00" partnew (%dev%,3) 0 0 0 && partnew (%dev%,3) 0x00 %ISO%
if not "%check%"=="0x00" echo WARNING: PARTITION TABLE 4 IN BIOS DEVICE %dev% IS ALREADY IN USE! && echo  && echo To prevent possible data loss will not continue further && pause && configfile /menu.lst
map --rehook
root (0xff)
chainloader (0xff)

Sure, that code is from WinSetupFromUSB and was adapted from E2B and based on original code from cdob.

But I still don't understand how you can boot from an LZMA-compressed VHD? What menu do you use?

Sure, that code is from WinSetupFromUSB and was adapted from E2B and based on original code from cdob.

But I still don't understand how you can boot from an LZMA-compressed VHD? What menu do you use?

 

i use the same as for vhd , file is named the same with lzma at end

so i have  two menu entries for the vhd & the lzma , i look for only one .

 

may be like that with OR as a separator that makes grub4dos looks for cfirex6.vhd first and if it does not find then it searches for second file cfirex6.lzma .

 

title Boot  Windows 10 x64 from Image cfirex6.vhd  or cfirex6.lzma

find --set-root --ignore-floppies /cfirex6.vhd OR find --set-root --ignore-floppies /cfirex6.lzma
map --mem /cfirex6.vhd (hd0) OR map --mem /cfirex6.LZMA (hd0)
map --hook
root (hd0,0)
chainloader  /bootmgr
boot

 

 

for lzma , see there for the latest 16.04 http://www.7-zip.org/sdk.html

Ah, OK, you use -mem. Most VHDs are at least several GB in size. Loading into memory would be quite slow and it would use up oodles of RAM.

 

So the advantage of using --mem and compressed files is that it takes less room on the boot drive to store the VHD, but the disadvantage is that it will be slow to load into memory, and it will use loads of memory. TBH I was not aware that booting to a compressed VHD in memory was even possible!

 

Your code would need to be

title Boot  Windows 10 x64 from Image cfirex6.vhd  or cfirex6.lzma
find --set-root --devices=h /cfirex6.vhd || find --set-root --devices=h /cfirex6.lzma
map /cfirex6.vhd (hd0) || map --mem /cfirex6.LZMA (hd0)
map --hook
root (hd0,0)
chainloader  /bootmgr
boot

There is no point in using --mem for the uncompressed VHD and we only need search disk devices.

 

can you describe how to use parameter : --devices=h

using the vhd on the hd means changes are loaded at next boot....

while a copy in ram stays fresh at next start .

having all in ram makes the os more stable , not really faster .

 

windows does not handle pc with more than 4 or 8 Go so it is cool to use ram that way : http://reboot.pro/to...7-from-ramdisk/

How big in size is the .vhd?

 

There are some common sense limits to the size and to whether it is faster to load in --mem a largish image as opposed to directly accessing it, depending also on the device on which the image is stored.

One thing is loading an image in memory through grub4dos and another one is to access directly a stored image and create from it a Windows in a Ramdisk, like the reference you posted to windows 7 in Ram via Firadisk.

 

The parameter --devices=h simply limits the find to devices which grub4dos id start with h, if you just get to command line and type

find [ENTER]

it will list which volumes it sees, as an example output:
(fd0)

(hd0,0)

(hd0,1)

(hd1,0)

(hd32)

whilst find --devices=h will output:

(hd0,0)

(hd0,1)

(hd1,0)

(hd32)

BUT since (hd32) is a mapped cd-rom, find --devices=h --ignore-cd will output:

(hd0,0)

(hd0,1)

(hd1,0)

 

Wonko

Ah, OK. Thanks for the link. So you are not booting to WinPE but a full Windows OS and you are using firadisk. Now I understand!

Ah, OK. Thanks for the link. So you are not booting to WinPE but a full Windows OS and you are using firadisk. Now I understand!

Does firadisk work with Windows 10?

 

Let's see if I can explain my doubts about the convenience of this LZMA compressed booting.

1) Normal booting:

OS accesses its files directly from the boot device (internal or external hard disk or USB stick, etc.) <- booting time is essentially connected to the OS and on the data transfer speed obtainable [1] from the device and from the bus it is connected to

2) VHD booting (with direct access):

Os accesses its files through the mounting of the .vhd which is directly accessed from the boot device <- there is no noticeable overlay when compared to #1 above 

3) VHD booting (with VHD loaded in RAM):

OS accesses its files from a Ramdisk, after it has been transferred from boot device <- here you have very fast access to files but an initial delay while the vhd is copied from boot device to RAM

4) VHD booting (with compressed lzma expanded to RAM):

OS accesses its files from a Ramdisk, after it has been transferred (compressed) from boot device and expanded in RAM   <- here, as above, you have very fast access to files but an initial delay while the vhd is copied from boot device to RAM and expanded in the meantime

 

Now the point is how much time(I presume noticeable) the expansion of the compressed data compares to the "saving" due to having to transfer less data through the bus from the boot device.

Example (data invented just for the sake of the example, and intended simplification between Mib and Mb using the decimal way):

A VHD is 1000 Mb in size.

If compressed with lzma it becomes 600 Mb.

The boot device has a 4 Kb "random" read speed of 20 Mb/s and a "bulk" speed of 30 Mb/s

The Ram/Ramdisk has a 4 Kb "random" read speed of 1000 Mb/s (write speed is not relevant as it will be anyway faster than read speed of the boot device)

The amount of files that must be read/loaded to get to the desktop is 300 Mb

There is a generic boot time overhead of 20 seconds

The top speed of the lzma decompression algorithm pipe is 100 Mb/s

 

1) Normal booting: 300/20=15 + 20 = 35 seconds

2) VHD booting (with direct access): Insignificant overlay to mount the .vhd 0 + 300/20=15 + 20 = 35 seconds

3) VHD booting (with VHD loaded in RAM): 1000/30=33.3 + Insignificant overlay to mount the .vhd 0 + 300/1000=0.3 + 20 = 53.3 seconds

4) VHD booting (with compressed lzma expanded to RAM): 600/30=20 + lzma expansion 600/100=6+ Insignificant overlay to mount the .vhd 0 + 300/1000=0.3 + 20 = 46.3 seconds

 

Am I missing something?

 

Wonko

 

 

[1] This is usually a "small size chunks" speed, that may differ noticeably from "bulk" sequential transfer speed.

it is a bit the same as winpe but takes more time to create and shrink [ thanks to Nlite ] , reducing size of windows means specializing it for few softwares . with the help of good tools from Mark Russinovich and Bryce Cogswell of Sysinternals , removing is easy .

firadisk works well with w10 x64 but w10 is very hard to slim compared to win 7 x64 , beside that w10 is very very buggy [ as an example it is not able of teaming network cards ] and like the control panel or the panel control [ mostly white & called settings ].
w10 looks like something half-finished [ it is the same with ati setting panel that still uses the reduced old ati control panel as "advanced settings" at least with current whql drivers...that should be in "the mood" to give half-done patchies software]

win7 has a lot more software than win10 : like the media center for those having a tv card or the xp support .

i made one vhd for w10 these days , the size of it with few softwares for video editing in HD is 12 Go . with win 7 x64 [ that i will rebuild these days because of updates of drivers and softwares ] i can get vhds of 7 or 8 Go for the same results and with all drivers working at 100% .

like i said , the good thing is not the speed [ if you have ssd hd... ] but the stability and the time of response [ if you have a classical hd that is no longer running and turned off with its controller by windows power management : you know what i mean / instead of getting up : win crashes..and kills hours of work ] , plus the fact your windows is always "clean" without updates ;"].... or at least at each boot ..

A few questions:

What size is the VHD you are using?

What size it becomes once LZMA compressed?

What is the actual booting time of the .vhd in memory?

What is the actual booting time of the lzma compressed one?

What is the actual difference in booting time between the "plain" .vhd and the lzma compressed one?

 

I have to assume that the vhd in memory offers the same stability of the lzma, so the only difference may be the booting time or the size occupied on disk.

 

Wonko