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

[Till Maas]

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.

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

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

Making it possible to rename the LiveOS directory and pass it's location to 
initrd and probably via initrd to livesys currently seems to be enough to 
make it possible to create a multi live medium. I will try to create a POC 
usb device, soon. The implementation of live-iso-to-disk and the real 
location / organization of the boot loader does not really change this. Only 
if we can also support booting isos via grub2, probably an additional loop 
mount needs to be added to the initrd, but this is only wild speculation.

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

Regards,
Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/fedora-livecd-list/attachments/20081202/cf70066d/attachment.sig>