Livecd techniques

Lauri Kasanen curaga at operamail.com
Sun Dec 2 10:43:57 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.

Thanks, this clears up a lot.
For using squashfs, I just thought it is overly complicated to modify many areas of an iso when booting toram, but when using squashfs the file could just be copied into tmpfs.

Lauri

-- 
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com

Powered by Outblaze



More information about the livecd mailing list