更新软件包

更新包是一个包，其中包含有关如何更新 系统。

系统更新

系统更新检查工具会检查要更新的系统映像的 Merkle 根目录 软件包具有，并将其与运行系统的 Merkle 根进行比较。它还会检查 更新软件包的 Merkle 根目录，并将其与系统 上次使用的更新检查工具。如果两者不同，则表明除 系统更新程序已更新系统。

系统更新成功后，系统更新程序会重新启动设备。

系统更新检查工具会使用更新包定期提取更新包 ，看看是否看起来有所不同。如果更新包与之前不同 系统触发软件包更新

系统更新程序的设计方式如下： ，并且不会导致系统处于不可启动或损坏状态。

首先，系统更新程序会读取 update_mode 文件来确定要执行的操作 效果。然后，板级文件读取并验证没有错误配置。 然后，更新软件包会提取要传送的软件包。最后，更新软件包会写入 内核映像，并确保必须在内核映像之后写入 vbmeta。

更新软件包的内容

更新软件包 fuchsia-pkg://fuchsia.com/update 的结构包含以下内容：

• /board 面板名称。更新程序会验证内容，并仅在此值匹配时才进行更新 之前的开发板名称。此检查可防止意外尝试将设备更新到 不受支持的架构例如，尝试将 x64 目标更新为 arm64 build 将失败。

• /bootloader 引导加载程序固件的映像。已弃用：请改用 firmware。

• /epoch.json 系统无法通过 OTA 进行降级的纪元。请参阅 RFC-0071，了解更多背景信息。例如：

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

• /firmware[_<type>] 固件映像。例如：firmware、firmware_bl2、firmware_full。每台设备 支持一组自定义的固件类型，不受支持的类型将被忽略。这用于 有两个主要用途：

  1. 指定多段固件；例如，多组设备 引导加载程序阶段。
  2. 提供一种简单安全的方式来转换到新固件类型；它只是 添加后端 paver 逻辑，然后将新文件放入更新软件包。

• /packages.json 属于基本软件包集的 Merkle 固定软件包网址的 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，则不得存在。zbi 或 zbi.signed 如果 update-mode 为 normal，则必须存在。

• /recovery 恢复映像

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

• /update_mode.json 选填。如果该文件不存在，则 update-mode 为 normal。另一种方法是 force-recovery：用于写入恢复映像并重新启动到其中。任何其他update-mode 值无效。 例如：

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