Hi,

In Debusine, we moved from building VM images with debos (in a UML / KVM VM) to
debefivm-create [0], which builds the base filesystem with mmdebstrap.

[0]: https://salsa.debian.org/helmutg/debvm/-/blob/main/bin/debefivm-create

This breaks this VM image detection logic:

https://salsa.debian.org/ci-team/autopkgtest/-/blob/07eb656d26b097028c28ff743f4ea7eb71bc2d01/setup-commands/setup-testbed#L72

Ideas:
1. We could just always install these root shell services (but they are
   a security risk, if these images are used for anything other than
   autopkgtest)
2. Detect a kernel?
3. Have a command line argument to install them?

Stefano

Hi


If I read the code correctly, the services loop over the devices they
know and use the first one they find. So I think more is needed than
just installing.

Paul

Yeah, I'd prefer to avoid that. A passwordless root shell on /dev/hvc1
and/or /dev/ttyS1 is non-problematic in a throwaway VM that is being run
via autopkgtest-virt-qemu, but could be a very serious problem if the VM
image is booted in some other way that we don't control.

(In the long term I still want to teach autopkgtest to communicate with
qemu VMs via ssh, so that we don't need to go to heroic efforts to
tunnel all commands through screen-scraping an interactive shell on a
serial port and writing files in a shared filesystem.)

Or an environment variable, perhaps? setup-testbed has historically not
taken command-line arguments except for the sysroot to act on, and
adding a proper command-line parser to it doesn't seem hugely appealing
when we have to write it with one hand tied behind our backs (as
described in debian/README.source it's expected to be runnable on 10+
year old operating systems).

     smcv

Hi Simon (2025.04.26_09:12:53_+0000)

Works for me!

BTW, how about making the qemu virt backend install python3 by itself,
if it's missing? Then we can use the same images for incus & qemu,
without having to pollute them with python3.

Stefano

Sorry, no. Because of the Rube Goldberg machine that
autopkgtest-virt-qemu currently uses to invoke arbitrary commands on the
testbed, it needs /usr/bin/python3 before it can run apt. It only needs
python3-minimal and not full python3, I think.

(Technically it could run apt directly in the passwordless root shell,
but then we'd have to duplicate all the machinery to make apt
noninteractive and set useful resolver options, and when something goes
wrong you wouldn't get any of the output of apt logged somewhere that
the autopkgtest caller can see it, except when using a-v-qemu --debug,
which is very noisy.)

Using ssh for command execution would address this, at the cost of
needing to preinstall either openssh-server or its dropbear equivalent.
Is that a normal thing to have in Incus VM images?

     smcv

Hi Simon (2025.04.26_18:43:26_+0000)

Yeah, I can confirm python3-minimal only seems to work.

Fair enough.

It's a "nice to have" minimal images, but not required.

For incus we have the incus-agent backdoor into VMs, which
autopkgtest-virt-incus uses. It's installed on startup by a shim that
detects a p9 filesystem housing the agent binary.

For qmeu, there is also qemu-guest-agent, I don't know if that's ever
been considered as on option for autopkgtest-virt-qemu.

Stefano