3:10 a.m.
Hiyas,
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.
How do you like this patch and do I have to submit it via bugzilla to the
mkinitrd component to get it included? Do you know other places on the live
medium that use a hardcoded LiveOS directory?
Regards,
Till
10:24 a.m.
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?
2) How do we want to namespace so that we can better support multiples
and have them identifiable?
3) How do we want to handle the boot-loader pieces if we have multiple
OS options on the same medium?
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
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.
Jeremy
3:51 p.m.
Sorry for my late reply, somehow your mail got marked as read here, without me
really reading it. :-/
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.
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. 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.
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.
> 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.
> 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.
Regards,
Till
8:57 p.m.
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
5:17 p.m.
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.
FWIW, the method I opted for in my viros project was to pass the
label/filename as a kernel boot cmdline parameter. It's not that
complicated.
> 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.
Yes, that would be cool, and I do think I tried this with grub2 a long
time ago. I'm pretty sure you still need initrd/bootscript support, as
I don't think the chainloader does quite so much magic that the
resulting OS sees a virtual cdrom drive. I.e. the initrd/bootscript
still needs extra logic to dig into the specific iso and get at its
specific rootfs.
-dmc
5:22 p.m.
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
10:49 a.m.
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
5617
days inactive
5645
days old
livecd@lists.fedoraproject.org
6 comments
3 participants
participants (3)
-
Douglas McClendon -
Jeremy Katz -
Till Maas