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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org