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 /versions/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 /versions/configs/XXX w/ new current, alt) 2. then swing /versions/boot symlink create /versions/running symlink to pristine/<hash> xo boot: $current = basename of readlink of /versions/boot/current (a hash) mnt /home /versions/run/$current/home mnt /security /versions/run/$current/security mnt /versions /versions/run/$current/versions chroot /versions/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 /versions/run/X on = pristine = run from /versions/run/X switch on->off: set the unlink flags on /versions/run off->on: create immutably-tagged /versions/run/a,b from /versions/a,b
List of directories in root
/sys, /proc, /ofw vfs /versions/pristine/{hashes} /versions/configs/`mkdtemp`/current -> /versions/pristine/<hash> /versions/configs/`mkdtemp`/alt -> /versions/pristine/<hash> /versions/boot -> configs/<something> /versions/running -> pristine/<hash> (version we booted from) /versions/updates/<hash> (temporary space for updates, preserved in case update net connection drops & updater is restarted) /versions/run/{hashes} /security /home /boot -> /versions/boot/current/boot /boot-alt -> /versions/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 /versions/pristine/<hash> doesn't already exist. 0. Create new /versions/configs/$c <- where $c = mkdtemp 1. Create /versions/configs/$c/current -> realpath(/versions/running) 2. Swap /versions/boot to point to /versions/configs/$c, save old contents in $old 3. Delete the tree(s) pointed to from /versions/configs/$old which are not pointed to by /versions/running (revisit when multiple trees) 4. Delete /versions/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 /versions/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 /versions/updates/<hash> matches <hash> 10. Move /versions/updates/<hash> to /versions/pristine/<hash> 10b. Create /versions/run/<hash> from /versions/pristine/<hash> according to P_SF_RUN setting 11. Make a new config /versions/configs/$d (d = mkdtemp) 12. Create 'current' symlink to /versions/pristine/<hash> 13. Create 'alt' symlink to *realpath of* /versions/running 14. Swing /versions/boot to /versions/configs/$d (atomic! iff we do file move of new symlink) 12. Delete /versions/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?
- Loadable kernel modules
- Bind-mount /lib/modules read-only? (Doesn't fix the problem, really)