Re: Common Live CD base and generator
- To: firstname.lastname@example.org
- Cc: 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: Mon, 23 Feb 2004 08:36:43 +0100
- Message-id: <4039AD8B.email@example.com>
- In-reply-to: <17979666.1077491245908.JavaMail.firstname.lastname@example.org>
- References: <17979666.1077491245908.JavaMail.email@example.com>
firstname.lastname@example.org a écrit :
AFAIK compressed fs used in LiveCD (cloop, squashfs) are read only.
Usage is create after the contents is made. That means you need 3G space
free to create LiveCD. If you can put in the image compressed data
directly, you need less than 1G.
- 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
A regular install of a .deb into the live CDs "chroot"
eviromnent, possibly into a mounted compressed fs.
Right. This need a clent side elaborate program, capable to detect wich
deb can be repackaged (or files reget) from a old version of the cd.
For that jigdolivecd-file needs to know what deb contains what
file in the fs.
Maybe this is not neseccary:
A .tamplate is made from the base of a live cd where the largest part that is
the compressed fs file is left out (md5sumed can be ignored in the case of
personal live cds).
On the client side jigdo or a helper program first takes a list of packages
(tasks/meta-packages?) and installs the .debs into a mounted compressed fs
file of the same size that will fits into the CD .template afterwards.
yes. I know Fabian Franz has this kind of ideas too. He has done a proof
of concept ppc port last year.
This part is actually like a normal install, you can do it manualy and choose
what you want or use a more automated method to install into the
"master chroot" location. The difference from a regular install in these days
are things like the use of a init package with permanent automatic hardware
detection. (i.e. .debs that could be brought back into debian from existing
knoppix/morphix etc. as agreed earlier  and with news heard to come soon)
IMHO autoconfiguration needs usage of discover2. hwsetup (in knoppix) is
a good solution but not enough generic. Anyway i use hwsetup ppc port
for the moment.
discover2 needs just a database with full configuration information
(like options to pass in XF86Config-4). It's very flexible.
eltorito is a PC problem. Integrate in debian means thinking in non PC
arch. This is why Fabian Franz has done a ppc port.
But maybe even the the eltorito bootimage and initrd should be
fetched/created from regular packages, in this case the adapted jigdo would
probably be run in a mode that calls mkisofs at the end,
again as disussed at  and later.
anyway in Mac a bootable cd needs hybrid HFS/ISO9660 CD, mkisofs can do
that too. so mkisofs seems a good solution.