On Tue, 20 Aug 2024 at 00:59:30 +0100, Jessica Clarke wrote: > On 20 Aug 2024, at 00:23, Simon McVittie <s...@debian.org> wrote: > > I was unable to reproduce this build failure ... > > There must presumably be something different about how sbuild-createchroot > > and schroot are configured or invoked on the affected buildds > > 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?
Yes, probably that. The patch I contributed to schroot involves a coordinated change to the various profiles' fstab templates and the 10mount script, so it's unlikely to work as intended if local configuration reverts half of that change while keeping the other half intact. The reason for the regression is probably that /dev/pts/ptmx on the host has permissions 000, making it inaccessible (despite being functionally equivalent to /dev/ptmx which is available to everyone). I'm not sure I ever understood why that was considered to be a useful default, even in 2017 when I originally looked at this. Bind-mounting the inaccessible device onto /dev/ptmx results in an inaccessible /dev/ptmx, which is certainly not what we want. It would probably be possible to drop the bind-mounting onto /dev/ptmx with modern kernels - it was functionally relevant when I originally contributed the patch in 2017 because the commit https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=eedf265aa003b4781de24cfed40a655a664457e6 was rather recent at that time, but hopefully we no longer have any machines that are running Debian 8 kernels... Unfortunately I'm not seeing a way to get the behaviour where schroot behaves like other container managers (mounting a new instance of /dev/pts) while being resilient against local configuration that continues to hard-code that we will not be doing that. Possibly some sort of fstab.d arrangement so that it's possible to override part of /etc/schroot/*/fstab without having to copy-and-modify the whole thing? But then the configuration in dsa-puppet would still have to change to accommodate that. (As far as I can see, the fstab configuration in dsa-puppet is intended to add some lines to schroot's defaults, rather than forcing specific handling for /dev/pts, but it forces specific handling for /dev/pts as a side-effect because it's overwriting the whole file.) smcv
