来自 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.