Re: Bug#983423: schroot: regression presumably in 1.6.13-4 after fixing #983423

On 20 Aug 2024, at 00:23, Simon McVittie <[email protected]> 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