Fwupd: Difference between revisions
(Update introduction from upstream.) |
(Fixed updated path) |
||
(9 intermediate revisions by 8 users not shown) | |||
Line 1: | Line 1: | ||
{{Lowercase title}} | {{Lowercase title}} | ||
[[Category:Hardware]] | [[Category:Hardware]] | ||
[[pl:Fwupd]] | |||
[[ja:Fwupd]] | [[ja:Fwupd]] | ||
[[zh-hans:Fwupd]] | [[zh-hans:Fwupd]] | ||
Line 23: | Line 24: | ||
* {{App|GNOME Software|Will check for updates periodically and automatically download firmwares in the background on [[GNOME]]. After a firmware has been downloaded a popup will be displayed in Gnome Software to perform the update.|https://wiki.gnome.org/Apps/Software|{{Pkg|gnome-software}}}} | * {{App|GNOME Software|Will check for updates periodically and automatically download firmwares in the background on [[GNOME]]. After a firmware has been downloaded a popup will be displayed in Gnome Software to perform the update.|https://wiki.gnome.org/Apps/Software|{{Pkg|gnome-software}}}} | ||
* {{App|KDE Discover|Software center used with [[Plasma]]. With the release of KDE Plasma 5.14, a new ''fwupd'' backend has been implemented in KDE Discover for firmware updates. These firmware updates are shown with other system updates.|https://userbase.kde.org/Discover|{{Pkg|discover}}}} | * {{App|KDE Discover|Software center used with [[Plasma]]. With the release of KDE Plasma 5.14, a new ''fwupd'' backend has been implemented in KDE Discover for firmware updates. These firmware updates are shown with other system updates.|https://userbase.kde.org/Discover|{{Pkg|discover}}}} | ||
* {{App|GNOME Firmware|Application to upgrade, downgrade and reinstall firmware on devices supported by ''fwupd''. It can unlock locked ''fwupd'' devices, verify firmware on supported devices and display all releases for a ''fwupd'' device.|https://gitlab.gnome.org/ | * {{App|GNOME Firmware|Application to upgrade, downgrade and reinstall firmware on devices supported by ''fwupd''. It can unlock locked ''fwupd'' devices, verify firmware on supported devices and display all releases for a ''fwupd'' device.|https://gitlab.gnome.org/World/gnome-firmware|{{Pkg|gnome-firmware}}}} | ||
== Usage == | == Usage == | ||
{{Expansion|Need to explain the meaning and usage of the package's other executables and systemd units.}} | {{Expansion|Need to explain the meaning and usage of the package's other executables and systemd units.}} | ||
The package provides a {{ic|fwupd.service}} which will automatically start the ''fwupd'' daemon when the first query is received. [https://fwupd.org/lvfs/docs/users] | |||
To display all devices detected by ''fwupd'': | To display all devices detected by ''fwupd'': | ||
Line 59: | Line 62: | ||
The following requirements should be met: | The following requirements should be met: | ||
# Make sure you are booted in [[UEFI]] mode, it will not work in legacy boot mode. | # Make sure you are booted in [[UEFI]] mode, because it will not work in legacy boot mode. | ||
# Verify [[Unified Extensible Firmware Interface#Requirements for UEFI variable support|your EFI variables are accessible]]. | # Verify [[Unified Extensible Firmware Interface#Requirements for UEFI variable support|your EFI variables are accessible]]. | ||
# Mount your [[EFI system partition]] (ESP) properly. {{ic|''esp''}} is used to denote the mountpoint in this section. | # Mount your [[EFI system partition]] (ESP) properly. {{ic|''esp''}} is used to denote the mountpoint in this section. | ||
# Make sure optional dependency {{Pkg|udisks2}} | # Make sure the optional dependency {{Pkg|udisks2}} is installed and the associated systemd unit is started before fwupd unit; it will provide UEFI firmware upgrade support. | ||
=== Prepare ESP === | === Prepare ESP === | ||
''fwupd'' will copy all the necessary files over to the {{ic|''esp''}}, but for this to work, a basic folder layout must be present on your {{ic|''esp''}} | ''fwupd'' will copy all the necessary files over to the {{ic|''esp''}}, but for this to work, a basic folder layout must be present on your {{ic|''esp''}}; | ||
this constitutes the creation of an {{ic|EFI}} directory on your {{ic|''esp''}}: | |||
{{Note|Depending on your boot loader or the presence of other operating systems, this directory may already exist.}} | {{Note|Depending on your boot loader or the presence of other operating systems, this directory may already exist.}} | ||
# mkdir ''esp''/EFI/ | # mkdir ''esp''/EFI/ | ||
{{Warning|The {{ic|EFI}} directory '''must''' be in all upper-case | {{Warning|The {{ic|EFI}} directory '''must''' be in all upper-case; if you used lower-case, ''fwupd'' may detect the {{ic|''esp''}} as {{ic|''esp''/efi/}} and look for {{ic|''esp''/efi/EFI/}} instead.}} | ||
[[Restart]] the {{ic|fwupd.service}} unit afterwards. You can now {{ic|fwupdmgr refresh}} and {{ic|fwupdmgr update}}. You will be prompted to reboot (into the firmware updater). | [[Restart]] the {{ic|fwupd.service}} unit afterwards. You can now {{ic|fwupdmgr refresh}} and {{ic|fwupdmgr update}}. You will be prompted to reboot (into the firmware updater). | ||
Line 82: | Line 83: | ||
=== Secure Boot === | === Secure Boot === | ||
Currently, ''fwupd'' relies on [[Secure Boot#shim|shim]] to chainload the ''fwupd'' EFI binary on systems with [[Secure Boot]] enabled | Currently, ''fwupd'' relies on [[Secure Boot#shim|shim]] to chainload the ''fwupd'' EFI binary on systems with [[Secure Boot]] enabled; for this to work, ''shim'' has to be installed correctly. | ||
==== Using your own keys ==== | ==== Using your own keys ==== | ||
Alternatively, you | Alternatively, you can manually sign the UEFI executable used to perform upgrades, which is located in {{ic|/usr/lib/fwupd/efi/fwupdx64.efi}}. The signed UEFI executable is expected in {{ic|/usr/lib/fwupd/efi/fwupdx64.efi.signed}}. Using {{Pkg|sbsigntools}}, this can be achieved by running: | ||
# sbsign --key ''keyfile'' --cert ''certfile'' /usr/lib/fwupd/efi/fwupdx64.efi | # sbsign --key ''keyfile'' --cert ''certfile'' /usr/lib/fwupd/efi/fwupdx64.efi | ||
Line 107: | Line 108: | ||
Make sure to replace {{ic|''keyfile''}} and {{ic|''certfile''}} with the corresponding paths of your keys. | Make sure to replace {{ic|''keyfile''}} and {{ic|''certfile''}} with the corresponding paths of your keys. | ||
Instead of a pacman hook you can also create a symlink from {{ic|/usr/lib/fwupd/efi/fwupdx64.efi}} to {{ic|/usr/lib/fwupd/efi/fwupdx64.efi.signed}} and add the file to the {{ic|EXTRA_SIGN}} list in {{ic|/etc/sbupdate.conf}}. | Instead of a pacman hook, you can also create a symlink from {{ic|/usr/lib/fwupd/efi/fwupdx64.efi}} to {{ic|/usr/lib/fwupd/efi/fwupdx64.efi.signed}}, and add the file to the {{ic|EXTRA_SIGN}} list in {{ic|/etc/sbupdate.conf}}. | ||
Finally, you have to set {{ic|DisableShimForSecureBoot}} in {{ic|/etc/fwupd/fwupd.conf}} and restart {{ic|fwupd.service}}: | |||
{{hc|head=/etc/fwupd/fwupd.conf|output= | |||
... | |||
[uefi_capsule] | |||
DisableShimForSecureBoot=true | |||
}} | |||
{{Note|If you set this up before ''fwupd'' 1.4, be aware of the subtle change to the configuration option name.}} | {{Note| | ||
* If you set this up before ''fwupd'' 1.9, this option is located in {{ic|/etc/fwupd/uefi_capsule.conf}}. | |||
* If you set this up before ''fwupd'' 1.4, be aware of the subtle change to the configuration option name. | |||
}} | |||
See https://github.com/fwupd/fwupd/issues/669 for more information. | See https://github.com/fwupd/fwupd/issues/669 for more information. | ||
Line 135: | Line 145: | ||
=== read-only filesystem error === | === read-only filesystem error === | ||
At least {{ic|fwupdmgr}} 1.5.2 deduces the wrong mount point if bind is used to mount | At least {{ic|fwupdmgr}} 1.5.2 deduces the wrong mount point if [[EFI system partition#Using bind mount|bind is used to mount the EFI system partition to /boot]]. Consequently it fails to write the UEFI update file to {{ic|/boot/EFI/arch/fw}} ({{ic|fwupdmgr}} while it should be written to {{ic|''esp''/EFI/arch/fw}}.) This results in a (misleading) {{ic|file system is read-only}} error message. In case the update was performed by {{ic|Discover}} (or any other fwupd-capable Update GUI), no error or misleading errors may be shown. | ||
As a workaround, run {{ic|umount /boot}} first if it was bind-mounted to {{ic|''esp''/EFI/arch}} before, then run {{ic|fwupdmgr update}} to write the UEFI update file to {{ic|''esp''/EFI/arch/fw}}, {{ic|mount /boot}} and reboot the system to perform the UEFI update. | As a workaround, run {{ic|umount /boot}} first if it was bind-mounted to {{ic|''esp''/EFI/arch}} before, then run {{ic|fwupdmgr update}} to write the UEFI update file to {{ic|''esp''/EFI/arch/fw}}, {{ic|mount /boot}} and reboot the system to perform the UEFI update. | ||
Line 158: | Line 168: | ||
=== Failed to load daemon: failed to load engine: No ESP with path === | === Failed to load daemon: failed to load engine: No ESP with path === | ||
When starts fwupd, it checks the esp location as {{ic|EspLocation}} from {{ic|/etc/fwupd/ | When starts fwupd, it checks the esp location as {{ic|EspLocation}} from {{ic|/etc/fwupd/fwupd.conf}}. Modify it to your corresponding setup if encounter this error. |
Latest revision as of 03:32, 22 January 2024
fwupd is a simple daemon to allow session software to update device firmware on your local machine. It's designed for desktops, but also usable on phones and headless servers.
Supported devices are listed here and more are to come.
Installation
See #Setup for UEFI upgrade if you intend such use.
Graphical front-ends
Certain desktop environments front-end solutions have built-in fwupd support:
- GNOME Software — Will check for updates periodically and automatically download firmwares in the background on GNOME. After a firmware has been downloaded a popup will be displayed in Gnome Software to perform the update.
- KDE Discover — Software center used with Plasma. With the release of KDE Plasma 5.14, a new fwupd backend has been implemented in KDE Discover for firmware updates. These firmware updates are shown with other system updates.
- GNOME Firmware — Application to upgrade, downgrade and reinstall firmware on devices supported by fwupd. It can unlock locked fwupd devices, verify firmware on supported devices and display all releases for a fwupd device.
Usage
The package provides a fwupd.service
which will automatically start the fwupd daemon when the first query is received. [1]
To display all devices detected by fwupd:
$ fwupdmgr get-devices
To download the latest metadata from the Linux Vendor firmware Service (LVFS):
$ fwupdmgr refresh
To list updates available for any devices on the system:
$ fwupdmgr get-updates
To install updates:
$ fwupdmgr update
- Updates that can be applied live will be done immediately.
- Updates that run at bootup will be staged for the next reboot.
- The root user may be required to perform certain device updates.
Setup for UEFI upgrade
The following requirements should be met:
- Make sure you are booted in UEFI mode, because it will not work in legacy boot mode.
- Verify your EFI variables are accessible.
- Mount your EFI system partition (ESP) properly.
esp
is used to denote the mountpoint in this section. - Make sure the optional dependency udisks2 is installed and the associated systemd unit is started before fwupd unit; it will provide UEFI firmware upgrade support.
Prepare ESP
fwupd will copy all the necessary files over to the esp
, but for this to work, a basic folder layout must be present on your esp
;
this constitutes the creation of an EFI
directory on your esp
:
# mkdir esp/EFI/
EFI
directory must be in all upper-case; if you used lower-case, fwupd may detect the esp
as esp/efi/
and look for esp/efi/EFI/
instead.Restart the fwupd.service
unit afterwards. You can now fwupdmgr refresh
and fwupdmgr update
. You will be prompted to reboot (into the firmware updater).
Secure Boot
Currently, fwupd relies on shim to chainload the fwupd EFI binary on systems with Secure Boot enabled; for this to work, shim has to be installed correctly.
Using your own keys
Alternatively, you can manually sign the UEFI executable used to perform upgrades, which is located in /usr/lib/fwupd/efi/fwupdx64.efi
. The signed UEFI executable is expected in /usr/lib/fwupd/efi/fwupdx64.efi.signed
. Using sbsigntools, this can be achieved by running:
# sbsign --key keyfile --cert certfile /usr/lib/fwupd/efi/fwupdx64.efi
To automatically sign this file when installed or upgraded, a Pacman hook can be used:
/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
Make sure to replace keyfile
and certfile
with the corresponding paths of your keys.
Instead of a pacman hook, you can also create a symlink from /usr/lib/fwupd/efi/fwupdx64.efi
to /usr/lib/fwupd/efi/fwupdx64.efi.signed
, and add the file to the EXTRA_SIGN
list in /etc/sbupdate.conf
.
Finally, you have to set DisableShimForSecureBoot
in /etc/fwupd/fwupd.conf
and restart fwupd.service
:
/etc/fwupd/fwupd.conf
... [uefi_capsule] DisableShimForSecureBoot=true
- If you set this up before fwupd 1.9, this option is located in
/etc/fwupd/uefi_capsule.conf
. - If you set this up before fwupd 1.4, be aware of the subtle change to the configuration option name.
See https://github.com/fwupd/fwupd/issues/669 for more information.
Troubleshooting
Stuck when rebooting
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.
No error but no upgrade on reboot
Symptom: fwupdmgr update
reports no error and prompts for reboot (e.g., on BIOS update). However, the system reboots normally (or stuck) and the firmware update does NOT happen.
Possible cause: In BIOS settings changing the boot order must be allowed.
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 the EFI system partition to /boot. 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
If ESP partition still not detected after all requirement in #Setup for UEFI upgrade are met, the mount point can be specified manually:
/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/fwupd.conf
. Modify it to your corresponding setup if encounter this error.