lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Vadim Zeitlin
Subject: Re: [lmi] [lmi-commits] master 5c461fb 1/2: Discuss schroot strategies to handle mounts
Date: Sun, 29 Sep 2019 14:10:22 +0200

On Sat, 28 Sep 2019 22:45:01 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2019-09-28 21:30, Vadim Zeitlin wrote:
GC> > On Sat, 28 Sep 2019 16:42:36 -0400 (EDT) Greg Chicares <address@hidden> 
wrote:
GC> > 
GC> > GC> +# If the chroot is ever to be eradicated, use 
'lmi_destroy_chroot.sh',
GC> > GC> +# which, crucially, unmounts before removing.
GC> > 
GC> >  I'd also recommend using --one-file-system option of "rm" in this script
GC> > for safety.
GC> 
GC> Thanks, I'll add that.
GC> 
GC> I hadn't realized that this option was added with chroots in mind:
GC>   https://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00332.html
GC> | This option is useful when removing a build ``chroot'' hierarchy,
GC> | which normally contains no valuable data.

 Interesting, I didn't know this. Somewhat surprisingly, I've actually
found this option by reading the man page (!) because I had realized that it
wasn't a good idea to "rm -rf" a chroot directory with /home bind-mounted
under it before (!!) doing it, and so went looking at the man page to check
if there was an option that would help to avoid doing it accidentally.

GC> A day or two ago, I did execute this 'rm' command without properly
GC> unmounting first, as root, and hilarity ensued:
GC> 
GC> rm: cannot remove 
'/srv/chroot/lmi_bullseyeeraseme/proc/2719/task/2809/attr/fscreate': Operation 
not permitted
GC> rm: cannot remove 
'/srv/chroot/lmi_bullseyeeraseme/proc/2719/task/2809/attr/keycreate': Operation 
not permitted
GC> rm: ^C
GC> /root[130]#umount /srv/chroot/lmi_bullseyeeraseme/dev/pts              
GC> 
GC> Why wasn't that permitted, given
GC>   ls -l /proc/1/attr/fscreate 
GC>   -rw-rw-rw- 1 root root 0 Sep 27 00:23 /proc/1/attr/fscreate
GC> ? Because 'proc' is a virtual filesystem?

 Yes, I've never actually tried deleting anything under /proc, so I don't
know the exact reason, but it doesn't really make sense to remove a path
representing some data exported by the kernel, does it.

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

 I probably should try switching to schroot too, just for consistency with
your setup, but it's difficult to find motivation to do it as long as
accessing my chroots by ssh-ing to localhost works without any problems for
me...

 Regards,
VZ

Attachment: pgpQQ3HvBVmoL.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]