Control: reassign -1 schroot Control: retitle -1 schroot: type=directory can make user IDs disappear, causing dpkg-statoverride fatal errors Control: affects -1 + exim4-base src:exim4
On Wed, 19 Jun 2024 at 12:45:29 +0100, Simon McVittie wrote: > On Tue, 19 Oct 2021 at 18:56:15 +0200, Andreas Metzler wrote: > > On 2021-09-21 Wookey <woo...@debian.org> wrote: > > > whilst trying to install build-deps for therion in an unstable chroot > ... > > > dpkg: unrecoverable fatal error, aborting: > > > unknown system group 'Debian-exim' in statoverride file; the system > > > group got removed > > > > no, it is not expected. Both -base and -config will add a Debian-exim > > system user with its own private group in postinst if it does not exist. > > But none of the exim packages ever remove the user. > > > > So it looks like random system breakage to me. - Isn't user removal > > logged usually? > > I think this is a problem specific to persistent schroots (those > that carry over on-disk state from one run to another), such as > type=directory. I saw a similar symptom in a schroot running a Debian > trixie derivative, on a Debian 12 host. > > By default, as per /etc/schroot/default/nssdatabases and > /etc/schroot/sbuild/nssdatabases, schroot copies the host system's > /etc/passwd into the chroot during chroot setup. ... > "source chroot" options, such as type=file, type=btrfs-snapshot, > type=zfs-snapshot, type=lvm-snapshot) would likely avoid this problem, > by only copying /etc/passwd during creation of a new chroot session, and > not overwriting it during the lifetime of the session. The cost of this is > that if you *want* state to persist, that's harder to achieve. > > I do not see any straightforward way that this could be addressed from > Exim's side, and an equivalent issue would affect any package that creates > a user or group dynamically and uses it for dpkg-statoverride; so maybe this > should be a schroot bug marked as affecting exim4, rather than an exim4 bug. > https://bugs.debian.org/499014 seems to be essentially the same bug, but > for dbus/messagebus rather than exim4/Debian-exim. Reassigning to schroot based on that reasoning. smcv
