Bug#862807: Testing a completely broken kernel leads to tmpfail
Package: autopkgtest
Version: 4.4
Severity: normal
Tags: upstream
Hey,
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 ]
Launched with a command of
/home/ubuntu/autopkgtest/runner/autopkgtest --output-dir /tmp/autopkgtest-work.1toxt5nd/out --timeout-copy=6000 --setup-commands /home/ubuntu/autopkgtest-cloud/worker-config-production/setup-canonical.sh --setup-commands /home/ubuntu/autopkgtest/setup-commands/setup-testbed --apt-pocket=proposed=src:linux-meta-azure --apt-upgrade glibc --timeout-test=20000 --env=ADT_TEST_TRIGGERS=linux-meta-azure/4.10.0.1005.5 --setup-commands 'apt-get install -y linux-image-azure linux-headers-azure || apt-get install -y linux-image-generic-azure linux-headers-generic-azure' -- ssh -s /home/ubuntu/autopkgtest/ssh-setup/nova -- --flavor m1.large --name adt-xenial-amd64-glibc-20170517-070322 --image 'ubuntu/ubuntu-xenial-.*-amd64-server' --keyname testbed-juju-prod-ues-proposed-migration-machine-3 --net-id=net_ues_proposed_migration -e ''"'"'http_proxy=http://squid.internal:3128'"'"'' -e ''"'"'https_proxy=http://squid.internal:3128'"'"'' -e ''"'"'no_proxy=127.0.0.1,127.0.1.1,localhost,localdomain,novalocal,internal,archive.ubuntu.com,security.ubuntu.com,ddebs.ubuntu.com,changelogs.ubuntu.com,ppa.launchpad.net'"'"'' --mirror=http://ftpmaster.internal/ubuntu
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?
Cheers,
--
Iain Lane [ iain at orangesquash.org.uk ]
Debian Developer [ laney at debian.org ]
Ubuntu Developer [ laney at ubuntu.com ]
* well, busted as far as autopkgtest is concerned - still investigating, but
one theory is that it might not be compatible with KVM intentionally
Reply to: