Control: tags -1 + patch
On Tue, 20 Aug 2024 at 12:10:33 +0100, Simon McVittie wrote:
> I'm testing a patch now.
Please see attached. As with the other known regression from 1.6.13-4
(#1078539), the proposed solution is a change to a conffile, so buildd
operators could try this manually if desired.
Tested successfully on a Debian unstable amd64 VM booted into either a
semi-recent unstable kernel (6.9.12-1, the same as the affected -ports
buildds) or the Debian 10 kernel (4.19.249-2 as used on some mips64el
buildds, see also #1050872).
With the unstable kernel, I can rebuild mksh successfully without changes.
With the Debian 10 kernel, I had to edit mksh's debian/control to remove
the klibc build-dependency (use of which requires a Debian 11+ kernel)
but otherwise the build also succeeds.
If I'm reading the kernel's git history correctly, applying the attached
patch would cause schroot to regress on v4.6 or older kernels, which
I hope are not at all relevant to Debian: Debian 9 'stretch' had v4.9,
so even if Thorsten was correct to say that some mips-family buildds are
still on v4.9, this shouldn't break them either (but I hope that he was
misinformed about that, because v4.19 kernels are already a cause for
concern, and we defintely shouldn't be relying on v4.9 in 2024).
> To reproduce:
...
> * edit /etc/schroot/buildd/fstab
Correction, if you are using sbuild in its default configuration on a
developer system, the reproducer is to edit /etc/schroot/sbuild/fstab
instead. To be sure, apply the change to each /etc/schroot/*/fstab.
smcv
From: Simon McVittie <s...@debian.org>
Date: Tue, 20 Aug 2024 11:37:25 +0100
Subject: setup.d/10mount: Don't bind-mount /dev/pts/ptmx onto
/dev/ptmx
If /dev/pts is a new instance of devpts with ptmxmode=666, as it is since
commit 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot",
then it's safe to bind-mount /dev/pts/ptmx onto /dev/ptmx because
we explicitly make its mode 0666.
However, if an old conffile has been kept or overwritten by configuration
management (as on debian-ports buildds), or if a profile has been
explicitly configured to bind-mount the host's /dev/pts in preference
to using a new instance, then it is not safe to bind-mount the host's
/dev/pts/ptmx onto /dev/ptmx, because the host's /dev/pts/ptmx will
often have permissions 000 for reasons that are not clear to me.
With recent-ish kernels (v4.7+, with commit eedf265a
"devpts: Make each mount of devpts an independent filesystem" included),
this bind-mount becomes unnecessary, because the kernel automatically
redirects actions on /dev/ptmx to work with an adjacent devpts mount.
It was included in my 2017 patch to accommodate older kernels like
the one in Debian 8 'jessie', but is unnecessary if we can assume a
Debian 9 'stretch' or later kernel.
Bug-Debian: https://bugs.debian.org/1079124
Fixes: 271acf6e "Subject: Mount a new instance of /dev/pts in the chroot"
Signed-off-by: Simon McVittie <s...@debian.org>
---
etc/setup.d/10mount | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/etc/setup.d/10mount b/etc/setup.d/10mount
index 010b8b4c..31e817dc 100755
--- a/etc/setup.d/10mount
+++ b/etc/setup.d/10mount
@@ -286,16 +286,6 @@ fi
if [ $STAGE = "setup-start" ] || [ $STAGE = "setup-recover" ]; then
if [ "$(uname -s)" = "Linux" ]; then
- # Depending on how /dev was set up, /dev/ptmx might either be
- # character device (5,2), or a symbolic link to pts/ptmx.
- # Either way we want it to be equivalent to /dev/pts/ptmx, assuming
- # both exist.
- if [ -e "$CHROOT_PATH/dev/pts/ptmx" ] && \
- [ -e "$CHROOT_PATH/dev/ptmx" ] && \
- ! [ "$CHROOT_PATH/dev/pts/ptmx" -ef "$CHROOT_PATH/dev/ptmx" ]; then
- mount --bind "$CHROOT_PATH/dev/pts/ptmx" "$CHROOT_PATH/dev/ptmx"
- fi
-
# If schroot was invoked from a terminal, we still want to be able to
# access that terminal. lxc and systemd-nspawn achieve this by
# binding it onto /dev/console; so can we.
