此页面由 Cloud Translation API 翻译。

更新软件包

更新软件包是一个软件包，其中包含有关如何更新系统的文件和规则。

系统更新

系统更新检查工具会检查更新软件包所具有的系统映像的 Merkle 根，并将其与正在运行的系统的 Merkle 根进行比较。它还会检查更新软件包的 Merkle 根目录，并将其与系统更新检查工具上次使用的版本进行比较。如果不一致，则表示不是系统更新程序更新了系统。

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

系统更新检查工具会定期使用软件包解析器提取更新软件包，并查看其外观是否有所不同。如果更新软件包不同，系统会触发软件包更新。

系统更新程序的设计可确保进程可能随时被中断，且不会使系统处于无法启动或损坏状态。

首先，系统更新程序会读取 update_mode 文件以确定要执行的操作。然后，开发板文件会读取并验证配置是否有误。然后，更新软件包会提取要提供的软件包。最后，更新软件包会写入内核映像，并确保 vbmeta 必须在内核映像之后写入。

更新软件包的内容

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

/board 面板名称。更新程序会验证内容，并且仅当此值与之前的开发板名称匹配时才会进行更新。此检查可防止意外尝试将设备更新到不受支持的架构。例如，尝试将 x64 目标更新为 arm64 构建将失败。
/bootloader 引导加载程序固件的映像。已弃用：请改用 firmware。
/epoch.json 系统无法通过 OTA 降级的周期。如需了解更多背景信息，请参阅 RFC-0071。例如：
```
{
    "version": "1",
    "epoch": 5
}
```
/firmware[_<type>] 固件映像。例如：firmware、firmware_bl2、firmware_full。每个设备都支持一组自定义固件类型，不受支持的类型会被忽略。这有两个主要目的：
1. 指定多个固件；例如，具有多个引导加载程序阶段的设备。
2. 提供一种轻松安全地转换到新固件类型的方式；您只需添加后端摊铺器逻辑，然后将新文件放入更新软件包即可。

/packages.json JSON 格式的列表，其中包含属于目标操作系统映像的基本软件包集的 Merkle 固定的软件包网址。更新软件包会查看 /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。
/recovery 恢复映像
所有软件包中均存在 /meta/contents 和 /meta/package 元数据文件。
/update_mode.json可选。如果该文件不存在，则 update-mode 为 normal。另一个选项是 force-recovery，可以写入恢复映像并重新启动到其中。任何其他 update-mode 值无效。例如：
```
{
    "version": "1",
    "content": {
        "mode" : "force-recovery"
    }
}
```