Recently, images ćreated for UEFI systems fail to boot. I can reproduce the problem with the base.vmdb2 file from tje vmb2 source. If I change that file to create an image for Bookworm and boot it with QEMU, I end up in the Grub shell. If I create an image for Ubuntu, I do not even get there. I can boot into a live system, mount all necessary devices and run 'dpkg-reconfigure grub-efi-amd64', and then it usually boots. vmdb2 shows no errors during its operation. Interestingly, the same appears to happen with vmdb2 in Bookworm. Given that vmdb2 also hasn't seen any recent uploads, a third-party might be the culprit here. Images built for BIOS are not affected. Regards, Daniel - -- System Information: Debian Release: 13.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.12.33+deb13-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vmdb2 depends on: ii debootstrap 1.0.141 ii e2fsprogs 1.47.2-3+b1 ii kpartx 0.11.1-2 ii parted 3.6-5 ii python3 3.13.5-1 ii python3-jinja2 3.1.6-1 ii python3-yaml 6.0.2-1+b2 ii qemu-utils 1:10.0.2+ds-1 Versions of packages vmdb2 recommends: ii ansible 12.0.0~a6+dfsg-1 ii dosfstools 4.2-1.2 ii qemu-user-static 1:10.0.2+ds-1 ii zerofree 1.1.1-1+b1 vmdb2 suggests no packages. - -- no debconf information -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmhn5FQACgkQS80FZ8KW 0F1z+hAAqJl2xtHs9QysigCakORiYobfbrxI1OZpDqBPPK5l1ydrPXJUyzCgScM6 3rqz1LMS9obdiWXprFv4cME/mhhMK2T9+G0OrMIPNm3aB4NuKWIr6LSkqoqtnPqN DXR9n3RW/01/alN3bsQO3H5hbP7gm+hfP7/ZpL7pUDAQz3TZ4UgkSy7bxSUDzqiD zTnjJxH2+LWHMQWDS23ddpE7dR3yqlAouqlr/L0z7GfhpU9y6PA2HQ4/e+PARi5h QTVQOcZORcjevLtrm5lW0lp4qmktYStbLLtNLMNj3PXzA2QuCMbNUVtCSyBN+arK 9WAc/FgY7gJqibGRDkm4xWuGrjzHuwhvwmcO8HbtLvmJ1nKeoiMeHOhCBKyN084F doG0fiswkPbe9IXUc914fbBnRPfaS9sQVcjYwEQ5ciW7ZqfHdLwlMJO8/cGDV7Pc vmP3v21Xw+2ParOxFDjIqAQ++Jzo4+rYN3B7YKPdh1qUt3TbaWOQk/SpLBvB0FZc QCjgzCkHiQMfEL9TanSEpgp/RnXrY0aWVsMEYfsjJmGlSbOd6SMWRntaoGoZ8mOj XedlTTol8yechN9aPK8Lt36UQ3RY0vuNtNLLun2Do2yc6Datnscs9TwZYarozgv7 8BjF+P8XDEENaAe/Jx8PWNQXnnc+FFnJ92o9rPU+N+fXiiDwb5o= =xERq -----END PGP SIGNATURE-----
severity 1108745 important tags 1108745 + upstream thanks Hello Daniel, Daniel Leidert dijo [Fri, Jul 04, 2025 at 04:25:25PM +0200]: I am sorry I could not reply (not even _look at_ this bug) until now that our dear friend Elbrus pulled my attention to it; I was preparing with the family for the trip to Europe, and am now dedicating most of my attention to DebConf. I do not have my regular systems with me, and cannot really check this with me. I will forward this bug report to the upstream developer; Lars, I hope you can take a look at this. Otherwise, I'll be able to devote some time to this once I'm back home, approx. a week from today. Daniel, given you say that "images built for BIOS are not affected", I hope you agree this bug does not break this package for all use cases, and will degrade its severity to "important". Thanks!
I've not got my test rig set up, but last time I tried, the UEFI images booted just fine. The test suite generates them and boots them. Of course, I only run the tests for the upstream code. You could run them in the Debian source tree, see the check-images script.
tags 1108745 + confirmed
thanks
Hi,
I did some basic testing, using the following vmdb spec:
steps:
- mkimg: "{{ output }}"
size: 4G
- mklabel: gpt
device: "{{ output }}"
- mkpart: primary
device: "{{ output }}"
start: 0%
end: 5%
tag: uefi
- mkpart: primary
device: "{{ output }}"
start: 5%
end: 100%
tag: root
- kpartx: "{{ output }}"
- mkfs: ext4
partition: root
- mkfs: vfat
partition: uefi
- mount: root
- debootstrap: bookworm
mirror: http://deb.debian.org/debian
target: root
- chroot: root
shell: |
mkdir /boot/efi
- mount: uefi
mount-on: root
dirname: '/boot/efi'
- apt: install
packages:
- linux-image-amd64
tag: root
- fstab: root
- grub: uefi
tag: root
efi: uefi
Effectively, on a VM, the image fails to boot. The command used to test it
is:
qemu-system-x86_64 -enable-kvm -m 1G -drive file=/tmp/build.img,media=disk,format=raw
I built the same image for BIOS, that is, applying the following patch:
@@ -1,7 +1,7 @@
steps:
- mkimg: "{{ output }}"
size: 4G
- - mklabel: gpt
+ - mklabel: msdos
device: "{{ output }}"
- mkpart: primary
device: "{{ output }}"
@@ -33,6 +33,5 @@
- linux-image-amd64
tag: root
- fstab: root
- - grub: uefi
+ - grub: bios
tag: root
- efi: uefi
The EFI partition is correctly populated matching what I have on my system:
EFI/debian/shimx64.efi
EFI/debian/grubx64.efi
EFI/debian/mmx64.efi
EFI/debian/fbx64.efi
EFI/debian/BOOTX64.CSV
EFI/debian/grub.cfg
EFI/BOOT/BOOTX64.EFI
EFI/BOOT/grubx64.efi
EFI/BOOT/mmx64.efi
Just to discard it's some quirk I didn't specify to qemu, I'll find an USB
stick and will try to boot on real hardware. I don't know if I'm missing
anything (i.e. a partition flag?)
Greetings,
I was wondering if this isn't the SBAT transition? Is your qemu using secure boot in some form? Chris
Chris Hofstaedtler dijo [Wed, Jul 30, 2025 at 10:26:35PM +0200]: I really doubt it -- I'm using the regular Debian-packaged qemu (version 1:10.0.2+ds-1). I tried booting with and without KVM. There isn't anything else to strip from the command line I posted!