Yves-Alexis Perez wrote:
> ischroot can return 0/1 depending on if a chroot is detected or not, but
> it can also return 2 when it failed to do the detection. This might
> happen for example when /proc is not available (USEPROC=false in
> pbuilder/cowbuilder) or /proc/1 is not available in a chroot
> (grsec kernels).
This also happens in standard chroots created by debootstrap too.
Upgrading those chroots from Squeeze to Wheezy leaves the host system
in a somewhat broken state.
> Right not, initscript postinst only check for 0 / !0, which means in
> case the detection fails, it'll behaves as if it wasn't a chroot. I
> think there should be a third case for 2, where you don't know, and thus
> shouldn't fail the same way if something bad happens.
Right now if ischroot returns an error the initscripts postinst treats
it as an indication that it is not a chroot and creates bind mounts
which leave the system in a broken state. But if ischroot returns an
error then of the two present cases the safer case would be to assume
that it is running in a chroot.
With that a brute force patch here would improve things. Although I
would prefer more refactoring of the shell script and complete
avoidance of the introduced bind mounts.
--- initscripts.postinst.original 2012-08-15 18:07:37.000000000
-0600
+++ initscripts.postinst 2012-08-15 18:09:53.000000000 -0600
@@ -299,7 +299,8 @@
# alternative; a symlink will be made to avoid moving wherever
# possible.
-if ischroot; then
+ischroot
+if [ $? -ne 1 ]; then
# Symlink /var/run from /run
# Note var/run is relative
if compat_link /var/run /run; then
Bob
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
