Control: tag -1 + unreproducible moreinfo Hi,
On Sat, 20 Sep 2014 15:25:41 +0100 Ian Campbell <[email protected]> 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
signature.asc
Description: signature
