Subject: Re: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

From: Matthew Gabeler-Lee <[email-masked]>
Date: Mon, 21 Jun 2021 13:07:33 -0400

Package: fwupd
Version: 1.5.7-2
Followup-For: Bug #943343

This started out as what I thought may be the same essential data as Ross
Vandergrift reported above, but I think I've figured out the problem.

I'm seeing this same issue on a bullseye system.  Interestingly, not on
_all_ of my bullseye systems, even though I thought they were all configured
equivalently as far as this package would be concerned.

On the failing system, if I use `systemctl edit fwupd-refresh.service` to
change `StandardError` from `null` to `inherit`, I see this error when it
fails:

Jun 21 12:15:26 myhostname systemd[1]: Starting Refresh fwupd metadata and update motd...
Jun 21 12:15:26 myhostname fwupdmgr[3874480]: Failed to connect to daemon: Exhausted all available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Main process exited, code=exited, status=1/FAILURE
Jun 21 12:15:26 myhostname systemd[1]: fwupd-refresh.service: Failed with result 'exit-code'.
Jun 21 12:15:26 myhostname systemd[1]: Failed to start Refresh fwupd metadata and update motd.

If I apply a fixed version of Ross' "strace" change to the refresh service
(need to clear ExecStart first), I see the "AUTH EXTERNAL" handshake is
_exactly_ the same ...  which I guess isn't the same because the dynamic
user id is chosen from hashing the same username, and so isn't actually all
that "dynamic".

Looking for other differences between the working and non-working systems, I
notice the working system has a
/etc/dbus-1/system.d/org.freedesktop.fwupd.conf file that is an exact copy
of its /usr/share/ counterpart.  But replicating that on the working system
and doing `systemctl reload dbus` doesn't fix things, and removing it on the
working system doesn't break things.

I resorted to rummaging in the dbus code itself to see why `AUTH EXTERNAL`
might fail, and most of it was pretty basic stuff like not providing a user,
or malloc failures or things like that, which I was pretty sure were not the
problem.  About the only thing left was this block of code:
https://github.com/freedesktop/dbus/blob/ef55a3db0d8f17848f8a579092fb05900cc076f5/dbus/dbus-auth.c#L1152

      if (!_dbus_credentials_add_from_user (auth->desired_identity,
                                            &auth->identity,
                                            DBUS_CREDENTIALS_ADD_FLAGS_NONE,
                                            &error))
        {
            // ...

          _dbus_verbose ("%s: could not get credentials from uid string: %s\n",
                         DBUS_AUTH_NAME (auth), error.message);
          // ...
          return send_rejected (auth);
        }
    }

And thought "OK, so it wants to look up user info from a uid" and thought
"how the heck does that work with dynamic users?" On a lark I went looking
at /etc/nsswitch.conf on the working vs.  non-working systems, and noticed
that the working system has "systemd" listed under "passwd" and "group", and
has `libnss-systemd` installed. The non-working system has neither!

So I installed that package and did `sudo systemctl restart dbus` and ...

Voila! Broken system now works.

So, libnss-systemd is only a Recommends in various places.  This package
seems to _Depend_ on it being installed & configured for its default
installation to work properly.

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-6-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupd depends on:
ii  libc6                  2.31-12
ii  libcurl3-gnutls        7.74.0-1.2
ii  libefiboot1            37-6
ii  libelf1                0.183-1
ii  libflashrom1           1.2-5
ii  libfwupd2              1.5.7-2
ii  libfwupdplugin1        1.5.7-2
ii  libglib2.0-0           2.66.8-1
ii  libgnutls30            3.7.1-5
ii  libgudev-1.0-0         234-1
ii  libgusb2               0.3.5-1
ii  libjcat1               0.1.3-2
ii  libjson-glib-1.0-0     1.6.2-1
ii  libpolkit-gobject-1-0  0.105-31
ii  libsmbios-c2           2.4.3-1
ii  libsqlite3-0           3.34.1-3
ii  libsystemd0            247.3-5
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb1               0.1.15-2
ii  shared-mime-info       2.0-1

Versions of packages fwupd recommends:
pn  bolt                               <none>
ii  dbus                               1.12.20-2
ii  fwupd-amd64-signed [fwupd-signed]  1.5.7+2
ii  python3                            3.9.2-3
pn  secureboot-db                      <none>
ii  udisks2                            2.9.2-2

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  <none>

-- Configuration Files:
/etc/fwupd/uefi_capsule.conf changed [not included]

-- no debconf information

---

From: Philipp Huebner <[email-masked]>
Date: Tue, 19 Oct 2021 11:58:22 +0200

Hi there,

looking into the same issues on multiple Bullseye systems,
I can confirm the cause to be an incorrect /etc/nsswitch.conf.

After fixing that I had to reboot for the fix to work,
I guess restarting some systemd or dbus service would have done the
trick as well.

Now for a proper fix: IMHO fwupd should either depend on libnss-systemd
or disable the refresh service and timer in postinst if this recommended
package is not present.

Best wishes
Philipp Huebner