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
。每部裝置 支援自訂韌體類型組合,且系統會忽略不支援的類型。這名國家/地區 兩個主要用途- 指定多件韌體;例如擁有多個 系統啟動載入程式階段。
- 輕鬆安全地轉換至新型韌體類型;包括 新增後端分區映像檔安裝工具邏輯,然後將新檔案放入更新套件中。
/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" } }