Thanks for proposing these patches, but when considering the various
patches that have been proposed for architecture support, I don't think
we can do them in a maintainable way while autopkgtest-build-qemu is
still a shell script. We have the following bugs with patches, all of
which propose switching boot from BIOS to EFI for all architectures,
and some of which propose switching the partition table from DOS to GPT
for all architectures:
* #973522 (i386 UEFI)
* #973038 (arm64 UEFI)
* #973663 (armel UEFI)
- needs support for having a secondary architecture
* #926945 (ppc64el UEFI)
- needs a small PReP partition for the firmware
- needs a special flag on that partition, with a vmdb2 patch that hasn't
been reviewed or merged yet
All of these seem like a useful proof-of-concept if the only thing you
need is the single architecture you are working on at the time, but none
of them seems like something we can merge, partly because they all touch
the same parts of the code and partly because they will cause important
regressions on architectures that already work.
In particular, qemu on x86 defaults to providing BIOS rather than EFI
firmware, which means that if we applied any of these, the ability to
build and boot x86 qemu images would regress. Features that already
work need to continue to work, and that's more important than having
new features.
I think there is also a danger that if we try to add too many things to
autopkgtest-build-qemu, it will end up with the same problems that led
to vmdebootstrap version 1 being discontinued - too many special cases,
too many code paths, and not possible to test for regressions in a
reasonable time - so we should be a bit careful about what we're willing
to merge into that script.
I think the best route for all these architectures goes something like
this:
* Make sure that if you have prepared an image by hand,
autopkgtest-virt-qemu can boot it. This might mean adding new code
paths for the --efi and/or --secure-boot options, or even turning on
EFI by default for certain architectures. It is going to be quicker to
review and test these if you can provide patches against the autopkgtest
source code (<https://salsa.debian.org/ci-team/autopkgtest/> or
`apt-get source autopkgtest`) instead of the installed files in /usr,
and especially if you can send patches as a merge request at
<https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests>.
* Make sure that there is a way to get a bootable Debian and/or Ubuntu
cloud image for that architecture: as discussed on #944386, I'd
like to use cloud images as the primary way to get a bootable image
for new architectures, because those are something that we're going
to want for new architectures *anyway*. Have a way to convert these
cloud images into something that autopkgtest-virt-qemu can use. At the
moment autopkgtest-buildvm-ubuntu-cloud only works for Ubuntu images,
but I want to make that or a similar script work similarly for Debian
cloud images as discussed on #944386.
* An autopkgtest maintainer (most likely to be me) should convert
autopkgtest-build-qemu from a shell script into a Python script,
so that instead of using simple string substitutions, it can build
the vmdb2 recipe using python3-yaml, preserving its structure.
* After autopkgtest-build-qemu is a Python script, we can consider giving
it an option that creates and populates the EFI system partition. That
option can perhaps be on by default for ARM and ppc64el, but it should
not be the default for x86, unless we can build x86 images that are
bootable in BIOS *and* UEFI mode.
* As we get new architecture support in OVMF and vmdb2, we can consider
setting up those architectures in autopkgtest-build-qemu.
smcv
