reassign 751574 autopkgtest 2.18 retitle 751574 schroot: refuse to work in non-ephemeral schroots thanks
Hello Neil again, Martin Pitt [2014-06-15 18:13 +0200]: > Neil Williams [2014-06-15 12:56 +0100]: > > neil@sylvester:~$ schroot -qb -c unstable > > unstable64 > > OK, this doesn't quite look like a regular session ID, I get > something like > > $ schroot -c sid -b > sid-amd64-cf55a0df-a987-47ed-b4b4-7afaed7becec Ooh, I just had an idea: In your original bug report you wrote However, schroot --location -c unstable does work: > $ schroot --location -c unstable > /srv/chroot/unstable This is definitively not a session ID, but the original chroot I assume. So I suppose what happens here is that you use "type=directory", but *no* "union-type". With "type=file" you'd get a tarball, which is unpacked into a temp dir, and after exiting the temp dir is removed. With union-type=aufs/overlayfs/unionfs you get an ephemeral overlay. But it seems you don't use either, thus anything which is done to that chroot stays around and never gets cleaned up. Thus this isn't an adequate schroot for using autopkgtest or sbuilding. You really want to only keep the pristine minimal chroot (tarball or dir) around permanently, and everything you do in it should be transient and gone after exiting the schroot. Thus I reassign this back to autopkgtest, and will add check that will just refuse working in such permanent schroots. This almost certainly also explains #751575, as I suppose schroot doesn't apply the profile's fstab/bind mounts in the "static chroot" case. Thanks, Martin P.S. You should really take another look at mk-sbuild. Whatever you did to generate your "unstable" chroot gave you something ridiculously broken :-( Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
signature.asc
Description: Digital signature
