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/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
