跳至內容

fwupd

出自 Arch Linux 中文维基

相關文章

fwupd 是一個簡單的守護程序，允許用戶會話中的軟體更新本機設備固件。主要面向桌面環境設計，但也支持手機和無頭伺服器。

設備支持情況請查看支持的設備列表和廠商支持計劃。

安裝

安裝 fwupd包。

大多數外設的固件可以直接在作業系統中更新。但是，更新 BIOS/UEFI 固件通常需要 UEFI 模式（UpdateCapsule），從而在重啟時安全地應用更新。若需要進行此類更新，請參見 #UEFI 升級設置。

圖形化前端

某些桌面環境提供的圖形化軟體內置有 fwupd 支持：

  • Discover — Plasma 的軟體中心。隨著 KDE Plasma 5.14 的發布，KDE Discover 中實現了新的 fwupd 後端，用於固件更新。這些固件更新與其他系統更新一起顯示。屬於 plasma包組。
https://userbase.kde.org/Discover || discover包
  • GNOME 固件 — 在 fwupd 支持的設備上更新、降級和重新安裝固件的應用程式。可以解鎖鎖定的 fwupd 設備、在受支持的設備上驗證固件和顯示 fwupd 設備的所有固件版本。
https://gitlab.gnome.org/World/gnome-firmware || gnome-firmware包
  • GNOME 軟體 — 定期檢查更新，並在 GNOME 的後台自動下載固件。下載固件後，軟體中彈窗提示更新。屬於 gnome包組。
https://apps.gnome.org/Software || gnome-software包

使用

軟體包提供了 fwupd.service 服務，在首次接收到 D-Bus 查詢請求時自動啟動 fwupd 守護進程。[1]

列出 fwupd 檢測到的所有設備： 

$ fwupdmgr get-devices
注意：列表中的部分設備（例如 Intel 核芯顯卡）可能不能通過 fwupd 更新。供應商可能會提供替代解決方案。

從 Linux 供應商固件服務（Linux Vendor firmware Service, LVFS）下載最新的元數據： 

$ fwupdmgr refresh
注意：啟用 fwupd-refresh.timer 可以自動執行該操作。

列出系統上設備可用的所有更新： 

$ fwupdmgr get-updates

安裝更新： 

$ fwupdmgr update
注意：
  • 可以實時應用的更新會立即完成。
  • 需要在啟動時運行的更新會在下次啟動時執行。
  • 某些設備需要使用 root 用戶更新。
  • 某些設備需要手動進行更新（例如下載所需文件，將其寫入 U 盤，然後手動應用更新）。對於主板（BIOS/UEFI）固件更新（其固件更新過程通常稱為「Q-Flash」或類似名稱）來說，情況尤其如此。

配置

禁用本地緩存伺服器（passim）

fwupd 於 2023 年 9 月發布的 v1.9.5 版本引入了對 passim包 的依賴。passim 是一個本地緩存伺服器，引入是為了通過讓每台機器向其他機器提供其每日下載的元數據文件，來減少 LVFS 的帶寬占用。[2][3]

passim 的守護進程 passimd 會監聽「任意 IP 地址」的 27500 埠（即，監聽 0.0.0.0:27500）。這一點因安全影響而招致了一些批評 [4][5]，並且就在幾周後，確實報告了數個漏洞 [6][7]。

在 Arch Linux 上，請求在編譯時將依賴設為可選的 FS#79614 被駁回，因為這需要為依賴庫創建分包。

因此，如果想要禁用 passim，應遵循作者給出的建議 [8]：在 /etc/fwupd/fwupd.conf 的 [fwupd] 部分下，添加 P2pPolicy=nothing，並屏蔽 passim.service。

UEFI 升級設置

警告：UEFI 固件更新可能會損壞引導加載程序，成功安裝固件更新後，可能需要重新創建 NVRAM 條目（例如，使用 efibootmgr）。

升級 UEFI 需要滿足以下要求：

  1. 使用 UEFI 模式啟動系統，否則 efibootmgr 無法工作。
  2. 驗證能夠獲取 EFI 變量。
  3. 正確掛載 EFI 系統分區（ESP）。
  4. 安裝可選依賴 udisks2包，並確保 udisks2.service 在 fwupd.service 前啟動。該可選依賴提供了 UEFI 升級支持。

準備 ESP 目錄

fwupd 會將所有必需的文件複製到 esp（該部分使用 esp 表示 ESP 掛載點）上，但是要使其正常工作，esp 上必須存在基本的文件夾布局，即需要在 esp 上創建一個 EFI 目錄：

注意：引導加載程序或其他作業系統可能已創建此目錄。
mkdir esp/EFI/
警告：EFI 目錄名必須全部大寫。如果使用小寫字母，fwupd 可能會認為 esp/efi/ 是 ESP 掛載點，並尋找 esp/efi/EFI/。

創建後重新啟動 fwupd.service 服務。然後可以執行 fwupdmgr refresh、fwupdmgr update，系統將提示重啟（進入固件更新程序）。

注意：在某些設備（例如 Lenovo ThinkPad P50（英語：Lenovo ThinkPad P50））上，固件更新時會顯示無任何信息的黑屏——別緊張，請勿中斷設備或強制重啟，幾秒或幾分鐘後就會重啟到作業系統。

安全啟動

fwupd 目前依賴 shim 在啟用了安全啟動的系統上鏈式加載 fwupd 的 EFI 二進制文件。使用該功能前請確保正確安裝 shim。

使用自己的密鑰

sbctl 輔助

sbctl包 可用於簽名 UEFI 可執行文件。關於安裝 sbctl 的說明，請參閱安全啟動#sbctl 輔助。 

# sbctl sign -s -o /usr/lib/fwupd/efi/fwupdx64.efi.signed /usr/lib/fwupd/efi/fwupdx64.efi

之後，每次更新 fwupd包 時，UEFI 可執行文件都會通過 sbctl 的 pacman 鉤子（/usr/share/libalpm/hooks/zz-sbctl.hook）自動簽名。

最後，需要在 /etc/fwupd/fwupd.conf 中設置 DisableShimForSecureBoot 並重新啟動 fwupd.service： 

/etc/fwupd/fwupd.conf
...

[uefi_capsule]
DisableShimForSecureBoot=true
手動

或者，也可以手動簽名用於升級的 UEFI 可執行文件，該文件位於 /usr/lib/fwupd/efi/fwupdx64.efi。簽名後的 UEFI 可執行文件應放在 /usr/lib/fwupd/efi/fwupdx64.efi.signed。若使用 sbsigntools包，執行以下命令簽名： 

# sbsign --key 密钥文件 --cert 证书文件 /usr/lib/fwupd/efi/fwupdx64.efi

為了在安裝或者升級時自動簽名，可使用以下 pacman 鉤子： 

/etc/pacman.d/hooks/sign-fwupd-secureboot.hook
[Trigger]
Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/fwupd/efi/fwupdx64.efi

[Action]
When = PostTransaction
Exec = /usr/bin/sbsign --key 密鑰文件 --cert 證書文件 /usr/lib/fwupd/efi/fwupdx64.efi
Depends = sbsigntools

確保將其中的 密鑰文件 和 證書文件 替換為相應路徑。

除了使用 pacman 鉤子，也可以創建從 /usr/lib/fwupd/efi/fwupdx64.efi 到 /usr/lib/fwupd/efi/fwupdx64.efi.signed 的符號連結，並將文件添加到 /etc/sbupdate.conf 中的 EXTRA_SIGN 列表中。

最後，需要在 /etc/fwupd/fwupd.conf 中設置 DisableShimForSecureBoot 並重新啟動 fwupd.service： 

/etc/fwupd/fwupd.conf
...

[uefi_capsule]
DisableShimForSecureBoot=true
注意：
  • 在 fwupd 1.9 之前，該選項位於 /etc/fwupd/uefi_capsule.conf。
  • 在 fwupd 1.4 之前，配置選項的名稱不同。

查閱此 GitHub issue 獲取更多信息。

故障排除

一直卡在重啟

fwupdmgr update 不會報錯，但提示重啟後卡住，且按住電源按鈕也沒有反應。

嘗試切斷電源，或按下復位按鈕（在筆記本電腦上，可能是背面的一個小孔）強制重啟。

沒有錯誤，但重啟後沒有升級

狀況：fwupdmgr update 未報告任何錯誤並提示重新啟動（例如，在 BIOS 更新中），但系統正常（或卡住後）重啟後固件未更新。

可能的原因：必須在 BIOS 設置中允許更改引導順序。

如果同時進行多個更新，另一種可能解決的辦法： 嘗試一次更新一個更新包。使用以下命令更新一個更新包： 

$ fwupdmgr update 更新_ID

（其中 更新_ID 類似於 f95c9218acd12697af946874bfe4239587209232。）

file system is read-only

如果將 EFI 系統分區 bind 掛載到 /boot，至少 fwupdmgr 1.5.2 會推斷出錯誤的掛載點。因此，它無法將 UEFI 更新文件寫入 /boot/EFI/arch/fw（fwupdmgr 本應寫入其指向的 esp/EFI/arch/fw 目錄）。這會導致一個（誤導性的）file system is read-only 錯誤消息。如果是通過 Discover（或任何其他支持 fwupd 的圖形化更新工具）執行更新，則可能不顯示任何錯誤，或顯示誤導性的錯誤。

臨時解決方法如下：如果之前已將 esp/EFI/arch bind 掛載到 /boot，請先執行 umount /boot，在使用 fwupdmgr update 將 UEFI 更新文件寫入 esp/EFI/arch/fw 之後再 mount /boot，最後重啟系統以執行 UEFI 更新。

UEFI ESP 分區未檢測到或未配置

如果達到 #UEFI 升級設置中的要求後，還是無法檢測到 ESP 分區，可以手動指定掛載點： 

/etc/fwupd/fwupd.conf
[fwupd]
EspLocation=/efi

有關導致該錯誤的其它可能原因，請參閱 fwupd wiki 的相關文章。

手動指定 ESP 位置可以避免 fwupdx64.efi 安裝到其它盤上的 ESP。

MSR 插件加載失敗

MSR 插件允許查詢 DCI 的狀態，DCI 是一種適用於 Intel CPU 的調試接口。根據 fwupd 的文檔，應在生產用機器上禁用該接口。

該插件需要加載 msr 內核模塊。msr 在所有 Arch Linux 官方內核包中都是內置內核模塊，但非官方內核包可能將其作為可加載內核模塊。對於後一種情況，需要顯式地在啟動時加載模塊。