Your message dated Sat, 01 Jun 2024 21:35:59 +0000 with message-id <e1sdwon-00hped...@fasolo.debian.org> and subject line Bug#1071462: fixed in glibc 2.38-12 has caused the Debian Bug report #1071462, regarding installing/upgrading libc6 does not work in sbuild when systemd is installed as ischroot declines to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1071462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071462 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: sbuild,debianutils,libc6,systemd-sysv Severity: important Hello lots of maintainers, I am faced with a very crazy interaction bug. Roughly speaking, when you use sbuild to build a package and your build-depends happen to include systemd-sysv and you happen to install (cross building) or upgrade libc6, installing build-depends reliably fails. Since upgrading libc6 is a thing, I guess that this now affects buildds and is why I file this at important severity. Regenerating buildd chroots, will "heal" buildds, so it is self-recovering there. Without further ado, let's dive into the details. The issue is reproducible using mmdebstrap: mmdebstrap unstable --verbose --architectures amd64,arm64 --variant=apt /dev/null --include=systemd-sysv,libc6:arm64 --essential-hook='ln -sf /bin/false $1/usr/bin/ischroot' This is using a cross build setting, because libc6 is installed early during bootstrap and reproducing the bug takes configuring libc6 after systemd-sysv has been unpacked. So I simply install a foreign libc6 and apt happens to configure it late enough in my tests. So we now look into libc6.postinst. We take the "$1" = "configure" branch. We eventually run into: | # Restart init. Currently handles chroots, systemd and upstart, and | # assumes anything else is going to not fail at behaving like | # sysvinit: | TELINIT=yes | if ischroot 2>/dev/null; then | # Don't bother trying to re-exec init from a chroot: | TELINIT=no I note that mmdebstrap creates a number of namespaces and then externally runs apt. If I understand things correctly, it also runs an external dpkg --root ... without --force-scripts-chrootless. Hence dpkg performs a chroot for every maintainer script and ischroot correctly detects this, so we would be setting TELINIT=no if I were not replacing it in the --essential-hook. In sbuild, the namespace setup is different. apt is entirely run inside the namespace. ischroot compares /proc/1/mountinfo to /proc/self/mountinfo. If both are readable and equal, it concludes that we're not in a chroot. If they differ, it concludes that we are in a chroot. For mmdebstrap, pid 1 happens to be a mmdebstrap process in the initial namespace and the ischroot process sees fewer mounts. Hence it concludes success there. For sbuild, pid 1 is a runuser process already running chrooted. Hence the mountinfo files equal and ischroot concludes that we are not running in a chroot. | elif [ -n "${DPKG_ROOT:-}" ]; then | # Do not re-exec init if we are operating on a chroot from outside: | TELINIT=no In neither case DPKG_ROOT is non-empty. | elif [ -d /run/systemd/system ]; then | # Restart systemd on upgrade, but carefully. | # The restart is wanted because of LP: #1942276 and Bug: #993821 | # The care is needed because of https://bugs.debian.org/753725 | # (if systemd --help fails the system might still be quite broken but | # that seems better than the kernel panic that results if systemd | # cannot reexec itself). | TELINIT=no In neither case /run/systemd/system exists. | if systemd --help >/dev/null 2>/dev/null; then | systemctl daemon-reexec | else | echo "Error: Could not restart systemd, systemd binary not working" >&2 | fi | fi | if [ "$TELINIT" = "yes" ]; then | telinit u 2>/dev/null || true ; sleep 1 | fi And finally we run telinit u when running inside sbuild or faking ischroot in mmdebstrap. Running telinit u doesn't go well. This actually has been a known problem with different symptoms recently. Earlier, cross build nodes would get stuck in libc6.postinst hanging in telinit forever. The reason was that telinit was re-executing itself over and over again attempting to forward to another init system but always returning back to itself. This has been fixed by Luca Boccassi: https://github.com/systemd/systemd/pull/31251 and #1063147 telinit no longer reexecs itself and rather does what it is supposed to do: kill(1, SIGTERM). Sadly this doesn't go well. In case of sbuild, we kill the runuser process. It exits non-zero and sbuild considers this a failure to install Build-Depends. This is bad. So I'm not exactly sure which part is broken here. We might argue that sbuild is setting up a container that looks too much like a container and should have pid 1 outside the chroot area or that the init process should handle SIGTERM more like an init system would handle that. We might argue that ischroot should detect init-less application container environments. We might argue that libc6 should ischroot is not meant for detecting application containers and libc6.postinst asks the wrong question and should be skipping telinit for such environments as well. We might argute that telinit should not kill a pid 1 that isn't systemd. At this time, I am really unsure which of these four packages we consider at fault. Possibly, we select multiple options to harden things in depth. I am now seeking feedback from the various maintainers: - debianutils - glibc - sbuild - systemd Do you think that your package handles this situation correctly and that some other package should change or do you see your package behaving wrongly? Thanks in advance for replying Helmut
--- End Message ---
--- Begin Message ---Source: glibc Source-Version: 2.38-12 Done: Aurelien Jarno <aure...@debian.org> We believe that the bug you reported is fixed in the latest version of glibc, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 1071...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Aurelien Jarno <aure...@debian.org> (supplier of updated glibc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Format: 1.8 Date: Sat, 01 Jun 2024 23:16:35 +0200 Source: glibc Architecture: source Version: 2.38-12 Distribution: unstable Urgency: medium Maintainer: GNU Libc Maintainers <debian-gl...@lists.debian.org> Changed-By: Aurelien Jarno <aure...@debian.org> Closes: 1071084 1071462 1071549 Changes: glibc (2.38-12) unstable; urgency=medium . [ Aurelien Jarno ] * debian/debhelper.in/libc.postinst: do not try to call telinit if it is provided by systemd, it is just broken. Closes: #1071462. * debian/debhelper.in/libc.postinst: test for $DPKG_ROOT first. * debian/debhelper.in/libc.postinst: emit libc-upgrade trigger on every upgrade and libc-major-upgrade on major glibc upgrade. This interface should be used by depending packages to restart themselves if needed. * debian/patches/git-updates.diff: update from upstream stable branch. . [ Dominik Stadler ] * debian/local/usr_sbin/update-locale: improve error reporting in update-locale. Closes: #1071084. . [ Bjarni Ingi Gislason ] * debian/local/manpages/gencat.1: editorial fixes. Closes: #1071549. Checksums-Sha1: 5def9ed3cfdfbf2e07169862359f54dff28c0543 7535 glibc_2.38-12.dsc 26bdaf1d7439918840b3775ce251fe7df33b6cf7 430016 glibc_2.38-12.debian.tar.xz ee9172871cf8893b723e8c6eb7dc5324d5ab7649 9640 glibc_2.38-12_source.buildinfo Checksums-Sha256: aa358979f631aabf67f73c7020263f9f2e9d11ba764afa9b7765a92d03cf8f19 7535 glibc_2.38-12.dsc 616fd5691b00e766ea6a9b3d8c3ba9a9b193e49709533aa6b85387dcfafa2a51 430016 glibc_2.38-12.debian.tar.xz 2435d0982e90cb5bef8ca2485c558751d7c7773b95851f56601e11b6bf7f4d2c 9640 glibc_2.38-12_source.buildinfo Files: 423520d04d33254afd509dd3a85ee876 7535 libs required glibc_2.38-12.dsc 5c7132746817fac20278eca920011081 430016 libs required glibc_2.38-12.debian.tar.xz d6afccc6dcfbc275b2eb0ef697092664 9640 libs required glibc_2.38-12_source.buildinfo -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEUryGlb40+QrX1Ay4E4jA+JnoM2sFAmZbkBcACgkQE4jA+Jno M2sLBw/9Fr7xE7VfnlF8ypIxvlIhu6R5dWIYQRA1IdzjTDfdBM+TdN0AHzvrk1Mw trW0dFfRBDNsTr2FkN3/JSL4vG3PeTUWmCnPlTsJy/IfrQEj8vpinOhHQ6qUDc8t lyAxLY0rLb7xJZHuDLYJAki8CnS5B11INDc+BBPHCjrCIJcbgf4xq5UXV0p0k3sO la/9CcpkTznuAs+K9zKh4Xoszz9LRLy8uhb/r4ieI8oXIIaZRTMGOVCjEhrvz8QY lAsHsikW6fyExw933oCDiCO+rHOBx0LfGJmTBF6xJoZdJr4vBV52rMAscROR4R3C Cum0H/k+YoiH/Nho0tKRPtGZqol/JLdZHn87tKR3ODdDrOv+poGn50MeItz4SESD wL+qU2+XygWLTqF3bXFGR28WrEpYSqTLQxmTdEvCVETcf8t/DRBI4FVqSDDW0YmQ L2OUKXpo5iK/OmEM8IcJZv1ObGV8+l/LT4ualeh5BCmZRS4bCTs6iHeRR1WamZdz 2MuVYXqh+Cur/pgVuO2gFXvzDWVubrHZQyDhqeGlPyi9Mit9l/Xt3nmMFESPdYUJ dhikJAZB9M71siiP75FYfyWd33bqJK82GkvldTnFwWmHpxKQRKVJdi2fzlVSKA32 yIQ2/RcyL2gwZCH7oE/PWkvGfehrxx56QnDXSocKcn4kuIW1BCs= =6BzU -----END PGP SIGNATURE-----
pgppW1bU_nGnW.pgp
Description: PGP signature
--- End Message ---
