State of Fedora spin

[Jim Gettys]

On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote:
> On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote:
> >  o a 520 megabyte spin was pretty easy to make; but that is using
> > Squashfs, which is more efficient than JFFS2, so it is still not small
> > enough to fit allowing olpc-update to be used for an in-place upgrade.
> > Said spin booted fine on conventional systems, though since it lacked a
> > kernel for OLPC, could not be booted on the XO.
> 
> Note that the config as it currently stands is missing some pretty
> important things.  Like, say, X drivers :)  It also ends up with a lot
> of duplication from the "base" config and thus will in the long run be a
> little more painful to maintain.
> 
> Unfortunately, with the older kernel, there's not a great way around
> this at the moment.  I'll try to add a fixup so that overriding repos
> works properly in a little bit.  
> 
> >  o the olpc kernel lacks the squashfs patch; we created a RPM adding it,
> > which would be necessary to use the Fedora live-cd-tools.
> 
> There are a couple of other quirks of the olpc kernel that break using
> it as-is for a live image:
> 1) squashfs as mentioned
> 2) dm_snapshot isn't being built
> 3) The %post of the kernel package doesn't call new-kernel-pkg, instead
> doing things by hand.  But not including mkinitrd.  This led to no
> initrd and the error that was later seen.  Given that the XO is always
> using an initrd, is there a reason new-kernel-pkg isn't just being
> called?, 

Yes, because right now, our initrd for the anti-theft system is pretty
magic, and gets built separately (on Debian, believe it or not, the last
I heard).  Ideally, this can get fixed, so we can share an identical
kernel between different loads.  Once our 8.2.0 system ships, I think we
can/should add the small set of stuff stock fedora needs to the OLPC
configuration so that the base system can be identical.

> 
> But with those taken care of, I can get an image built based on rawhide
> + that kernel that boots.  I then have to drop an xorg.conf in as the
> driver is busted and doesn't manage to auto-config, but that too should
> be fairly straight-forward to get fixed (bz#460581).
> 
> > Problems right now:
> >  o live-cd-tools doesn't seem to find the initrd, when Sebastian tries
> > to build a spin with an OLPC kernel.  We don't understand this. Anyone
> > familiar with the live-cd-tools who can help is greatly appreciated...
> 
> This is because the initrd isn't being built.  See 3 above.
> 
> >  o Note that there is tons of other fat to nuke; some unneeded
> > dependencies (e.g. libgweather), icons at a bunch of
> > sizes, /usr/share/doc is accumulates to several hundred megabytes
> > (uncompressed).  Note that this is several hundred megabytes larger than
> > the OLPC Sugar only build.  We'll need lots of help here; some of it is
> > very easy; for example, nuking post install (most of) what is
> > in /usr/share/doc.
> 
> libgweather is part of what's needed for the actual desktop -- it's
> depended on by the time/date stuff carried by gnome.  it


Actually, it is just the stupid clock applet to show the names of the
cities where you may also show the current time and weather.
> Also, just nuking
> docs willy-nilly isn't the wisest of ideas.  For one thing, in some
> cases, the license file is required to be included.  Also, if they're
> just nuked with an rm, then a later update by the user will bring them
> back.  So I have been very cautious about doing anything along those
> lines for "general purpose" use -- and since it seems one of the goals
> here is to have the XO generally running Fedora, it may be something to
> avoid.

Much of this is ChangeLogs and the like, which I think we can safely
delete.  We can't burn several hundred meg (uncompressed) on this.  I'll
get some statistics of the different file types.  Preserving license
files I agree is essential; we don't want to have to do the inventorying
we're doing for the olpc load.

> 
> >  o what the manifest of the system should be is something well worth
> > serious discussion: there are questions such as claws versus
> > thunderbird, versus other mail possibilities.
> 
> That depends to some extent what the goal is -- do we want to be able to
> be running "stock" Fedora or a special spin?  The former seems like it's
> more valuable in a lot of ways because a user who is used to Fedora has
> the _exact_ same applications, etc available.
> 
> >  o Once a spin exists, some modifications would be needed to the
> > installation program to install the spin onto jffs2.
> 
> >From what I remember, jffs2 is substantially different in that you don't
> do formatting, etc and rather just do imaging.  The live install process
> is already somewhat imaging-like in that we just dd over the filesystem
> to the final partition and do some resizing tricks, but that's not going
> to work as-is.  I'd have to go back and refresh my memory of jffs2
> imaging to give any better indication.  It does, at least, look like
> jffs2 should have all of the right hooks in the kernel for security
> xattrs, though.

No, for olpc-update, we'll just have to put the bits in the right place
on the server, and jffs2 /olpc-update will take care of the rest.
Similarly, for an "install to disk". Jffs2 can/should be treated as a
normal file system.  To coexist with our sugar based load to be able to
install via olpc-update, we just put it in a root of its own.  Our
firmware is set up to allow booting two different systems in their own
roots (which may even be sharing hardlinked files); this is to enable
our robust upgrade stuff. On our system, you can have an olpc-upgrade
fail in the middle, yet still end up with your old system intact.  So
other than putting a prefix on the paths, (and optionally hardlinking
identical files) install from a live CD/USB image should be easy.

The only time we need to build a jffs2 image from scratch is if we want
an image from scratch that can be installed from ofw using "copy-nand".

> 
> > We hope that by the time this all is ready to go, conventional packages
> > for Sugar for Fedora will make it possible for a simple sugar
> > installation as well; but only time will tell.
> 
> Yeah, a couple of separate things need following up on there.  Marco's
> proposed bundlebuilder changes should take care of one set of them.
> Then it should at least be easier to get packages being built and
> through the review process, at which point, I'll return to that
> 
> Jeremy
> 
> _______________________________________________
> Fedora-olpc-list mailing list
> Fedora-olpc-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-olpc-list
-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child