Firmware updates rarely get the attention they deserve. Most administrators obsess over kernel patches, package upgrades, and application-layer security, yet the layer sitting underneath the operating system — BIOS/UEFI, SSD controllers, Thunderbolt docks, network interface cards — often goes untouched for years. That neglect isn’t laziness; it’s friction. Flashing firmware manually has historically meant downloading vendor ISOs, burning USB sticks, rebooting into DOS-like utilities, and praying nothing goes wrong mid-flash.

fwupd changed that equation entirely. It’s the daemon that powers the Linux Vendor Firmware Service (LVFS), letting you check, download, and apply firmware updates the same way you’d run a routine package upgrade. On Fedora 44, fwupd is deeply integrated into the base system — GNOME Software even surfaces firmware updates automatically — but that doesn’t mean every installation ships with a fully functional setup out of the box, especially on minimal server builds, headless installations, or custom spins used in production environments.

This guide walks through installing fwupd on Fedora 44 from scratch, verifying the daemon is actually running (not just installed), and using fwupdmgr to manage updates safely. It also covers the edge cases that trip people up — services that report “already installed” but never start, systemd unit quirks, and situations where your hardware simply isn’t supported by LVFS. Whether you’re managing a fleet of Fedora workstations, a lab of bare-metal servers, or a single laptop you actually care about, the workflow below reflects what actually happens in production, not just what the man page says.

Why Firmware Updates Matter More Than You Think

Firmware sits below the kernel, which means kernel-level security mitigations can’t protect against a compromised or buggy firmware layer. Spectre and Meltdown mitigations, for instance, required microcode updates delivered partly through firmware channels. SSDs with known data-corruption bugs, NICs with power-management firmware issues that cause random link drops under load, and laptops with battery-charging firmware defects are all real-world cases where a firmware update — not a software patch — was the actual fix.

There’s also a performance angle that gets overlooked. Firmware controls low-level power states, thermal throttling curves, and in some cases, disk I/O scheduling at the controller level. An outdated SSD firmware revision can silently cap write throughput or mishandle TRIM commands, leading to gradual performance degradation that looks like a software problem but isn’t. On servers running heavy I/O workloads, this is the kind of thing that eats a Friday afternoon before someone finally checks fwupdmgr get-devices and finds a two-year-old firmware version sitting untouched.

What Exactly Is Fwupd?

fwupd is a background daemon written by Richard Hughes and maintained as part of the broader LVFS ecosystem, designed to update device firmware on Linux without requiring a reboot into vendor-specific tools. It communicates over D-Bus, exposes a CLI tool called fwupdmgr, and pulls signed firmware metadata from cdn.fwupd.org — the public mirror for LVFS content.

Under the hood, fwupd supports a surprising range of hardware: UEFI system firmware, Thunderbolt controllers, Logitech peripherals connected via Unifying receivers, NVMe SSDs from vendors like Samsung and Western Digital, and even some managed network switches. Not every device vendor participates in LVFS, so don’t be surprised if fwupdmgr get-devices lists your hardware but shows no updates — that’s a vendor participation gap, not a bug in fwupd itself.

Pre-Installation Checklist

Before running a single command, it’s worth confirming a few things. Skipping this step is exactly how people end up filing bug reports for issues that are actually configuration mismatches.

• Confirm you’re running Fedora 44 with cat /etc/fedora-release, since package versions and default service states shift between releases.
• Check whether fwupd is already present — on Fedora, it typically ships as part of the default Workstation install, but Server and minimal Cloud images often exclude it.
• Verify UEFI boot mode with [ -d /sys/firmware/efi ] && echo "UEFI" || echo "Legacy BIOS", since many firmware update types (system firmware especially) require UEFI.
• Make sure you have a stable power source if working on a laptop — firmware flashing during a battery cutoff is one of the few scenarios that can genuinely brick hardware.

Step-by-Step: Installing Fwupd on Fedora 44

Step 1: Check If Fwupd Is Already Installed

Run this first, always:

rpm -q fwupd

If it returns a version string like fwupd-2.0.16-1.fc44, it’s already present. If it returns “package fwupd is not installed,” move to the next step. Don’t assume — Fedora’s minimal Server edition and many cloud images strip out desktop-adjacent packages like this one to keep image size down.

Step 2: Install the Package via DNF

sudo dnf install fwupd

DNF will resolve dependencies automatically, pulling in libfwupd, libxmlb, and other shared libraries fwupd relies on for parsing firmware metadata. On a typical Fedora 44 install with a decent connection, this takes under a minute. If you’re behind a corporate proxy or a restrictive firewall, make sure outbound HTTPS to Fedora’s mirror network and to cdn.fwupd.org is permitted — fwupd needs both to function correctly later.

Step 3: Enable and Start the Service

Installing the package does not automatically start the daemon. This is the step people skip, then wonder why fwupdmgr commands hang or error out.

sudo systemctl enable --now fwupd.service

The --now flag both enables the unit for future boots and starts it immediately, saving a second command. Confirm it’s actually active:

systemctl status fwupd.service

You want to see active (running) in the output. If it shows inactive (dead) with no errors, that’s usually fine too — fwupd is designed to be socket-activated in some configurations, meaning it starts on-demand when fwupdmgr is invoked rather than running persistently in the background.

Step 4: Refresh Firmware Metadata

sudo fwupdmgr refresh

This pulls the latest signed metadata catalog from LVFS, which fwupd uses to match your hardware against available updates. The first run downloads a GPG-signed XML manifest and validates the signature before caching it locally — this is important from a security standpoint, since it means malicious or tampered metadata gets rejected before it ever reaches your update logic.

Step 5: List Detected Devices

fwupdmgr get-devices

This enumerates every device fwupd can see and manage — UEFI firmware, SSDs, docks, whatever the daemon has drivers for. Some devices will show a firmware version and vendor; others will show “Not Updatable,” which typically means the vendor hasn’t submitted firmware to LVFS or the device lacks a supported update protocol.

Step 6: Check for Available Updates

fwupdmgr get-updates

If updates exist, you’ll see the device name, current version, and available version listed side by side. This is a read-only operation — nothing gets downloaded or applied yet, which makes it safe to run on a schedule via cron or a systemd timer for auditing purposes.

Step 7: Apply Updates

sudo fwupdmgr update

This downloads the firmware payload, verifies its cryptographic signature, and applies it. Some updates apply live; others require a reboot to complete, and fwupd will tell you explicitly which category you’re dealing with. UEFI capsule updates, for example, almost always need a reboot because the actual flash happens during the next boot sequence, before the OS even loads.

Alternative Installation Methods

DNF isn’t the only path, and depending on your environment, you might prefer one of these instead.

Snap package: Fedora 44 is listed as a supported target for the fwupd snap, which some administrators prefer when they want a version newer than what’s in Fedora’s stable repos.

sudo dnf install snapd
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install fwupd

Note the symlink step — without it, classic snap confinement won’t resolve paths correctly on Fedora.

Copr repository: For bleeding-edge builds straight from upstream maintainer Richard Hughes, the Copr repo is the go-to option, particularly useful when you need a fix that hasn’t landed in Fedora stable yet.

sudo dnf copr enable rhughes/fwupd
sudo dnf install fwupd

Use Copr with caution on production machines — it’s explicitly unsupported by Fedora QA and can introduce version mismatches with system libraries.

Container image: For CI pipelines or isolated testing, an official OCI container image is published and can be pulled directly.

docker pull ghcr.io/fwupd/fwupd-fedora:latest

Fwupd on Other Distributions (Ubuntu, Debian, CentOS/AlmaLinux)

Since infrastructure teams rarely run a single distro across their fleet, here’s the equivalent install flow elsewhere.

The core workflow — install, enable service, refresh metadata, check updates, apply — is identical across all of these. Only the package manager syntax changes, which is one of fwupd’s underrated strengths as a cross-distro standard.

Troubleshooting Common Fwupd Issues

“The unit files have no installation config” warning

This message appears when running systemctl enable --now fwupd.service on some Fedora configurations, and it confused a fair number of users on the Fedora Discussion forums. It’s largely benign — it means the unit relies on socket or D-Bus activation rather than a traditional WantedBy= target, so systemd is just noting that “enable” doesn’t have much to persist. The daemon still starts and functions correctly via fwupdmgr.

Fwupd reports “already installed” but the service won’t start

If dnf install fwupd says the package is present, but systemctl status fwupd.service shows nothing running, don’t fight the service directly. Instead, run any fwupdmgr command — fwupd is D-Bus activated in many configurations, meaning the daemon spins up on-demand rather than sitting resident. Trying to force a persistent running state when it’s designed for on-demand activation is chasing a non-problem.

“Failed to refresh: unable to connect” errors

This is almost always a network or firewall issue, not a fwupd bug. Check outbound HTTPS access:

curl -I https://cdn.fwupd.org/downloads/firmware.xml.gz

If this fails, look at proxy environment variables, corporate SSL inspection breaking certificate validation, or an overly aggressive egress firewall rule blocking the CDN’s IP range.

No devices show updatable firmware

Run fwupdmgr get-devices --show-all-devices to see the full device list including non-updatable hardware, which sometimes reveals fwupd detected the device but flagged it as unsupported rather than simply invisible. This distinction matters when you’re auditing whether fwupd itself is misconfigured versus whether the hardware genuinely lacks LVFS support.

Update downloads but installation hangs

Certain UEFI capsule updates require specific ESP (EFI System Partition) space and permissions. Check available space with df -h /boot/efi — a full ESP partition is a surprisingly common cause of stalled firmware installs that never surface a clear error message.

Security Considerations

Firmware updates operate with more system trust than almost anything else you’ll run, so treat the update pipeline with the same scrutiny as a package repository. fwupd validates GPG signatures on both the metadata catalog and the firmware payloads themselves before applying anything, which is the primary defense against tampered updates. Don’t disable signature verification even temporarily, no matter how tempting it is during a debugging session.

Restrict who can invoke fwupdmgr update on shared or multi-admin systems using sudoers policies scoped specifically to that binary, rather than granting broad sudo access. On systems with Secure Boot enabled, verify that fwupd’s UEFI capsule updates remain compatible — some third-party firmware submissions to LVFS aren’t Secure Boot signed, and applying them can trigger a boot chain-of-trust failure that’s painful to diagnose remotely.

Firewall rules matter here too. If your organization enforces strict egress filtering, whitelist cdn.fwupd.org explicitly rather than opening broad outbound HTTPS, keeping the firmware update channel auditable and narrow.

Performance and Optimization Tips

Firmware refresh operations are lightweight on CPU and RAM — the daemon idles at near-zero resource usage when not actively checking or applying updates. The heavier resource consumer is disk I/O during an actual firmware flash, particularly for NVMe controller updates, which briefly saturate the storage bus. Schedule these during low-traffic windows on production systems, the same way you’d schedule a kernel update reboot.

For fleets running scheduled fwupdmgr refresh via cron or systemd timers, stagger the schedule across machines rather than firing simultaneously — hitting the LVFS CDN with hundreds of synchronized requests at the top of every hour is unnecessary load you can avoid with basic jitter in your scheduling logic.

Network-wise, metadata refreshes are small (a few hundred KB), but actual firmware payloads for UEFI system firmware can run into tens of megabytes. On bandwidth-constrained remote sites, consider a local LVFS metadata mirror rather than every machine pulling independently from the public CDN.