Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ship fwupd #449

Closed
cgwalters opened this issue Apr 3, 2020 · 38 comments
Closed

ship fwupd #449

cgwalters opened this issue Apr 3, 2020 · 38 comments

Comments

@cgwalters
Copy link
Member

cgwalters commented Apr 3, 2020

A lot of work has gone into fwupd - it's important to apply firmware updates too.

But it looks like their dependency set is pretty broken from our PoV:

# rpm-ostree install fwupd
Checking out tree 436592e... done
Enabled rpm-md repositories: updates fedora
Updating metadata for 'updates'... done
rpm-md repo 'updates'; generated: 2020-04-02T08:34:19Z
Updating metadata for 'fedora'... done
rpm-md repo 'fedora'; generated: 2019-10-23T22:52:47Z
Importing rpm-md... done
Resolving dependencies... done
Will download: 32 packages (19.6?MB)
Downloading from 'updates'... done
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Added:
  ModemManager-glib-1.10.6-2.fc31.x86_64
  abattis-cantarell-fonts-0.111-3.fc31.noarch
  adobe-source-code-pro-fonts-2.030.1.050-7.fc31.noarch
  dmidecode-1:3.2-3.fc31.x86_64
  flashrom-1.2-2.fc31.x86_64
  fonts-filesystem-2.0.3-1.fc31.noarch
  fwupd-1.3.9-2.fc31.x86_64
  gdbm-libs-1:1.18.1-1.fc31.x86_64
  glib-networking-2.62.3-1.fc31.x86_64
  gsettings-desktop-schemas-3.34.0-1.fc31.x86_64
  libftdi-1.3-17.fc31.x86_64
  libgcab1-1.1-7.fc31.x86_64
  libgudev-232-6.fc31.x86_64
  libgusb-0.3.4-1.fc31.x86_64
  libmbim-1.20.0-1.fc31.x86_64
  libmodman-2.0.1-20.fc31.x86_64
  libproxy-0.4.15-14.fc31.x86_64
  libqmi-1.24.0-1.fc31.x86_64
  libsmbios-2.4.2-4.fc31.x86_64
  libsoup-2.68.4-1.fc31.x86_64
  libxcrypt-compat-4.4.15-1.fc31.x86_64
  libxmlb-0.1.14-1.fc31.x86_64
  pciutils-libs-3.6.4-1.fc31.x86_64
  python-pip-wheel-19.1.1-7.fc31.noarch
  python-setuptools-wheel-41.6.0-1.fc31.noarch
  python-unversioned-command-3.7.6-2.fc31.noarch
  python3-3.7.6-2.fc31.x86_64
  python3-libs-3.7.6-2.fc31.x86_64
  python3-pip-19.1.1-7.fc31.noarch
  python3-setuptools-41.6.0-1.fc31.noarch
  shared-mime-info-1.15-1.fc31.x86_64
  tpm2-tss-2.3.1-1.fc31.x86_64
Run "systemctl reboot" to start a reboot
@dustymabe
Copy link
Member

dustymabe commented Apr 3, 2020

yeah I like fwupd (I almost wish the entire host system could be managed through a single pain of glass TBH, including firmware and "system containers"), but that set of deps is quite daunting. Do we have any requests out to see if we can rein those deps a bit?

@LorbusChris
Copy link
Contributor

@ashcrow ashcrow added the jira for syncing to jira label Jun 1, 2020
@LorbusChris
Copy link
Contributor

PR to move python dependency to sub-package: https://src.fedoraproject.org/rpms/fwupd/pull-request/2

@travier
Copy link
Member

travier commented Sep 29, 2020

This has recently landed in Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2020-728951fb41

@cgwalters
Copy link
Member Author

@dustymabe
Copy link
Member

Yep. Looks like this will ship when we move to F33 unless something drastically changes.

@cgwalters
Copy link
Member Author

OK so...there's a lot to like about fwupd but broadly speaking it's only useful on bare metal environments. A bit like usbguard...I'm hesitant to say that it makes sense to include fwupd in e.g. AWS instances.

But saying one needs an extension to update the Secure Boot DBX isn't great (which would be true now that fwupd/fwupd#2326 merged).

There are other sub-threads to discuss here, such as part of the CoreOS philosophy is automatic updates, but fwupd is "inert" by default. Should we try to have zincati enable firmware updates by default?

I think eventually the MCO should support fwupd in the same way it supports rpm-ostree too. (And tangentially related the MCO will need to gain support for bootupd too)

@travier travier removed their assignment Oct 2, 2020
@hughsie
Copy link

hughsie commented Oct 5, 2020

But it looks like their dependency set is pretty broken from our PoV:

Can you do the dep list again on f33 please? I think we can certainly split out a lot of things as subpackages; for instance making the modem updating optional (but installed by default on workstation) gets rid of libmbim, libqml, and ModemManager; splitting out the coreboot support gets rid of flashrom, libftdi and pciutils-libs -- but I'd appreciate if you could identify what were the most problematic deps other that those.

The python stuff should all be gone now.

@jlebon
Copy link
Member

jlebon commented Oct 5, 2020

@hughsie Would it be possible to make dbxtool a subpackage? Seems odd that installing that pulls in all of fwupd.

Should we try to have zincati enable firmware updates by default?

I don't think I'd want the OS to presume this is safe to do by default. So I'd say at least making it opt-in. Though I'm not sure if that functionality should belong in Zincati in the first place. The sophistication Zincati brings is in update graphs, but that's not something we can realistically provide for all firmwares that fwupd supports. (Edit: to clarify, I agree otherwise with everything in #449 (comment)!)

My proposal is to try to get dbxtool into a subpackage and ship it in FCOS, and then make fwupd an extension.

@hughsie
Copy link

hughsie commented Oct 5, 2020

My proposal is to try to get dbxtool into a subpackage

I think that would also mean splitting out fwupd-libs, but that's probably no bad thing either. I do think (UEFI?) firmware updates are just as security sensitive (and thus as important) as dbx updates, if that helps. There's a binary called fwupdagent that lets you do stuff with fwupd using a JSON payload, if that helps at all, it doesn't have to be RAW DBus or scraping command line scripts.

@jlebon
Copy link
Member

jlebon commented Oct 6, 2020

I think that would also mean splitting out fwupd-libs, but that's probably no bad thing either.

Ahh OK, so the new dbxtool links to libfwupd. And looking at ldd /lib64/libfwupd.so.2 and comparing to the deps that are being added in coreos/fedora-coreos-config#640, IIUC it seems like shipping just dbxtool and libfwupd should allow us to shed quite a few deps.

@hughsie
Copy link

hughsie commented Oct 6, 2020

so the new dbxtool links to libfwupd

I think it links to libfwupdplugin, which then depends on libfwupd -- not a huge problem either way but I didn't want to cause a confusion.

@hughsie
Copy link

hughsie commented Oct 7, 2020

How's this for starters: fwupd/fwupd#2451

commit 607ca836c34106d5bdaabf26b5a55402d8e4ef6a (HEAD -> wip/hughsie/coreos, origin/wip/hughsie/coreos)
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Oct 7 08:52:18 2020 +0100

    spec: Split out a fwupd-plugin-flashrom subpackage
    
    This is installed by default, but means it can be excluded from the minimal
    CoreOS image. It's highly unlikely that anything running CoreOS has anything
    unlocked that can be flashed using flashrom.
    
    This drops inclusion of dmidecode, libftdi, pciutils-libs and flashrom as hard
    dependencies from the package set.

:100644 100644 701176c0 f4b4a11f M      contrib/fwupd.spec.in

commit b8c7d04229d90d2f594021de38354b2c943c1670
Author: Richard Hughes <richard@hughsie.com>
Date:   Wed Oct 7 08:44:55 2020 +0100

    spec: Split out a fwupd-plugin-modem-manager subpackage
    
    This is installed by default, but means it can be excluded from the minimal
    CoreOS image. It's highly unlikely that anything running CoreOS has mobile
    broadband hardware attached.
    
    This drops inclusion of libmbim, libqmi and ModemManager-glib as hard
    dependencies from the package set.

:100644 100644 1f5cef6c 701176c0 M      contrib/fwupd.spec.in

@cgwalters
Copy link
Member Author

Thanks Richard, that sounds useful. Long term though this gets trickier because e.g. in IoT cases one might actually have a cell connection for devices and want to update the firmware, etc.

(In general IoT spans the middle ground between laptops and data center servers and handling it too means we need more sophistication than just "minimal" and "full")

@dustymabe
Copy link
Member

Thanks @hughsie - do you think you could submit an update for Fedora 33 with those changes?

@hughsie
Copy link

hughsie commented Oct 22, 2020

do you think you could submit an update for Fedora 33 with those changes

Monday; that should be when the 1.5.0 release gets released upstream if nothing explodes in the interim.

@dustymabe
Copy link
Member

All, is the only remaining work item here to chase down dependency sprawl (which may already be done with Richard's work upstream)?

@hughsie
Copy link

hughsie commented Oct 26, 2020

1.5.0 was released this morning and is available in f32 and f33 too if that helps. Yell if anything explodes.

@travier
Copy link
Member

travier commented Nov 10, 2020

fwupd is currently included in the next stream. Looking at the dependencies there, I only see the gsettings-desktop-schemas package standing out, required by the glib-networking package. From a classic Fedora 33 installation:

$ dnf info gsettings-desktop-schemas
Installed Packages
Name         : gsettings-desktop-schemas
Version      : 3.38.0
Release      : 1.fc33
Architecture : x86_64
Size         : 4.4 M
Source       : gsettings-desktop-schemas-3.38.0-1.fc33.src.rpm
Repository   : @System
From repo    : fedora
Summary      : A collection of GSettings schemas
URL          : https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas
License      : LGPLv2+
Description  : gsettings-desktop-schemas contains a collection of GSettings schemas for
             : settings shared by various components of a desktop.

Looks like this is related to proxy support.

@hughsie
Copy link

hughsie commented Nov 10, 2020

If you forcibly remove glib-networking, what breaks? At 4.4 Mb for the schemas it seems like something we should untangle....

@travier
Copy link
Member

travier commented Nov 10, 2020

The full dependency chain is:
gsettings-desktop-schemas <- glib-networking <- libsoup <- fwupd

The bulk of the package is coming from the locales:

$ du -csh /usr/share/locale/*/LC_MESSAGES/gsettings-desktop-schemas.mo
...
4.4M    total

Looking into if this is really needed.

@travier
Copy link
Member

travier commented Nov 10, 2020

From https://codesearch.debian.net/search?q=org.gnome.system.proxy&literal=1 (found via https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/issues/27), it looks like we will not be able to remove the package entirely.

@hughsie
Copy link

hughsie commented Nov 11, 2020

If you forcibly remove glib-networking, what breaks

I mean, if we switched it to Reccomends rather than Requires, does libsoup explode in a ball of fire or just ignore the GNOME proxy settings?

@travier travier self-assigned this Nov 12, 2020
@travier
Copy link
Member

travier commented Nov 17, 2020

I think we want to keep proxy settings supported on FCOS so I will try to split this package in two.

@hughsie
Copy link

hughsie commented Nov 17, 2020

I will try to split this package in two

If you can, super; otherwise don't panic -- the IoT people also are quite upset with fwupd using libsoup rather than libcurl.

@travier
Copy link
Member

travier commented Nov 17, 2020

As libcurl is already in FCOS, moving to a single HTTP library would indeed be beneficial for us too.

@hughsie
Copy link

hughsie commented Nov 18, 2020

Work in progress fwupd libcurl branch here: fwupd/fwupd#2601 -- review feedback or fixes very welcome.

@superm1
Copy link

superm1 commented Nov 18, 2020

Does dmidecode really still get pulled in from fwupd? I don't think it should actually be needed. Similarly I don't see why all those fonts are actually coming in. It would be nice if we can see the updated list based on the the stuff in the latest repositories now.

@hughsie
Copy link

hughsie commented Nov 23, 2020

fwupd just released with libcurl dep: https://blogs.gnome.org/hughsie/2020/11/23/fwupd-1-5-2/ -- packages building in Fedora now.

@travier
Copy link
Member

travier commented Nov 23, 2020

Wow, that was fast! Thanks!

@travier
Copy link
Member

travier commented Nov 24, 2020

Does dmidecode really still get pulled in from fwupd? I don't think it should actually be needed. Similarly I don't see why all those fonts are actually coming in. It would be nice if we can see the updated list based on the the stuff in the latest repositories now.

Neither dmidecode nor fonts get pulled in anymore. With the move to libcurl, the only additional packages pulled in should be some necessary libraries. I will do an updated comparison soon but things looks good here.

@travier travier added the status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. label Nov 24, 2020
@travier
Copy link
Member

travier commented Nov 24, 2020

This is now included in last week testing release. The package diff for this release is as follow (note that those packages may not have been pulled in by fwupd, this is the raw package diff between the F32 and F33 FCOS release):

fedora-release-identity-coreos-33-2.noarch
fedora-repos-modular-33-1.noarch
fwupd-1.5.1-1.fc33.x86_64
glib-networking-2.66.0-1.fc33.x86_64
gsettings-desktop-schemas-3.38.0-1.fc33.x86_64
hwdata-0.340-1.fc33.noarch
libeconf-0.3.8-4.fc33.x86_64
libgcab1-1.4-3.fc33.x86_64
libgudev-234-1.fc33.x86_64
libgusb-0.3.5-1.fc33.x86_64
libibverbs-32.0-1.fc33.x86_64
libjcat-0.1.4-1.fc33.x86_64
libmodman-2.0.1-23.fc33.x86_64
libproxy-0.4.15-25.fc33.x86_64
libsmbios-2.4.2-10.fc33.x86_64
libsoup-2.72.0-3.fc33.x86_64
libxmlb-0.2.1-1.fc33.x86_64
mozjs78-78.4.0-1.fc33.x86_64
pciutils-3.6.4-2.fc33.x86_64
pciutils-libs-3.6.4-2.fc33.x86_64
rdma-core-32.0-1.fc33.x86_64
samba-libs-2:4.13.2-1.fc33.x86_64
shared-mime-info-2.0-3.fc33.x86_64

I don't think that anything stands out here.

@hughsie
Copy link

hughsie commented Nov 24, 2020

You want fwupd 1.5.2 -- that drops a lot of the deps you just added.

@cgwalters
Copy link
Member Author

BTW as soon as we merge this it will bring back
coreos/bootupd#1
in that we'll need to do some work bootupd side to exclude fwupd from being updated and allow it to update itself.

@travier
Copy link
Member

travier commented Dec 4, 2020

@cgwalters Reading coreos/bootupd#1 (comment), do we still need work on the bootupd side for fwupd support?

@jlebon
Copy link
Member

jlebon commented Dec 4, 2020

Full list of deps removed with all the fwupd dep cutting:

  • glib-networking
  • gsettings-desktop-schemas
  • libmodman
  • libproxy
  • libsoup

@travier
Copy link
Member

travier commented Dec 7, 2020

I will close this one as fwupd should be included in the next stable release happening this week and the deps cut will happen in the next. Additional work will be tracked in new issue. Thanks @hughsie for the libcurl work!

@travier travier closed this as completed Dec 7, 2020
@dustymabe
Copy link
Member

The fix for this went into stable stream release 33.20201201.3.0.

@dustymabe dustymabe removed the status/pending-stable-release Fixed upstream and in testing. Waiting on stable release. label Dec 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants