Control: tags -1 confirmed Hi,
On Wed, 17 May 2017 11:47:39 +0100 Iain Lane <[email protected]> wrote:
We just got a busted* kernel "linux-azure" in Ubuntu's xenial-proposed. It failed like so: May 17 07:36:27 machine sh[31524]: Setting up linux-image-azure (4.10.0.1005.5) ... May 17 07:36:27 machine sh[31524]: autopkgtest [07:30:56]: rebooting testbed after setup commands that affected boot May 17 07:36:27 machine sh[31524]: Exit request sent. May 17 07:36:27 machine sh[31524]: autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... May 17 07:36:27 machine sh[31524]: autopkgtest-virt-ssh: WARNING: ssh connection failed. Retrying in 3 seconds... [ … until timeout, tmpfail, loop, worker death, no workers left, huge queue, crying, end of the world ]
Is there a good way to handle this in autopkgtest? Maybe: if testing a kernel (in triggers or as the real pkg), a failure to reboot after installing the new kernel is a real and not a testbed failure?
I don't think autopkgtest should care about what triggered the test, but if it successfully connected to the testbed before the reboot, the test should indeed fail and not tmpfail (blaming "infrastructure"). It should be up to the test submitter (human or tools) to blame whatever needs blaming. britney2 in Debian will retry after a day anyways, so if this really would be infrastructure, the failure would go away the next day.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
