| RFC-0075：淘汰以 Zedboot 為基礎的設定，以便佈建裝置 | |
|---|---|
| 狀態 | 已接受 |
| 領域 |
|
| 說明 | 將裝置佈建作業標準化採用 Quickboot 功能，並淘汰採用 Zedboot 基礎的鋪面措施。 |
| 更小鳥 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年月分) | 2021-02-25 |
| 審查日期 (年-月-日) | 2021-03-12 |
摘要
本文件提議淘汰，並最終移除裝置佈建流程的 zedboot。而是透過以 Fastboot 為基礎的刷新流程取代流程，藉此改善裝置佈建程序的穩定性和穩定性。
提振精神
以 Zedboot 為基礎的佈建或「paving」經常用於啟動 Fuchsia 裝置。Zedboot 其實是 Zircon 核心的執行個體，具有最少的驅動程式和服務。
Fastboot 是一種透過 USB 和乙太網路與系統啟動載入程式通訊的機制。也用於佈建 Fuchsia 裝置。通常稱為「刷新」裝置。
以 Zedboot 為基礎的鋪式工作流程需要大量 Fuchsia 系統正常運作，具體而言：
- 核心
- 驅動程式堆疊
- 磁碟區管理 (FVM)
- 網路堆疊 (netsvc)
這些子系統必須先開始運作，才能用於佈建 Fuchsia 系統。另一方面，Fastboot 通訊協定會直接在系統啟動載入程式中實作，不需要任何其他依附元件，即可使用 Fuchsia 啟動及佈建裝置。
使用 Fastboot 有一些優點：
裝置只需要執行單一步驟佈建流程，因為裝置只需要處於系統啟動載入程式模式，就能啟動刷新程序。
- 針對保存流程，裝置分區 (R、A 或 B 分區) 必須含有 Zedboot。如要在分區上使用 Zedboot，就必須使用閃爍的流程。最後，將 Fuchsia 系統儲存到裝置後，系統最終會覆寫 zedboot。
不需要透過 UDP 提供啟動伺服器才能取得要佈建的資產。只需要一組預先建構的圖片素材資源。
Fuchsia 平台不同版本和分支版本的相容性和支援。避免需要對開發人員和平台發布程序造成影響的大規模變更。
不需要仔細檢查建構時間，即可在 Fuchsia 裝置的
Recovery (R)分區中執行映像檔。
以 Zedboot 為基礎的佈建作業有一些問題如下：
- 當 FVM 變更如 RFC-0005 Blobfs 快照中記錄的格式時，必須對應 Zedboot 的滾動式變更。裝置必須使用不同的 Zedboot 版本啟動，以免使用者利用不相容的版本覆寫裝置 FVM 分區。
- 當使用者切換 Fuchsia 的分支版本時，開發人員、blobfs 或 fvm 的不相容版本可能會意外導致開發人員失敗。
- 根據先決條件，必須使用 Fastboot 刷新至裝置上的分區來刷新 Zedboot。因此，使用者必須執行閃爍的步驟才能貼上。
- 透過 Zedboot 公開的 Fuchsia 介面區域會顯示佈建裝置不需要的額外功能，因此被視為安全風險。
簡化「Fastboot」的佈建程序對開發人員工作流程的優點，整合所有 Fuchsia 裝置的佈建作業，以及平台中低階區域 (例如儲存層) 的變更。
背景
Zedboot 版本管理
執行鋪路式工作流程的 Fuchsia 裝置和主機之間須具備 Zedboot 版本相容性，而且 Fuchsia 裝置和主機傳送的映像檔之間的 FVM 格式相容性。
在推出 FVM 和 zedboot 版本時，這些版本管理限制對開發人員來說是一大問題，尤其是可能在分支版本之間切換的開發人員 (這也意味著裝置經常在舊版和較新版本的 FVM 或 Zedboot 版本之間切換)。
當開發人員需要將裝置橫跨 Zedboot 版本邊界降級時，就會發生主要問題。在這種情況下，開發人員需要先在裝置上重新初始化 Zedboot，而必須重新刷新裝置，或執行由最佳努力復原 Zedboot 自身的兩步驟序列。在升級路徑中，開發人員選擇透過無線更新 (OTA) 更新程序。
Fastboot 版本管理
另外，Fastboot 也具有版本相容性需求，因為佈建程序需要將額外的 Fuchsia 映像檔或檔案寫入，在某些情況下，系統啟動載入程式必須更新為支援新的映像檔格式。
不過，與較高層級儲存格式 (例如 FVM) 的變更相比，這種格式更加簡單且穩定。舉例來說，您對系統啟動載入程式所做的任何變更，都能由 OTA 處理，或透過 Fastboot 的刷新工作流程處理。在大多數情況下，您可以直接新增其他映像檔，而不需要變更系統啟動載入程式。
設計
Fuchsia 產品中的系統啟動載入程式正式支援 fastboot。目前用於在裝置上佈建 Fuchsia 映像檔。
實作
進入淘汰階段後，Zedboot 就會從佈建工作流程和相關說明文件中移除。
實施範圍涵蓋淘汰後的遷移程序。 因此，許多使用傾印的指令碼和開發人員工具會如下所示：
- 在 Fuchsia SDK 中標示為已淘汰。
- 更新為在使用鋪路式時顯示警告
- 已遷移至 SDK 中已提供的刷新工具。
- 會在淘汰期結束後移除
效能
對系統的效能沒有影響。
安全性考量
淘汰及移除 Zedboot 有助於降低安全性的整體疑慮。 主要是這需要廣泛的攻擊面和操作者可用的控制層級，包括基礎檔案系統的存取權。
Fastboot 已通過適當的安全性核准程序，並已獲準用於佈建 Fuchsia 生產裝置。
隱私權注意事項
和安全性一樣，移除 Zedboot 即可減少隱私權疑慮，而 Fastboot 已獲準與正式版裝置搭配使用。
測試
Fuchsia 目前的開發人員目前採用以 Fastboot 為基礎的佈建模式。將要求 Fuchsia 的 CI/CQ 系統中適當的基礎架構，以支援以 Fastboot 為基礎的佈建功能。這麼做可確保 Fastboot 流程定期接受測試。
說明文件
開發人員工作流程的說明文件必須更新，以反映以刷新為基礎的新流程。
缺點、替代項目和未知
缺點
主要的缺點是，淘汰並遷移使用閃爍的現有指令碼和工作流程。
除了已支援的 U-Boot 外，其他 Fuchsia 系統啟動載入程式也支援 Fastboot。也就是說，因為新的主面板會在 Fuchsia 中推出，因此在早期啟動期間，需要 Fastboot 支援功能。
Intel NUC 產品的 Gigaboot 系統啟動載入程式並未完全支援，但目前仍處於開發階段：https://fxbug.dev/42147743: NUC：支援完整裝置刷新。
SeaBIOS 是 qemu 的預設系統啟動載入程式，但 qemu 中沒有預備工作流程。因此不需要 Fastboot 支援功能。
Coreboot 是用來在 Pixelbook 裝置上啟動 Fuchsia。Pixelbook 裝置唯一支援的佈建流程。您可以使用 depthcharge 酬載機制支援 Fastboot。
其他注意事項和注意事項
編寫 RFC 時，系統會假設主要工作流程為以 Fuchsia 做為主要作業系統的裝置佈建裝置。但就一般用途 x64 系統 (例如 Intel NUC) 來說，Zedboot 支援設定分區資料表，以啟用此用途。
- Fastboot 支援寫入 GPT 資料表。不過，我們建議的做法是使用 Fastboot 編寫安裝程式或復原酬載，並使用該酬載執行 Fuchsia 系統的初始啟動作業。
Zedboot 也可用於網路啟動 (從網路啟動裝置)。
- Fastboot 的
boot指令支援本機啟動映像檔。這可進一步擴充，以支援類似網路啟動的功能。 - 或者，利用設施深度充電來支援特定硬體目標的網路啟動功能。
刷新作業會抹除裝置上的 FTL (Flash 翻譯層) 狀態。
- 能夠追蹤 FTL 穿戴式層級資料的變化，對某些團隊來說很有用。Fastboot 包含對 oem 子指令的支援，以便實作特定產品特定指令。這裡可以選擇透過 Fastboot 機器匯出 FTL 資訊。
mexec 是一個流程，可使用新的核心和開機映像檔，軟重新啟動系統。改用以 Fastboot 為基礎的佈建流程不會影響這項功能。
優先藝術與參考資料
使用 Fastboot 進行佈建的裝置之前有許多先進圖片。以下列舉兩個例子：
Android
Android 裝置完全仰賴以 Fastboot 為基礎的流程，詳情請參閱這篇文章。
隨著 Android 裝置經歷各種升級和變更，以快速啟動 (Fastboot) 的刷新和佈建功能來說，啟動系統和將系統還原到原廠狀態時，可提供一致的開發人員流程和體驗。
林納羅
Linaro 是資助及推廣各種專案，用於加快 Arm 生態系統中的產品部署速度。在各種 Arm 開發和原型板 (例如 96boards) 中佈建 Linaro Linux 韌體時，Fastboot 是常用的通訊協定和方法。