[Debian-iot-maintainers] autopkgtest on s390x (was: Migration blocked by tests of depending package)
Simon McVittie
smcv at debian.org
Sat Oct 26 11:15:41 BST 2024
On Sat, 26 Oct 2024 at 11:02:29 +0200, Joachim Zobel wrote:
> I have tried all available --boot options for autopkgtest with s390x
> and was not able to create an image
I suspect you mean autopkgtest-{build,virt}-qemu. autopkgtest itself (the
test runner) does not have a --boot option.
The ci.debian.net infrastructure does not use autopkgtest-{build,virt}-qemu
on s390x. Instead, it sends jobs to a pre-existing s390x worker machine
(probably a VM, but I don't know) and the worker machine runs the tests
using autopkgtest-virt-lxc, most likely something like this:
autopkgtest ./package.dsc -- lxc autopkgtest-sid
where the autopkgtest-sid lxc image was probably generated by
autopkgtest-build-lxc.
To run an emulated or virtual s390x machine via qemu, there are two steps:
build the image (autopkgtest-build-qemu or manually), and then boot it
(autopkgtest-virt-qemu or manually).
If there is a way for autopkgtest-build-qemu to install a bootloader
into a qemu image and make it bootable by qemu, s390x porters or other
interested developers would be very welcome to provide a MR adding
it. I would guess that it will be most similar to the --boot=bios and
--boot=ieee1275 code paths. Depending on how booting a s390x VM works,
it might be possible to do this purely within autopkgtest-build-qemu,
or it might require changes in vmdb2 first. I assume this would have
something to do with the zipl bootloader, which is packaged in s390-tools
and seems to be vaguely "the same shape" as syslinux, but I don't know
the specifics.
autopkgtest-virt-qemu can run images prepared via autopkgtest-build-qemu,
but can also run images prepared in some other way (for example manually,
using debian-installer). It only needs a special --boot option if there
is something extra that needs to be added to the qemu command-line to
make the bootloader work: currently --boot=bios, --boot=ieee1275 and
--boot=none are functionally equivalent (they just run qemu in the obvious
way and hope that a bootloader comes up), and it's only --boot=efi that
is special (it needs to add appropriate emulated flash devices containing
EFI firmware).
smcv
More information about the Debian-iot-maintainers
mailing list