Bug#751574: Bug#751575: adt-virt-schroot: fails to replicate tests which pass elsewhere

Sun Jun 15 12:37:21 UTC 2014

On Sun, 15 Jun 2014 13:24:56 +0200
Martin Pitt <mpitt at debian.org> 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 at sylvester:/# cat /etc/fstab
# UNCONFIGURED FSTAB FOR BASE SYSTEM
(sid-amd64-sbuild)root at 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 at 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 at 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 at sylvester:/# mountpoint /proc
/proc is not a mountpoint
(sid-amd64-sbuild)root at sylvester:/# mountpoint /dev/pts
/dev/pts is not a mountpoint
(sid-amd64-sbuild)root at sylvester:/# mount proc -t proc /proc
(sid-amd64-sbuild)root at sylvester:/# mount devpts -t devpts /dev/pts
(sid-amd64-sbuild)root at sylvester:/# mountpoint /proc
/proc is a mountpoint
(sid-amd64-sbuild)root at sylvester:/# mountpoint /dev/pts
/dev/pts is a mountpoint

... build / test ....

Then umount these before the chroot is exited:

(sid-amd64-sbuild)root at sylvester:/# umount /dev/pts
(sid-amd64-sbuild)root at sylvester:/# umount /proc
(sid-amd64-sbuild)root at sylvester:/# mountpoint /proc
/proc is not a mountpoint
(sid-amd64-sbuild)root at sylvester:/# mountpoint /dev/pts
/dev/pts is not a mountpoint

-- 

Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20140615/617064f6/attachment.sig>