vcswatch reports that
this package seems to have a new changelog entry (version
5.17, distribution
UNRELEASED) and new commits
in its VCS. You should consider whether it's time to make
an upload.
Here are the relevant commit messages:
commit 0585a565bef0d70f649a79f2d45ff2bd373b749d
Merge: e85b337 a55a4f3
Author: Paul Gevers <elbrus@debian.org>
Date: Tue Apr 6 17:36:33 2021 +0000
Merge branch 'tr-quote' into 'master'
ssh-setup/nova: Quote arguments to `tr`
See merge request ci-team/autopkgtest!123
commit a55a4f342688569f41a2937e942bee0dc8d05be5
Author: Iain Lane <iain.lane@canonical.com>
Date: Tue Apr 6 13:24:38 2021 +0100
ssh-setup/nova: Quote arguments to `tr`
Otherwise they can be expanded as globs, which breaks badly if they
match anything in the cwd.
commit e85b337149abf19bae93a4a09ed58421e73ea246
Merge: a88a415 d8518a9
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 24 13:44:25 2021 +0000
Merge branch 'qemu-sync-prompts' into 'master'
virt-qemu: Make sure prompts correspond to commands
See merge request ci-team/autopkgtest!122
commit d8518a9cf71cebdb17932120e08f45e3ef40908e
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 24 11:08:15 2021 +0000
virt-qemu: Improve mypy annotations
Signed-off-by: Simon McVittie <smcv@debian.org>
commit f335690ce76d3d3812c508fc7f0a41c301e10007
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 24 11:07:46 2021 +0000
virt-qemu: Make sure prompts correspond to commands
Because we don't always expect() every shell prompt on the serial
console, it's possible that we send a command, wait for what we think
is the command finishing, but stop waiting too soon because we
actually saw the shell prompt corresponding to a *previous* command.
To avoid this, set a distinctive prompt: a UUID for recognition,
followed by a sequence number so we can match up commands to prompts,
followed by the usual "# ".
Signed-off-by: Simon McVittie <smcv@debian.org>
commit a88a415c444b4ab58187692b7110513b027a5b8c
Merge: f0a0278 681c185
Author: Simon McVittie <smcv@debian.org>
Date: Fri Feb 12 21:50:49 2021 +0000
Merge branch 'buildvm-ubuntu-cloud-dpkg-arch' into 'master'
autopkgtest-buildvm-ubuntu-cloud: Use correct argument name for dpkg architecture, fix call to find console socket
See merge request ci-team/autopkgtest!120
commit 681c185da4da0fb449f4aedf08972a9265034d5a
Author: Iain Lane <iain.lane@canonical.com>
Date: Fri Feb 12 16:17:05 2021 +0000
autopkgtest-buildvm-ubuntu-cloud: Use `get_console_socket()`
Commit ded58837b767ba4d00ce7c1fd0ee16564cb43df9 removed the
`ttys0_socket_path` property and provided `get_console_socket()` to get
the right socket. Use that instead.
commit ddb223cb7c2b148f0842359388bec468a67e30f0
Author: Iain Lane <iain.lane@canonical.com>
Date: Fri Feb 12 13:25:19 2021 +0000
autopkgtest-buildvm-ubuntu-cloud: Pass the `arch` argument to`boot_image()`
The code references a `--dpkg-architecture` argument which isn't
specified, but we have `--arch` which is and is already required to be a
dpkg architecture (rather than a QEMU one which e.g.
`autopkgtest-build-qemu` can accept).
commit f0a0278240081135f565e4a9c70957c79f5e08ee
Author: Simon McVittie <smcv@debian.org>
Date: Fri Feb 12 10:15:29 2021 +0000
Update changelog
commit 13688b6b1adc5022679f9f0ce305a1c480297181
Author: Simon McVittie <smcv@debian.org>
Date: Fri Feb 12 10:02:31 2021 +0000
qemu: Remove redundant '-machine virt' for ARM on aarch64
Christian Kastner pointed out that this is redundant, now that
qemu_architecture = aarch64 always implies -machine virt.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit c8321f912e6f0936d37621105a22ea248ac7cce6
Merge: 87a08c6 defff6c
Author: Simon McVittie <smcv@debian.org>
Date: Fri Feb 12 10:00:49 2021 +0000
Merge branch 'i386-efi-fix' into 'master'
Fix: i386 EFI boot requires -machine q35
See merge request ci-team/autopkgtest!119
commit defff6cc2f0c5910cef549418441c33e0cd63057
Author: Christian Kastner <ckk@debian.org>
Date: Fri Feb 12 00:16:17 2021 +0100
qemu: Use -machine q35 on i386, amd64 with EFI
Empirically, it seems to be the minimum required for EFI-booting on
i386. With the default -machine pc, some firmware error occurs.
Oddly, pc seems to be sufficient for amd64 EFI, but it would be somewhat
inconsistent to bump the machine only for one of these architectures.
According to -machine '?', q35 is a "Standard PC (Q35 + ICH9, 2009)".
commit 813b906f9f4f6f4d7f913fff83eecc3a0917f312
Author: Christian Kastner <ckk@debian.org>
Date: Fri Feb 12 00:32:21 2021 +0100
qemu: Move boot mode determination to an earlier point
The boot mode can affect the default -machine type to use. For example,
on i386, the default -machine pc is sufficient for BIOS, but not for
EFI.
commit 87a08c69a66de9b27e1b0f0d6eaf3552ddc958a1
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 21:46:53 2021 +0000
virt-qemu: Upgrade grub-pc even if devices changed
The boot device can change if we keep the same image when switching
between virtio-blk and virtio-SCSI disk devices.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 604d1fc21bbb0ebfd81d507d97a12a9245b584f8
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 19:29:45 2021 +0000
Update changelog
commit 3178613ac9c4e496157f431cd799d9740fadae9b
Merge: 3675277 34fe4bb
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 18:42:09 2021 +0000
Merge branch 'wip/smcv/aarch64' into 'master'
qemu: Do the right thing on aarch64 by default
See merge request ci-team/autopkgtest!118
commit 3675277ad200aea7b1a6ba7a267808ece715c365
Merge: 81fbfc8 ded5883
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 18:41:32 2021 +0000
Merge branch 'wip/smcv/hvc' into 'master'
qemu: Put console on hvc0 in addition to ttyS0, and root shell on hvc1 in addition to ttyS1
See merge request ci-team/autopkgtest!113
commit 81fbfc82ac9d7bb2ddb2df41df34ef40df6a5ada
Merge: f5224f8 0b4ddb4
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 18:41:06 2021 +0000
Merge branch 'wip/smcv/upgrade-grub-982296' into 'master'
qemu: Make sure we can upgrade grub-pc, if installed
See merge request ci-team/autopkgtest!117
commit f5224f8a10c4856a2d1b25b259b59fa8d87ce27c
Merge: 7af8132 748dae4
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 18:40:47 2021 +0000
Merge branch 'wip/smcv/enable-kvm' into 'master'
qemu: Infrastructure for better support for non-x86
See merge request ci-team/autopkgtest!116
commit 34fe4bb22f79e7143591d3fa79f5d22ec9b9a3c0
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 16:35:22 2021 +0000
qemu: Set a default CPU for qemu-system-aarch64
qemu-system-aarch64's default CPU is not compatible with -enable-kvm,
and doesn't seem to boot at all when emulating aarch64 on x86_64.
When running natively with -enable-kvm, we can use host or max
(presumably synonyms). Let's use host, which is more self-explanatory.
When running under emulation, -cpu max is unusably slow (at least on
x86_64). [1] mentions cortex-a53 as something that works, and that
does seem to emulate at an acceptable speed on my laptop - good enough!
[1] https://translatedcode.wordpress.com/2017/07/24/installing-debian-on-qemus-64-bit-arm-virt-board/
Thanks: Ryutaroh Matsumoto
Thanks: Peter Maydell
Signed-off-by: Simon McVittie <smcv@debian.org>
commit ded58837b767ba4d00ce7c1fd0ee16564cb43df9
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 17:30:53 2021 +0000
virt-qemu: Create serial devices for /dev/hvc0, /dev/hvc1
Instead of assuming all virtual machines have two PS/2-style serial
ports, try to use the hypervisor virtual console interface on /dev/hvc1
for our root shell, falling back to ttyS1 if that wasn't set up. As
before, reserve /dev/hvc0 for a Linux console and login prompt.
One oddity here is that in the default configuration of
qemu-system-ppc64le, the serial port is itself considered to be a
hypervisor virtual console and shows up as /dev/hvc0 inside the VM,
so we only need to create one virtio-serial device to get /dev/hvc1.
Based on a patch from Ryutaroh Matsumoto.
Thanks: Ryutaroh Matsumoto
Signed-off-by: Simon McVittie <smcv@debian.org>
commit a6ca1e4e08b3b97b9578c06de297091a652a877d
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 13:19:08 2021 +0000
qemu: Automatically select a kvm-capable VM if testing arm on aarch64
According to reports from Ryutaroh Matsumoto, qemu-system-arm cannot be
kvm-accelerated on aarch64, but qemu-system-aarch64 is kvm-accelerated
and can be told to operate in a 32-bit-only mode.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 9bb097ce6e720effcbe99ae57dc0e86d52a01f98
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 14:16:55 2021 +0000
setup-testbed: Put Linux console on all the usual console ports
Linux console logging can be directed to any number of devices, so
let's send it to all of:
* the first emulated hardware serial port, ttyS0 (x86) or ttyAMA0 (ARM)
* the first hypervisor virtual console, hvc0 (qemu, Xen, PowerPC)
* whichever graphical virtual terminal is in the foreground, tty0
(this is unnecessary for autopkgtest itself, but is convenient if
you want to boot an autopkgtest VM image interactively)
systemd should automatically start an interactive getty on each of these
via systemd-getty-generator(8).
sysvinit will not do that without further configuration, but that isn't
a regression: it already needed special configuration to put a serial
getty on ttyS0.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit a9b43fc5e3236c7e184e34b2205348c3d46cb38e
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 16:34:01 2021 +0000
qemu: Default machine type to virt for ARM family
qemu doesn't have a default machine to emulate for ARM, so we need to
select one explicitly.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 724621cd2905a2340143694b4e3c866b68809b8a
Author: Simon McVittie <smcv@debian.org>
Date: Mon Feb 8 16:22:46 2021 +0000
autopkgtest-build-qemu: Load virtio_console in the initramfs
This is a workaround for it not being built-in (#689962). If
we don't load virtio_console early enough, it won't be detected before
systemd-getty-generator(8) runs, so we won't automatically get a getty
prompt on it.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 7f9d7297b43c29b305ecd9118e73482578570c02
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 17:40:00 2021 +0000
qemu: Default to EFI boot on 32- and 64-bit ARM
This matches the behaviour of build-qemu.
Thanks: Ryutaroh Matsumoto
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 810e71ef1cba7100c7a1b303807093fbb75ca6aa
Author: Simon McVittie <smcv@debian.org>
Date: Mon Feb 8 16:30:53 2021 +0000
setup-testbed: Put root shells on both ttyS1 and hvc1 if they exist
ttyS1 is PC-specific (it's the second serial port of qemu's emulation
of the IBM PS/2's 16550 UART), whereas hvc1 is more hardware-agnostic
(it's the second virtio serial console). There's no reason why we
need to choose one or the other - we can have both.
In particular, Ryutaroh Matsumoto reports that the ARM and ppc64el
machines emulated by qemu only have one serial port available via the
-serial option (ttyAMA0 or hvc0 respectively), so we cannot rely on the
second serial port.
I'm not using hvc0 (the first virtio serial console) for this special
purpose, because it's a sensible place to put a Linux console and an
ordinary getty on any architecture, and in particular the serial port
of the default machine emulated by qemu-system-ppc64le (used for boot
messages and the Linux console) shows up as /dev/hvc0 inside the VM.
Accordingly, reserve hvc0 for either the Linux console or a placeholder,
and start from hvc1 for these autopkgtest-specific shells.
Under systemd, we do this with an instanced unit that automatically
disables itself via a Condition if the referenced device doesn't exist.
similar to the previous autopkgtest.service that hard-coded ttyS1.
Under sysvinit, we just start them all in a loop (untested, I'm not
running sysvinit on any test VMs in practice).
Thanks: Ryutaroh Matsumoto
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 16a0988560707e8ec15d2eec0c9c043ad5692e86
Author: Simon McVittie <smcv@debian.org>
Date: Mon Feb 8 16:22:18 2021 +0000
setup-testbed: Make sure /etc/init.d/ exists
It probably will, but it seems better to be sure.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 748dae4ebc032541687b85099ddc13ff010ee1cf
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 16:32:43 2021 +0000
virt-qemu: Generalize --efi into --boot, similar to build-qemu
Signed-off-by: Simon McVittie <smcv@debian.org>
commit d2350929d7d570aa71d40f15c297c56bc489a014
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 13:11:28 2021 +0000
qemu: Only -enable-kvm if VM is compatible with host architecture
Loosely based on a patch from Ryutaroh Matsumoto.
Note that ARM-specific and aarch64-specific quirks regarding machine
and CPU selection are not included here: this is only the framework.
Thanks: Ryutaroh Matsumoto
Signed-off-by: Simon McVittie <smcv@debian.org>
commit e69290066d7a6896b19b04d1111c33bc99435f27
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 13:02:37 2021 +0000
qemu: Make the qemu architecture a first-class option
Instead of guessing what qemu implementation we are using from the
qemu command, make the dpkg and qemu architectures first-class options.
If the qemu architecture is explictly given, it is used; otherwise it
is derived from the dpkg architecture if given, or derived from
`dpkg --print-architecture` on the host, or guessed from the qemu
command for backwards compatibility, or guessed from uname -m on the
host.
If the qemu command is explicitly given, it is used; otherwise it is
derived from the qemu architecture.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 8284e5dd108fa3dd104dbdcceca0cecbc78a19c7
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 18:09:11 2021 +0000
build-qemu: Update man page
Signed-off-by: Simon McVittie <smcv@debian.org>
commit de4d6073bdf5eca22d34aa2cfe0f009c8dcafcfb
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 16:32:55 2021 +0000
build-qemu: Include 'none' in choices
Fixes: 49a1aee1 "autopkgtest-build-qemu: Generalize --efi into --boot="
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 0b4ddb492c1a4847ff5ac8541be77a5b759d9971
Author: Simon McVittie <smcv@debian.org>
Date: Wed Feb 10 13:37:59 2021 +0000
qemu: Make sure we can upgrade grub-pc, if installed
vmdb2 installs grub to the boot sector, but it doesn't know what the
device name will look like in the final system, so it can't preseed
the debconf question.
If the same image is booted under different qemu configurations, the
same disk image might end up as either /dev/vda or /dev/sda, so we
set this up from first principles every time.
Closes: #982296
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 7af813215b07ea34ea889360912ee8993be7268c
Merge: 97eadcf 9e87aef
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 12:00:15 2021 +0000
Merge branch 'wip/bug926945' into 'master'
ppc64el support for autopkgtest-build-qemu (#926945)
See merge request ci-team/autopkgtest!91
commit 97eadcf73ff60ddfffeb8128f04a7b1365d8c8e1
Merge: a787902 fc1c238
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 11:59:44 2021 +0000
Merge branch 'wip/smcv/expect' into 'master'
virt-qemu: Improve ttyS0 screen-scraping
See merge request ci-team/autopkgtest!115
commit fc1c23802913820e7b0a865d066a5205bcf8c4ac
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 11:22:39 2021 +0000
virt-qemu: Don't rely on exiting from a shell printing "logout"
For some reason the root shell on /dev/hvc0 of a qemu-system-ppc64le
virtual machine doesn't do this.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 9ec855a383fee3570ceb423091221432ce60ada3
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 11:14:10 2021 +0000
virt-qemu: Cope with passwordless shell
If the specified user's password is blank, then entering the username
is enough to give us a shell.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit fbdff92cd420cc1b6a350ba1442fad17ba136a38
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 11:22:16 2021 +0000
VirtSubproc: Allow expecting multiple options
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 9e87aef9c7cf057366f90fbbfe43583bed6411bf
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 09:50:24 2021 +0000
autopkgtest-build-qemu: Add grub-ieee1275 support, default on ppc64el
Very loosely based on a patch by Thierry Fauck.
Co-authored-by: Thierry Fauck <thierry@linux.ibm.com>
Thanks: Christian Kastner
Closes: #926945
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 49a1aee1311a53176f4a45f8c9be3f08ace6a71a
Author: Simon McVittie <smcv@debian.org>
Date: Tue Feb 9 09:45:44 2021 +0000
autopkgtest-build-qemu: Generalize --efi into --boot=
This will let us add --boot=ieee1275. While I'm here, add --boot=none
for porting new architectures: in this case developers will have to set
up the bootloader via --script, or directly boot a suitable kernel with
autopkgtest-virt-qemu --qemu-options='-kernel ...'.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit b0ee468015b6dd2a31c6d8328b52d580d0edbee2
Author: Thierry Fauck <thiery@linux.vnet.ibm.com>
Date: Mon Jun 3 09:56:18 2019 +0200
Set kernel release name for ppc64el
Partially addresses #926945.
[smcv: Split out from a larger commit]
commit a7879027a546dc61bba915e7460e578fa63858c8
Merge: acf9f07 f874c77
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 18:35:32 2021 +0000
Merge branch 'uefi-support' into 'master'
build-qemu: Add UEFI support
See merge request ci-team/autopkgtest!111
commit f874c77b1901d854c98336b28f2cfaba7a04bac9
Author: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date: Mon Feb 1 06:27:56 2021 +0000
build-qemu: Add --efi option to create UEFI-bootable image
This is required for making armhf and arm64 testbeds. The built images
should also be secure-bootable on amd64 and i386 VMs.
This requires vmdb2 0.22-1~ or newer, and UEFI boot of i386 VMs needs
the ovmf-ia32 package.
commit acf9f07342b10bcd345916c3a71c6278f675e2f2
Merge: 3099810 e419eca
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 17:47:52 2021 +0000
Merge branch 'wip/smcv/fakemachine' into 'master'
build-qemu: Automatically run under fakemachine if not uid 0
See merge request ci-team/autopkgtest!114
commit e419eca35c5f76d5a018edcec11ff11432f4fd7d
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 15:32:48 2021 +0000
build-qemu: Automatically run under fakemachine if not uid 0
vmdb2 needs to run as root, but if we run it under fakemachine, it'll
be root in the virtual machine.
Signed-off-by: Simon McVittie <smcv@debian.org>
commit 3099810229147ccc70642b0b60b30e428d967062
Merge: 216c26e 1a637d2
Author: Simon McVittie <smcv@debian.org>
Date: Sun Feb 7 13:03:08 2021 +0000
Merge branch 'patch-1' into 'master'
Add unit to pflash by following the example at...
See merge request ci-team/autopkgtest!98
commit 1a637d23f6ea52ddc734cfcb12107726c101ec44
Author: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date: Mon Nov 30 01:33:04 2020 +0000
qemu: Explicitly assign unit numbers for pflash devices
This follows the example
at <https://github.com/tianocore/edk2/blob/master/OvmfPkg/README>.
OVMF_CODE seems required to be unit 0, but the unit number is implicitly
determined by the order of options to qemu, which seems fragile.
commit 216c26e7f5482c5ca82ad6d5c98c1e0c0900a5d4
Author: Simon McVittie <smcv@debian.org>
Date: Sat Jan 30 16:28:46 2021 +0000
Update changelog
commit 98798a632021dfa34ce88d336b48dc1d731f99e2
Merge: 6557d28 df15a87
Author: Simon McVittie <smcv@debian.org>
Date: Sat Jan 30 16:21:07 2021 +0000
Merge branch 'patch-2' into 'master'
Correct selection of AAVMF32
See merge request ci-team/autopkgtest!101
commit df15a87811ba4ffe66d40735b86c2f4ff57f0905
Author: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date: Mon Dec 7 11:48:18 2020 +0000
Use AAVMF32 for qemu-system-aarch64 if aarch64 is disabled
Running Debian armhf/armel VM on Debian arm64 can be accelerated
by KVM. To use KVM acceleration, one has to use qemu-system-aarch64
-machine virt -cpu host,aarch64=off, which misleads autopkgtest-virt-qemu
to select AAVMF_CODE.fd. 32-bit ARM CPUs cannot execute AAVMF_CODE.fd
which is 64-bit code, so select the correct AAVMF32_CODE.fd.
commit 6557d28d50641d74fcbb3611ccd5885121f39201
Merge: 145cbc5 758788a
Author: Simon McVittie <smcv@debian.org>
Date: Sat Jan 30 15:54:05 2021 +0000
Merge branch 'ovmf-ia32' into 'master'
virt-qemu: use ovmf-ia32 for qemu-system-i386
See merge request ci-team/autopkgtest!106
commit 145cbc5ac3bd5e4444ad037047fc16bfcc8d48f2
Merge: 4fee0d8 9eecc84
Author: Paul Gevers <elbrus@debian.org>
Date: Mon Jan 25 18:55:58 2021 +0000
Merge branch 'lxd-wait-reboot-fetch-uptime-earlier' into 'master'
lxd: Add a hook_prepare_reboot and pass arguments from it to wait_reboot
See merge request ci-team/autopkgtest!104
commit 9eecc842741630bd02fc84f40705fee4fa430572
Author: Iain Lane <iain.lane@canonical.com>
Date: Wed Dec 16 10:41:28 2020 +0000
lxd: Add a hook_prepare_reboot and pass arguments from it to wait_reboot
We've got a race condition currently. When rebooting the testbed, the
flow is like this:
hook_prepare_reboot
reboot
hook_wait_reboot
The idea is that hook_wait_reboot waits for the testbed to come back up,
so we can go on with the tests. For lxd, this means fetch the uptime,
and wait for it to go backwards, indicating the the reboot happened.
We fetch the 'initial' uptime in hook_wait_reboot, though. As this is
after we actually ask the testbed to reboot itself, there's a race
condition. If we managed to go down before we get into hook_wait_reboot,
we will not be able to get the initial uptime.
Instead, add a prepare_reboot hook to autopkgtest-virt-lxd, which
fetches the initial uptime. Then it needs to be able to return a value
back to the caller, so that wait_reboot can know what it needs to
compare to. That needs a bit of adjustment to hook_wait_reboot's
interface, to allow it to accept arguments. We make this generic, so
it's optional across backends.
commit 758788aad65ff1968f89cdf63941fb4eb2d5b383
Author: Ryutaroh Matsumoto <ryutaroh@ict.e.titech.ac.jp>
Date: Thu Jan 7 23:43:09 2021 +0000
qemu-system-i386 cannot run OVMF_CODE.fd, and 32-bit OVMF has Debian archive. Correct 32-bit OVMF should be used by autopkgtest-virt-qemu.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/a/autopkgtest.png){kind=link}