[Fedora-livecd-list] Targetting other file systems besides iso

[Jane Dogalt]

--- "John (J5) Palmieri" <johnp at redhat.com> wrote:

> At OLPC we need to support ext3 and jffs2 builds even more so than
> livecd isos.  Since most of the process is the same up until the
> final
> image and bootloaders we would like to add this support into the
> livecd
> tools so that all fedora projects use one toolchain.  The question is
> how can this best be accomplished?
> 
> I think passing a --variant switch (i.e. --variant=jffs2) should
> switch
> the backend to generating the correct image.  This also requires
> template support and the ability to select templates to write out
> based
> on the variant in the %post.  For instance the olpc.fth file is read
> in
> by the openfirmware.  For jffs2 builds we point to the nand on the XO
> machines.  For ext3 we point to a USB disk.  Also on ext3 we write
> out
> grub entries for use with standard machines and vitalization software
> like qemu.
> 
> What would be the best way to add this support to the livecd tools?


This isn't really an answer to your question, but I would like to
affirm the usefulness of what you described.  I.e. creating a clear
demarcation between the system installation frontend, and the system
target type mogrification backend.

While I've never been a huge fan of the read-only root
kadischi/stateless style system, I admit it may be the right choice in
some situations.  And in general I think there are several other
interesting system target type backends one could have.  I.e. I think
if things get modularized the way you described, it would be gracefully
doable to merge the kadischi code into the tool as another alternate
backend.  And likewise, one could have a standard knoppix style unionfs
backend (I think the scientific-linux folks use this style on their
centos derived livecd).  Not to mention the nearly half dozen 'out
there' ideas I've posted on this list over the years.

Likewise, I can see several possibly useful variants on the frontend as
well.  I.e. the kadischi anaconda --rootpath.  Or my preferred method
of installing inside qemu so as not to require root privs (at the
expense of speed)

I realize of course there are rational arguments to avoid having too
many choices.  On the other hand, lots of choices can be a good thing,
in that the most useful among them will see the most development and
evolution.

Of course my overambitious 'one ring to rule them all' goal is to even
support other distributions such as debian/ubuntu/centos/whatever in
the frontend options as well.

But yeah...  What you said sounds excellent.  $0.02...

-dmc/jdog


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com