On Sun, 15 Jun 2014 13:24:56 +0200 Martin Pitt <[email protected]> wrote:
> retitle 751575 schroot fails with /dev/fd/62: No such file or > directory thanks > > Hey Neil, > > Neil Williams [2014-06-14 13:46 +0100]: > > E: Can not write log (Is /dev/pts mounted?) - openpty (2: No such > > file or directory) Setting up adt-satdep (0) ... $ schroot -c unstable -u root -d / I: [unstable64 chroot] (neil→root) Running login shell: ‘/bin/bash’ (sid-amd64-sbuild)root@sylvester:/# cat /etc/fstab # UNCONFIGURED FSTAB FOR BASE SYSTEM (sid-amd64-sbuild)root@sylvester:/# Hmm. Doesn't cause issues for other uses of sbuild though. > This error from apt might be insightful: Which profile does your > schroot use, and what is your corresponding > /etc/schroot/<profile>/fstab ? > > I use the "default" profile for my schroots which bind-mounts /dev/, > /dev/pts, and /dev/shm. (First I've seen of schroot profiles and the man page describes schroot-script-config which itself is deprecated, for profile support.) I don't see how to discover which profile might be in use (I suspect none or "default") or how to add a profile to the existing schroot configuration without using the deprecated script-config which sounds like an awful hack which autopkgtest should not require. > The "sbuild" profile still bind-mounts /dev/pts, so I suppose you are > using something else. ? I've no idea. I have made no profile settings of any kind and there is no need for profiles in the normal use of an sbuild chroot it appears. I don't see any /dev/pts notices when installing build-dependencies for package builds using sbuild. > However, even if I comment out /dev/pts from > /etc/schroot/sbuild/fstab, I do get this error from apt (which doesn't > stop autopkgtest), but I still don't get the main error: > > > adt-run [2014-06-14 13:39:52]: & apt0t-testsuite: > > [----------------------- bash: line 10: /dev/fd/62: No such file or > > directory > > I think the most likely explanation for this is that your schroot > doesn't have /proc bind-mounted, as /dev/fd is usually a symlink to > /proc/self/fd (please double-check in your schroot). If I explicitly mount proc and devpts inside the schroot (and hack around to fix #751574) I do now get a pass. $ mount .... proc on /srv/chroot/unstable/proc type proc (rw,relatime) devpts on /srv/chroot/unstable/dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000) ... Ran 302 tests in 0.059s OK adt-run [2014-06-15 13:24:30]: & apt0t-testsuite: -----------------------] <VirtSubproc>: debug: executing copyup /tmp/adt-run.8SUbwc/apt0t-testsuite-stdout /srv/chroot/unstable//tmp/adt-run.8SUbwc/apt0t-testsuite-stdout <VirtSubproc>: debug: copyup_shareddir: tb /tmp/adt-run.8SUbwc/apt0t-testsuite-stdout, host /srv/chroot/unstable//tmp/adt-run.8SUbwc/apt0t-testsuite-stdout, is_dir False, downtmp_host /srv/chroot/unstable//tmp/adt-run.8SUbwc <VirtSubproc>: debug: executing copyup /tmp/adt-run.8SUbwc/apt0t-testsuite-stderr /srv/chroot/unstable//tmp/adt-run.8SUbwc/apt0t-testsuite-stderr <VirtSubproc>: debug: copyup_shareddir: tb /tmp/adt-run.8SUbwc/apt0t-testsuite-stderr, host /srv/chroot/unstable//tmp/adt-run.8SUbwc/apt0t-testsuite-stderr, is_dir False, downtmp_host /srv/chroot/unstable//tmp/adt-run.8SUbwc adt-run: & apt0t-testsuite: - - - - - - - - - - results - - - - - - - - - - apt0t-testsuite PASS adt-run: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ tests done. <VirtSubproc>: debug: executing close Unmount /srv/chroot/unstable/proc and /srv/chroot/unstable/dev/pts and the test fails again, same way as before. > If I comment out the /proc bind mount from /etc/schroot/*/profile, I > get exactly the same error. > > If you use any kind of nontrivial stdin/out/err redirections in > dash/bash that will use /dev/fd/ rather heavily. A lot of other stuff > will also fail without /proc/ in your schroot, so I'm rather surprised > that you never noticed that? I can only assume that sbuild manages all of this internally. Equally, I don't habitually create an /etc/fstab for other chroots or root filesystems, especially for /proc or /dev. Incidentally, pbuilder does just the same root@sylvester:/# mount /proc on /proc type proc (rw,relatime) tmpfs on /run/shm type tmpfs (rw,relatime) /dev/pts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) root@sylvester:/# cat /etc/fstab # UNCONFIGURED FSTAB FOR BASE SYSTEM It's just that schroot doesn't - sbuild is probably the one doing it. I think adt-virt-schroot should check and ensure that these are mounted without needing changes to the schroot configuration. > So to guard against this I could add an explicit test for > "bind-mounted /proc" to the schroot runner; but a schroot without > /proc is rather useless, so it's a bit of a surprise that folks have > them in the first place :-) I suggest that adt-virt-schroot checks for /proc and /dev/pts being mounted inside the chroot and mounts them itself if not. (sid-amd64-sbuild)root@sylvester:/# mountpoint /proc /proc is not a mountpoint (sid-amd64-sbuild)root@sylvester:/# mountpoint /dev/pts /dev/pts is not a mountpoint (sid-amd64-sbuild)root@sylvester:/# mount proc -t proc /proc (sid-amd64-sbuild)root@sylvester:/# mount devpts -t devpts /dev/pts (sid-amd64-sbuild)root@sylvester:/# mountpoint /proc /proc is a mountpoint (sid-amd64-sbuild)root@sylvester:/# mountpoint /dev/pts /dev/pts is a mountpoint ... build / test .... Then umount these before the chroot is exited: (sid-amd64-sbuild)root@sylvester:/# umount /dev/pts (sid-amd64-sbuild)root@sylvester:/# umount /proc (sid-amd64-sbuild)root@sylvester:/# mountpoint /proc /proc is not a mountpoint (sid-amd64-sbuild)root@sylvester:/# mountpoint /dev/pts /dev/pts is not a mountpoint -- Neil Williams ============= http://www.linux.codehelp.co.uk/
signature.asc
Description: PGP signature
