#1139880 chrony: Use of statoverride breaks apt when using schroot

Package:
chrony
Source:
chrony
Description:
Versatile implementation of the Network Time Protocol
Submitter:
Ken Sharp
Date:
2026-06-13 17:59:01 UTC
Severity:
normal
Tags:
#1139880#5
Date:
2026-06-12 23:22:45 UTC
From:
To:
found: 4.6.1-3+deb13u1
found: 4.8-3

schroot, by default, copies /etc/group from the host. Because of the use
of statoverride, this immediately breaks any installation attempt with
apt, given that my host does not use chrony, nor is it guaranteed that
any host does.

dpkg: unrecoverable fatal error, aborting:
  unknown system user '_chrony' in statoverride file; the system user
got removed
before the override, which is most probably a packaging bug, to recover you
can remove the override manually with dpkg-statoverride
E: Sub-process /usr/bin/dpkg returned an error code (2)

# dpkg-statoverride --list
root crontab 2755 /usr/bin/crontab
_chrony _chrony 750 /var/lib/chrony
_chrony _chrony 750 /var/log/chrony

Removing these entries, or setting setup.nssdatabases= in the schroot
.conf for the chroot, allows installation to continue, albeit at the
potential cost of other functionality with the chroot.

These checks don't look like they should be done by dpkg, and should be
done by an init/startup script provided by the package. Alternatively it
should be safe to assume that the package installer has done its job and
these directories are created correctly.

I don't know if Chrony is even useful in a schroot, but Ubuntu Stonking
includes it now by default. This may be subject to change as Stonking is
not yet released. (But perhaps this is an Ubuntu problem for Ubuntu to
deal with.)

#1139880#16
Date:
2026-06-13 06:01:15 UTC
From:
To:
Hi,


I didn't check *any* details of chrony, but for an other package I
considered using systemd-tmpfiles support (see tmpfiles.d(5)) to ensure
permissions of directories (don't be fooled by the name). (Apparently
doesn't work on hurd though).

Paul

#1139880#21
Date:
2026-06-13 12:20:43 UTC
From:
To:
Hi Ken,

Le 2026-06-13 00:22, Ken Sharp a écrit :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101001

This issue is a schroot limitation. From schroot-faq(7):

    Why is schroot overwriting configuration files in the chroot?

    By default, schroot copies over the system NSS databases (‘passwd’, ‘shadow’,
    ‘group’, ‘gshadow’, ‘services’, ‘protocols’, ‘networks’, and ‘hosts’, etc.)
    into the chroot. The reason for this is that the chroot environment is not a
    completely separate system, and it copying them over keeps them synchronised.
    However, this is not always desirable, particularly if installing a package
    in the chroot creates system users and groups which are not present on the
    host, since these will disappear next time the databases are copied over.

    The suggested workaround here is to disable the copying. This may be achieved
    by setting the setup.nssdatabases key to be empty in schroot.conf.
    In prior schroot releases, this was done by commenting out the NSSDATABASES
    file for the chroot (/etc/schroot/default/config by default).
    The database list may also be customised by editing the file containing the
    database list (/etc/schroot/default/nssdatabases by default).

    In the future, we will be working on a better scheme for keeping the
    host and chroot databases in sync which can merge entries rather than
    overwriting the entire database, which would preserve chroot-specific
    changes.

As aforementioned, you can filter which system databases you want to
copy into the chroot by editing /etc/schroot/default/nssdatabases
instead of setting "setup.nssdatabases=" in schroot.conf.

Cheers,
Vincent

#1139880#26
Date:
2026-06-13 12:20:43 UTC
From:
To:
Hi Ken,

Le 2026-06-13 00:22, Ken Sharp a écrit :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1101001

This issue is a schroot limitation. From schroot-faq(7):

    Why is schroot overwriting configuration files in the chroot?

    By default, schroot copies over the system NSS databases (‘passwd’, ‘shadow’,
    ‘group’, ‘gshadow’, ‘services’, ‘protocols’, ‘networks’, and ‘hosts’, etc.)
    into the chroot. The reason for this is that the chroot environment is not a
    completely separate system, and it copying them over keeps them synchronised.
    However, this is not always desirable, particularly if installing a package
    in the chroot creates system users and groups which are not present on the
    host, since these will disappear next time the databases are copied over.

    The suggested workaround here is to disable the copying. This may be achieved
    by setting the setup.nssdatabases key to be empty in schroot.conf.
    In prior schroot releases, this was done by commenting out the NSSDATABASES
    file for the chroot (/etc/schroot/default/config by default).
    The database list may also be customised by editing the file containing the
    database list (/etc/schroot/default/nssdatabases by default).

    In the future, we will be working on a better scheme for keeping the
    host and chroot databases in sync which can merge entries rather than
    overwriting the entire database, which would preserve chroot-specific
    changes.

As aforementioned, you can filter which system databases you want to
copy into the chroot by editing /etc/schroot/default/nssdatabases
instead of setting "setup.nssdatabases=" in schroot.conf.

Cheers,
Vincent

#1139880#31
Date:
2026-06-13 17:25:47 UTC
From:
To:
Thanks Vincent.

I always search for existing bugs before reporting. I have no idea why I
missed this.

#1139880#36
Date:
2026-06-13 17:56:41 UTC
From:
To:
Le 2026-06-13 18:25, Ken Sharp a écrit :

You probably missed it because that bug report has been closed.