At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image. This also requires template support and the ability to select templates to write out based on the variant in the %post. For instance the olpc.fth file is read in by the openfirmware. For jffs2 builds we point to the nand on the XO machines. For ext3 we point to a USB disk. Also on ext3 we write out grub entries for use with standard machines and vitalization software like qemu.
What would be the best way to add this support to the livecd tools?
--- "John (J5) Palmieri" johnp@redhat.com wrote:
At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image. This also requires template support and the ability to select templates to write out based on the variant in the %post. For instance the olpc.fth file is read in by the openfirmware. For jffs2 builds we point to the nand on the XO machines. For ext3 we point to a USB disk. Also on ext3 we write out grub entries for use with standard machines and vitalization software like qemu.
What would be the best way to add this support to the livecd tools?
This isn't really an answer to your question, but I would like to affirm the usefulness of what you described. I.e. creating a clear demarcation between the system installation frontend, and the system target type mogrification backend.
While I've never been a huge fan of the read-only root kadischi/stateless style system, I admit it may be the right choice in some situations. And in general I think there are several other interesting system target type backends one could have. I.e. I think if things get modularized the way you described, it would be gracefully doable to merge the kadischi code into the tool as another alternate backend. And likewise, one could have a standard knoppix style unionfs backend (I think the scientific-linux folks use this style on their centos derived livecd). Not to mention the nearly half dozen 'out there' ideas I've posted on this list over the years.
Likewise, I can see several possibly useful variants on the frontend as well. I.e. the kadischi anaconda --rootpath. Or my preferred method of installing inside qemu so as not to require root privs (at the expense of speed)
I realize of course there are rational arguments to avoid having too many choices. On the other hand, lots of choices can be a good thing, in that the most useful among them will see the most development and evolution.
Of course my overambitious 'one ring to rule them all' goal is to even support other distributions such as debian/ubuntu/centos/whatever in the frontend options as well.
But yeah... What you said sounds excellent. $0.02...
-dmc/jdog
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 2007-04-24 at 15:10 -0400, John (J5) Palmieri wrote:
At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image.
I think adding an option
--target=[livecd| disk_msdos_ext3| disk_msdos_ext3_separate_boot| ext3| jffs2]
with this help text (for --help)
--target Choose target mode; defaults to livecd livecd: A compressed livecd ISO with the root file system disk_msdos_ext3 : An image with a MSDOS partitioning table, a single ext3 data partition and a bootloader for IBM PC hardware disk_msdos_ext3_separate_boot : Like disk_msdos_ext3 only that /boot is on a separate partition. ext3 : A single ext3 partition jffs2 : A jffs2 file system
is what we want. Perhaps disk_msdos_ext3_separate_boot can be achieved by a separate option just like we have --skip-compression for --target=livecd. Thoughts?
This also requires template support and the ability to select templates to write out based on the variant in the %post. For instance the olpc.fth file is read in by the openfirmware. For jffs2 builds we point to the nand on the XO machines. For ext3 we point to a USB disk. Also on ext3 we write out grub entries for use with standard machines and vitalization software like qemu.
The olpc.fth business is probably not something we need to teach the livecd tools about at all; e.g. it's simply just something you do in % post depending on the target. This raises the question of how do we pass "options" like --target to kickstart so you can do different things depending. An environment variable. Jeremy?
David
On Wed, 2007-04-25 at 13:41 -0400, David Zeuthen wrote:
On Tue, 2007-04-24 at 15:10 -0400, John (J5) Palmieri wrote:
At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image.
I think adding an option
--target=[livecd| disk_msdos_ext3| disk_msdos_ext3_separate_boot| ext3| jffs2]
with this help text (for --help)
--target Choose target mode; defaults to livecd livecd: A compressed livecd ISO with the root file system disk_msdos_ext3 : An image with a MSDOS partitioning table, a single ext3 data partition and a bootloader for IBM PC hardware disk_msdos_ext3_separate_boot : Like disk_msdos_ext3 only that /boot is on a separate partition. ext3 : A single ext3 partition jffs2 : A jffs2 file system
is what we want. Perhaps disk_msdos_ext3_separate_boot can be achieved by a separate option just like we have --skip-compression for --target=livecd. Thoughts?
I've a few of patches to do something similar, except I've been using livecd-creator to build xen system images for the likes of image based deployment (e.g. stateless) or this virtual appliances notion.
See the attached patches - the first makes LiveCDTarget be a sub-class of InstallationTarget, the second adds --target and the last adds RawTarget which I've been playing with.
Cheers, Mark.
Hey,
On Thu, 2007-04-26 at 10:22 +0100, Mark McLoughlin wrote:
On Wed, 2007-04-25 at 13:41 -0400, David Zeuthen wrote:
I think adding an option
--target=[livecd| disk_msdos_ext3| disk_msdos_ext3_separate_boot| ext3| jffs2]
with this help text (for --help)
--target Choose target mode; defaults to livecd livecd: A compressed livecd ISO with the root file system disk_msdos_ext3 : An image with a MSDOS partitioning table, a single ext3 data partition and a bootloader for IBM PC hardware disk_msdos_ext3_separate_boot : Like disk_msdos_ext3 only that /boot is on a separate partition. ext3 : A single ext3 partition jffs2 : A jffs2 file system
is what we want. Perhaps disk_msdos_ext3_separate_boot can be achieved by a separate option just like we have --skip-compression for --target=livecd. Thoughts?
I've a few of patches to do something similar, except I've been using livecd-creator to build xen system images for the likes of image based deployment (e.g. stateless) or this virtual appliances notion.
See the attached patches - the first makes LiveCDTarget be a sub-class of InstallationTarget, the second adds --target and the last adds RawTarget which I've been playing with.
So, there hasn't been any comments on these patches. Re-factoring out the InstallationTarget sub-class seems to me like a good start - can we get that patch merged?
Thanks, Mark.
On Fri, 2007-06-01 at 12:41 +0100, Mark McLoughlin wrote:
See the attached patches - the first makes LiveCDTarget be a sub-class of InstallationTarget, the second adds --target and the last adds RawTarget which I've been playing with.
So, there hasn't been any comments on these patches. Re-factoring out the InstallationTarget sub-class seems to me like a good start - can we get that patch merged?
I'm not ignoring you -- just was first trying to get Fedora 7 out on a relatively stable toolset. Now that that's out of the way, it's time to step back and look at the big picture of what we're doing with the livecd creation and see where we can and should go.
I'm hopefully going to sit down and write some things up in the next day or so if I don't get otherwise distracted
Jeremy
On Wed, 2007-04-25 at 13:41 -0400, David Zeuthen wrote:
On Tue, 2007-04-24 at 15:10 -0400, John (J5) Palmieri wrote:
At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image.
I think adding an option
--target=[livecd| disk_msdos_ext3| disk_msdos_ext3_separate_boot| ext3| jffs2]
with this help text (for --help)
But when we start getting to this degree of complication, I really start to wonder why we're reimplementing all of this stuff as opposed to instead moving in the direction of being able to generate all of these different things with anaconda. While anaconda isn't entirely there right now to be able to do this easily, if we're serious about wanting to generically generate images of a lot of different formats, then it's not *that* much work to get there. Yeah, it's more code and it's more of a learning curve to work on, but that's not necessarily a reason to move away.
Jeremy
On Fri, 2007-04-27 at 16:04 -0400, Jeremy Katz wrote:
On Wed, 2007-04-25 at 13:41 -0400, David Zeuthen wrote:
On Tue, 2007-04-24 at 15:10 -0400, John (J5) Palmieri wrote:
At OLPC we need to support ext3 and jffs2 builds even more so than livecd isos. Since most of the process is the same up until the final image and bootloaders we would like to add this support into the livecd tools so that all fedora projects use one toolchain. The question is how can this best be accomplished?
I think passing a --variant switch (i.e. --variant=jffs2) should switch the backend to generating the correct image.
I think adding an option
--target=[livecd| disk_msdos_ext3| disk_msdos_ext3_separate_boot| ext3| jffs2]
with this help text (for --help)
But when we start getting to this degree of complication, I really start to wonder why we're reimplementing all of this stuff as opposed to instead moving in the direction of being able to generate all of these different things with anaconda. While anaconda isn't entirely there right now to be able to do this easily, if we're serious about wanting to generically generate images of a lot of different formats, then it's not *that* much work to get there. Yeah, it's more code and it's more of a learning curve to work on, but that's not necessarily a reason to move away.
I'm 100% with you here. Though the nice thing with livecd is that it is easy for someone to jump into. I would love one installer tool to rule them all and spend time shaping up fedora packages so that no matter what target you choose it all just works.
livecd@lists.fedoraproject.org