Processed: Re: Bug#986665: $HOME not writable when using schroot
Processing control commands: > severity -1 normal Bug #986665 [autopkgtest] $HOME not writable when using schroot Severity set to 'normal' from 'serious' > retitle -1 autopkgtest-virt-schroot: cannot guarantee that $HOME is writable Bug #986665 [autopkgtest] $HOME not writable when using schroot Changed Bug title to 'autopkgtest-virt-schroot: cannot guarantee that $HOME is writable' from '$HOME not writable when using schroot'. > found -1 2.0.0 Bug #986665 [autopkgtest] autopkgtest-virt-schroot: cannot guarantee that $HOME is writable Marked as found in versions autopkgtest/2.0.0. -- 986665: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986665 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#986665: $HOME not writable when using schroot
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
Bug#986665: $HOME not writable when using schroot
Le 9/04/21 à 11:09, Simon McVittie a écrit :
On Fri, 09 Apr 2021 at 10:37:59 +0200, Laurent Bigonville wrote:
The dep8 specification says:
Tests can expect that the ``$HOME`` environment variable to be set
to a directory that exists and is writeable by the user running the test.
But when using schroot (not tried anythong else), $HOME is set to the
HOME of the user running the autopkgtest and does not exists in the
schroot. So either the spec is wrong or the implementation.
What schroot configuration are you using? Relevant information:
* your user's home directory
* the file in /etc/schroot/chroot.d defining the chroot you're using
* /etc/schroot/${profile}/fstab, where ${profile} is taken from the
chroot's configuration
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.
Using a chroot that contains a pre-created home directory for the user
running autopkgtest is also an option, but this is not currently something
that can be set up automatically.
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
Shouldn't HOME be pointing a temporary directory like for AUTOPKGTEST_TMP ?
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
Bug#986665: $HOME not writable when using schroot
On Fri, 09 Apr 2021 at 10:37:59 +0200, Laurent Bigonville wrote:
> The dep8 specification says:
>
> Tests can expect that the ``$HOME`` environment variable to be set
> to a directory that exists and is writeable by the user running the test.
>
> But when using schroot (not tried anythong else), $HOME is set to the
> HOME of the user running the autopkgtest and does not exists in the
> schroot. So either the spec is wrong or the implementation.
What schroot configuration are you using? Relevant information:
* your user's home directory
* the file in /etc/schroot/chroot.d defining the chroot you're using
* /etc/schroot/${profile}/fstab, where ${profile} is taken from the
chroot's configuration
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.
Using a chroot that contains a pre-created home directory for the user
running autopkgtest is also an option, but this is not currently something
that can be set up automatically.
I would recommend using autopkgtest-virt-lxc or autopkgtest-virt-qemu:
those are considerably better-tested in practice than -schroot.
smcv
Bug#986665: $HOME not writable when using schroot
Package: autopkgtest Version: 5.16 Severity: serious Hello, The dep8 specification says: Tests can expect that the ``$HOME`` environment variable to be set to a directory that exists and is writeable by the user running the test. But when using schroot (not tried anythong else), $HOME is set to the HOME of the user running the autopkgtest and does not exists in the schroot. So either the spec is wrong or the implementation. Kind regards, Laurent Bigonville -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy Versions of packages autopkgtest depends on: ii apt-utils 2.2.2 ii libdpkg-perl1.20.7.1 ii procps 2:3.3.17-5 ii python3 3.9.2-3 ii python3-debian 0.1.39 Versions of packages autopkgtest recommends: ii autodep8 0.24 Versions of packages autopkgtest suggests: pn lxc pn lxd ii ovmf 2020.11-4 pn qemu-efi-aarch64 pn qemu-efi-arm pn qemu-system ii qemu-utils1:5.2+dfsg-9 ii schroot 1.6.10-12 pn vmdb2 -- no debconf information
