[buildd-tools-devel] Bug#789694: schroot: Please consider patch to fix it on hurd-i386

[Gabriele Giacone]

On Thu, Jul 9, 2015 at 10:45 AM, Samuel Thibault <sthibault at debian.org> wrote:
> - debootstrap sets up a passive (i.e. permanent) bind mount from /proc
> to $CHROOT/proc

debootstrap in hurd case just runs "setup-translators -K", which sets
another passive /proc under chroot, and it bindmounts /dev and
/servers.
Bindmounts are active.
BTW patch fixes CHROOT_TYPE=file case only, I didn't spend time on
other cases. So how one creates the chroot tarball should not actually
matter.

> - schroot sets up other active bind mounts (e.g. for /dev, /servers,
> etc.) as added in gnu/fstab from your patch

Yes, /proc /dev /servers in gnu/fstab.

> - do_umount_all "$CHROOT_MOUNT_LOCATION" does not work on the Hurd
> because of bug #763932, that's why the second do_umount_all call.

Correct.

> - that second call (do_umount_all "${CHROOT_FILE_UNPACK_DIR}/${SESSION_ID}")
> manages to umount /dev, /servers etc. but not /proc because that one is
> passive, and umount doesn't unmount passive mounts. This is why the
> addition of the explicit settrans to make it go away.

Correct.

> Please correct anything wrong in this summary.  Notably I don't think
> debootstrap uses a passive translator, and thus I don't see why the
> second do_umount_all shouldn't be able to umount $CHROOT/proc actually.

As said above, debootstrap does create /proc passive translator under
chroot and maybe that would break chroot removal in CHROOT_TYPE!=file
cases. Not tested.
In CHROOT_TYPE=file case, tarball gets uncompressed, no passive
translators around, /proc /dev /servers get bindmounted and everything
works and gets removed fine. Unless... one runs setup-translators by
hand or by upgrading hurd package in chroot, that will set /proc
passive translator, which will make chroot removal fail.

I already tried to explain it at [0][1], probably fixable by making
setup-translators not to set passive /proc under chroots if already
bindmounted, as said [2] no idea how to detect that.

[0] https://lists.debian.org/debian-hurd/2014/09/msg00058.html
[1] https://lists.debian.org/debian-hurd/2015/05/msg00069.html
[2] https://lists.debian.org/debian-hurd/2014/10/msg00007.html

-- 
G..e