On 13 Nov 2024, at 11:03, Simon McVittie <s...@debian.org> wrote: > > On Wed, 13 Nov 2024 at 10:55:59 +0000, Jessica Clarke wrote: >> [pbuilder? has] mounted /proc for quite a few years now similarly to how >> schroot >> recently started to, but /proc/*/fd/N has always been a little broken. >> Isn’t that also true of schroot though? I seem to recall observing the >> same thing there when testing the new schroot code recently. > > All I can say is that when I tested the xorg-server change, it built > successfully in the bookworm versions of sbuild/schroot, in a bookworm VM. > > One possibility is that sbuild/schroot might make stderr a pipe, which can > be reopened via /proc/self/fd/2; but pbuilder might make it an open fd > to a log file owned by some other uid, which might not be reopenable? > Or something like that?
Uh, I meant to refer to schroot’s new */dev/pts* behaviour. Have you tried the trixie/sid version? I expect you’ll see similar issues. You end up with the following: (sid_ppc64-dchroot)jrtc27@perotto:~$ ls -l /proc/self/fd total 0 lrwx------ 1 jrtc27 jrtc27 64 Nov 13 11:06 0 -> /dev/pts/0 lrwx------ 1 jrtc27 jrtc27 64 Nov 13 11:06 1 -> /dev/pts/0 lrwx------ 1 jrtc27 jrtc27 64 Nov 13 11:06 2 -> /dev/pts/0 lr-x------ 1 jrtc27 jrtc27 64 Nov 13 11:06 3 -> /proc/934851/fd (sid_ppc64-dchroot)jrtc27@perotto:~$ ls -l /dev/pts total 0 crw-rw-rw- 1 root root 5, 2 Nov 13 11:06 ptmx This worked prior to your /dev/pts changes as you’d get the same /dev/pts as the host with all the other PTYs, but now I expect will see the same error. This isn’t really a new problem, it’s just another case similar to redirecting to a file that lives outside the chroot, for which neither chroot tool currently has a general solution. Jess
