On 2024-05-20 17:55, Christian Kastner wrote: > Hi, > > On 2024-05-19 17:06, Wouter Verhelst wrote: >> Package: autopkgtest >> Version: 5.35 >> Severity: normal >> >>> sudo autopkgtest-build-qemu --architecture amd64 sid >>> /opt/chroots/autopkgtest-qemu.img >> >> followed by >> >>> autopkgtest . --test-name=initrd-boot -- qemu >>> /opt/chroots/autopkgtest-qemu.img >> >> in a directory that is a checkout of https://salsa.debian.org/wouter/nbd.git >> >> It installed the test dependencies, and then failed on: >> >>> autopkgtest [16:55:00]: Setting up user "user" to sudo without password... >>> qemu-system-x86_64: terminating on signal 15 from pid 150414 >>> (/usr/bin/python3) >>> autopkgtest [17:00:02]: ERROR: testbed failure: sent `auxverb_debug_fail', >>> got `timeout', expected `ok...' >> >> which I did not expect... > > I've also starting seeing this recently in the Debian ROCm Team's CI. > > In my case, this happens only with packages that have 2+ tests. When the > testbed is rebooted after the first test concludes, everything works > fine right until the "Setting up user "<user>" to sudo without > password...", and then the timeout occurs. > > In our particular case, the tests first started failing on 2024-05-17. > This was still with autopkgtest 5.34, and nothing else changed in our > infra over the past few days. > > The test trigger we recorded was "linux-signed-amd64=6.8.9+1" but that > could just be coincidental.
Hi, this seems to be the same of: https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2056461 which turned out to be a kernel bug. If you want to verify that's actually the case, I suggest running autopkgtest --debug and checking that the timeout happens during a "copydown" operation. Paride
