fwupd is a simple daemon allowing you to update some devices' firmware, including UEFI for several machines.
See #Setup for UEFI upgrade if you intend such an use.
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.
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, it will not work in legacy boot mode.
- Verify your EFI variables are accessible.
- Mount your EFI system partition (ESP) properly.
espis used to denote the mountpoint in this section.
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.
After creation, you will have to restart the fwupd service.
systemctl restart fwupd.service
You can now
$ fwupdmgr refresh and
$ fwupdmgr update. It will ask to reboot and should now automatically reboot into the firmware updater.
Using your own keys
Alternatively, you have to manually sign the UEFI executable used to perform upgrades, which is located in
The signed UEFI executable is expected in
Using , 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:
[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
<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.signed and add the file to the
EXTRA_SIGN list in
Finally, you have to change the line containing
DisableShimForSecureBoot=true and restart
Check out this GitHub issue for more information discussing this.
No error but no upgrade on reboot
fwupdmgr update reports no error and prompts for reboot (e.g., on BIOS update). However, the system reboots normally and the firmware update does NOT happen.
Possible cause: In BIOS settings changing the boot order must be allowed.
read-only filesystem error
fwupdmgr 1.5.2 deducts the wrong mount point if bind is used to mount esp to
/boot . Consequently it fails to write the UEFI update file to
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
mount /boot and reboot the system to perform the UEFI update.
UEFI ESP partition not detected or configured
fwupd needsto detect the ESP. As a workaround, the mount point can also be specified manually:
[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. The msr module is a built-in kernel module in all the official Arch Linux kernel packages but AUR kernel packages might have it as a loadable kernel module. In the latter case, we need to explicitly load it. To automatically load the kernel module with systemd, create the following
For more details about loading kernel module see the Kernel module article.