[Fedora-livecd-list] RFE: allow multi live medium

[Jeremy Katz]

On Tue, 2008-12-02 at 00:22 +0100, Till Maas wrote:
> On Sun November 30 2008, Jeremy Katz wrote:
> > On Thu, 2008-11-27 at 22:51 +0100, Till Maas wrote:
> > > > 2) How do we want to namespace so that we can better support multiples
> > > > and have them identifiable?
> > >
> > > I guess the easiest way would be to use the name of the iso/torrent file
> > > for each live image, e.g.:
> > >
> > > LiveOS/F10-i686-Live
> > > LiveOS/F10-i686-Live-KDE
> > >
> > > or even seperate directories in the root of the filesystem.
> >
> > This could work and is definitely better than some of the other things
> > that have been suggested in the past.  It'd require keeping some
> > knowledge of the original label/filename when we do the transform in
> > livecd-iso-to-disk/liveusb-creator.  And if go this route, it probably
> > makes the most sense to do it in all cases and not just as a special
> > case.
> 
> Maybe it would be also possible to use some meta information from the .iso 
> file to make this work also in case the iso filename was not preserved.

Yeah, the fslabel was what I really meant there

> > > What I would
> > > really enjoy would be a generic bootloader that would recognize any iso
> > > image on the medium and would allow to chainboot them. I believe at least
> > > chainbooting iso images is possible with grub2, but I did not yet test
> > > it.
> >
> > Unless a lot has changed since I last looked at grub2 a few months ago,
> > it's in no way ready for primetime.  And to be honest, I'm not entirely
> > convinced that it's going to be.  Chainbooting the iso is an interesting
> > thought, though.  I wonder if it could be done at all easily with the
> > com32 support in syslinux.
> >
> > > > 3) How do we want to handle the boot-loader pieces if we have multiple
> > > > OS options on the same medium?
> > >
> > > I do not yet have an answer for this.
> >
> > I don't either :)  Which might put it on the critical path for
> > implementing
> 
> Yesterday I inspected a multi live optical medium that contained several 
> distributions. There the append keyword was used to load the several isolinux 
> config files for each distribution from a generic one.

Hmmm, I wonder how bad it would be to wire up a com32 module that walked
the LiveOS directory and for each subdirectory in it, grabbed and
appended LiveOS/fslabel/isolinux.cfg.  Since that seems like a better
way than having to explicitly do an append keyword for each "image" we
add

> > > Yes, it is hardcoded in the livesys initscript. Where does it come from?
> > > I cannot find it or any reference to it in the livecd git repository and
> > > it is also not owned by any package on the live medium.
> >
> > The initscript is in the kickstart config, so the spin-kickstarts repo.
> > Getting these pieces to work also matters for landing the initrd support
> 
> Is there any other reason than lack of time to not add the livesys init script 
> to the initscripts package? One kickstart file I opened already contained a 
> FIXME saying, that the livesys script should be in some package and I guess 
> it should be initscripts.

There are bits and pieces that are specific to each individual spin.  I
guess the base bits could go into the initscripts package if notting
could be talked into it

Jeremy