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

[Jeremy Katz]

On Thu, 2008-11-27 at 22:51 +0100, Till Maas wrote:
> Sorry for my late reply, somehow your mail got marked as read here, without me 
> really reading it. :-/

No worries -- it was pretty late to consider for F10 anyway.

> On Tue November 4 2008, Jeremy Katz wrote:
> > On Tue, 2008-11-04 at 10:10 +0100, Till Maas wrote:
> > > I would like to create a usb device that contains several live mediums.
> > > Afaics, this is currently not possible, unless I use a separate partition
> > > for each live medium, because they all expect LiveOS to be the directory
> > > containing some images. Attached is a patch agains mkliveinitrd from the
> > > current rawhide cvs repository that makes it possible to pass a
> > > "live_dir" kernel parameter, that is then used instead of LiveOS.
> >
> > This has now come up a couple of times.  Unfortunately, changing it
> > makes things a lot more complicated.  Right now, I know that if I have a
> > LiveOS directory, that's the live image and that's what I have to warn
> > people about if we change.  If instead, it could be in any directory,
> > how does the boot loader bits get handled?
> 
> > So while this gets some of the simple bits, if this is something that's
> > worth supporting, I'd rather think about the whole picture.
> > 1) Do we want to support this just off of USB-type media or on CDs also?
> 
> Normally I do not use optical media, but since DVDs do not cost much more than 
> CDs here, I consider a multi Live DVD useful, too. For DVDs it would be also 
> helpful if one could create a DVD that also contains all the original iso 
> images and is able to boot from then. It would also be nice to have a 
> combined full installation DVD with live support I guess.

The latter bits are all fairly orthogonal (well, aside from the
bootloader question).  But it sounds like (and I'd also think) that if
we do this, we have to do it to work for optical media too.

> > 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.

> 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

> > > How do you like this patch and do I have to submit it via bugzilla to the
> > > mkinitrd component to get it included?
> >
> > On this list is fine
> 
> I noticed that the patch is not yet applied. Are there any reasons against it, 
> because it is not yet necessary to decide the open questions for the 
> frontends that use the boot param yet, because they will not need the patch 
> to be modified. Unless of course booting .iso files is added, but this is 
> more a plan for the far away future.

The open questions are important, though, as they'll impact the way the
entire path is structured.  I'd rather not be in a situation of having
case statements upon case statements to support each stage in the
evolution of the way it works.  The live initrd is already bad enough
there with the movement we've already had -- and this is already going
to add another case to care about.

> > > Do you know other places on the live
> > > medium that use a hardcoded LiveOS directory?
> >
> > There's definitely at least livecd-iso-to-disk.  Possibly some of the
> > install pieces, but I'd have to go double-check.  And also some things
> > in the livesys initscript.
> 
> 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

Jeremy