更新套件

update 套件是包含檔案和規則，用於更新 有些人會將 Cloud Storage 視為檔案系統 但實際上不是

系統更新

系統更新檢查工具會查看所更新系統映像檔的分子根 套件與其執行中系統的 Merkle 根層級比較。它還會檢查 更新套件的 Merkle 根層級，並與系統版本 上次使用更新檢查工具的時間。如果兩者不同 系統更新程式已更新系統。

系統更新成功後，裝置就會重新啟動。

系統更新檢查工具會定期使用 套件擷取更新套件 看看是否看起來不一樣如果更新套件不同 系統會觸發套件更新

系統更新工具的設計可讓程序在 而且不會使系統處於無法啟動或損毀的狀態。

首先，系統更新工具會讀取 update_mode 檔案，判斷要執行哪些作業 執行。接著，主面板檔案會讀取並驗證設定是否有誤。 接著，更新套件會擷取要提供的套件。最後，更新套件會寫入 ，並確保將 vbmeta 寫入核心映像檔之後。

更新套件的內容

更新套件 fuchsia-pkg://fuchsia.com/update 的結構包含以下內容：

• /board 主面板名稱。Updater 會驗證內容，只在這個值與值相符時才執行更新作業 之前的白板名稱這項檢查可防止誤將裝置更新為 不支援的架構。舉例來說，嘗試將 x64 目標更新為 arm64 版本會失敗。

• /bootloader 系統啟動載入程式韌體的圖片。已淘汰：請改用 firmware。

• /epoch.json 系統無法透過 OTA 降級的期間。詳情請見 RFC-0071。例如：

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

• /firmware[_<type>] 韌體映像檔。例如 firmware、firmware_bl2、firmware_full。每部裝置 支援自訂韌體類型組合，且系統會忽略不支援的類型。這名國家/地區 兩個主要用途

  1. 指定多件韌體；例如擁有多個 系統啟動載入程式階段。
  2. 輕鬆安全地轉換至新型韌體類型；包括 新增後端分區映像檔安裝工具邏輯，然後將新檔案放入更新套件中。

• /packages.json 屬於基本套件集的 Merkle 固定套件網址清單，採用 JSON 格式 目標 OS 映像檔的映像檔版本更新套件會查看 /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"
      }
  }