[lmi] Unwanted schroot mounts (resolved)

[Greg Chicares]

This is just historical documentation. The problem has been
fully resolved as discussed below.

Experimenting with 'rinse' yesterday caused "disk full", and
after recovering from that, internet connectivity was gone,
so I rebooted...and now I see some unexpected mounts. I
thought I'd see only the handful specified in /etc/fstab :

#</etc/fstab sed -e'/^#/d'
LABEL=buster   /               ext4    errors=remount-ro 0       1
LABEL=grubboot /boot           ext2    defaults          0       2
/dev/sr0       /media/cdrom0   udf,iso9660 user,noauto   0       0
devpts /srv/chroot/bullseye0/dev/pts devpts 
rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
proc   /srv/chroot/bullseye0/proc    proc   rw,nosuid,nodev,noexec,relatime 0 0

along with all the usual exotica like cgroup, mqueue, etc.,
and none with UUIDs (because I'd taken care to use LABEL
in /etc/fstab). But there are unexpected mounts containing
"bullseye", although this is a "buster" system:

/home/greg[0]#grep VERSION_CODENAME /etc/os-release 
VERSION_CODENAME=buster
/home/greg[0]#grep bullseye /proc/mounts
devpts /srv/chroot/bullseye0/dev/pts devpts 
rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
proc /srv/chroot/bullseye0/proc proc rw,nosuid,nodev,noexec,relatime 0 0
/dev/sdb5 /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398 
ext4 rw,relatime,errors=remount-ro 0 0
proc /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/proc 
proc rw,nosuid,nodev,noexec,relatime 0 0
sysfs /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/sys 
sysfs rw,nosuid,nodev,noexec,relatime 0 0
udev /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/dev 
devtmpfs rw,nosuid,relatime,size=32908632k,nr_inodes=8227158,mode=755 0 0
devpts 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/dev/pts 
devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
/dev/sdb5 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/home ext4 
rw,relatime,errors=remount-ro 0 0
/dev/sdb5 /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/tmp 
ext4 rw,relatime,errors=remount-ro 0 0

The first two mounts in the list above are expected because
of the last two lines in /etc/fstab, but where do the others
come from? They contain an apparent UUID, but it's not the
UUID of any disk:

/home/greg[0]#ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 May 12 14:02 0aa85075-4320-4735-974f-26b9c7c1b6e0 -> 
../../sda2
lrwxrwxrwx 1 root root 10 May 12 14:02 656ec90b-5cce-4760-9f09-badc796d3666 -> 
../../sdb2
lrwxrwxrwx 1 root root 10 May 12 14:02 8ddb3107-2fdf-4016-9530-1432c07890c6 -> 
../../sdb1
lrwxrwxrwx 1 root root 10 May 12 14:02 d052134d-2b97-4e51-878f-1d4f8ec80a07 -> 
../../sdb3
lrwxrwxrwx 1 root root 10 May 12 14:02 d305202b-9238-4650-ae5b-556049456e33 -> 
../../sdb6
lrwxrwxrwx 1 root root 10 May 12 14:02 d6a1e16c-9993-4b28-a4e7-134124c3e0f2 -> 
../../sdb5
lrwxrwxrwx 1 root root 10 May 12 14:02 ec52e17a-a4b3-47d9-b77e-335cd8f566b7 -> 
../../sda1

It seems natural to assume that "bullseye0-aafb8581..." comes
from schroot, but this is a 2014 version of schroot:

#schroot --version
schroot (Debian sbuild) 1.6.10 (04 May 2014)

...which hasn't used UUIDs since 2013 [not! see below]:

https://launchpad.net/debian/+source/schroot/+changelog
| schroot (1.7.0-1) experimental; urgency=low
| - Remove UUID support.
| 05 May 2013 11:33:16 +0100

except that UUIDs were apparently removed in 1.7 and I have 1.6 .
[Our corporate RHEL-7.7 server has exactly the same schroot-1.6.10,
presumably thanks to "EPEL". The same goes for my centos-7.7 chroot.]

AFAICT, schroot might start up a chroot when the system is
rebooted if its "type" is something fancy, but mine are
all "plain":

#grep type /etc/schroot/chroot.d/*         
/etc/schroot/chroot.d/bullseye0.conf:type=plain
/etc/schroot/chroot.d/bullseye0.conf:#type=directory
/etc/schroot/chroot.d/centos7lmi.conf:type=plain
/etc/schroot/chroot.d/centos7old.conf:type=plain
/etc/schroot/chroot.d/lmi_bullseyeeraseme.conf:type=plain

Experimentally, I commented out the "bullseye" lines in /etc/fstab
and rebooted. The "good" mounts like
  proc /srv/chroot/bullseye0/proc proc rw,nosuid,nodev,noexec,relatime 0 0
vanished as expected, but the "bad" ones like
  udev /run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/dev 
devtmpfs
remained.

An online search led me to this schroot option:

https://manpages.debian.org/testing/schroot/schroot.1.en.html
| --recover-session
|   Recover an existing session. If an existing session has become unavailable,
|   for example becoming unmounted due to a reboot, this option will make the
|   session available for use again, for example by remounting it. The session
|   ID is specified with the --chroot option.

which inspired me to try the following commands, which worked
(after rebooting again, the bullseye-UUID mounts don't return):

#schroot --recover-session 
--chroot=session:bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398
I: Executing ‘00check setup-recover ok’
I: 00check: STAGE=setup-recover
I: 00check: STATUS=ok
...
I: 00check: CHROOT_DESCRIPTION=debian bullseye cross build (session chroot)
I: 00check: CHROOT_DIRECTORY=/srv/chroot/bullseye0
I: 00check: 
CHROOT_MOUNT_LOCATION=/var/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398
I: 00check: CHROOT_NAME=bullseye0
I: 00check: 
CHROOT_PATH=/var/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398
I: 00check: CHROOT_PROFILE=default
I: 00check: CHROOT_PROFILE_DIR=/etc/schroot/default
I: 00check: CHROOT_SESSION_CLONE=false
I: 00check: CHROOT_SESSION_CREATE=false
I: 00check: CHROOT_SESSION_PURGE=false
I: 00check: CHROOT_SESSION_SOURCE=false
I: 00check: CHROOT_TYPE=directory

Voila` the root cause. I had experimented with a "type=directory"
chroot. Although I had subsequently removed some of its files, clearly
I didn't manage to eradicate all of them.

I: 00check: CHROOT_UNION_TYPE=none
I: 00check: DATA_DIR=/usr/share/schroot
I: 00check: LIBEXEC_DIR=/usr/lib/x86_64-linux-gnu/schroot
I: 00check: MOUNT_DIR=/var/run/schroot/mount
I: 00check: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
I: 00check: PID=2714
I: 00check: PLATFORM=linux
I: 00check: PWD=/
I: 00check: SESSION_ID=bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398

I still have:

$ls /var/run/schroot/mount 
bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398

I: Executing ‘10mount setup-recover ok’
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/tmp
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/home
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/dev/pts
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/dev
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/sys
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398/proc
I: 10mount: Unmounting 
/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398
I: 10mount: Mounting /srv/chroot/bullseye0 on 
/var/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398
I: 10mount: -v --bind  /srv/chroot/bullseye0 
/var/run/schroot/mount/bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398

The "10mount" step unmounts and remounts all the aafb85 stuff.
The command I actually need is:

schroot --end-session 
--chroot=session:bullseye0-aafb8581-aa7e-4681-ae68-81ea080c5398

which unmounts and doesn't remount them. After that:

#ls -l /var/run/schroot/mount/
total 0