Firmware is the part of a Linux machine nobody wants to think about, right up until a laptop stops waking from suspend, an NVMe drive starts throwing odd latency spikes, or a security advisory says the UEFI needs a patch. Then it becomes urgent. Many admins still handle it the old way: download a vendor ISO, build a bootable USB, reboot into a DOS-like utility and hope. That works, but it doesn’t scale. It also leaves no audit trail.

Fwupd is the better answer. It is a system daemon that talks to your hardware, pulls signed firmware metadata from the Linux Vendor Firmware Service (LVFS), and applies updates with the same tooling on a laptop, a workstation or a rack server. This guide covers installing fwupd on Ubuntu 26.04 LTS, and also how to run it without surprises.

On a fresh Ubuntu 26.04 install, fwupd is often already present on desktop editions. Minimal installs, cloud images and server builds frequently leave it out, or leave the refresh timers in a state nobody has checked. So the first job is to find out what you actually have.

The sections below cover the apt install, the snap alternative and how to choose between them. They then walk through the update workflow, scheduling, Secure Boot and ESP pitfalls, and a troubleshooting section built from the failures that come up most often.

What Fwupd Actually Does

Fwupd is two things that people tend to mix up. The first is fwupd, the background daemon that detects devices and performs updates. The second is fwupdmgr, the command line client that talks to that daemon. The LVFS project provides both components: the daemon updates the firmware, and the client shows and applies updates.

The metadata comes from LVFS, which collects firmware uploaded by hardware vendors. Fwupd is configured by default to download from it. More than 100 vendors publish through LVFS. That covers a lot of ground: UEFI system firmware, Thunderbolt controllers, some NVMe drives, USB docks, fingerprint readers, input devices, and the Secure Boot forbidden signature database (dbx).

Why a sysadmin should care

Three reasons come up in practice.

• Security: Firmware vulnerabilities sit below the operating system, so a perfectly patched kernel doesn’t help. Updating the dbx, for example, is a routine fwupd task.
• Consistency: One tool across a mixed fleet beats ten vendor utilities.
• Traceability: fwupdmgr get-history shows what was applied and when, which matters in change-controlled environments.

One caveat is worth knowing. Fwupd only covers hardware whose vendor has published to LVFS. If your device isn’t listed, no amount of tweaking will conjure an update. Check first, then plan.

Check What Ubuntu 26.04 Already Ships

Before installing anything, ask the system. Ubuntu 26.04 LTS is codenamed resolute, and its updates pocket carries fwupd 2.1.1-1ubuntu3.1 as of July 2026. Upstream has moved on since then, and fwupd 2.1.9 was announced in October 2026. Ubuntu’s archive version will lag behind upstream by design. That is normal for an LTS release and rarely a problem for everyday use.

Check what is installed:

fwupdmgr --version
apt policy fwupd

If the first command returns “command not found,” fwupd isn’t installed. If it prints a version block, you already have it and can skip ahead to the update workflow. The output lists both the compile-time and runtime versions of fwupd and its libraries, which helps when you compare against bug reports.

Also confirm what kind of machine this is, because it changes your expectations:

sudo dmidecode -s system-manufacturer
sudo dmidecode -s system-product-name
sudo dmidecode -s bios-version

Write those values down. If an update goes wrong, you will want them.

Install Fwupd on Ubuntu 26.04 LTS with APT

This is the recommended method for almost everyone. It integrates with the system’s D-Bus, systemd and polkit setup, receives security updates through the normal Ubuntu channels, and doesn’t bring its own runtime.

Step 1: Refresh package indexes

sudo apt update

Don’t skip this on a long-lived box. A stale index is the classic reason for fetching an old fwupd build, or for a 404 on a package that has since been superseded.

Step 2: Install the package

sudo apt install fwupd

On Ubuntu the package pulls in the daemon, the fwupdmgr client and the supporting plugin libraries. On UEFI systems you will normally see the signed EFI binary package come along too, which is what lets capsule updates boot under Secure Boot. If your install is minimal and uses --no-install-recommends, add it explicitly:

sudo apt install fwupd fwupd-signed

Check that the package exists in your enabled repositories first with apt-cache policy fwupd-signed. On non-UEFI hardware, such as many virtual machines, it isn’t needed.

Step 3: Verify the daemon

systemctl status fwupd.service
fwupdmgr --version

Don’t panic if the service reports as inactive. Fwupd is typically D-Bus activated, so it starts when something asks for it and exits after a period of idleness. Running any fwupdmgr command wakes it up. Run sudo fwupdmgr get-devices and then look at the status again.

Step 4: Look at the refresh timer

systemctl list-timers | grep fwupd

Ubuntu ships a fwupd-refresh timer and service that fetch metadata in the background. On desktop installs this is often enough to keep GNOME Software or the Firmware app informed. On servers, check that it exists and is enabled, since server images sometimes trim these defaults.

sudo systemctl enable --now fwupd-refresh.timer

If that unit name isn’t found on your build, don’t force it. Run the refresh manually or from your own scheduler, which is covered later.

Alternative: Install the Snap Version

Sometimes the archive version is too old for a newly supported device. A recent example would be a dock or controller added in the latest upstream release. In that case the snap is an option. Dell’s own documentation, written when Ubuntu 18.04’s fwupd reached end of life, describes the same route. You remove the distribution fwupd and install the snap, which carries its runtime dependencies.

sudo apt purge fwupd
sudo snap install fwupd

Some community documentation uses the --classic flag for the snap, so read the output of snap info fwupd on your system before choosing flags. Confirmation messages from snapd will tell you what confinement the current revision uses.

APT versus snap: when each makes sense

My own preference on production hardware is the apt build. Fewer moving parts is a feature when the operation in question can brick a board. Use the snap only when a specific device requires a fix that hasn’t reached the archive, and don’t run both at once. Two daemons fighting over the same hardware is a bad afternoon waiting to happen.

Install Fwupd on Other Distributions

Since readers often manage mixed estates, here are the equivalents.

Debian 12 or newer:

sudo apt update
sudo apt install fwupd

AlmaLinux, Rocky Linux and RHEL 9:

sudo dnf install fwupd
sudo systemctl enable --now fwupd

There’s a wrinkle on Red Hat family systems. Red Hat’s documentation notes that LVFS is not enabled by default on RHEL, and fwupdmgr refresh asks whether you want to enable it. Answer that prompt deliberately, and make sure your security policy allows outbound traffic to the LVFS.

The Core Workflow: Refresh, Review, Update

The upstream project documents a simple sequence: list devices, refresh metadata, review available updates, then apply. It looks trivial. Here is why each step exists.

1. List detected devices

sudo fwupdmgr get-devices

This shows every device fwupd can see, along with its current firmware version, vendor, device flags and update state. To include devices that fwupd can see but can’t update, add the “show all” option. Red Hat’s guidance uses fwupdmgr get-devices --show-all-devices for this purpose.

Why bother? Because it answers the supportability question before you commit to a maintenance window. A machine with only a “System Firmware” entry and a couple of USB devices has a very different risk profile from one with Thunderbolt docks and NVMe drives.

2. Refresh metadata

sudo fwupdmgr refresh

If the cached data is recent, you will see a message that metadata is up to date, and you can use --force to override it. This is the only command that checks the network for new information. One forum thread on a Framework laptop makes the point well: get-updates only looks at the local cache, and the cache is readable and writable only by root, so refresh needs sudo.

That behavior explains a very common complaint. Someone runs get-updates, sees nothing, and assumes no firmware exists. In reality their metadata is weeks old.

sudo fwupdmgr refresh --force

3. Review available updates

sudo fwupdmgr get-updates

Read the output. It includes release notes, the version delta and sometimes warnings, such as “this update requires AC power” or “device will be unavailable during update.” Treat those as instructions and not decoration.

4. Apply the updates

sudo fwupdmgr update

Fwupd asks for confirmation and walks through each device. Updates that can be applied live happen right away. Others are staged and run at the next boot. UEFI capsule updates fall into that second group, and the machine will show a firmware update screen during restart.

5. Verify the outcome

After reboot:

sudo fwupdmgr get-history
sudo fwupdmgr get-results

A short post-update routine is worth having. Compare dmidecode -s bios-version with the pre-update value you wrote down. Check journalctl -u fwupd -b for errors. Then spend a minute confirming that the usual suspects (network, storage, suspend) behave.

Troubleshooting Common Errors

“No updatable devices” or empty device list

Possible causes: the hardware isn’t supported by any plugin, the daemon lacks permission, or you’re inside a virtual machine or container without passthrough. Run the following and read the output:

sudo fwupdmgr get-devices --show-all-devices
sudo journalctl -u fwupd -b --no-pager | tail -n 50

“No updates available” when you expect one

First force a refresh. As noted earlier, get-updates uses cached data:

sudo fwupdmgr refresh --force
sudo fwupdmgr get-updates

If it’s still empty, check whether the vendor even publishes your model to LVFS, and whether the firmware has been released to the stable channel and not only the testing remote. Some vendors stage new releases in a testing channel first, which you should not enable on production machines.

For deeper diagnosis, fwupdtool get-updates -vv shows verbose output without going through the daemon, which a Framework community thread suggested for a similar issue.

“Metadata is up to date” but nothing changes

This is expected behavior and not an error. Use --force if you suspect the cache is wrong.

Download failures, TLS errors or timeouts

Check connectivity and the system clock. A wrong date breaks certificate validation, which is more common on freshly provisioned VMs than anyone admits.

timedatectl
curl -I https://fwupd.org

If a proxy is required, configure it for the daemon environment and not only your shell, because the daemon runs as a service. A systemd drop-in works:

sudo systemctl edit fwupd.service

[Service]
Environment="https_proxy=http://proxy.example.com:3128"

Then restart:

sudo systemctl restart fwupd.service

Capsule update did not apply after reboot

The usual suspects are a mispointed or full EFI System Partition, Secure Boot configuration problems, or low battery. Check:

findmnt /boot/efi
df -h /boot/efi
mokutil --sb-state
sudo fwupdmgr get-results

Make sure the ESP is mounted at a location fwupd expects. If you have a non-standard layout, the EspLocation setting in /etc/fwupd/fwupd.conf can point to the right place. Restart the daemon after changing it.

“Command not found”

Either the package isn’t installed or you installed the snap and the path doesn’t include /snap/bin. Check:

which fwupdmgr
snap list | grep fwupd

Conflicts between apt and snap

If you installed the snap on top of the apt package, remove one. Dell’s guidance for the snap transition is to purge the distribution package first. Never keep both active.

Failed update on a device that now looks dead

Stop. Don’t repeatedly retry. Read the logs, check the vendor’s recovery procedure and, if it’s a laptop, look for a documented emergency BIOS recovery method. Many boards support recovery from a USB stick holding a specific file. Retrying blindly can turn a recoverable situation into a permanent one.