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

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.

    smcv