更新包

更新包是一个包含文件以及更新规则的包。

系统更新

系统更新检查器会查看更新包中系统镜像的墨克根（Merkle Root）并将其与运行中的系统的墨克根进行比较。同时，它还会检查此次更新与系统更新检查器所使用的版本。如果不一致，则说明上次更新并未使用系统更新器。

系统更新器会在系统更新成功后重启设备。系统更新检查器会通过包解析器周期性地获取更新包，并检查是否与目前更新包不一致。如果不一致，系统会启动一次更新。

系统更新器的进程被设计为可随时打断的，因此它不会使系统陷入无法启动或损坏的状态。

首先，系统更新器读取 update_mode 文件来决定采取何种操作。然后，读取主板文件来核实有无错误的配置。之后，更新器从服务器获取更新包。最后，更新器写入内核镜像，并确保 vbmeta 在内核之后写入。

更新包的内容

更新包（fuchsia-pkg://fuchsia.com/update）包含如下的结构：

• /board 主板名。更新器会核实该文件的内容，并确保更新包中的值与当前值一致时才会启动更新。这种检查可以阻止对不受支持的架构的设备进行更新。例如，如果尝试在一台 x64 的设备上安装 arm64 的更新包将会导致失败。

• /bootloader bootloader 的镜像。已弃用：请使用 firmware。

• /epoch.json 系统不能通过 OTA 跨越 Epoch 降级。Epoch 指系统底层发生重大改变的一个版本，详见 RFC-0071.下例表示无法通过 OTA 将 epoch 降为 4：

  {
      "version": "1",
      "epoch": 5
  }

• /firmware[_<type>] 固件镜像。例如：firmware，firmware_bl2，firmware_full。每种设备支持一套定制的固件类型，不支持的类型会被忽略。这样设计有两种目的：
  1. 可以指定多个固件；例如，当设备是多阶段启动时。
  2. 提供一种简单且安全的方法来转换到新的固件类型；其实就是添加后端铺设逻辑并在更新包中放入新文件这样一档事。

• /packages.json JSON 格式的附带有哈希值的包的链接，这些包属于目标系统镜像的基础软件包集。更新包会查看 /packages.json 来决定哪个包（以及按哪种顺序）升级。例如：

  {
      “version”: “1”,
      “content”: [
          "fuchsia-pkg://fuchsia.com/component_index/0?hash=40da91deffd7531391dd067ed89a19703a73d4fdf19fe72651ff30e414c4ef0a",
          "fuchsia-pkg://fuchsia.com/system_image/0?hash=c391b60a35f680b1cf99107309ded12a8219aedb4d296b7fa8a9c5e95ade5e85"
      ]
  }

• /version 与 /config/build-info/version 文件格式相同。

• /zbi[.signed] 内核镜像。在 update-mode 为 force-recovery 时必须不包含此项。在 update-mode 为 normal 时，则必须包含zbi 或 zbi.signed 此项。

• /zedboot[.signed] 恢复镜像。

• /meta/contents 与 /meta/package 所有包中都有的元数据文件。

• /update_mode.json 可选项。如果没有此文件，则 update-mode 是 normal。如果有此文件，则处于 force-recovery 模式。该模式下会写入一个恢复镜像并重启进入该镜像。其它的 update-mode 值均不合法。例如：

  {
      "version": "1",
      "content": {
          "mode" : "force-recovery"
      }
  }