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. This means it should
be possible to reproduce the issue that Wookey reported like this:
- have a host system (virtual machine will be easiest) that has never
had Exim installed, for example a fresh bookworm installation
- have a persistent schroot, like this one (it's a trixie derivative):
[steamrt_steamrt5_amd64]
description=Steam Runtime 5 development
directory=/var/chroots/steamrt_steamrt5_amd64
personality=linux
groups=sudo
root-groups=sudo
preserve-environment=true
type=directory
- in one schroot session, install Exim: it will add Debian-exim to the
/etc/passwd in the chroot
- completely end the schroot session (reboot the machine, etc.)
but keep the on-disk state in (in my case)
/var/chroots/steamrt_steamrt5_amd64
- open a new schroot: schroot will overwrite
/var/chroots/steamrt_steamrt5_amd64/etc/passwd with the /etc/passwd
from the host, which does not contain Debian-exim
- try to run dpkg (for example I ran `apt autoremove`):
dpkg sees that its statoverride database contains Debian-exim but
/etc/passwd has no record of that user, and panics
Using transient schroots (those that are documented as implementing
"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.
smcv
