Re: Common Live CD base and generator
- To: email@example.com
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: Common Live CD base and generator
- From: Fleny68 <firstname.lastname@example.org>
- Date: Sun, 22 Feb 2004 22:27:28 +0100
- Message-id: <[🔎] 40391EC0.email@example.com>
- In-reply-to: <[🔎] 14620102.1077480145424.JavaMail.firstname.lastname@example.org>
- References: <[🔎] 14620102.1077480145424.JavaMail.email@example.com>
firstname.lastname@example.org a écrit :
thanks for all your attention. Unfortunately this goes accross different
lists, so please just ignore if you are not interested.
same for me.
From what you wrote Alex, the morphix tools look very promising as part of a
universal debian-live CD generator as they take regular .debs.
Well. Morphix is modular knoppix cloop based, isn't it?
This modularity is a good way, but a personnal livecd neds more: the
choice of every .deb installed in the LiveCD.
I am not sure this is more easy to make a personnal module for morphix,
than to personalize knoppix.
OK, now I now what you ment before when talking about the problem with
compressed images. You would also need compressed chunks of data to allocate
in the .template. Unfortunately they are not the same as the .debs and
they are hard to locate in the loop file in the first place.
There is only 2 solutions:
- You may have a mirror with the file to get, even if the files are
conprssed trunks of data. But you lose the possibility to reuse the 300
In this case you split the compressed loop fs, and put in the mirrors
the compressed data. A better way than cloop to use with that is a
compressed filesystem, like squashfs, because you compress file by
file and all the unchanged files can be kept. You just have to split the
squashed loop image by inode and by files.
- You write an adaptation of jigdo: it could get a .deb, unpack it
and put the files in the right place of the iso, eventually compressing
them. For that jigdolivecd-file needs to know what deb contains what
file in the fs.
Of course the second solution needs a compressed filesystem instead a
compressed block system, i.e. squashfs  instead of cloop.
With cloop you need to get all the files and to compress after. In
squashfs you need the compressed inode too, this is a kind of .template
to add in this case.
 squashfs is good enough to replace cloop, i use it in the
k-mib-ppc project (it's a port of knoppix for ppc).