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

[Johannes Schauer]

Control: tag -1 + unreproducible moreinfo

Hi,

On Sat, 20 Sep 2014 15:25:41 +0100 Ian Campbell <ijc at debian.org> wrote:
> 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).

since I cannot reproduce this problem (sbuild with sid chroots work fine for
me) please give me a step-by-step instruction on how I get from a clean chroot
of whatever Debian release to a situation where I see your error messages.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20151224/e50a418f/attachment-0001.sig>