[lmi-commits] [lmi] master dae42d6 2/5: Let 'schroot' handle all unmounting for chroots

[Greg Chicares]

branch: master
commit dae42d6be01a64b8e4a62021cbcfb83228d7a85a
Author: Gregory W. Chicares <gchicares@sbcglobal.net>
Commit: Gregory W. Chicares <gchicares@sbcglobal.net>

    Let 'schroot' handle all unmounting for chroots
---
 lmi_setup_02.sh  | 25 ++++++-------------------
 lmi_setup_02c.sh | 20 +++++++-------------
 2 files changed, 13 insertions(+), 32 deletions(-)

diff --git a/lmi_setup_02.sh b/lmi_setup_02.sh
index 4e1691c..4e31fe5 100755
--- a/lmi_setup_02.sh
+++ b/lmi_setup_02.sh
@@ -29,17 +29,13 @@ set -evx
 assert_su
 assert_not_chrooted
 
-# umount expected mounts, then list any that seem to have been missed.
+# Show all lmi mountpoints; abort if there are any.
 #
-# It might seem snazzier to extract the relevant field of
-#   grep "${CHRTNAME}" /proc/mounts
-# and pipe it into
-#   xargs umount
-# but that would do something astonishing if two chroots (one nested
-# and the other not) have mounted /proc thus:
-#   proc /srv/chroot/"${CHRTNAME}"/proc
-#   proc /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/proc
-# and only the non-nested one is intended to be destroyed.
+# The most likely cause is that a user has entered the chroot with
+# 'schroot', but has not yet left it. Otherwise, this "shouldn't"
+# occur (although it has been observed), and 'rm --one-file-system'
+# below should be safe anyway (yet an actual catastrophe did occur
+# nonetheless).
 #
 # The 'findmnt' invocation is elaborated thus:
 #   -r
@@ -69,20 +65,11 @@ assert_not_chrooted
 #   | column -t
 # along with '-r' because '-l' does a poor job of columnization.
 
-umount /srv/chroot/"${CHRTNAME}"/srv/cache_for_lmi      || true
-umount /srv/chroot/"${CHRTNAME}"/var/cache/apt/archives || true
-umount /srv/chroot/"${CHRTNAME}"/dev/pts                || true
-umount /srv/chroot/"${CHRTNAME}"/proc                   || true
-
 findmnt -ro SOURCE,TARGET \
   | grep "${CHRTNAME}" \
   | sed -e's,^[/A-Za-z0-9_-]*[[]\([^]]*\)[]],\1,' \
   | column -t
 
-# Abort if any $CHRTNAME mountpoint remains.
-#
-# This shouldn't occur, and 'rm --one-file-system' below should be
-# safe anyway, yet an actual catastrophe did occur nonetheless.
 findmnt | grep "${CHRTNAME}" && exit 9
 
 # Use '--one-file-system' because it was designed for this use case:
diff --git a/lmi_setup_02c.sh b/lmi_setup_02c.sh
index 3f77bfa..d962736 100755
--- a/lmi_setup_02c.sh
+++ b/lmi_setup_02c.sh
@@ -29,25 +29,19 @@ set -evx
 assert_su
 assert_not_chrooted
 
-umount /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/srv/cache_for_lmi      
|| true
-umount /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/var/cache/apt/archives 
|| true
-umount /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/dev/pts                
|| true
-umount /srv/chroot/centos7lmi/srv/chroot/"${CHRTNAME}"/proc                   
|| true
-umount /srv/chroot/centos7lmi/srv/cache_for_lmi      || true
-umount /srv/chroot/centos7lmi/var/cache/lmi_schroots || true
-umount /srv/chroot/centos7lmi/var/cache/yum          || true
-umount /srv/chroot/centos7lmi/dev/pts                || true
-umount /srv/chroot/centos7lmi/proc                   || true
+# Show all centos lmi mountpoints; abort if there are any.
+#
+# The most likely cause is that a user has entered the chroot with
+# 'schroot', but has not yet left it. Otherwise, this "shouldn't"
+# occur (although it has been observed), and 'rm --one-file-system'
+# below should be safe anyway (yet an actual catastrophe did occur
+# nonetheless).
 
 findmnt -ro SOURCE,TARGET \
   | grep centos7lmi \
   | sed -e's,^[/A-Za-z0-9_-]*[[]\([^]]*\)[]],\1,' \
   | column -t
 
-# Abort if any centos lmi mountpoint remains.
-#
-# This shouldn't occur, and 'rm --one-file-system' below should be
-# safe anyway, yet an actual catastrophe did occur nonetheless.
 findmnt | grep 'centos.*lmi' && exit 9
 
 loc0=/srv/chroot/centos7lmi