Re: HELP NEEDED: debuging a ppc64el autopkgtest failure involving polkitd?
On Thu, 12 Jun 2025 at 23:43:22 +0200, Michael Biebl wrote:
Am 12.06.25 um 23:27 schrieb Theodore Ts'o:
Creating group 'polkitd' with GID 989. <---- We created the polkitd group here
Creating user 'polkitd' (User for polkitd) with UID 989 and GID 989.
chown: invalid group: ‘root:polkitd’ <---------- Huh?!?!?
This is the systemd-sysusers code path, as opposed to adduser, in case
that's significant; but either should end up adding the user and group to
/etc/passwd and /etc/group, respectively, in the usual way.
So maybe some weird interaction is going on by the way the
debian-edu-config test bed is setup.
Does debian-edu-config perhaps install an unusual nss(5) plugin that
could interfere with group-name resolution?
I see from the log that it installs libnss-systemd (should be normal and
heavily-tested), libnss-mdns (only resolves hosts, shouldn't be
relevant), libnss-sudo (provides a separate service 'sudoers', shouldn't
be relevant) and libnss-ldapd (unusual and probably *does* resolve
groups). This makes me immediately suspicious of libnss-ldapd.
I also see:
193s Configurando udev (257.6-1) ...
193s Creating group 'input' with GID 993.
193s Creating group 'sgx' with GID 992.
193s Creating group 'kvm' with GID 991.
193s Creating group 'render' with GID 990.
193s /usr/lib/tmpfiles.d/static-nodes-permissions.conf:18: Failed to resolve group 'kvm': No such process
193s /usr/lib/tmpfiles.d/static-nodes-permissions.conf:19: Failed to resolve group 'kvm': No such process
193s /usr/lib/tmpfiles.d/static-nodes-permissions.conf:20: Failed to resolve group 'kvm': No such process
(although in udev, unlike polkitd, the missing group is not functionally
required immediately, so the error is not fatal.)
So my suspicion is that libnss-ldapd is somehow set up in such a way
that resolving groups fails, with the combination of its result and its
nsswitch.conf(5) setup being such that instead of failing over to
libnss_files, it completely prevents group name lookups. Perhaps the
nslcd service that's used to do the actual LDAP lookup is crashing, or
failing to start, or something?
This is clearly not a bug in polkitd, and also seems unlikely to be a
bug in e2fsprogs, systemd-sysusers or debianutils.
What I don't understand is why this is apparently ppc64el-specific.
I've retried debian-edu-config's migration-reference autopkgtest
(testing against purely trixie packages, without the new e2fsprogs) in the
hope that it will shed some light on this.
smcv
Reply to: