Hi,
I was thinking my bug was #1016359, but with the additionnal
info, it is a different one. So, I'm opening this bug as asked.
ovmf in sid does not allow one to boot over a virtio-scsi contrôleur.
My disques are not seen anymore (not even in the EFI menus).
Downgrading to 2020.11-2+deb11u1 fixes the issue.
Regards,
Vincent
-- System Information:
Debian Release: bookworm/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel
Kernel: Linux 6.0.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
Hello,
Paquet : ovmf
Version : 2022.11-1
État: installé
With 2022.11, virtio-blk drive is no longer recognized.
Reverting to 2022.08 is a workaround to solve the issue.
With 2022.11, the debian entry disappears from Tianocore "Boot Manager Menu". Here is a copy of the menu list :
Boot Manager Menu Device Path:
PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x2,0xFFFF,0x0)
UEFI QEMU DVD-ROM QM00005
UEFI Misc Device
UEFI PXEv4 (MAC:B8ADCAFE0000)
UEFI PXEv4 (MAC:B8ADCAFE0000) 2
UEFI PXEv6 (MAC:B8ADCAFE0000)
UEFI HTTPv4 (MAC:B8ADCAFE0000)
UEFI HTTPv6 (MAC:B8ADCAFE0000)
EFI Internal Shell
Once in EFI Shell, it is possible to access debian directory and
boot the VM
FS0:
cd EFI\debian
grubx64.efi
VM is booted through this script : https://github.com/platu/inetdoc/blob/master/guides/vm/files/ovs-startup.sh
Once the VM is up, we get :
etu@vm0:~$ sudo dmesg -HT | grep vd
[jeu. 8 déc. 16:55:13 2022] virtio_blk virtio2: [vda] 125829120
512-byte logical blocks (64.4 GB/60.0 GiB)
[jeu. 8 déc. 16:55:13 2022] vda: vda1 vda2 vda3
[jeu. 8 déc. 16:55:14 2022] EXT4-fs (vda2): mounted filesystem
with ordered data mode. Quota mode: none.
[jeu. 8 déc. 16:55:16 2022] EXT4-fs (vda2): re-mounted. Quota
mode: none.
[jeu. 8 déc. 16:55:16 2022] Adding 999420k swap on /dev/vda3.
Priority:-2 extents:1 across:999420k FS
Is there any hint to reinstate boot manager menu entry ?
Regards,
-- - Philippe Latu -- https://inetdoc.net
Hello,
I confirm that this upgrade path works fine.
> So, an upgrade path seems possible, but it is not easy to find.
> If you have a bullseye VM booting with OVMF_CODE.fd on a SCSI disk,
> you have to:
> 1) change OVMF_CODE.fd into OVMF_CODE_4M.secboot.fd (or to another variant) in the XML
> 2) remove (rename?) the _VARS.fd file
> 3) manually boot the VM from the UEFI shell
> 4) re-install grub ("grub-install efi")
I can also confirm that we are quite far from the first bug report title.
I tested this on Debian / Kali / Ubuntu / Windows / Cisco
CSR1000v / Cisco nexus 9000v
The boot issue with a fresh copy of
/usr/share/OVMF/OVMF_VARS_4M.fd only happens with Debian and Kali.
All other systems are booting properly after "some kind of" Boot
manager entries update.
With Ubuntu images, we can see a "Reset System" message appearing
on first boot.
Unfortunately, this is not my area of expertise and I cannot help.
Kind regards,