Bug#862807: Testing a completely broken kernel leads to tmpfail

[Iain Lane]

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