User:Mstone/Commentaries/olpc-update: Difference between revisions
Jump to navigation
Jump to search
m (→Partitioned) |
mNo edit summary |
||
Line 28: | Line 28: | ||
= Partitioned = |
= Partitioned = |
||
== Data Structures == |
|||
The design for partitioned systems is simpler than for unpartitioned systems. It works as follows. |
The design for partitioned systems is simpler than for unpartitioned systems. It works as follows. |
||
Line 38: | Line 40: | ||
### the contents of <tt>$root:/boot</tt> for some other partition <tt>$root:</tt> |
### the contents of <tt>$root:/boot</tt> for some other partition <tt>$root:</tt> |
||
### possibly some other unspecified metadata |
### possibly some other unspecified metadata |
||
== Robust Updates == |
|||
Updating the boot configuration is accomplished by |
|||
# filling out a new directory <tt>boot:/boot-versions/$u</tt> |
|||
# making a new symlink in <tt>boot:/</tt> pointing to <tt>boot-versions/$u</tt> |
|||
# renaming it on top of <tt>boot:/boot</tt> |
|||
Next, assume that <tt>boot:/boot</tt> currently points to <tt>boot-versions/$r</tt>. In order to preserve the <tt>alt</tt> invariant while updating, when no consistent alternate data may be available, the *running* <tt>boot:/boot-versions/$r/alt</tt> symlink may be made to loop by being made to point to <tt>../$r</tt>. |
Revision as of 02:27, 5 November 2009
This is a commentary intended to elucidate the data structures used by olpcrd and olpc-update in Early boot.
Unpartitioned
Data Structures
- For rollback purposes, we need a data structure with some pointers in it. (e.g., "current", and usually "alt".) The pointers should point to trees of files.
- This data structure is called a "boot config", and is implemented as a directory in /versions/configs containing some symlinks.
- We need a distinguished boot config so that OFW has something specific to hand control to. This distinguished boot config is the target of another pointer implemented as a symlink at /versions/boot.
- We need to be able to atomically modify the distinguished boot configuration. We do this by
- making a fresh boot config,
- making a fresh symlink pointing to it
- renaming the freshly created symlink to /versions/boot
- For update purposes, we need to know what actual *tree* is currently running. Therefore, our initramfs puts a symlink at /versions/running to identify the currently running *tree*.
- For update purposes, we need to maintain cryptographic manifests of our trees of files. These go in /versions/contents/...
Robust Updates
Automatic updates require sufficient free space to install the update. We get that space by
- Making and installing a new boot config with no fallback, thereby unreferencing any non-sticky old builds.
- Deleting any non-sticky old builds.
- Installing the update.
- Verifying the update.
- Making and installing a new boot config with our current running tree as the "alt" image and with the new tree as the "current" image.
This way, the system is *always* in a consistent state.
Partitioned
Data Structures
The design for partitioned systems is simpler than for unpartitioned systems. It works as follows.
- Partitions are identified by colon-delimited prefixes, like boot:, root:, and so on.
- At all times, for all tree-ids $a:
- boot:/boot should be a symlink to 'boot-versions/$a'
- boot:/boot-versions/$a should contain:
- a symlink named alt pointing to ../$b for some tree-id $b
- the contents of $root:/boot for some other partition $root:
- possibly some other unspecified metadata
Robust Updates
Updating the boot configuration is accomplished by
- filling out a new directory boot:/boot-versions/$u
- making a new symlink in boot:/ pointing to boot-versions/$u
- renaming it on top of boot:/boot
Next, assume that boot:/boot currently points to boot-versions/$r. In order to preserve the alt invariant while updating, when no consistent alternate data may be available, the *running* boot:/boot-versions/$r/alt symlink may be made to loop by being made to point to ../$r.