On 20 Aug 2024, at 00:23, Simon McVittie <s...@debian.org> wrote: > > I'm using Thorsten's regression report in #983423 as my representative > sample of a package that regressed with schroot 1.6.13-4, because mksh > builds much more quickly than gcc-14, but I suspect that the same would > apply equally to Adrian's regression report in #856877: the important > factor is probably just "any package that wants to run script(1) > or expect(1)". > > I was not able to reproduce the mksh build failure, so there must be > some relevant difference in setup (other than CPU architecture, which > shouldn't actually matter here) between the affected -ports buildds and > my attempt to set up a mockup of a buildd. Please could a buildd operator > provide more details of how something resembling the -ports buildd > environment can be replicated in a test VM? > > On Mon, 19 Aug 2024 at 17:02:33 +0100, Simon McVittie wrote: >> On Sun, 18 Aug 2024 at 23:44:57 +0000, Thorsten Glaser wrote: >>> On three buildds, mksh FTBFS already because the whole >>> /dev/ptmx and /dev/pts stuff is malfunctioning again >> >> Which buildds? Are you referring to -ports builds >> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=powerpc&ver=59c-39&stamp=1724031073&raw=0, >> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=ppc64&ver=59c-39&stamp=1724031078&raw=0, >> https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=sparc64&ver=59c-39&stamp=1724031447&raw=0 >> each of which reported >> "script: failed to create pseudo-terminal: Permission denied"? > > I was unable to reproduce this build failure in an amd64 unstable VM > (created with autopkgtest-build-qemu, if it matters), coincidentally > with a 6.9.12-1 kernel matching those buildds, by running these commands > as a user in the sudo and sbuild groups from a virtual console or from > an interactive ssh shell: > > sudo sbuild-createchroot sid /srv/sid http://192.168.122.1:3142/debian > sbuild -dsid mksh > > where http://192.168.122.1:3142 is an apt-cacher-ng instance > (replace that argument with http://deb.debian.org/debian or similar if > required). > > I also tried running sbuild with no controlling tty, by doing this outside > the test VM: > > ssh -T user@testvm sbuild -n -dsid mksh > > and that also seems to be working fine: mksh can run its test suite > involving script(1), and the test suite and build succeed. > > sbuild-createchroot defaulted to creating this schroot configuration: > > [sid-amd64-sbuild] > description=Debian sid/amd64 autobuilder > groups=root,sbuild > root-groups=root,sbuild > profile=sbuild > type=directory > directory=/srv/sid > union-type=overlay > > There must presumably be something different about how sbuild-createchroot > and schroot are configured or invoked on the affected buildds, but I don't > know specifically what. > > On my test VM, while I have one ssh session active (logged in as 'user' > on /dev/pts/0), some relevant parts of the VM's /dev look like this: > > $ ls -l /dev/console /dev/ptmx /dev/pts/* /dev/tty > crw------- 1 root root 5, 1 Aug 19 22:06 /dev/console > crw-rw-rw- 1 root tty 5, 2 Aug 19 23:08 /dev/ptmx > crw--w---- 1 user tty 136, 0 Aug 19 23:08 /dev/pts/0 > c--------- 1 root root 5, 2 Aug 19 22:06 /dev/pts/ptmx > crw-rw-rw- 1 root tty 5, 0 Aug 19 22:55 /dev/tty > > (/dev/pts/ptmx having permissions 000 is strange, but seems to be expected, > and does not cause observable brokenness for the VM: in particular > script(1) still works fine there, because accessing /dev/ptmx is > successful.) > > The /dev in /srv/sid/dev (the base chroot created by debootstrap) has: > > crw-rw-rw- 1 root root 5, 1 Aug 19 22:47 console > lrwxrwxrwx 1 root root 13 Aug 19 22:47 fd -> /proc/self/fd > crw-rw-rw- 1 root root 1, 7 Aug 19 22:47 full > crw-rw-rw- 1 root root 1, 3 Aug 19 22:47 null > crw-rw-rw- 1 root root 5, 2 Aug 19 22:47 ptmx > drwxr-xr-x 2 root root 4096 Aug 19 22:47 pts # is empty > crw-rw-rw- 1 root root 1, 8 Aug 19 22:47 random > drwxr-xr-x 2 root root 4096 Aug 19 22:47 shm # is empty > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stderr -> /proc/self/fd/2 > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdin -> /proc/self/fd/0 > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdout -> /proc/self/fd/1 > crw-rw-rw- 1 root root 5, 0 Aug 19 22:47 tty > crw-rw-rw- 1 root root 1, 9 Aug 19 22:47 urandom > crw-rw-rw- 1 root root 1, 5 Aug 19 22:47 zero > > The /dev in the schroot environment while one of my mksh builds was > running (ls -l /run/schroot/mount/sid-*/dev) has: > > crw--w---- 1 user tty 136, 0 Aug 19 22:51 console > lrwxrwxrwx 1 root root 13 Aug 19 22:47 fd -> /proc/self/fd > crw-rw-rw- 1 root root 1, 7 Aug 19 22:47 full > crw-rw-rw- 1 root root 1, 3 Aug 19 22:47 null > crw-rw-rw- 1 root root 5, 2 Aug 19 22:50 ptmx > drwxr-xr-x 2 root root 0 Aug 19 22:48 pts # devpts mounted > crw-rw-rw- 1 root root 1, 8 Aug 19 22:47 random > drwxrwxrwt 2 root root 40 Aug 19 22:48 shm # tmpfs mounted > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stderr -> /proc/self/fd/2 > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdin -> /proc/self/fd/0 > lrwxrwxrwx 1 root root 15 Aug 19 22:47 stdout -> /proc/self/fd/1 > crw-rw-rw- 1 root root 5, 0 Aug 19 22:47 tty > crw-rw-rw- 1 root root 1, 9 Aug 19 22:47 urandom > crw-rw-rw- 1 root root 1, 5 Aug 19 22:47 zero > > and /run/schroot/mount/sid-*/dev/pts/ptmx is char device 5,2 with > permissions 0666 (because it's a new instance of devpts with ptmxmode=666). > > If I ran sbuild from a terminal, the terminal is mounted over > the schroot's /dev/console (necessary to make processes inside an > interactive schroot detect the terminal as expected). If I didn't, the > schroot's /dev/console remains as char device 5,1. > > If the regression in 1.6.13-4 had been reported as a bug, I would be > tagging it moreinfo at this point.
Possibly relevant is that dsa-puppet’s buildd schroot fstab, which we also use for the -ports buildds, has: > /dev/pts /dev/pts none rw,bind 0 0 Looking at the patch you applied to schroot, schroot’s own fstab templates had that line modified. So I suspect your patch assumes that the fstab doesn’t just bind-mount /dev/pts, which fails to account for dsa-puppet’s config? Jess
