fwupd

fwupd 是一个简单的守护进程，允许会话软件更新本地机器上的设备固件。它专为桌面环境设计，但也适用于手机和无头服务器。

支持的设备列表列在此处，未来还会增加更多支持。

安装

安装 fwupd 软件包。

大多数外设可以直接在操作系统内更新。然而，BIOS/UEFI 更新通常需要 UEFI 模式（UpdateCapsule），由固件在重启时安全地应用更新。如果您打算这样使用，请参阅 #设置 UEFI 升级。

图形前端

某些桌面环境的前端解决方案内置了 fwupd 支持。

Discover — 与 Plasma 一起使用的软件中心。随着 KDE Plasma 5.14 的发布，KDE Discover 中实现了新的 fwupd 后端以支持固件更新。这些固件更新会与其他系统更新一同显示。属于 plasma 组。

https://apps.kde.org/discover/ || discover

GNOME Firmware — 用于升级、降级和重新安装 fwupd 支持的设备固件的应用程序。它可以解锁已锁定的 fwupd 设备，验证支持设备的固件，并显示 fwupd 设备的所有发布版本。

https://gitlab.gnome.org/World/gnome-firmware || gnome-firmware

GNOME Software — 将在 GNOME 中定期检查更新并在后台自动下载固件。固件下载完成后，GNOME Software 中会显示一个弹窗以执行更新。属于 gnome 组。

https://apps.gnome.org.cn/Software/ || gnome-software

用法

本文章或章节需要扩充。

原因： 需要解释软件包中其他可执行文件和 systemd 单元的含义及用法。（在 Talk:Fwupd 中讨论）

该软件包提供了一个 fwupd.service，它将在接收到第一个查询时自动启动 fwupd 守护进程。[1]

要显示 fwupd 检测到的所有设备：

$ fwupdmgr get-devices

注意： 列出的设备可能无法通过 fwupd 更新（例如 Intel 集成显卡）。可能会提供其他的供应商解决方案来替代。

要从 Linux 供应商固件服务 (LVFS) 下载最新的元数据：

$ fwupdmgr refresh

注意： 这可以通过启用 fwupd-refresh.timer 来自动完成。

要列出系统上任何设备可用的更新：

$ fwupdmgr get-updates

要安装更新：

$ fwupdmgr update

注

可以实时应用的更新将立即执行。
在启动时运行的更新将被暂存，留待下次重启时执行。
root 用户可能需要执行某些设备更新。
某些硬件组件可能不被 fwupd 覆盖，可能需要手动应用更新（例如下载必要文件，将其刷入 U 盘，然后手动应用更新）。对于主板 (BIOS/UEFI) 固件更新（通过“Q-Flash”或类似过程）尤其如此。

配置

禁用本地缓存服务器 (passim)

2023 年 9 月发布的 fwupd v1.9.5 引入了对 passim 的依赖。passim 是一个本地缓存服务器，旨在通过让每台机器能够将其每天下载的元数据文件提供给其他机器，从而减少 LVFS 带宽使用[2][3]。

passimd 是一个监听 任意 IP 地址 上端口 27500 连接的守护进程（即它监听在 0.0.0.0:27500）。这引发了一些关于安全影响的批评[4][5]，事实上在几周后就报告了几个漏洞[6][7]。

在 Arch 上，FS#79614 中提出的在编译时将该依赖设为可选的请求被拒绝，因为这将需要为库创建一个分包。

因此，如果您希望禁用 passimd，应遵循作者给出的建议[8]：在 /etc/fwupd/fwupd.conf 的 [fwupd] 部分下添加 P2pPolicy=nothing，并屏蔽 passim.service。

设置 UEFI 升级

警告： 对 UEFI 固件的更新可能会丢弃当前的引导加载程序安装。在成功安装固件更新后，可能有必要重新创建 NVRAM 条目（例如使用 efibootmgr）。

应满足以下要求：

确保您以 UEFI 模式启动，因为它在传统引导模式下无法工作。
验证您的 EFI 变量是可访问的。
正确挂载您的 EFI 系统分区 (ESP)。本节中 esp 用于表示挂载点。
确保安装了可选依赖项 udisks2，并且关联的 systemd 单元在 fwupd 单元之前启动；它将提供 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 在启用了安全启动 (Secure Boot) 的系统上依赖 shim 来链式加载 fwupd 的 EFI 二进制文件；为了使其工作，必须正确安装 shim。

使用自定义密钥

使用 sbctl 的辅助流程

您可以使用 sbctl 对 UEFI 可执行文件进行签名。关于如何设置 sbctl 的说明，请参阅 Unified Extensible Firmware Interface/Secure Boot with sbctl。

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

随后，每次更新 fwupd 后，得益于 sbctl 的 pacman 钩子 (/usr/share/libalpm/hooks/zz-sbctl.hook)，UEFI 可执行文件将自动被签名。

最后，您必须在 /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 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/fwupd.conf 中设置 DisableShimForSecureBoot 并重启 fwupd.service。

/etc/fwupd/fwupd.conf

...

[uefi_capsule]
DisableShimForSecureBoot=true

注

如果您在 fwupd 1.9 之前进行了此设置，该选项位于 /etc/fwupd/uefi_capsule.conf 中。
如果您在 fwupd 1.4 之前进行了此设置，请注意配置选项名称的微小变化。

有关更多信息，请参阅 https://github.com/fwupd/fwupd/issues/669。

故障排除

重启时卡住

fwupdmgr update 报告没有错误，但它提示的重启过程卡住了，按住电源键也没有响应。请尝试切断电源，或按下重置按钮（笔记本电脑上可能是一个小孔）以强制重启。

重启时无错误但未升级

症状： fwupdmgr update 报告没有错误并提示重启（例如在 BIOS 更新时）。但是，系统正常重启（或卡住），且固件更新并未发生。

可能原因： 在 BIOS 设置中，必须允许更改引导顺序。

如果存在多个待处理更新时的其他可能解决方案： 尝试一次更新一个软件包。使用以下命令选择软件包：

$ fwupdmgr update update_ID

（其中 update_ID 类似于 f95c9218acd12697af946874bfe4239587209232。）

只读文件系统错误

至少 fwupdmgr 1.5.2 在使用 bind 挂载将 EFI 系统分区挂载到 /boot 时，会推断出错误的挂载点。因此，它无法将 UEFI 更新文件写入 /boot/EFI/arch/fw（正确路径应该是 esp/EFI/arch/fw）。这导致了（误导性的）file system is read-only 错误消息。如果更新是由 Discover（或任何其他支持 fwupd 的更新 GUI）执行的，则可能不会显示错误或显示误导性错误。

作为权宜之计，如果之前使用了 bind 挂载到 esp/EFI/arch，请先运行 umount /boot，然后运行 fwupdmgr update 将 UEFI 更新文件写入 esp/EFI/arch/fw，随后 mount /boot 并重启系统以执行 UEFI 更新。

UEFI ESP 分区未检测到或未配置

如果在满足 #设置 UEFI 升级中的所有要求后仍未检测到 EFI 系统分区 (ESP)，可以手动指定挂载点：

/etc/fwupd/fwupd.conf

[fwupd]
EspLocation=/efi

请参阅 fwupd wiki 中的相关文章，了解可能导致此问题的其他原因。

设置 ESP 位置可以防止 fwupdx64.efi 被安装到位于其他磁盘上的不需要的 EFI 系统分区中。

MSR 插件加载失败

MSR 插件允许查询 DCI 的状态，DCI 是 Intel CPU 上提供的一种调试接口。根据 fwupd 文档，它在生产机器上应该被禁用。

此插件需要加载 msr 内核模块。msr 是所有官方 Arch Linux 内核软件包中的内置内核模块，但非官方内核软件包可能将其作为可加载内核模块。在后一种情况下，我们需要显式地在启动时加载该模块。