Bug#1071462: installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines

[Luca Boccassi]

On Mon, 20 May 2024 at 10:49, Aurelien Jarno <aurel32 at debian.org> wrote:
>
> On 2024-05-20 10:40, Luca Boccassi wrote:
> > On Mon, 20 May 2024 at 10:37, Aurelien Jarno <aurel32 at debian.org> wrote:
> > >
> > > On 2024-05-20 10:22, Luca Boccassi wrote:
> > > > On Mon, 20 May 2024 at 10:20, Johannes Schauer Marin Rodrigues
> > > > <josch at debian.org> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Quoting Chris Hofstaedtler (2024-05-20 10:38:04)
> > > > > > * Johannes Schauer Marin Rodrigues <josch at debian.org> [240520 07:35]:
> > > > > > > [..] But maybe it [glibc's postinst] should be doing some
> > > > > > > more involved checks about what PID 1 is? It could then make sure to only call
> > > > > > > systemd telinit if systemd is pid 1. [..]
> > > > > >
> > > > > > Well, that would probably suck. Putting the knowledge when to call
> > > > > > telinit, and a specific telinit, into a ton of different things
> > > > > > makes all those things hard to get right, hard to update, the usual.
> > > > > >
> > > > > > I've checked the sysvinit and the systemd implementations now, and
> > > > > > they are not that different. Both try to talk to their respective
> > > > > > pid1 daemons first using their respective communication socket.
> > > > > >
> > > > > > But then, if that doesn't work, they diverge:
> > > > > > - sysvinit's telinit just gives up
> > > > > > - systemd's telinit, *as an explicit fallback*, sends signals.
> > > > > >
> > > > > > systemd's telinit (aka systemctl) helpfully exits if it detects
> > > > > > being in a chroot, before doing any of that.
> > > > > >
> > > > > > IWSTM systemd's telinit could, if called as telinit, not do the
> > > > > > fallback to stick with sysvinit's behaviour?
> > > > > >
> > > > > > As a bonus, sysvinit's telinit could also gain the chroot check, and glibc's
> > > > > > postinst (and other places) can become simpler again.
> > > > >
> > > > > via irc, jochen also pointed out: telinit could be the component which checks
> > > > > what PID 1 actually is and only do its thing after it confirmed that it is
> > > > > indeed an init system like systemd that is providing PID 1?
> > > >
> > > > That's all legacy stuff and I really don't want to touch it anymore.
> > > > Going from the other side, maybe libc6.postinst could use something
> > > > more reliable than ischroot()? Is systemd-detect-virt able to figure
> > > > out the situation a bit better?
> > >
> > > Nope.
> >
> > What's the output? With SYSTEMD_LOG_LEVEL=debug exported
>
> In sbuild using unshare chroot running in a VM:
>
> | SYSTEMD_LOG_LEVEL=debug /usr/bin/systemd-detect-virt
> | Failed to read $container of PID 1, ignoring: Permission denied
> | Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
> | Found container virtualization none.
> | Virtualization QEMU found in DMI (/sys/class/dmi/id/sys_vendor)
> | UML virtualization not found in /proc/cpuinfo.
> | Virtualization XEN not found, /proc/xen does not exist
> | Virtualization found, CPUID=KVMKVMKVM
> | Found VM virtualization kvm
> | kvm

Is sbuild running unshare with a user namespace (-U)? If so,
systemd-detect-virt --private-users should catch that