Early boot

  This page is monitored by the OLPC team.

NOTE: The contents of this page are not set in stone, and are subject to change! This page is a draft in active flux ... Please leave suggestions on the talk page.

Draft of early boot upgrade/init procedures designed by Michael Stone and C. Scott Ananian.

Early userland startup steps

[initrd]
v
python2.5 (pid 1)
v
network_setup(), mount usb/sd, etc
v
antitheft client (ATC)
 olpc.atc.run(fqdn of schoolserver, callback)

(sometime later, or immediately if already activated)
v
callback (as pid 2)
v
mount /sysroot, unmount usb/sd
copy /security/lease to /sysroot/security/lease if first boot
parse chosen/bootpath, swing /pristine/current
v
make minimal userland context (mount --move /sysroot /)
 vserver (protect PID 1, RTC <- vserver delta time)
v
--------------------> (post-FRS) debian w/ developer key:
|                      def run():
|                        os.exec('/sbin/init')
if booting from a backup:
 1. make new config w/ swapped current and alt
    (ie. create a /pristine/configs/XXX w/ new current, alt)
 2. then swing /pristine/boot symlink
create /pristine/running
xo boot:
$current = basename of realpath of /pristine/boot/current (a hash)
mnt /home /run/$current/home
mnt /security /run/$current/security
mnt /pristine /run/$current/pristine
chroot /run/$current (mount --move ?) [ actually vserver container here ]
v
if exists '/sbin/olpc_init.py':
  sys.path = ['/sbin'] + sys.path
  from olpc_init import run
  run(<parameters?>)
else:
  exec '/sbin/init --init'
---------------------> debian w/o developer key (in run)
|
pyinit + rainbow stuff (take over legacy init's job)
 fork run-parts (/etc/inittab stuff)
 listen for shutdown, etc.
 vserver (- CONTEXT)

Notes on P_SF_RUN

P_SF_RUN:
 off = allow mod = run from /run/X
 on  = pristine  = run from /run/X

switch on->off: set the unlink flags on /run
      off->on:  create immutably-tagged /run/a,b from /pristine/a,b

List of directories in root

 /sys, /proc, /ofw   vfs
 /pristine/trees/{hashes}
 /pristine/configs/`mkdtemp`/current -> /pristine/trees/<hash>
 /pristine/configs/`mkdtemp`/alt     -> /pristine/trees/<hash>
 /pristine/boot -> configs/<something>
 /pristine/running -> trees/<hash>  (version we booted from)
 /pristine/updates/<hash>   (temporary space for updates, preserved in case update
                             net connection drops & updater is restarted)
 /run/{hashes}
 /security
 /home
 /boot -> /pristine/boot/current/boot
 /boot-alt -> /pristine/boot/alt/boot

Upgrade procedure

Upgrade procedure, creating new b from a (w.l.o.g)
 Rainbow: (ATC gives <version> <hash> <priority>)
 -1: Check that /pristine/trees/<hash> doesn't already exist.
  0. Create new /pristine/configs/$c <- where $c = mkdtemp
  1. Create /pristine/configs/$c/current -> realpath(/pristine/running)
  2. Swap /pristine/boot to point to /pristine/configs/$c, save old contents in $old
  3. Delete the tree(s) pointed to from /pristine/configs/$old which are not pointed to by
     /pristine/running (revisit when multiple trees)
  4. Delete /pristine/configs/$old.
  5. Invoke 'olpc-updater <version>'
     in new container:
[MICHAEL WILL REWRITE STARTING FROM HERE]
           /current (ro-bind mount from /pristine/a)
           /upgrade (initially empty)
 OLPC updater:
  6. clone /current to /upgrade
  7. upgrade /upgrade by hook or crook
[END MICHAEL REWRITES]
  8. exit
 Rainbow:
  9. Verify /pristine/updates/<hash> matches <hash>
 10. Move /pristine/updates/<hash> to /pristine/trees/<hash>
 11. Make a new config /pristine/configs/$d (d = mkdtemp)
 12. Create 'current' symlink to /pristine/trees/<hash>
 13. Create 'alt' symlink to *realpath of* /pristine/running
 14. Swing /pristine/boot to /pristine/configs/$d
      (atomic!  iff we do file move of new symlink)
 12. Delete /pristine/configs/$c
 13. If <priority> reboot. (Ask Eben & sugar folks)

Open Questions

1. Are thawed trees persistent?
   1. when I use a frozen tree?
   2. when I upgrade
2. Is "thawness" global? Or per-OS-version?
3. Can thawed trees be frozen for temporary read-only use?
4. Space limits for upgrader?
5. UI for:
   1. P_SF_RUN
   2. which image you boot (esp if more than two)
   3. Rest of security UI
6. Configuration versioning / globalness
   1. do security settings persist across updates
   2. do we inherit a security configuration from the 'old' version when upgrading?