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 -- Fedora-livecd-list mailing list Fedora-livecd-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-livecd-list