Package: cloud.debian.org
X-Debbugs-CC: evg...@redhat.com, ew...@redhat.com
Ohai,
we're using the debian/bullseye64 vagrant box for some automated
testing, and to allow multiple tests to run in parallel, we configure
vagrant-libvirt with `graphics_type: none` (otherwise QEMU/Libvirt
sometimes picks the same VNC port for two runs started in parallel,
which doesn't end well). Doing so removes the <graphics> and <video>
sections from the generated Libvirt XML.
This setup works quite well with several other boxes from Vagrant (we
use centos/7, centos/stream8, generic/ubuntu2004) but fails with
debian/bullseye64 (more specifically, I tried v11.20220328.1 and
v11.20220912.1). The machine just hangs at boot and Vagrant at some
point flags the boot as failed and reports a timeout.
After a bit of poking around, I managed to get to the following, rather
minimal reproducer:
qemu-system-x86_64 -m 2048 -smp 2 -snapshot -nographic <image_file>
When the `image_file` is the generic nocloud image (I used
debian-11-nocloud-amd64-20220911-1135.qcow2 today), things work fine and
I see GRUB coming up, handing over to the kernel, and some seconds later
have a login promt.
However, when I use the img file from the Vagrant box
(~/.local/share/libvirt/images/debian-VAGRANTSLASH-bullseye64_vagrant_box_image_<version>_box.img)
things hang the moment GRUB tries to render something on the screen:
SeaBIOS (version 1.16.0-1.fc36)
iPXE (https://ipxe.org) 00:03.0 CA00 PCI2.10 PnP PMM+7FF8C260+7FECC260 CA00
Booting from Hard Disk...
GRUB loading.
Welcome to GRUB!
<blinking cursor>
Given the nocloud image works, I assume the issue is somewhere in the
Vagrant specific customizations, but didn't have a deeper look yet.
Please reassign as you see fit!
As a workaround, manually adding a <video> section to the XML, or making
libvirt call QEMU otherwise with `-device cirrus-us,id=video0` works,
but is clearly not how it was intended to be.
Thanks for your work on providing those images!
Evgeni
