[buildd-tools-devel] Bug#762280: sbuild: Problems with /dev/shm symlinked to /run

[Ian Campbell]

Package: sbuild
Version: 0.64.2-1
Severity: normal

Dear Maintainer,

It's possible that this is mostly a schroot rather than sbuild issue but since
at least some of it appears to be sbuild related I'm filing here first.

Recently I have started seeing:

$ sbuild --dist sid --arch i386
[...]
E: 10mount: E: Failed to resolve path “/var/lib/schroot/mount/sid-i386-sbuild-38bcf41e-5a6e-4b07-9a4c-ebb5ab330da4/dev/shm”: Not a directory
E: sid-i386-sbuild-38bcf41e-5a6e-4b07-9a4c-ebb5ab330da4: Chroot setup failed: stage=setup-start
Chroot setup failed

This seems to be due to /dev/shm being a symlink to /run/shm. At first I
thought this was due to a recent update in sid/jessie but looking at my
existing chroots it seems that this already became a symlink for Wheezy, so I
guess it must be a sbuild/schroot change (but I'm not sure what, everything
related which I spot in changelog.Debian.gz was many moons ago).

My first thought was to change /etc/schroot/sbuild/fstab to remove:
-tmpfs           /dev/shm        tmpfs   defaults        0       0
and add
+tmpfs           /run            tmpfs   defaults        0       0

This fixed bare invocations of "schroot -c sid-i386-sbuild" but not sbuild
which now fails with:

$ sbuild --dist sid --arch i386
[...]
Failed to create lock file /var/lock/sbuild: No such file or directory
E: Error locking chroot session: skipping xss-lock

This is because /var/lock is also a symlink (to ../run/lock) and /run/lock does
not exist, because of the newly added tmpfs. The chroot filesystems contain a
bunch of things, including /run/lock which were created somewhere along the
line, but which are shadowed by the tmpfs.

Lastly I tried adding at the very end of /etc/schroot/setup.d/10mount:

if [ ! -d $CHROOT_PATH/var/lock/ ] ; then
    mkdir -p $CHROOT_PATH/var/lock
    chown -R root:sbuild "$CHROOT_PATH/var/lock"
    chmod -R 02775 "$CHROOT_PATH/var/lock"
fi

Which fixes things for a Wheezy+ chroot, but due to the change to fstab
/dev/shm in Squeeze and earlier will no longer be a tmpfs. I'm not sure how
best to fix all kinds of chroot.

An alternative to editing /etc/schroot/setup.d/10mount seems to be to list
/run/shm in fstab instead of either /dev/shm or /run. This might be better WRT
chroots which contain packages which assume /run (or things linked to it) are
persistent, but it also has similar issues WRT chroots which have a real
/dev/shm and not a symlink (i.e. squeeze).

Cheers,
Ian.
 
-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf
armel

Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages sbuild depends on:
ii  adduser         3.113+nmu3
ii  apt-utils       1.0.7
ii  libsbuild-perl  0.64.2-1
ii  perl            5.20.0-4
ii  perl-modules    5.20.0-4

Versions of packages sbuild recommends:
ii  debootstrap  1.0.61
ii  fakeroot     1.20.1-1.1

Versions of packages sbuild suggests:
ii  deborphan  1.7.28.8
ii  wget       1.15-1+b1

-- no debconf information