fwupd: Linux firmware updates through LVFS, and when fwupdmgr is the wrong tool

The gap fwupd fills: firmware that only Windows could reach

Firmware on a laptop, dock, SSD or network card has historically been updated by a vendor utility that runs on Windows. On Linux the equivalent either did not exist or was a vendor-specific script that touched raw flash and hoped for the best. fwupd is the attempt to make that a normal package-managed operation: a daemon on the system bus, a client called fwupdmgr, and a catalogue of firmware capsules served by the Linux Vendor Firmware Service at fwupd.org.

The audience is narrower than the project's reach suggests. The README is explicit that end users should not compile fwupd from source, calling it a complicated project with dozens of dependencies and as many configuration options, and saying users should have fwupd installed and updated by their distribution. So the primary consumers are distribution package maintainers and the administrators who run the resulting package. If you are the person who has to decide whether a fleet of Linux machines gets firmware updates, that is you.

How the daemon, the client and LVFS fit together

The architecture is a privileged daemon plus a thin client. fwupd runs as a system service, owns the D-Bus interface, and does the work that needs root: identifying devices, downloading metadata, and writing firmware. fwupdmgr is the command line front end that talks to it. The README notes that graphical frontends are enumerated in the fwupdmgr man page, which implies the same D-Bus surface serves GNOME Software and anything else that wants to present updates.

Metadata is the pivot. fwupdmgr refresh downloads the latest metadata from LVFS, and that metadata is what maps a device to an available capsule. The default remote is LVFS, but the remote configuration is a file, and the enterprise section shows the file can carry an ApprovalRequired=true key. The project also has a peer-to-peer path: if Passim is installed and enabled, fwupd re-publishes the downloaded metadata to be served on 0.0.0.0:27500 by default, and other clients on the same network can use it via mDNS or LLMNR to cut bandwidth to the configured remotes. That is a LAN-level cache, not a mirror protocol, and it is off if you set P2pPolicy=none in /etc/fwupd/daemon.conf, remove the package, or mask passim.service.

The codebase itself is C, with a Rust workspace declared in Cargo.toml that includes rust/fwupd and rust/fwupd-ffi. Both dev and release profiles set panic = "abort" with the comment that unwinding through C FFI is undefined behavior. That is a deliberate choice about what happens when Rust code panics inside a C host: the process dies rather than unwinding into frames that cannot handle it.

Installing fwupd and running a first update

The README does not give distribution-specific install commands. It points at docs/building.md for a development environment, and at the snap and flatpak wiki pages for a bleeding edge version to update a specific device from the command line. The project's stated position is that your distribution should provide fwupd, so the install step is whatever your package manager calls it. What the README does document is the usage flow once it is installed, and that is the part worth walking through.

Start by listing what the daemon can see:

fwupdmgr get-devices

This displays all devices detected by fwupd. If your SSD, dock or webcam is absent here, no amount of refreshing will produce an update for it, because the device is not being matched against the metadata at all.

Next, pull current metadata from the remote:

fwupdmgr refresh

This downloads the latest metadata from LVFS. Then ask what is available:

fwupdmgr get-updates

If updates are available for any devices on the system, they are displayed. Finally:

fwupdmgr update

This downloads and applies all updates for your system. The README splits the outcome in two: updates that can be applied live are done immediately, and updates that run at boot-up are staged for the next reboot. That distinction matters in practice, because it means fwupdmgr update can return successfully while the actual flash is still pending.

Reporting is a separate, optional command:

fwupdmgr report-history

Only updates that were distributed from LVFS are reported back to LVFS, and the README describes the feature as optional but encouraged, with the privacy policy on the LVFS readthedocs site.

Approved updates: the enterprise control that is really a checksum allowlist

The enterprise feature is the most interesting design decision in the README, and also the easiest to misread. Adding ApprovalRequired=true to a remote configuration file, for example lvfs.conf, makes the remote serve only firmware that has been approved. The approval list itself lives in fwupd.conf as a comma-delimited list:

ApprovedFirmware=foo,bar

The README states that foo and bar refer to the container checksums that correspond to two updates in the metadata file. This is not a human-readable allowlist of vendor and version names. It is a list of hashes, which means the administrator needs a process to extract checksums from the metadata before writing them down. The list can also be supplemented at runtime with fwupdmgr set-approved-firmware baz or through the D-Bus interface.

The trade-off is honest but sharp. An approval list keyed on container checksums is precise and hard to forge, and it is also brittle: a vendor republishing the same firmware as a new container changes the checksum, and the update silently stops being approved. The README does not document any tooling for translating a firmware version into its container checksum, so that step is on the administrator.

Where fwupd is the wrong tool

The clearest limitation is stated by the project itself, in the tip about compiling: end users should not build fwupd from scratch, and a snap or flatpak install should not be considered a replacement for the distro-provided system version. If your distribution does not package a recent fwupd, the sanctioned path is to wait or to use a distribution that does, not to build it on a workstation you depend on.

There are also hard boundaries in the update model. Updates that run at boot-up are staged for the next reboot, so a machine that never reboots never completes them. On a server with a long uptime, or a container host where the firmware target is not exposed to the guest, fwupdmgr update can report work queued and the flash can stay pending indefinitely. Nothing in the README describes a forced immediate path for those boot-time updates.

Device coverage is not universal either. fwupdmgr get-devices is the only honest inventory, and it reflects what the daemon detected and what the metadata matches. Hardware whose vendor never publishes capsules to LVFS is simply invisible to the whole pipeline, and the README does not claim otherwise. The Passim integration is a bandwidth optimisation for machines that already have fwupd working, not a way to reach devices that are not supported.

Alternatives and the difference in approach

The README names one adjacent tool directly: mgmt, described as providing declarative resources and functions for fwupd for configuration management and reactive automation. The difference is the layer. fwupdmgr is imperative and local: you run a command on a host, it talks to the daemon on that host, and the result is that host's firmware state. mgmt describes the desired state across a set of machines and reconciles it, treating fwupd as one resource type among others. If you already run a configuration management system, the declarative route avoids writing your own wrapper around fwupdmgr and around the ApprovedFirmware list.

The other alternative is the vendor's own updater. It is usually a Windows executable or a vendor-specific Linux script, it covers exactly one product family, and it does not share metadata with anything. fwupd's advantage is the shared LVFS catalogue and the D-Bus interface that desktop software can drive; its disadvantage is that it only helps for hardware whose vendor chose to publish there.

Maintenance, upgrades and the LGPL-2.1 licence

The repository is not archived, and the last push was on 2026-09-23. Recent releases in the repository are 2.1.7 on 2026-07-27, 2.1.6 on 2026-07-01, and 2.0.21 on 2026-06-23, which shows a maintained 2.1 line and a separate 2.0 line still receiving releases. For an administrator the practical consequence is that the version you get is the version your distribution chose, and the upgrade cadence is your distribution's, not the upstream repository's.

fwupd is licensed LGPL-2.1. The README does not discuss linking or distribution obligations, and this is not legal advice, but the distinction that matters for most readers is the usual one: running the daemon and calling it over D-Bus does not put your application under the LGPL, while linking against libfwupd or libfwupdplugin and distributing the result brings the licence terms into play. If you are shipping a product that embeds the libraries, that question belongs with your legal team, not with this article.

Editorial conclusion

Adopt fwupd if you run a mainstream Linux distribution and want firmware updates delivered by your package manager and applied through fwupdmgr, with the option of ApprovalRequired=true and ApprovedFirmware for fleet control. Do not adopt it if you expect to compile it yourself for a desktop, if your hardware vendor publishes firmware only as a Windows executable, or if you need firmware updates on a system where you cannot reboot. Verify first that your distribution ships a current fwupd package, that the daemon is running, and that fwupdmgr get-devices lists the component you actually care about before you trust it with a staged update.

Frequently asked questions

Official sources

1. fwupd/fwupd on GitHub
2. Issues
3. License: LGPL-2.1
4. README
5. Releases