This document provides a set of brief Chromium OS design supplements, covering areas related to the file system and autoupdates.
ReinstallationReinstallation requires a recovery image (on a USB drive or SD card) to be attached to the system. When the system boots, the user may force reinstallation by forcing the firmware into recovery mode by pressing a recovery button. The exact details of how the firmware accomplishes this are outside the scope of this document.The recovery image performs the actions described in the following diagram: Firmware updatingThe firmware discussed in this document references a firmware designed by Google for Chromium OS-based devices. We recommend that devices that support the Google firmware use that firmware; that lets them take advantage of the boot time, security, and recovery features discussed in the Firmware Boot and Recovery and Verified Boot documents. The firmware is covered in more detail in the Firmware Boot and Recovery document, but here is how it will work from the autoupdate perspective.We plan to generally update the firmware after successful boot of a new image that contains new firmware to install, but we will be able to force installation of new firmware before an update is applied if necessary. The firmware contains a stub that can boot into either of two on-chip boot loaders (A or B). The stub first tries to boot from A. If A's checksum fails, it boots B. If B's checksum also fails, it goes into recovery mode. The firmware updater is a userspace program that runs on system boot. It performs the following actions: Bit rot evasion (corruption on the hard drive)Note: it's unclear how much we expect to be impacted by drive corruption.In this scheme, we take advantage of the fact that we could have two identical system partitions. Note that this is an early design that may change over time based on feedback. We use the extra bits in
the partition table as follows. Note that we have 8 bits in each byte
reserved for the bootable flag. This gives us 7 unused bits per
partition for the boot loader.
Updates will be stackable. In other words:
Updates can be applied, one after another as they come out, without a reboot. So, for example, if you boot into version n, then update the other partition to n+1 but don't reboot, you're still running n. Then, if n+2 comes out, we will update from n+1 to n+2 in the other partition, while remaining booted into n. We will be able to force a reboot should we need to apply an emergency security update.
|
Chromium OS > Design Documents >