Package: autopkgtest
Severity: normal
Tags: bookworm
Version: 5.28
User: autopkgt...@packages.debian.org
Usertags: lxc
Control: fixed -1 5.35
I'm not sure how much we really care about autopkgtest/stable when
autopkgtest/stable-backports exists, fixes this bug, is easy to install
and is used on ci.debian.net, but I'm reporting this for completeness,
because it interferes with another bug I'm looking into.
Steps to reproduce:
* Be in a Debian 12 virtual machine. I used the output of
autopkgtest-build-qemu, booted via virt-manager/libvirtd.
* apt install autopkgtest lxc
(for simplicity I installed all of their Recommends)
* autopkgtest-build-lxc debian bookworm amd64
* autopkgtest-build-lxc debian trixie amd64
* autopkgtest-build-lxc debian sid amd64
* autopkgtest hello -- lxc autopkgtest-bookworm-amd64
* autopkgtest hello -- lxc autopkgtest-trixie-amd64
* autopkgtest hello -- lxc autopkgtest-sid-amd64
Expected result: all three test runs succeed.
Actual result: bookworm testbed succeeds. sid and trixie testbeds fail
with an error message similar to:
> <VirtSubproc>: failure: (down) ['mkdir', '-m', '777',
> '/tmp/autopkgtest-lxc.XXXXXXXX/downtmp'] failed (exit status 1, stderr
> 'mkdir: cannot create directory '/tmp/autopkgtest-lxc.XXXXXXXX/downtmp':
> No such file or directory\n')
Successful workaround: upgrade autopkgtest (and no other packages) from
bookworm-backports, and run autopkgtest again. (Re-running
autopkgtest-build-lxc with the updated autopkgtest is not required.)
Not a successful workaround: upgrade autopkgtest (and no other packages)
from bookworm-backports, and run autopkgtest-build-lxc again; and then
downgrade autopkgtest to bookworm and run the test.
This probably indicates that there is a change in trixie/sid that broke
the stable autopkgtest's ability to run them as a testbed OS, and the
trixie/sid autopkgtest(-virt-lxc) has a solution or workaround for it.
I suspect that this might be caused by systemd (>= 256~rc3-3) mounting
/tmp as a tmpfs, in which case Luca's commit c6592419 "lxc: define /tmp
mount via lxc-start" might be the bug-fix we're missing; but I attempted
to work around the issue with
autopkgtest hello -- lxc autopkgtest-trixie-amd64 --define
'lxc.mount.entry=tmpfs tmp tmpfs defaults'
and that was not successful. So it might be something different.
My unsuccessful attempt to work around this by using a backported
-build-lxc together with bookworm's -virt-lxc indicates that commit
5c0be5c3 "setup-testbed: prevent /tmp from getting a tmpfs mount" is
not a solution to this either.
smcv
-- System Information:
Debian Release: 12.6
APT prefers stable
APT policy: (500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-22-amd64 (SMP w/3 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autopkgtest depends on:
ii apt-utils 2.6.1
ii libdpkg-perl 1.21.22
ii procps 2:4.0.2-3
ii python3 3.11.2-1+b1
ii python3-debian 0.1.49
Versions of packages autopkgtest recommends:
ii autodep8 0.28
ii fakeroot 1.31-1.2
Versions of packages autopkgtest suggests:
pn docker.io <none>
pn fakemachine <none>
ii lxc 1:5.0.2-1+deb12u2
pn lxd <none>
pn ovmf <none>
pn ovmf-ia32 <none>
pn podman <none>
pn python3-distro-info <none>
pn qemu-efi-aarch64 <none>
pn qemu-efi-arm <none>
pn qemu-system <none>
ii qemu-utils 1:7.2+dfsg-7+deb12u6
pn schroot <none>
ii util-linux 2.38.1-5+deb12u1
pn vmdb2 <none>
pn zerofree <none>
-- no debconf information
