This message is in MIME format and has been PGP signed.
Hi Simon,
On Fr 13 Jun 2025 17:44:14 CEST, Simon McVittie wrote:
The symptom of the failure is that sometimes, polkitd.postinst will successfully invoke systemd-sysusers to create the polkitd user and
group in passwd(5) and group(5):
173s Configurando polkitd (126-2) ...
173s Creating group 'polkitd' with GID 989.
173s Creating user 'polkitd' (User for polkitd) with UID 989 and GID 989.
but then immediately after that, an operation that involves looking up
the newly-created polkitd group will fail, instead of falling back to group(5) as it should:
173s chown: invalid group: ‘root:polkitd’
173s dpkg: erro processando pacote polkitd (--configure):
173s o subprocesso instalado pacote polkitd script
post-installation retornou estado de saída de erro 1
This is not specific to polkitd. Other postinsts also fail to look up a newly-created user:
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
194s systemd-udevd.service is a disabled or a static unit, not starting it.
The error message "No such process" indicates ESRCH, but that might be
an error synthesized internally by systemd utility code to represent
"the lookup failed" rather than specifically referring to a process not
being found.
I have looked into this a bit close with help from elbrus to intercept
a testbed after autopkgtest run.
Only thing I could spot is that /etc/nsswitch.conf refers to the
systemd libnss plugin. This requires systemd-userdbd.service to be
started which is not the case in the testbed it seems.
passwd: files systemd
group: files systemd
shadow: files systemd
gshadow: files systemd
Could a non-started systemd-userdbd be the cause of the problem?
Furthermore, the recommended setup is:
passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd
Greets,
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail:
[email protected],
http://sunweavers.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIzBAABCgAdFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAmiCVpMACgkQmvRrMCV3 GzEFCBAAhqdZWsdkoQjvyc72Be3B4TbT4x7MQZ89FCmom4UFbE2HwFFAV9+++Kht Z02i1yLDzXyLmDtUtrSzj/zL/Togls273668RNUDBC/xmkAnzEghAIX0GeUbQzwP 2U7Sy7sgBicBrgv0DsweC1NGhYcTrHyJ5rk3fV68KAcrZAwJtFEVw+TmzrlDEB+S DbEHJZpOyH3U5HKgHWCSqKvdXHF751ClxVZ+BKhRhVD3gBkkPeHws+BK7C/s3iiF QJE3NZHg23PV3GwcR0Gl/iSuHyk2zt72UnoslKujs0YAFf5oGLospPXpH+pTXxBb Bl2Vvwtis78YRrYx37d4yk2Z7GYHiw++jIvJZ+znlNJgFZi+ud3hwsOE+KYys0DI 7IYVEm85o5dWrfBVBKQHQRMW0u3QdHCP01IrcMctLWGRQqk3Y9A6Zy0EHVZp+bap 1lvg22ugYJZvALX4UmlHK3LIIrvHn7ioF11StP1oXX5vcVumSC3IQKp/9EEyJm4G IOozRBxULuq7cCaU2uu6uRevBwkqBogHAyHzzmIpyVqyIQ3oF2MK9aRSdbIiZj1c USWPYUy23WCEsODRYSCFfVc+1Bp4zKZMtAUdEYf67s19eiiSX4KDlW0JuWdzNEZd
uho