On Tue, 29 Jun 2021 at 10:54:59 +0000, Andrea Pappacoda wrote:
> > The version of autopkgtest-build-qemu included in autopkgtest 5.16
> > (which was current at freeze time) has never supported anything other
> > than BIOS boot, and therefore can't work on anything except x86.
>
> So for the time being we can't use autopkgtest to build non-x86 images,
> right? Are there any workarounds?
I do not know of any workarounds other than using autopkgtest-build-qemu
from git. The qemu code in autopkgtest 5.16 was written with x86 and
BIOS-boot assumptions, and the necessary generalizations and
architecture-specific quirks to deal with EFI and other architectures
simply weren't there.
The uses of autopkgtest on Debian production infrastructure use lxc,
or x86, or both.
Most of the tools in autopkgtest can be run from a git clone with no
particular build or preparation steps necessary, for example:
$ git clone https://salsa.debian.org/ci-team/autopkgtest.git
$ cd autopkgtest
$ ./tools/autopkgtest-build-qemu --arch=arm64 bullseye ~/tmp/bullseye.qcow2
I don't think the packaged autopkgtest-virt-qemu can boot aarch64 EFI
images either, but you could use autopkgtest-virt-qemu from git as well:
$ autopkgtest sed -- ./virt/autopkgtest-virt-qemu --dpkg-architecture=arm64
~/tmp/bullseye.qcow2
or to use the development version of the autopkgtest frontend too:
$ ./runner/autopkgtest sed -- ./virt/autopkgtest-virt-qemu
--dpkg-architecture=arm64 ~/tmp/bullseye.qcow2
(You shouldn't need --dpkg-architecture=arm64 or --arch=arm64 if you are
running on an aarch64 machine, only if you are emulating aarch64 on x86
or similar.)
I'll try to get a new autopkgtest uploaded to experimental at some point,
which will close this bug.
smcv
