Control: severity -1 normal
Control: retitle -1 autopkgtest-virt-schroot: cannot guarantee that $HOME is
writable
Control: found -1 2.0.0
I'm sure autopkgtest could do better to try to arrange things "normally",
and I'd be happy to review an implementation if you have one in mind,
but I don't think we can treat this as RC when autopkgtest-virt-schroot
has (as far as I can tell) always worked like this since its introduction
in 2011.
On Fri, 09 Apr 2021 at 13:24:54 +0200, Laurent Bigonville wrote:
> Le 9/04/21 à 11:09, Simon McVittie a écrit :
> > If you are using profile=default (which is the default if left unspecified),
> > /etc/schroot/default/fstab usually bind-mounts the real /home.
> >
> > If you are using profile=sbuild, /etc/schroot/sbuild/fstab usually does
> > not, making it unsuitable for autopkgtest-virt-schroot.
>
> I'm indeed using the "sbuild" profile, but I don't think that anybody would
> want to have their real home bind mounted in the chroot and mixed with the
> one from the tests
Sure, but this is not really under autopkgtest's control. You've chosen to
use a particular schroot profile which has a particular meaning, and
autopkgtest-virt-schroot is doing its best to run tests in that environment.
The responsibility for making autopkgtest implement the spec is shared
between autopkgtest itself, the virt backend (in this case -virt-schroot),
and virt-backend-specific configuration: autopkgtest can't really guarantee
that an arbitrary chroot/container/VM implements everything it needs,
because you might have given it a chroot that is missing important things
or isn't even Debian-based.
> Shouldn't HOME be pointing a temporary directory like for AUTOPKGTEST_TMP ?
That would be following the letter of the spec, but not really the spirit,
IMO. Some packages look at a user's "official" home directory (according to
getent passwd) instead of looking at $HOME, and those packages ought to be
testable too.
Setting $HOME to a temporary directory owned by the running user might be
the next best thing, and I'd be happy to review an implementation of that.
If we're root, then it might be possible to `install -d` the "official"
home directory if it doesn't already exist, and optionally mount a tmpfs
onto it? But I'm not sure whether mounting an extra tmpfs would break
schroot session teardown, and we definitely wouldn't want to do this if
autopkgtest-virt-schroot is (mis)configured to run tests as a user whose
home directory is something like /nonexistent!
If mounting an extra tmpfs doesn't break schroot teardown, then perhaps
it would be possible to mount a tmpfs on /home (if it exists), then
`install -d` the "official" home directory if it happens to be below /home,
which in practice it usually will be?
Or maybe autopkgtest could install an /etc/schroot/setup.d/ hook to set
up the desired situation during schroot setup and undo it during teardown
if asked to do so (somehow) by autopkgtest-virt-schroot?
> > I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
> > those are considerably better-tested in practice than -schroot.
>
> I should maybe look at that, but my schroot setup is usually enough for me
Given that schroot is orphaned in Debian, had its most recent upstream
release 6 years ago and is mostly only used by Debian, I'd be reluctant
to put a lot of time or work into relying on schroot, for anything where
Debian doesn't already rely on it.
For porterboxes and official buildds, we're stuck with it for now (until
someone implements first-class-citizen support for doing those things with
for example Docker, podman or systemd-nspawn, which I'm sure will happen
eventually), and for systems that aim to emulate official buildds as
closely as possible (like my "vectis"), we're also stuck with it for now;
but for things like autopkgtest that are not already particularly tied to
schroot, I think we need to be looking for an exit strategy onto a real
container manager, more than trying to turn schroot into one.
smcv
