跳至內容
出自 Arch Linux 中文维基

fwupd 是一個進行設備固件更新的簡單守護程序,雖然是為桌面計算機設計,但是同樣也支持手機和伺服器。

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

安裝

安裝 fwupd

如果您將其用於 UEFI 固件升級,請參閱 #UEFI 升級設置

圖形化前端

某些桌面環境前端解決方案具有內置的 fwupd 支持:

  • GNOME Software — 將定期檢查更新,並在 GNOME 的後台自動下載固件。下載固件後,將在 Gnome Software 中顯示一個彈出窗口以執行更新。
https://wiki.gnome.org/Apps/Software || gnome-software
  • KDE Discover — 與 Plasma 一起使用的軟體中心。隨著 KDE Plasma 5.14 的發布,KDE Discover中已實現了新的 fwupd 後端以進行固件更新。這些固件更新與其他系統更新一起顯示。
https://userbase.kde.org/Discover || discover
  • GNOME Firmware — 在 fwupd 支持的設備上升級,降級和重新安裝固件的應用程式。它可以解鎖鎖定的 fwupd 設備,驗證支持的設備上的固件並顯示 fwupd 設備的所有發行。
https://gitlab.gnome.org/hughsie/gnome-firmware-updater || gnome-firmware

使用

要顯示 fwupd 檢測到的所有設備:

$ fwupdmgr get-devices
注意:列表中的部分設備可能不能使用該工具更新,例如 Intel 核芯顯卡,可以替代地提供的供應商解決方案。

要從 Linux Vendor firmware Service (LVFS) 下載最新的元數據:

$ fwupdmgr refresh

要列出系統上任何設備可用的更新:

$ fwupdmgr get-updates

要安裝更新:

$ fwupdmgr update
注意:
  • 可以實時應用的更新將立即完成。
  • 在啟動時運行的更新將為下一次重新啟動做好準備。
  • 可能需要使用 root 用戶執行特定設備的更新。

UEFI 升級設置

警告:UEFI 固件更新可能會損壞您的引導程序,成功安裝固件更新後,可能需要重新創建 NVRAM 條目(例如,使用 efibootmgr
  1. 使用 UEFI 模式啟動系統,efibootmgr 無法在舊版啟動模式下工作。
  2. 驗證您的 EFI 變量是否可以獲取
  3. 正確掛載 EFI 系統分區 (ESP),esp 用於表示此部分中的掛載點。
  4. 請安裝可選依賴 udisks2,這個軟體包提供了 UEFI 升級支持。

準備 ESP 目錄

fwupd 會將所有必需的文件複製到 esp 上,但是要使其正常工作,"esp" 上必須存在基本的文件夾布局。

注意:由於您所使用的引導加載程序或其他作業系統的存在,此目錄可能已經存在。

這會在 esp 目錄創建 EFI 目錄 。

mkdir esp/EFI/
警告:'EFI' 目錄必須全部大寫。如果使用小寫字母,fwupd 可能會將 esp 檢測為 esp/efi/,並開始尋找 esp/efi/EFI/

創建後,必須重新啟動 fwupd.service 服務。

您現在可以 $ fwupdmgr refresh$ fwupdmgr update。它將要求重新啟動,現在應該自動重新啟動到固件更新程序。

注意:在某些設備上,例如 Lenovo ThinkPad P50,固件更新時將顯示 無任何信息的黑屏——別緊張, 不要 中斷設備或強制重啟,過幾分鐘後,系統會自動重啟到作業系統。

安全啟動

安全啟動開啟的系統下,fwupd 使用 shim 來引導 fwupd EFI 文件。使用前請確保正確安裝 shim。

用自己的密鑰

或者,您必須手動簽名用於執行升級的 UEFI 可執行文件,該文件位於 /usr/lib/fwupd/efi/fwupdx64.efi。 已簽名的 UEFI 可執行文件應放在 /usr/lib/fwupd/efi/fwupdx64.efi.signed. 使用 sbsigntools,可以通過運行以下命令來實現:

# sbsign --key keyfile --cert certfile /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 keyfile --cert certfile /usr/lib/fwupd/efi/fwupdx64.efi
Depends = sbsigntools

確保用密鑰的相應路徑替換 <keyfile><certfile>

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

最後,您必須將 /etc/fwupd/uefi_capsule.conf 中包含 DisableShimForSecureBoot 的行更改為 DisableShimForSecureBoot=true 並重新啟動 fwupd.service

注意:如果在 fwupd 1.4 之前進行了此設置,請注意配置選項的名稱已更改。

查閱此 GitHub issue,以獲取更多討論此問題的信息。

故障排除

一直卡在重啟

fwupdmgr update reports no error, but the reboot it prompts stuck and holding the power button has no response. Try switching off the power, or press the reset button (on a laptop, it might be a hole on the back) to force-reboot.

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

狀況:fwupdmgr update 未報告任何錯誤並提示重新啟動(例如,在 BIOS 更新中)。 但是,系統將正常重啟,並且不會進行固件更新。

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

Possible other solution if there are multiple updates pending: Try updating packages one at a time. Use the following to select packages:

$ fwupdmgr update update_ID

(Where update_ID is something like f95c9218acd12697af946874bfe4239587209232.)

read-only filesystem error

At least fwupdmgr 1.5.2 deduces the wrong mount point if bind is used to mount esp to /boot [1]. Consequently it fails to write the UEFI update file to /boot/EFI/arch/fw (fwupdmgr while it should be written to esp/EFI/arch/fw.) This results in a (misleading) "file system is read-only" error message. In case the update was performed by Discover (or any other fwupd-capable Update GUI), no error or misleading errors may be shown.

As a workaround, run umount /boot first if it was bind-mounted to esp/EFI/arch before, then run fwupdmgr update to write the UEFI update file to esp/EFI/arch/fw, mount /boot and reboot the system to perform the UEFI update.

UEFI ESP partition not detected or configured

如果按上面 UEFI 更新的要求執行了操作,還是無法識別 ESP 分區,可以手動指定掛載點:

/etc/fwupd/uefi_capsule.conf
[uefi_capsule]
OverrideESPMountPoint=/efi   # Change according to your setup

Also see the relevant article in the fwupd wiki.

MSR plugin is failing to load

The MSR plugin allows querying the state of DCI, a debugging interface available for Intel CPUs that should be disabled on production machines according to fwupd's documentation.

This plugin needs the msr kernel module loaded. msr is a built-in kernel module in all the official Arch Linux kernel packages, but unofficial kernel packages might have it as a loadable kernel module. In the latter case, we need to explicitly load the module at boot.

Failed to load daemon: failed to load engine: No ESP with path

When starts fwupd, it checks the esp location as EspLocation from /etc/fwupd/daemon.conf. Modify it to your corresponding setup if encounter this error.