Early boot
Jump to navigation
Jump to search
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 ... |
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 symlink to trees/<hash> xo boot: $current = basename of readlink of /pristine/boot/current (a hash) mnt /home /pristine/run/$current/home mnt /security /pristine/run/$current/security mnt /pristine /pristine/run/$current/pristine chroot /pristine/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 /pristine/run/X on = pristine = run from /pristine/run/X switch on->off: set the unlink flags on /pristine/run off->on: create immutably-tagged /pristine/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) /pristine/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] NOTE THAT /upgrade must live in same bind-mount as /current if we're to be able to clone it. MORE LIKELY THAT RAINBOW WILL CREATE /upgrade FOR US AS CLONE OF /current /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> 10b. Create /pristine/run/<hash> from /pristine/trees/<hash> according to P_SF_RUN setting 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
- Are thawed trees persistent?
- when I use a frozen tree?
- when I upgrade
- Is "thawness" global? Or per-OS-version?
- Can thawed trees be frozen for temporary read-only use?
- Space limits for upgrader?
- UI for:
- P_SF_RUN
- which image you boot (esp if more than two)
- Rest of security UI
- Configuration versioning / globalness
- do security settings persist across updates
- do we inherit a security configuration from the 'old' version when upgrading?