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 and
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
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__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!
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 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
