Richard Hughes announced on August 4 that NVIDIA is now a premier sponsor of the Linux Vendor Firmware Service, which makes it the fourth hardware vendor at that tier alongside Dell, Lenovo and HP. The immediate practical change is small: DGX Spark firmware is being distributed through fwupd. The structural change is larger, and it is the one Hughes chose to lead with, because four sponsoring OEMs is the number the project set as its funding target last year. If you have ever wondered why firmware updates on Linux work beautifully on some machines and not at all on others, this is the machinery that decides it.
The short answer
NVIDIA has become a premier sponsor of the Linux Vendor Firmware Service, joining Dell, Lenovo and HP. Richard Hughes, who maintains LVFS and fwupd at Red Hat, announced it on August 4 and framed it as reaching the funding target the project set for itself last year. DGX Spark firmware is already being distributed through fwupd. Vera Rubin servers are the expected next step, and graphics card firmware is a possibility rather than a commitment.
Most infrastructure news announces a feature. This one announces a budget line, and it is the more interesting of the two.
On August 4, Richard Hughes published a short post titled "NVIDIA is now supporting the LVFS". The substance is that NVIDIA has signed on as a premier sponsor of the Linux Vendor Firmware Service, and that DGX Spark firmware is being rolled out through fwupd. Hughes then said the part that matters most to anyone who depends on this plumbing: "This now takes us to 4 OEMs sponsoring LVFS, which means we've successfully reached the funding target we set for ourselves last year."
Why the funding sentence is the story
fwupd is not a struggling project in the engineering sense. It works, it is shipped by every mainstream distribution, and on well supported hardware it turns firmware updating from a Windows-only errand into a command you run without thinking about it.
What has always been thin is everything around that. Someone has to run the hosted service, keep the signing infrastructure honest, review vendor submissions, and maintain the protocol plugins for a hardware landscape that expands every year. That work has been carried by a very small number of people, principally Hughes at Red Hat, on a funding base that never matched how much of the Linux hardware ecosystem quietly depends on it.
Phoronix puts the premier tier at 100,000 dollars a year or more. Four vendors at that level is not a large sum in absolute terms. It is a large change in the odds that this service is still running, and still staffed, in five years.
What NVIDIA is actually shipping
Be precise about the device list, because it is short.
DGX Spark, the desktop sized system NVIDIA sells for local model development, is the product confirmed as distributing firmware through the service today. Phoronix reports that Vera Rubin servers are anticipated to follow, and raises graphics card firmware as a possibility. Those two are expectations, not announcements, and we would not plan around them.
That is a normal shape for LVFS onboarding. Enrolling hardware is per product: the vendor builds a firmware package, signs it, writes the metadata that says which device identifiers it applies to, and tests the update path. A sponsorship funds the service and signals commitment. It does not retroactively enroll a catalogue.
Check your own coverage before you assume it
The practical follow up is not to wait for NVIDIA, it is to find out what your existing fleet can already do. Coverage on Linux tracks the vendor and the model, not the distribution, and most people are surprised in both directions when they actually look.
The device list is the interesting output. It shows you not just the machine's own system firmware but Thunderbolt controllers, docks, SSD controllers and anything else exposing an update path fwupd understands. Devices that report as updatable are inside the LVFS world. Devices that appear with no update capability are visible but unreachable, almost always because the vendor never enrolled them.
What we would do
Let metadata refresh run on a schedule, keep the applying part deliberate.
Firmware is the one category of update where a bad outcome is a machine that does not boot and a recovery procedure that involves walking to it. We are happy for fwupdmgr refresh to run unattended so the metadata is never stale. We are not happy for updates to apply themselves across a fleet at three in the morning. Review what is offered, apply to one machine per hardware model, wait, then continue.
That is a boring policy, and the news here makes it more useful rather than less. A firmware distribution service with four funded OEMs behind it is one you can build a policy on top of. That is a better position than the ecosystem has been in for most of the last decade.
Sources and further reading
- NVIDIA is now supporting the LVFS, Richard Hughes, GNOME blog, August 4, 2026
- NVIDIA becomes a premier sponsor of LVFS / fwupd, Phoronix, August 4, 2026
- The Linux Vendor Firmware Service
- fwupd source and documentation on GitHub
Frequently asked questions
What is the difference between LVFS and fwupd?
They are two halves of one system and the names get used interchangeably, which causes confusion. fwupd is the daemon running on your machine. It knows how to talk to the update mechanisms your hardware exposes, UEFI capsule updates, Thunderbolt controllers, dock firmware, SSD controllers, and it is what actually writes the new firmware. The LVFS, the Linux Vendor Firmware Service, is the hosted side: a repository where vendors upload signed firmware and the metadata describing which devices it applies to. Vendors push to the LVFS, fwupd pulls from it. Neither is useful without the other, and both are maintained largely by Richard Hughes at Red Hat, which is precisely why the sponsorship question matters.
Does this mean my NVIDIA graphics card will get firmware updates through fwupd?
Not today. The device confirmed as shipping firmware through the service is the DGX Spark, the desktop sized system NVIDIA sells for local model work. Phoronix notes that Vera Rubin servers are the expected next step and that graphics card firmware is a possibility rather than an announcement. We would treat consumer GPU firmware as unconfirmed. It is worth understanding why the distinction exists: a vendor has to build, sign and validate a firmware package for every device it enrolls, and that work is per product line. Becoming a sponsor signals intent and funds the infrastructure, but it does not retroactively enroll a catalogue.
How do I find out whether my own machines are covered?
Run fwupdmgr get-devices on a machine and read the output rather than skimming it. Every device fwupd can see is listed, and each one tells you whether it has an update mechanism it can drive. Devices that report as updatable are the ones the LVFS can reach. Devices listed with no update capability are visible but out of scope, usually because the vendor never enrolled them or the hardware exposes no safe update path. On a fleet, the useful move is to run that across a representative machine from each hardware generation you own, because coverage tracks the vendor and the model, not the distribution you installed.
Why does a sponsorship announcement deserve attention at all?
Because the failure mode of this project has never been technical. fwupd works. The reason firmware updates are inconsistent on Linux is that enrolling hardware requires sustained vendor participation, and the service that hosts it has been running on a funding base far thinner than its importance to the ecosystem. Hughes framed the NVIDIA news as reaching the target set last year, which tells you the target was about sustainability rather than expansion. For anyone maintaining Linux hardware at scale, a firmware distribution service that is not one maintainer away from collapse is worth more than most feature releases.
Is it safe to apply firmware updates through fwupd automatically?
We do not run them unattended on anything that matters, and that is a preference about blast radius rather than a criticism of the tooling. Firmware updates are the one class of update that can leave a machine unable to boot, and the recovery path is physical. Our habit is to let fwupdmgr refresh run automatically so metadata stays current, then review what fwupdmgr get-updates reports and apply deliberately, starting with one machine per hardware model before the rest of the fleet. On laptops, check that the machine is on mains power first, since fwupd will refuse some updates on battery and that refusal is there for a reason.