Livecd techniques

Alexander E. Patrakov patrakov at gmail.com
Sun Dec 2 08:48:59 PST 2007


2007/12/2, Lauri Kasanen <curaga at operamail.com>:
> Hi
>
> I'm looking into the various livecd techniques, how to pretend r/w, compression..
> I just looked at the latest 6.3-min cd. I understood most of it, but have some questions left:
>
> In the past Alexander told me:
> > Cloop was never used on LFS LiveCDs. Older CDs used squashfs for
> > compression, while modern CDs use zisofs. The change was done because,
> > with device-mapper based RW mechanism, one has to compress a single file
> > (root.ext2), not a full filesystem tree, and both zisofs and squashfs
> > are equally efficient for that - but zisofs is simpler to set up.
>
> Why is this so?

Because device-mapper needs a single block device (say, loop), and
loop needs a single file, not a filesystem, to be attached to.

> There isn't much documentation on device-mapper available..

I used this article when implementing a LiveCD:
http://linuxgazette.net/114/kapil.html

> Why couldn't a squashfs file be used as the first loop device?

A squashfs file can be loop-mounted and produces a filesystem (i.e., a
whole tree). Device-mapper expects a block device, not a filesystem,
as its input.

So yes, you can produce a squashfs file containing a filesystem with a
single root.ext2 file that you can use for a loop. Thus, you are
proposing this:

isofs -(mount)-> compressed.sqfs -(loop)-(mount)-> root.ext2 -(loop)->
device-mapper

while the CD uses this simpler setup:

zisofs -(mount)-> root.ext2 -(loop)-> device-mapper

Note no mount between root.ext2 and device-mapper in both cases, while
squashfs produces usable compression only when loop-mounted.

> 2) How did you come up with the overhead calculated?
> I guess it's used to have a little bigger writable area than the original even if there's less ram than the livecd size available, correct me if I'm wrong..

I made a device mapper snapshot setup with two loops over sparse
files, with the second file being too large, and filled the resulting
device with junk. Then I looked how much of the second file was
actually filled with data. This way, I can guarantee that the snapshot
won't go offline even if a user erases everything from the LiveCD
filesystem and fills the resulting empty filesystem with completely
different data.

Of course, this is overkill. If you create the second file with only
256 MB size, the snapshot won't go offline until the user actually
writes a bit less than 256 MB.

And yes, it is possible to fill the RAM completely by creating files,
if the computer has less than 1.5 GB of RAM.

> 3) What's the minimum amount of RAM needed to boot the LFS livecd? By my tries in qemu it's somewhere between 20 and 30mb, as 22 didn't boot and 30 booted.

Yes, this is a reasonable estimation.

> Is this because the
> initramfs file is 15mb uncompressed?

Yes.

-- 
Alexander E. Patrakov



More information about the livecd mailing list