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

Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?

  -dann

Thanks for opening this new issue! As I mentioned in #1016359, I had
no problems booting a VM w/ virtio-scsi in sid, so this seems like it
may be config-specific. Can you provide me with a way to reproduce
this - e.g. your libvirt XML?

  -dann

Dixi quod…


Vincent Danjean dixit:


This led me to reinvestigate. Turns out that OVMF cannot boot
when the ISO image is added as a read-only SCSI disc to the
system, as opposed to a read-write one.

So I have to change my earlier statement to:
->bullseye works with neither lsilogic nor virtio-scsi. This makes
+ bullseye does not work with lsilogic, but works in bullseye
+ with virtio-scsi. This makes

I agree that the virtio-scsi bug should be split from the lsilogic
bug, especially as the former seems to be a regression against
bullseye while the latter is a missing functionality.

Thanks,
//mirabilos

   Hi,

Le 07/12/2022 à 22:26, dann frazier a écrit :

Here is.

   Regards,
     Vincent

   Hi,

Le 07/12/2022 à 22:26, dann frazier a écrit :

Here is.

   Regards,
     Vincent

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,

   Hi,

   I come back to this bug.

Le 07/12/2022 à 22:26, dann frazier a écrit :
really in the ovmf software, but in the upgrade path.

   I retried today to upgrade ovmf to 2022.11-6. Then, my VM becomes
unable to boot and the SCSI Disk does not appear anymore (only the
SATA CDROM (empty) is visible) in the UEFI Boot Manager.
   See ovmf-2022-11-6.png
   I tried both with the Virtio SCSI contrôler and the lsilogic one.
In both cases, the disk is not visible at all in the UEFI shell
or UEFI Boot Manager.

   Downgrading ovmf to 2020.11-2+deb11u1 fixes these problems.
The disk is then visible in the UEFI Boot Manager (see
ovmf-2020.11-2+deb11u1.png)


   As you said that you succeeded to boot, I then tried to create
a new VM (using the same file for the HD, so taking care to never
boot both VM at the same time) with the new ovmf package.
   It works! More exactly, the HD is visible in the UEFI Boot Manager
and the UEFI shell (as FS0). From the latter, typing:
FS0:
cd efi
cd debian
shimx64.efi
allows me to boot my system.

   So, I come back to my first (old) VM and try to spot the
differences. It comes to the fact that the old VM is using
<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
and the new is using
<loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.secboot.fd</loader>
[probably other OVMF_CODE_4M.* should also work, not tested]
And when creating new VM, virt-manager only proposes
OVMF_CODE_4M.*, not OVMF_CODE.* (whereas still present in the ovmf package)

   In my old VM in virt-manager, I used the XML editor to change
"OVMF_CODE.fd" into "OVMF_CODE_4M.secboot.fd"
   At this time, the VM does not boot anymore at all (no UEFI Bios
screen, only a message saying that the video is not initialized yet).
I went to /var/lib/libvirt/qemu/nvram and removed (renamed)
the nvram VARS file.
   This time, it works, the (old) VM boot and the UEFI Shell
shows my SCSI disk (and the nvram VARS file has been recreated, bigger).
   I booted manually from the UEFI shell, then I ran
"grub-install efi", and, at next boot, my VM started
correctly.

$ sudo ls -l /var/lib/libvirt/qemu/nvram/
-rw------- 1 libvirt-qemu libvirt-qemu 540672  6 mars  15:26 debian11_VARS.fd
-rw------- 1 libvirt-qemu libvirt-qemu 131072 20 sept.  2020 visio_VARS-2023-03-06.fd
-rw------- 1 libvirt-qemu libvirt-qemu 540672  6 mars  15:29 visio_VARS.fd

The first is the new VM (that I will destroy)
The next one is a rename of VARS file of the old VM
The last one is the one created when booting the old VM with the new ovmf 4M (four times bigger)

   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 do not know if something can be done for this path to be
easier, but, at the very least, it should be documented.
Perhaps, it may also be possible to get an error message
- if the VM boot on a SCSI disk with OVMF_CODE.*
- if the OVMF_CODE_4M.* code finds a *_VARS.fd related to OVMF_CODE.*

   Regards,
     Vincent

Le 06/03/2023 à 16:01, Vincent Danjean a écrit :

   As a side note, only the VirtIO SCSI controler is supported by
OVMF_CODE_4M.*, not lsilogic (that is the default for the
hypervisor with virt-manager/libvirt).
   But this is probably #1016359

   Regards,
     Vincent

Hello,

I confirm that this upgrade path works fine.

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,