Actionable Item: Integrate fwupd (pulled from repo due to lack of integration points) in various tools and software in Solus. The should likely be:
Description
Description
Revisions and Commits
Revisions and Commits
| D1503 Initial inclusion of fwupd | |||
| R4064 fwupd | |||
| R4064:77d71f15f613 Initial inclusion of fwupd | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | None | T2532 Package & Integrate fwupd | ||
| Resolved | ikey | T2675 Update appstream-glib to 0.6.11 |
Event Timeline
There are a very large number of changes, so older changes are hidden. Show Older Changes
Comment Actions
Yesterday, 20.08.2018 I noticed an interesting info: "The Next Challenge For Fwupd / LVFS Is Supporting NVMe SSD Firmware Updates". Shortly said, Richard Hughes at Red Hat is hoping for Linux users with NVMe drives to send him the id-ctrl identification data on their drives - this data will be useful so he knows what drives/models are most popular but also for how the firmware revision string is advertised across drives and vendors:
https://blogs.gnome.org/hughsie/2018/08/17/nvme-firmware-i-need-your-data/
I followed the instructions. Can you please confirm that all went ok:
solus@user ~ $ sudo nvme id-ctrl --raw-binary /dev/nvme0 > /tmp/id-ctrl
Password:
solus@user ~ $ curl -F type=nvme \-F "machine_id="`cat /etc/machine-id` \ -F file=@/tmp/id-ctrl \ https://staging.fwupd.org/lvfs/upload_hwinfo{
"success": true}solus@user ~ $
Comment Actions
FYI the upload is failing
cat /etc/machine-id` \
-F file=@/tmp/id-ctrl \
https://staging.fwupd.org/lvfs/upload_hwinfo
<!DOCTYPE html>
<!-- Copyright (C) 2018 Richard Hughes <richard@hughsie.com>
Licensed under the GNU General Public License Version 2 -->
<html lang="en">
<head>
<title>LVFS: Temporarily Unavailable</title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8"/>
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/4.0.0-beta.2/css/bootstrap.min.css" integrity="sha384-PsH8R72JQ3SOdhVi3uxftmaW6Vc51MKb0q5P2rRUpPvrszuE4W1povHYgTpBfshb" crossorigin="anonymous">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
<body>
<div class="container mt-3">
<div class="container mt-3">
<div class="alert alert-warning" role="alert">
The LVFS is temporarily unavailable and should be back soon.
</div>
</div>
</div>
</body>
</html>Comment Actions
Any updates on fwupd its badly needed for folks like me who have purchase laptops like X1 Carbon 6th gen and have battery drain issues during sleep
Comment Actions
I wanted to give it another try because I also really need this and I noticed that Clear Linux already has a package for it, which means that clr-boot-manager must be compatible.
TL;DR: I just updated the ME firmware of my T480s successfully.
The package still needs some polish (as I have basically no knowledge of DBus, polkit & stuff like that), but it's working fine. The only problem I see is that we don't mount the EFI partition which means the user has to do it himself when he wants to update BIOS/firmware. Any ideas on that? Maybe someone can help me with that, see D5647.
Comment Actions
The only problem I see is that we don't mount the EFI partition which means the user has to do it himself when he wants to update BIOS/firmware.
That's what ikey meant by fwupd needs managing by clr-boot-manager.
Comment Actions
Ah, you're probably right. However I wouldn't consider this a blocker because there are lots of updates that don't require the EFI partition and it's possible to make it run without clr-boot-manager integration. Also it doesn't seem like there is much development on that front.
Comment Actions
It looks like the Clear Linux team is no longer interested in integrating this into clr-boot-manager. If all that needed, is to mount the /boot partition before running fwupd, maybe we could consider integrating this with eopkg for the time being, and then sol later on.
Comment Actions
Indeed :(
If all that needed, is to mount the /boot partition before running fwupd, maybe we could consider integrating this with eopkg for the time being, and then sol later on.
Can someone else confirm if that's a viable solution for Solus?
Comment Actions
Apparently tss2-esys from tpm2-tss is now required to compile xmlb, one of fwupd's dependencies.
Comment Actions
Any updates here? IT would be a great move foreward to more kind of "bare-metal security" in solus.
Need any more reasons? Here => https://www.bleepingcomputer.com/news/security/intel-patched-77-vulnerabilities-in-november-2019-platform-update/
Comment Actions
@Solus_BLN Stop spreading FUD. fwupd is not a requirement for updating firmware. You can do this using the manufacturer provided tools for your motherboard. We also provide updated microcode from Intel and other firmware from linux-firmware over at kernel.org. TSX is disabled in the kernel and we don't support BMC as this is a desktop OS.
Comment Actions
Sorry about that folks, seems we had a random user being abusive for seemingly no reason.
Comment Actions
If all that needed, is to mount the /boot partition before running fwupd, maybe we could consider integrating this with eopkg for the time being, and then sol later on.
Alternative solution: add an executable to the fwupd package that mounts /boot and put in in the ExecPre for the service. This allows fwupd to be a standalone service that can be used on the command line. Integration with the Software Center (which imho should be the only integration point) can then be done at a later time.
The executable, of course, could also be a clr-boot-manager command, which should be easy enough to contribute.
Comment Actions
I have a working fwupd integrated with clr-boot-manager based on my previous comment. The changes are fairly minimal:
- A mount-boot command and service for clr-boot-manager (changes). This can probably be contributed upstream.
- A 2-line patch adding a dependency on clr-boot-manager-mount-boot.service for fwupd.service.
@kyrios123, @JoshStrobl: is this sufficient integration to get fwupd back in the repo?
Comment Actions
It is going to be very exciting to hopefully see those patches landing @silke. I think I remember seeing a differential revision opened here for integrating it, but I can't seem to find it any more. Am I remembering incorrectly or is it just very hard to find?
Comment Actions
@Jacalz I haven't posted a differential, as I'm waiting on a go-ahead from @JoshStrobl. It is on his to-do list afaik, so we'll just have to be patient :)
Comment Actions
@silke Thank you. Looks like I am remembering incorrectly then. Looking forward to seeing one posted :)
Comment Actions
There is no update there, nothing changed. Last post was from 31 Jan 2020 an basically reaffirmed their position from 8 May 2019 which had already been linked too.
We don't need updates that tell us that nothing has changed.
Comment Actions
Just wandering if any progress can be made here.
I personally installed the snap version and was able to update my bios with fwupdmgr. The snap version is not perfect as it displays errors about missing libraries so a native package would be a plus, even without clr-boot-manager integration.
Comment Actions
Let's get all the packaging stuff landed (at least with the patches on phab) then we can figure out how to integrate it into the upgrade process. Consider the packaging progress part up for grabs.
Comment Actions
I could not agree more. If things are not ready or are undecided, then they do not yet need t be deployed, but at least the foundations should be prepared on Phabricator and then figure out how to work on top of them.
Comment Actions
I did a quick check and I think those buildeps must be added:
- gcab-devel
- libgnutls (instead of gnutls)
Compile cannot be completed a this time as fwup (https://github.com/fwup-home/fwup) is a dependency.
Comment Actions
Both of those are present: pkgconfig(libgcab-1.0) (i.e. gcab-devel) and pkgconfig(gnutls) (i.e. libgnutls-devel).
Compile cannot be completed a this time as fwup (https://github.com/fwup-home/fwup) is a dependency.
I don't see fwup as a dependency of fwupd, and it builds fine for me. What compilation errors do you see?
Comment Actions
I cloned this repo: https://dev.getsol.us/source/fwupd.git and this is what I get on first compile test:
me master ~ git fwupd make make build make[1] : on entre dans le répertoire « /home/me/git/fwupd » sudo solbuild build package.yml -p unstable-x86_64; Updating repositories Updating repository: Solus eopkg-index.xml.xz.sha1sum (40.0 B)100% 0.00 --/- [--:--:--] [complete] Solus repository information is up-to-date. No packages to upgrade. The following package(s) are already installed and are not going to be installed again: abi-wizard iproute2 sccache No packages to install. The following package(s) are already installed and are not going to be installed again: autoconf automake bash-completion-devel binutils bison catbox cmake dbus-devel diffstat diffutils expat-devel fakeroot file-devel flex flex-devel g++ gcc gfortran glibc-devel gmp-devel gobject-introspection-devel intltool libarchive-bin libffi-devel libgpg-error-devel libgudev-devel libtool-devel libxml2-devel linux-headers m4 make meson mpc-devel mpfr-devel nano nanorc nasm ncurses-devel openssl-11-devel openssl-devel pam-devel patch pkg-config polkit-devel python-devel quilt readline-devel systemd-devel texinfo util-linux-devel ypkg zlib-devel No packages to install. [BuildDep] Checking build-deps for fwupd-1.0.5-1 [pkgconfig:fwup] This dependency is not in any repo [BuildDep] pkgconfig(fwup) build dep does not exist in the repository. ? Failed to build packages make[1]: *** [../Makefile.common:26 : build] Erreur 1 make[1] : on quitte le répertoire « /home/me/git/fwupd » make: *** [../Makefile.common:11 : complete] Erreur 2
Comment Actions
It looks like you haven't applied D13506, also don't forget to build the dependencies first!
Comment Actions
Good to know :)
Now I have this error:
ERROR:../src/fu-self-test.c:3997:fu_firmware_builder_process_func: assertion failed (error == NULL): failed to build firmware: bwrap: No permissions to creating new namespace, likely because the kernel does not allow non-privileged user namespaces. On e.g. debian this can be enabled with 'sysctl kernel.unprivileged_userns_clone=1'. (FwupdError, 0)
Comment Actions
Strange, AFAIK Solus doesn't disable unprivileged user namespaces. Can you execute unshare -U true as your user?