[buildd-tools-devel] Bug#762597: Bug#762597: /var/lib/schroot/mounts should be in /var/run for --one-file-system

[Wookey]

+++ Roger Leigh [2014-11-24 13:43 +0000]:
> On Tue, Sep 23, 2014 at 03:55:40PM +0100, Ian Jackson wrote:
> > If you have a directory schroot chroot whose source directory is the
> > same as /, schroot's bind mount in /var/lib/schroot/mounts is
> > invisible to file tree walking tools.
> > 
> > That is, rsync --one-file-system (rsync -x), cp --one-file-system
> > (cp -x), find -xdev, etc., do not notice the mount point, and
> > typically traverse through it.
> > 
> > This is far from ideal.  Now arguably this is a bug in bind mounts
> > (perhaps a design bug).  But as it happens it is easy to work around
> > this problem in schroot in a way that is both correct and will fix
> > almost all the problems:
> > 
> > Move /var/lib/schroot/mounts to /var/run/schroot/mounts or some such.
> > 
> > Typically /var/run is a tmpfs.  As a result there will be a filesystem
> > with a different devid between / and the chroot.  So to all the file
> > tree walkers, it will look like two mount points.  Backup tools,
> > find, etc., will not descend into schroot's bind mount because they'll
> > stop at /var/run.
> 
> Hmm, this is an interesting problem.  Your proposed solution would
> certainly provide a boundary to stop traversal, but I'm not sure it
> would help in all situations, since e.g. for file-based chroots we
> unpack them under /var/lib/schroot.  Putting the mounts themselves
> under /var/run should be safe enough though.

> I'll need to do some testing of this to make sure it doesn't
> break anything.  If you have any further thoughts or ideas, please
> do let me know!

As a heavy schroot user, I've certainly had plenty of (mostly minor)
trouble with tools descending into the chroots and thus getting
double-counting of disk usage, recursive copying, repeatedly-mounted
locate results and so on. So I agree with Ian that it is a problem,
and I'd like to see this improved.

I worry that using /var/run would introduce limits around the size of
the tmpfs and recoving sessions after reboot (due to lack of
persistence), but maybe if it really is only the mount point in there
and not the actual data then this will work out OK? I admit to being
vague about the details of how this all actually fits together.

So yes, please do try it and see how it works. I work mostly with
tarball chroots and sometimes lvm chroots, and sometimes plain chroots
so can help testing those.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/