LVFS – Linux Vendor Firmware Service(fwupd.org)
fwupd.org
LVFS – Linux Vendor Firmware Service
https://fwupd.org
66 comments
blush -- my blog is https://blogs.gnome.org/hughsie/ for the important stuff, and https://mastodon.social/@hughsie is for the inane stuff.
Some firmware they may only have reduced redistribution rights to. A modern computer is a giant ball of firmware from many different vendors.
Hence things like Linux firmware updaters that just download the windows firmware file (which they have rights to) and extracting the firmware blob (which they know exactly where it is) so they can avoid the question if they can distribute the blob directly.
Hence things like Linux firmware updaters that just download the windows firmware file (which they have rights to) and extracting the firmware blob (which they know exactly where it is) so they can avoid the question if they can distribute the blob directly.
Firmware for Dell computers are also offered via the Windows update software. It’s still cool that it works with Linux too.
As a hardware developer lvfs and fwupd is amazing. It has support for all kinds of standard update protocols. So if you build a product and use a standardized update mechanism, it is super easy to get updates on lvfs.
The other thing that is great is the testing and validation groups allows you to setup target groups so you can fully validate your updates internally before staging rollouts.
Also @hughsient is really responsive at fixing issues.
We use fwupd at Framework Computer.
The other thing that is great is the testing and validation groups allows you to setup target groups so you can fully validate your updates internally before staging rollouts.
Also @hughsient is really responsive at fixing issues.
We use fwupd at Framework Computer.
This is honestly a gigantic ad for Dell and Lenovo. Looking at the vendor list substantially changed my opinion on Dell in a matter of minutes.
I just wrote in a different comment that this completely sold me on Dell.
I got a Dell laptop from work with Windows on it. Installed Ubuntu and it immediately prompted me to update the firmware. What an amazing experience!
I always recommend Dell to people looking for a Linux laptop. Although I hear Lenovo started to get their shit together too in the last few years.
I got a Dell laptop from work with Windows on it. Installed Ubuntu and it immediately prompted me to update the firmware. What an amazing experience!
I always recommend Dell to people looking for a Linux laptop. Although I hear Lenovo started to get their shit together too in the last few years.
I am using both a professional Dell latitude laptop and a personal thinkpad on Fedora and both receive firmware updates. And I am pretty sure I saw the Dell USB-C docking station receiving updates through this too.
Not sure this applies also to non Latitude/Thinkpad consumer models though but I tend to never recommend them anyway.
Not sure this applies also to non Latitude/Thinkpad consumer models though but I tend to never recommend them anyway.
I'm not a huge fan of the kind of laptops Dell sells with Linux on them (thin, poorly ventilated ultraportable donglebooks) or super loyal to the Dell brand or whatever.
However, I will say that their Linux laptops I've used have been fine executions of their concepts, and the Linux support, including for firmware updates, has been problem-free even though I don't run the stock OS.
They're a good choice for Linux laptops if thin and light ultraportables are your style.
However, I will say that their Linux laptops I've used have been fine executions of their concepts, and the Linux support, including for firmware updates, has been problem-free even though I don't run the stock OS.
They're a good choice for Linux laptops if thin and light ultraportables are your style.
Dell has a pretty good record for providing firmware updates without too much hassle. Although it does seem like they ship product with.. a lot of problems.
We bought a 10gbit enabled PowerConnect switch only to learn that the “10gbit” part didn’t actually work until they released a new firmware.
We bought a 10gbit enabled PowerConnect switch only to learn that the “10gbit” part didn’t actually work until they released a new firmware.
I use `fwupd`[0] all of the time.
Mandatory: I use arch btw :D
[0](https://wiki.archlinux.org/title/fwupd)
Mandatory: I use arch btw :D
[0](https://wiki.archlinux.org/title/fwupd)
One of the cool things about Fedora or Arch is we get to see these changes in their infancy before most are aware. This, pipewire, etc.
https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates
https://fedoraproject.org/wiki/Changes/SystemFirmwareUpdates
Fedora devs often also develop those components and are among the first to integrate them. Fedora seems like a great desktop for those curious about what's coming next to the Linux desktop stack.
NixOS doesn't curate a default desktop experience like Fedora does, but it's also a great place to enjoy some of this tech early, and in a very risk-free way thanks to declarative configuration and rollbacks. PipeWire has been effortless to set up (and impressively compatible, performance, and unobtrusive in its own right!) on NixOS for some time now.
A rolling release or a cutting edge kind of distro, even with regular releases, can be really nice if you're into exploring this stuff, like you say.
NixOS doesn't curate a default desktop experience like Fedora does, but it's also a great place to enjoy some of this tech early, and in a very risk-free way thanks to declarative configuration and rollbacks. PipeWire has been effortless to set up (and impressively compatible, performance, and unobtrusive in its own right!) on NixOS for some time now.
A rolling release or a cutting edge kind of distro, even with regular releases, can be really nice if you're into exploring this stuff, like you say.
I'm a big fan of NixOS, but sometimes it is obscenely difficult to test new things.
Example is iptables-nft. On every other distribution installing that is enough to make all applications use the nft version. In NixOS, you can easily change the environment path to iptables-nft, but any package that can modify rules won't be updated. And a package that updates rules is systemd. So attempting what is normally a 1 minute change is now recompiling every single package.
Example is iptables-nft. On every other distribution installing that is enough to make all applications use the nft version. In NixOS, you can easily change the environment path to iptables-nft, but any package that can modify rules won't be updated. And a package that updates rules is systemd. So attempting what is normally a 1 minute change is now recompiling every single package.
Yeah, it would be nice if Nixpkgs had something like Guix's grafts for replacing library dependencies like that without requiring mass rebuilds.
There, I suppose GuixSD is a stronger proposition than NixOS at the moment.
There, I suppose GuixSD is a stronger proposition than NixOS at the moment.
I mean... any distribution is like that, no? Pipewire for example has been in Debian since two releases ago. You would probably not to run it on those releases unless you were building your own up-to-date bug-fixed packages from a custom repo, but that is not out of the question especially with CI/CD being what it is nowadays.
Was it?
> Using as a substitute for PulseAudio/JACK/ALSA
> Debian 11
> As per Simon McVittie, "This is not a supported scenario for Debian 11, and is considered experimental."
(Debian Wiki, PipeWire)
In Fedora, it is default since Fedora 35 (released in 2021/11).
> Using as a substitute for PulseAudio/JACK/ALSA
> Debian 11
> As per Simon McVittie, "This is not a supported scenario for Debian 11, and is considered experimental."
(Debian Wiki, PipeWire)
In Fedora, it is default since Fedora 35 (released in 2021/11).
fwupdmgr is amazing.
It’s like a package-manager for system firmware. For the devices supported, it feels infinitely better than downloading random files from the various vendor-sites on the internet and running setup wizards and all kinds of bloated inconsistent nonsense.
I’d argue fwupdmgr actually represents something objectively done better on Linux than Windows, and my only complaint overall is that not enough vendors are supporting it.
It’s like a package-manager for system firmware. For the devices supported, it feels infinitely better than downloading random files from the various vendor-sites on the internet and running setup wizards and all kinds of bloated inconsistent nonsense.
I’d argue fwupdmgr actually represents something objectively done better on Linux than Windows, and my only complaint overall is that not enough vendors are supporting it.
Don't know much about it yet, and it is undoubtedly is a useful service. However looking at that page boasting telemetry and noticing an always running fwupd process running here as root it looks like this is probably leaking information thru its comm channel.
Does anyone know why this is running 24/7? I don't expect my firmware to be changing minute to minute. I need to get OpenSnitch running to keep an eye on these things, heard it was making it into Debian and hopefully derivatives soon.
Does anyone know why this is running 24/7? I don't expect my firmware to be changing minute to minute. I need to get OpenSnitch running to keep an eye on these things, heard it was making it into Debian and hopefully derivatives soon.
> this is probably leaking information thru its comm channel
It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.
> Does anyone know why this is running 24/7
We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.
It's really not. The fwupd process doesn't have any internet access at all -- all communication is done through a socket over DBus. All the telemetry is done with the user explicitly opting in -- we even show the JSON in the terminal that is going to be sent.
> Does anyone know why this is running 24/7
We auto-quit on idle or for low memory conditions -- unless you have hardware that's expensive (either in terms of power, or time) like thunderbolt and synaptics MST. The resident RSS is tiny as we mmap all the data files which can be paged out by the kernel -- we can even run fwupd on the tiny BMC processor as well. I'd be interested in what OpenSnitch says, but the D-Bus interface is the only way in and out. Interesting, the daemon doesn't actually do any policy actions itself; all actions have to be initiated by the front end -- which includes downloading new firmware metadata.
Good to know. Why is it a root daemon and not a command/library if other tools are directing it? If I had to guess, so the end user does not have to elevate to superuser to initiate actions?
Yes, mostly that. Depending on local policy, it might be possible to upgrade [only] signed firmware from the correct vendor without authenticating. Downgrade always requires authentication for obvious reasons. Most firmware requires you to be root (some even CAP_SYS_ADMIN) to just enumerate the hardware and read the firmware version.
The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.
The other main reasons is that some hardware is really, really slow (like 8 seconds to query a dock PD version, or 12 seconds to query a thunderbolt retimer version) and you can't really build a GUI that can do firmware update operations with potentially minutes of delay for each action. Also, cache invalidation is hard if you can't see the device uevents and usb hotplug events.
Now that I think of it, I don't want this happening without my approval/confirmation. Super password seems like a good way to gate it.
(Thought I'd seen a GUI for firmware but can't find it at the moment.)
(Thought I'd seen a GUI for firmware but can't find it at the moment.)
Oh no "leaking telemetry". Heavens.
I think what yesterday's SSD discussion revealed is that an open database of "leaked" SMART data would be of immense value to users and should have happened years ago. It sucks that privacy derangement vetoes the development of things of real value.
I think what yesterday's SSD discussion revealed is that an open database of "leaked" SMART data would be of immense value to users and should have happened years ago. It sucks that privacy derangement vetoes the development of things of real value.
> privacy derangement
Are you using this to refer to the attitude of companies that want to collect as much data as possible whether or not they have a clear and good use for it, or the attitude of users who are no longer willing to trust large-scale data collection efforts?
Are you using this to refer to the attitude of companies that want to collect as much data as possible whether or not they have a clear and good use for it, or the attitude of users who are no longer willing to trust large-scale data collection efforts?
Chances are high that lots of people here are in fact working for said companies, delivering data collection tools, so there is that…
He works (or worked) for Google, and the experience gives many of his comments a warped perspective. Which is why I'm genuinely unsure where he's trying to lay the blame for the status quo that even well-meaning telemetry efforts cannot be trusted.
I don't really get where you think the well has been poisoned by Google or any others. Telemetry projects that I am familiar with at that company, like chromeos-wide profiling, are conducted with best in the industry privacy, and they result in a significantly improved experience for users.
Big Tech does not want your stupid private data. It is in all objective respects toxic waste. But they do want to know if your CPU is overheating, or your SSD is failing early, or if your programs run slowly. Telemetry is good and valuable.
Big Tech does not want your stupid private data. It is in all objective respects toxic waste. But they do want to know if your CPU is overheating, or your SSD is failing early, or if your programs run slowly. Telemetry is good and valuable.
> Big Tech does not want your stupid private data. It is in all objective respects toxic waste.
This is so obviously contradicted by the actual behavior of Google and most other tech companies, big and small. From the inside, you may see a clear distinction between telemetry and the truly creepy amount of personal data collection happening in other parts of the company. But you should have no trouble understanding how end users are less able to draw that distinction, especially when they are not offered the choice to only opt-in to some of the data collection and "personalization".
So, do you really think that a user being suspicious of large-scale data collection means they're deranged?
This is so obviously contradicted by the actual behavior of Google and most other tech companies, big and small. From the inside, you may see a clear distinction between telemetry and the truly creepy amount of personal data collection happening in other parts of the company. But you should have no trouble understanding how end users are less able to draw that distinction, especially when they are not offered the choice to only opt-in to some of the data collection and "personalization".
So, do you really think that a user being suspicious of large-scale data collection means they're deranged?
Hate to trot out the Upton Sinclair quote again, but it's a bullseye here.
I'll decide that for myself, you insensitive clod!
I can imagine your future assault robbery trial. "But your honor, stealing his wallet was good for him! Couldn't get into the bar that night and gave his liver a well-needed break." :-D
I can imagine your future assault robbery trial. "But your honor, stealing his wallet was good for him! Couldn't get into the bar that night and gave his liver a well-needed break." :-D
[deleted]
On the bright side, you can finally mask it in latest Fedora without Software store going haywire and spamming you with useless error messages about it being unavailable.
Still waiting for that to arrive in next Debian…
I’m sure it’s useful to Dell users, but not much to anyone with DIY setups.
Still waiting for that to arrive in next Debian…
I’m sure it’s useful to Dell users, but not much to anyone with DIY setups.
> Still waiting for that to arrive in next Debian…
This is the second comment I've noticed "waiting for it to hit Debian" and I don't understand.
This is the second comment I've noticed "waiting for it to hit Debian" and I don't understand.
hbarta@olive:~$ apt-cache policy fwupd
fwupd:
Installed: 1.5.7-4
Candidate: 1.5.7-4
Version table:
\*\* 1.5.7-4 500
500 http://deb.debian.org/debian bullseye/main amd64
Packages
100 /var/lib/dpkg/status
hbarta@olive:~$
Sorry, I should’ve worded it better.
I’m waiting for fixes to Software center, so that there are no visible side effects after masking fwupd. I do know this was addressed in or before Fedora 37, but is an issue in current Debian stable.
The only time I saw fwupd itself working is when it attempted to update uefi firmware in my VM :)
I’m waiting for fixes to Software center, so that there are no visible side effects after masking fwupd. I do know this was addressed in or before Fedora 37, but is an issue in current Debian stable.
The only time I saw fwupd itself working is when it attempted to update uefi firmware in my VM :)
I actually did not know this existed. Found the project after all the Samsung SSD talk.
Unfortunately it doesn't seem like Samsung is uploading that much firmware. "Is uploading firmware on behalf of other vendors" according to the site.
Unfortunately it doesn't seem like Samsung is uploading that much firmware. "Is uploading firmware on behalf of other vendors" according to the site.
Make sure you open a support ticket asking for LVFS updates -- it's easy to ignore one person, but much harder to ignore hundreds of people asking for the same thing.
That is a good point, will do!
With most things I just complain a bit and then go on with my life, but this actually feels like it could work. Samsung does already release some sort of broken Linux livecd for fw updates, seems like LVFS would be easier for everyone.
With most things I just complain a bit and then go on with my life, but this actually feels like it could work. Samsung does already release some sort of broken Linux livecd for fw updates, seems like LVFS would be easier for everyone.
Samsung actually upload firmware to the LVFS on behalf of a few different OEMs, so they certainly know how. It's a policy decision, not a technical or legal one.
Some wikis for firmware updates of things not supported by LVFS:
https://wiki.debian.org/Firmware/Updates https://help.ubuntu.com/community/BIOSUpdate https://wiki.gentoo.org/wiki/BIOS_Update https://en.opensuse.org/SDB:How_update_your_bios https://wiki.archlinux.org/index.php/Flashing_BIOS_from_Linu...
https://wiki.debian.org/Firmware/Updates https://help.ubuntu.com/community/BIOSUpdate https://wiki.gentoo.org/wiki/BIOS_Update https://en.opensuse.org/SDB:How_update_your_bios https://wiki.archlinux.org/index.php/Flashing_BIOS_from_Linu...
I wish some more of this firmware was open source with reproducible builds, built using a toolchain that is also open source with reproducible builds.
https://wiki.debian.org/Firmware/Open
https://wiki.debian.org/Firmware/Open
As mentioned, I did not know this exists either, but I wonder what they consider a "Major Linux Distro" ?
> This site is used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME Software.
Based upon that statement and the fact fwupdmgr does not come with Slackware, maybe major equates to GNOME Based ?
But with some extra work, looks like this could be useful for non-GNOME distros.
> This site is used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME Software.
Based upon that statement and the fact fwupdmgr does not come with Slackware, maybe major equates to GNOME Based ?
But with some extra work, looks like this could be useful for non-GNOME distros.
Is Slackware a major Linux distribution? There's nothing wrong with Slackware, and no reason why fwupd wouldn't work on that distro -- but it's not one that most people would considered "major" IMHO. There are no GNOME deps on fwupd, although there are a couple of GNOME frontends available -- as there is also a CLI and KDE frontend.
Slackware is the oldest active Linux distribution.
Older doesn't mean major though.
As someone who has never used Slackware, I think Slackware is important, whether or not it's 'major'.
Subjective. Debatable.
"Major" = RHEL, Fedora, Ubuntu, Debian, perhaps also Arch.
Slackware is niche, sorry.
Slackware is niche, sorry.
Not niche enough, AFAICT
https://slackbuilds.org/repository/15.0/system/fwupd/
https://slackbuilds.org/repository/15.0/system/fwupd/
fwupd is available on quite a few niche distros, including NixOS, GuixSD, Void Linux, Gentoo, and also, of course, Slackware.
Also I feel that openSUSE qualifies as a major distro despite not appearing on that list!
Also I feel that openSUSE qualifies as a major distro despite not appearing on that list!
fwupd has nothing to do with gnome. It's a cli program and library. That library can be integrated with guis, but it works standalone.
I wouldn't take it too literally, rather it's just a way of marketing its popularity.
Is there an alternative organization that gathers firmware that ends up on Slackware? If so, then sure there is an argument to be made that companies need to pay attention to both and one shouldn't be claiming to be fully authoritative. But if not, then progress would be Slack getting firmware updates from here, if the distro is interested in such things.
Is there an alternative organization that gathers firmware that ends up on Slackware? If so, then sure there is an argument to be made that companies need to pay attention to both and one shouldn't be claiming to be fully authoritative. But if not, then progress would be Slack getting firmware updates from here, if the distro is interested in such things.
Yeah I worry if you change that statement and put an asterisk like "most major distros", vendors might take it less seriously. It does sort of set you up for a no true Scotsman discussion, though.
Also Slackware does have fwupd, at least in its "SlackBuilds" system where a lot of optional packages end up AFAICT.
Also Slackware does have fwupd, at least in its "SlackBuilds" system where a lot of optional packages end up AFAICT.
I looked into fwupd once... it sounds nice to be able to update through a central service, but then it devolved into a rabbit hole of turning on all the privacy bugs I had previously disabled on my laptop. Why any of that is part of a firmware updater, I don't know.
> it devolved into a rabbit hole of turning on all the privacy bugs
What does that mean? We've got a very comprehensive privacy policy... https://lvfs.readthedocs.io/en/latest/privacy.html
What does that mean? We've got a very comprehensive privacy policy... https://lvfs.readthedocs.io/en/latest/privacy.html
I mean all of this junk (not my screenshot - my laptop is much worse) https://blogs.gnome.org/hughsie/files/2020/10/Screenshot-fro...
You're going to have to be more specific on why a failing HSI attribute contributes to the undoing of your privacy? You're aware the security attributes are each based on mitigating actual real-world attacks, right?
You're aware that ME itself is considered a security hole, and that a lot of people disabled it, right? Not to mention, most of the hsi2 and 3 stuff need ME as a dependency?
Edit: again, why is this any part of a firmware updater?
Edit2: this doesn't even get into unsigned kernels, out of tree modules, and unencrypted swaps (or at least not encrypted in the special way fwupd wants them to be)
Edit: again, why is this any part of a firmware updater?
Edit2: this doesn't even get into unsigned kernels, out of tree modules, and unencrypted swaps (or at least not encrypted in the special way fwupd wants them to be)
I feel I must apologize, but my first experience with fwupd was switching from MATE to KDE, opening kinfocenter and seeing all of this... While some of this is a KDE problem, I don't even see a place to update said firmware without using the CLI.
LVFS is one of those things that makes modern Linux feel so civilized. Browsing around for images (or God forbid, images distributed as Windows executables) to burn to external media for firmware updates feel downright prehistoric in comparison!
I just wish this existed for drivers.
It's really nice to read the author's blogposts describing how he forces hardware vendors to get their shit together and either use a standardized update mechanism or create a thoroughly tested open source plugin.
I remember the first time I got a Dell laptop and put Ubuntu on it, GNOME Software immediately prompted me to install a firmware update. I was so amazed by this. It really felt like Ubuntu was finally a first-class citizen. I'm still completely sold on Dell because of this experience. Sadly they still don't upload all the firmware for all machines. I have no idea why though..