[buildd-tools-devel] Bug#579387: Bug#579387: schroot: Please allow to use variables in default/fstab

Mike Hommey mh at glandium.org
Wed Apr 28 09:18:58 UTC 2010


On Tue, Apr 27, 2010 at 04:45:04PM +0100, Roger Leigh wrote:
> Hi Mike,
> 
> On Tue, Apr 27, 2010 at 03:58:49PM +0200, Mike Hommey wrote:
> > I'm currently using the new unionfs support in schroot, which is an awesome
> > addition, but it would be useful for my setup to be able to specify variables
> > in some places of the fstab, so that I don't need to write extra setup
> > scripts.
> 
> OK.  It's good to know it's all working correctly!
> 
> > Currently, I'm removing /home from the default fstab and mount it later with
> > custom unionfs setup, and I also bind mount /var/cache/apt/archives from the
> > original chroot, so that it is not part of the unionfs.
> 
> So you have both the chroot rootfs /and/ /home as separate unions?
> Or do they share the same union overlay?

They share the same overlay, though they have to be separate mounts.

> > It would be much simpler for me (and other users, for that matter), to be able
> > to specify, say:
> > 
> > /home /home aufs br:${CHROOT_UNION_OVERLAY_DIRECTORY}/home:/home=ro 0 0
> > ${CHROOT_DIRECTORY}/var/cache/apt/archives /var/cache/apt/archives none rw,bind 0 0
> > 
> > (though in my case, there would still be a problem, as
> > ${CHROOT_UNION_OVERLAY_DIRECTORY}/home doesn't exist at first ; does
> > schroot-mount create mount points when they don't exist ?)
> 
> Yes, missing mountpoints are created recursively.
> 
> The reason we don't /currently/ support variables in the configuration
> files was for this reason: it exposes the internals of the setup
> scripts, which would mean if we were to rename or alter their use in
> the future, it could potentially break people's scripts.  For unionfs
> at least, I wanted to be sure that things were working and stable and
> wouldn't require further changes before allowing this.  So I'm not
> opposed to the idea, I just want to make sure we have the possibility
> of changing things down the line should be need to, and that we don't
> break people's systems.  One nasty example would be if we remove the
> variable and ${foo}/home evaluates to /home; for cleanup that could
> purge one's data...

OTOH, custom scripts also can use these variables, and break when the
variables names change.

> The other reason is purely technical; we read this file using
> setmntent(3)/getmntent(3), which are the POSIX interfaces to
> fstab(5) format files.  We would need to do the variable substitution
> ourselves rather than allowing shell expansion.  One approach would
> be to allow the shell setup script to evaluate and write out a
> temporary file which we can then use.
> 
> I'm aware that aufs can do some fairly complex things, but in the
> setup scripts we assume that (for the basic chroot) there's just
> an read-only "underlay" and writable "overlay".  If that assumption
> isn't always true, it would also be possible to teach the setup
> scripts and configuration file to allow more sophisticated things.

Note that in the /home case in my usecase, I'm only really interested
in having the same setup for the root directory and /home, as they are
separate mount points and as such the default setup doesn't use a union
for /home. A special syntax for that case would work for me, too.

Mike





More information about the Buildd-tools-devel mailing list