更新软件包

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

系统更新

系统更新检查工具会检查要更新的系统映像的 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"
    }
}