diff options
Diffstat (limited to 'chromium/docs/website/site/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements/index.md')
| -rw-r--r-- | chromium/docs/website/site/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements/index.md | 92 |
1 files changed, 0 insertions, 92 deletions
diff --git a/chromium/docs/website/site/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements/index.md b/chromium/docs/website/site/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements/index.md deleted file mode 100644 index e0c2ce52ff0..00000000000 --- a/chromium/docs/website/site/chromium-os/chromiumos-design-docs/filesystem-autoupdate-supplements/index.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -breadcrumbs: -- - /chromium-os - - Chromium OS -- - /chromium-os/chromiumos-design-docs - - Design Documents -page_name: filesystem-autoupdate-supplements -title: File System/Autoupdate Supplements ---- - -[TOC] - -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](/chromium-os/chromiumos-design-docs/firmware-boot-and-recovery) and -[Verified Boot](/chromium-os/chromiumos-design-docs/verified-boot) documents. -The firmware is covered in more detail in the [Firmware Boot and -Recovery](/chromium-os/chromiumos-design-docs/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](/chromium-os/chromiumos-design-docs/filesystem-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. |