Package: autopkgtest
Version: 5.47
Severity: normal

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

if [ "$root" != "/" ] || [ -e /dev/ttyS1 ] || [ -e /dev/hvc1 ]; then

$root is / and the host's serial devices are... whatever they are.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 25 Apr 2025 at 18:15:56 -0400, Stefano Rivera wrote:

This breaks this VM image detection logic:

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

if [ "$root" != "/" ] || [ -e /dev/ttyS1 ] || [ -e /dev/hvc1 ]; then

$root is / and the host's serial devices are... whatever they are.

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)

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.)

3. Have a command line argument to install them?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

3. Have a command line argument to install them?

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).

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

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 26 Apr 2025 at 13:20:06 +0000, stefanor@debian.org wrote:

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

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.

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

(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.)

Fair enough.

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

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?

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

--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)