On Mon, 20 May 2024 at 15:11, Johannes Schauer Marin Rodrigues <jo...@debian.org> wrote: > > Hi, > > Quoting Aurelien Jarno (2024-05-20 11:49:32) > > > > > 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 > > would it help (and be correct) if PID 1 in sbuild unshare mode would have the > "container" environment variable set to something? And/or if sbuild unshare > mode would create the file /run/systemd/container with some content? > > I'd need input from somebody who knows how containers (if this is one) are > supposed to work. :)
Does it run in PID + mount + user namespaces, on a different filesystem than the host? If so, then yeah it does look like a container