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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-olpc-list --
Jim Gettys <jg(a)laptop.org>
One Laptop Per Child