State of Fedora spin

[Jeremy Katz]

On Thu, 2008-08-28 at 16:36 -0400, Jim Gettys wrote: 
> 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 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).  

Ewwww :-)

> 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.

There's definitely been a lot of drift between the two kernel spec
files.  Which is worth resolving in any case.  The ideal, to me at
least, would be if we can just use one of the same kernels that's
shipped in Fedora.  That's the only way that we're going to be able to
have any spin carry the Fedora trademark at present.  And really, that
doesn't look like it should be that far off -- there's not that much in
the diff of 2.6.26 to the olpc kernel tree from a glance.  And some may
even be resolved in 2.6.27.

> > >  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.

Which is also used for the timezone setting bits.  While the current
stored form of the data has its downsides, it's actually quite good to
be able to possibly have a better way in the future of timezone
selection than just dealing with the poor stuff that's in tzdata.  So
rather than throwing out the baby and the bathwater, it's more likely
worthwhile to help upstream come up with a better way of representing
the data with less duplication.

> > >  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.

Easy-ish, but slow.  Doing a file-based copy took on the order of a heck
of a lot longer from what I remember.  I'll have to look closer at that,
but it's a little lower on my todo list

Jeremy