From ArchWiki
Jump to navigation Jump to search

fwupd is a simple daemon allowing you to update some devices' firmware, including UEFI for several machines.

Supported devices are listed here and more are to come.


Install fwupd.

See #Setup for UEFI upgrade if you intend such an 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.
https://wiki.gnome.org/Apps/Software || gnome-software
  • 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 || discover
  • 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/hughsie/gnome-firmware-updater || gnome-firmware


To display all devices detected by fwupd:

$ fwupdmgr get-devices
Note: Listed devices may not be updatable through fwupd (e.g. Intel integrated graphics). Alternative vendor solutions may be provided instead.

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

Warning: An update to your UEFI firmware may discard the current bootloader installation. It may be necessary to recreate the NVRAM entry (for example using efibootmgr) after the firmware update has been installed successfully.

The following requirements should be met:

  1. Make sure you are booted in UEFI mode, it will not work in legacy boot mode.
  2. Verify your EFI variables are accessible.
  3. Mount your EFI system partition (ESP) properly. esp is used to denote the mountpoint in this section.

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.

Note: Depending on the boot loader you have in use or the presence of other operating systems, this directory may already exist.

This constitutes the creation of an 'EFI' directory on your esp.

mkdir esp/EFI/
Warning: The 'EFI' directory MUST be in all upper-case. If you used lower-case, fwupd may detect the esp as esp/efi/ instead and would start looking for esp/efi/EFI/

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.

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 have to 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:

Operation = Install
Operation = Upgrade
Type = Path
Target = usr/lib/fwupd/efi/fwupdx64.efi

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 change the line containing DisableShimForSecureBoot in /etc/fwupd/uefi.conf to DisableShimForSecureBoot=true and restart fwupd.service.

Note: If you set this up before fwupd 1.4, be aware the name of the configuration option changed subtly.

Check out this GitHub issue for more information discussing this.


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 and the firmware update does NOT happen.

Possible cause: In BIOS settings changing the boot order must be allowed.

Error while loading shared library

Symptom: fwupdmgr crashes with message

fwupdmgr: error while loading shared libraries: libxmlb.so.1: cannot open shared object file: No such file or directory

Cause: fwupdmgr relies on libxmlb 0.1 whereas Arch currently ships v0.2.

Workaround: to temporary workaround the issue simply do:

# ln -s /usr/lib/libxmlb.so /usr/lib/libxmlb.so.1