Re: [lmi] [lmi-commits] master 5c461fb 1/2: Discuss schroot strategies to handle mounts

[Greg Chicares]

On 2019-09-28 21:30, Vadim Zeitlin wrote:
> On Sat, 28 Sep 2019 16:42:36 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> +# If the chroot is ever to be eradicated, use 'lmi_destroy_chroot.sh',
> GC> +# which, crucially, unmounts before removing.
> 
>  I'd also recommend using --one-file-system option of "rm" in this script
> for safety.

Thanks, I'll add that.

I hadn't realized that this option was added with chroots in mind:
  https://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00332.html
| This option is useful when removing a build ``chroot'' hierarchy,
| which normally contains no valuable data.

A day or two ago, I did execute this 'rm' command without properly
unmounting first, as root, and hilarity ensued:

rm: cannot remove 
'/srv/chroot/lmi_bullseyeeraseme/proc/2719/task/2809/attr/fscreate': Operation 
not permitted
rm: cannot remove 
'/srv/chroot/lmi_bullseyeeraseme/proc/2719/task/2809/attr/keycreate': Operation 
not permitted
rm: ^C
/root[130]#umount /srv/chroot/lmi_bullseyeeraseme/dev/pts              

Why wasn't that permitted, given
  ls -l /proc/1/attr/fscreate 
  -rw-rw-rw- 1 root root 0 Sep 27 00:23 /proc/1/attr/fscreate
? Because 'proc' is a virtual filesystem?

Fortunately, I didn't have /home mounted--only proc and devpts,
so I guess I didn't do any actual damage.

It grows more appealing to use 'type=directory' with schroot,
so that such mounts are removed automatically.