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