[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi-commits] [lmi] master dae42d6 2/5: Let 'schroot' handle all unmount
From: |
Greg Chicares |
Subject: |
[lmi-commits] [lmi] master dae42d6 2/5: Let 'schroot' handle all unmounting for chroots |
Date: |
Tue, 7 Jul 2020 16:48:25 -0400 (EDT) |
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