Control: forwarded -1
https://salsa.debian.org/ci-team/autopkgtest/-/merge_requests/236
On Tue, 21 Mar 2023 at 19:58:19 +0100, Helmut Grohne wrote:
> * You cannot test bootloaders with this (obviously).
> * You cannot test stuff that requires rebooting into an updated initrd
> or Linux kernel.
> * You cannot use a non-ext filesystem.
The lack of bootloaders is a bit annoying, but not necessarily fatal:
we'll often already have a different bootloader per architecture.
The inability to reboot into an updated initrd or kernel is quite
significant for autopkgtest, and I'd be very tempted to call it a
blocker: I think many of the tests that specifically want a VM, and
are not satisfied with a lxc/podman container, are going to want that
*because* they are doing kernel/initrd things. On the merge request
(thanks for opening that!) I suggested a way to fix that limitation by
running `qemu-system-whatever -no-reboot` in a loop, so that the kernel
and initrd can be re-extracted after each shutdown (where reboot(8)
in the VM is turned into a shutdown as a result of -no-reboot).
> We include python3 here, because autopkgtest-virt-qemu says so. We also
> include a generic kernel image, because debvm prefers a cloud image,
> which lacks support for the 9p filesystem used by autopkgtest-virt-qemu
> (see #1027174). Then we must enable the additional serial gettys.
You say "cloud image" here, but official Debian cloud images are
partitioned disks, and debvm uses a raw ext* filesystem filling the
entire disk (no partition table). Did you mean "cloud kernel"?
I'm already not very happy with -virt-qemu's use of screen-scraping
serial gettys, because screen-scraping an interactive shell isn't a
reliable thing to do, and the root shell on tty1/hvc1 means we end up
running the tests in a rather unrealistic environment that doesn't match
anyone's real Debian system: in practice real Debian systems are much
more likely to be server + ssh, or graphical console + display manager,
or graphical or serial console + getty, and they're certainly not what
we end up using with -virt-qemu (which is usually serial console +
passwordless root shell + su into user shell).
The way I'm hoping to resolve that is to introduce a -virt-ssh setup
script that shares code (the autopkgtest_qemu module) with -virt-qemu,
at which point we can use some sort of early-boot mechanism (perhaps
cloud-init, or the serial console, or debugfs, or a virtual CD-ROM
containing a script) to inject an authorized ssh key into the image and
(if necessary) install sshd, and then access it via ssh like an ordinary
server from then on. That'll make the test environment more realistic.
I believe the only reason we need python3(-minimal) in the image is for
the eofcat tool that is used to capture commands' stdout/stderr, which
means we can discard that when using -virt-ssh.
smcv
