[Pkg-shadow-devel] Bug#1126595: dbus-system-bus-common: Many packages FTBFS with the nocheck build profile due to weird dbus/adduser error

[Simon McVittie]

Control: affects -1 + shadow adduser
Control: tags -1 + moreinfo help

On Thu, 29 Jan 2026 at 13:57:11 +0100, Santiago Vila wrote:
>Setting up dbus-system-bus-common (1.16.2-2) ...
>fatal: The user `messagebus' already exists and has a password. Exiting.

I suspect this to be a regression in a related package (adduser, useradd 
or something in that general ecosystem) or a regression on the host 
system where you are doing the builds, rather than a problem with 
dbus-system-bus-common specifically, because dbus-system-bus-common 
isn't doing anything particularly fancy with adduser. Here is the code 
that is failing:

     if command -v systemd-sysusers >/dev/null; then
         systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} dbus.conf
     else
         in_sysroot adduser --system --quiet --group "$MESSAGEUSER"
     fi

I think you are seeing this in dbus simply because it is a 
widely-depended-on package that calls adduser, and in particular, lots 
of packages (usually incorrectly) build-depend on dbus (see recent MBF 
<https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=dbus@packages.debian.org&tag=direct-dbus-dependency>, 
resolving more of those bugs would mitigate the impact of what you've 
reported here).

codesearch says the error message you quoted comes from adduser, so we 
must be in the code path where dbus-system-bus-common has pulled in 
adduser to satisfy the adduser|systemd-sysusers dependency. I'd expect 
that in a chroot or minimal container like the ones used in sbuild 
(although not in a full bootable system with systemd, where 
dbus-system-bus-common would use systemd-sysusers).

I was unable to reproduce this with just

     $ podman run --rm -it debian:sid
     # apt update && apt upgrade && apt install dbus-system-bus-common

(which installs adduser), so there must be something in the build 
environment that is causing a more complicated setup than just that. The 
error message also suggests that the prior contents of /etc/passwd (on 
entry to dbus' maintainer scripts) could be significant.

 From the build logs for the packages you marked as affected, am I 
correct to think that you're using sbuild in its schroot mode (like 
older official buildds), as opposed to unshare mode (like newer official 
buildds) or any other backend? I *think* the build logs imply that by 
mentioning var/run/schroot/mount, but it isn't 100% obvious.

schroot usually (configuration-dependent!) copies the /etc/passwd, 
/etc/shadow and similar files from the host system into the container.  
Is your schroot configured to do that? I don't think we can tell from 
the log. Please check /etc/schroot/*/nssdatabases, replacing * by 
whichever profile your build chroot is configured to use (normally I 
would expect "buildd" for this purpose).

What is the host system that these builds run on, and how/when was it 
installed? (A cloud image perhaps?) If the regression is being triggered 
by /etc/passwd and friends being copied from the host into the chroot, 
then the root cause might be a regression in the packages or 
configuration used on the host, rather than in the packages inside the 
chroot.

What is the output of these on the host system? (run at least the last 
two as root, e.g. via sudo)

getent passwd messagebus
getent group messagebus
getent shadow messagebus
getent gshadow messagebus

For comparison, what I get on a desktop machine that was installed as 
trixie is:

messagebus:x:101:108::/nonexistent:/usr/sbin/nologin
messagebus:x:108:
messagebus:!:19814::::::
messagebus:!::

Also, if you do a similar build but with the unshare backend instead of 
schroot, does that alter the behaviour? The specific package shouldn't 
matter, just choose anything smallish that Build-Depends on dbus 
(perhaps telepathy-glib).

>Maybe this is related to this other bug in the shadow package:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1124795
>but I'm not really sure.

It doesn't look closely related to any of the quoted errors at first 
glance, but it could be a similar regression in useradd or adduser 
(stricter validation or a user being created in a different state), perhaps.

>During a rebuild of all packages in unstable using the nocheck build profile,
>all the above packages failed to build.

I would be surprised if the presence or absence of nocheck matters here. 
If you build one of the packages in the same environment (one should be 
enough, choose whichever one is quick to build) but without nocheck, 
does it fail in the same way?

If a build failure doesn't appear to have anything to do with nocheck, 
then reporting it as "FTBFS with nocheck" without knowing whether 
nocheck is a key factor seems likely to send maintainers off on a wrong 
track.

     smcv