2:10 p.m.
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(a)redhat.com>
8:23 p.m.
--- "John (J5) Palmieri" <johnp(a)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
12:41 p.m.
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
4:22 a.m.
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.
6:41 a.m.
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.
11:03 a.m.
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
3:04 p.m.
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
3:52 p.m.
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.
--
John (J5) Palmieri <johnp(a)redhat.com>
6168
days inactive
6211
days old
livecd@lists.fedoraproject.org
7 comments
5 participants
participants (5)
-
David Zeuthen -
Jane Dogalt -
Jeremy Katz -
John (J5) Palmieri -
Mark McLoughlin