Chromium OS‎ > ‎Design Documents‎ > ‎

File System/Autoupdate Supplements

Contents

  1. 1 Reinstallation
  2. 2 Firmware updating
  3. 3 Bit rot evasion (corruption on the hard drive)
  4. 4 Stacking updates
  5. 5 Forced reboot
This document provides a set of brief Chromium OS design supplements, covering areas related to the file system and autoupdates.

Reinstallation

Reinstallation 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 updating

The 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.

0x80
Bootable flag: this partition can be booted. This bit being set implies that it's a good partition to boot from; it's been vetted.
0x40
Tryboot flag: this partition, which must be bootable, should be booted this time, in the event of multiple bootable partitions being found.
0x20-0x04
Unused.
0x02-0x01
Attempt boot counter, also known as the "remaining_attempts" flag. This takes precedence over bootable/tryboot. For more information, see the File System/Autoupdate document.
The boot loader flow is then:





Open issue: We could use a third system partition. This comes at a cost of space, but lets us always have a backup partition ready, even midway through an autoupdate. If a system partition is 200MB, we might do this. If it's 1 GB, we might not want to.

Stacking updates

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.

Forced reboot

We will be able to force a reboot should we need to apply an emergency security update.
ċ
bootloader_flowpng
(10k)
Unknown user,
Nov 19, 2009, 9:03 AM
v.1
ċ
firmware_updaterpng
(22k)
Unknown user,
Nov 19, 2009, 9:03 AM
v.1
ċ
partition_extra_bitspng
(4k)
Unknown user,
Nov 19, 2009, 9:03 AM
v.1
ċ
recovery_imagepng
(14k)
Unknown user,
Nov 19, 2009, 9:03 AM
v.1
Comments