Early boot, activation, upgrades

[C. Scott Ananian]

My current work on early boot/activation/upgrades is at:

http://dev.laptop.org/git?p=users/cscott/d-i
http://dev.laptop.org/git?p=users/cscott/rootskel-olpc;a=tree;f=src-olpc;hb=HEAD

I built a new initrd, which replaces the existing 'mayflower' initrd
for emulated builds (XOs do not currently use an initrd).  The initrd
boots into python2.5 as PID 1, and does the usual initrd things
(mounting root, /proc, and /sys, parsing the kernel command line).

In theory, we then do some basic XO networking setup (unwritten due to
a lack of XO which will be soon remedied) and then invoke activation
if necessary (Ivan will write this part?).

After the (missing) activation code, we frob a symlink at /current
which points to either /a or /b.  The standard bin, var, tmp, etc
directories are symlinks.  For example, /bin -> /current/bin.  Moving
/current is thus sufficient to get us to boot from either /a or /b.
OFW should give us some bits on the kernel command line to tell which
to boot from.  There's a bit of placeholder stuff here; I believe
Mitch is writing up the official OFW-to-initrd handoff spec.

I've also written some code to create hard-linked directory clones:
  http://dev.laptop.org/git?p=users/cscott/rmanifest-py;a=blob;f=rclone.py;hb=HEAD

We start an upgrade by making a hard-linked clone of the current OS
bits, then we fetch the new bits, updating our clone as we go, then we
tell the security service that we're done and it authenticates the new
bits and swings /current as needed.  This still needs to be written.

Some questions:
 a) can someone who understands the 'stateless' code and the
activities and journal directory structure give me a quick guide to
separating these from the base image?  I'd guess that we'd create new
root directories (/activities, /journal, etc) and bind-mount them into
the proper places in the active filesystem image during startup.
Discussion welcome.
 b) should we be more aggressive in using bind-mounts to create
directory clones, to avoid creating a copy of the directory tree when
making our hard-link clones?  Bind-mounted trees aren't copy-on-write
like (vserver-ized) hard links are.
 c) pilgrim handholding to integrate this code should be welcome.  It
may be time to separate out the activities from the build image,
although at the moment I've got a hackish piece of initrd code which
recognizes the standard build image directory structure and rearranges
it on first boot.
 d) I'd like to see the ide-core, ide-disk, and piix modules built in
to the kernel, to break the kernel dependency caused by having to
include them in the initrd image.  If space is at a premium, we could
build separate qemu and XO kernel images, and only include piix and
friends in the qemu image.  I think once I plug in the networking, I'm
going to want IPv6 included in the kernel non-modularly as well (and
the qemu builds might need a static rtl8139 driver included).
  --scott
-- 
                         ( http://cscott.net/ )