1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1099500: ovmf 2025.02-1 breaks boot from rockylinux and Fedora

    From dann frazier@21:1/5 to All on Fri Mar 14 02:00:01 2025
    tag 1099500 + confirmed
    thx

    On Tue, Mar 04, 2025 at 07:47:52AM +0100, Holger Schröder wrote:
    Package: ovmf
    Version: 2024.11-5
    Severity: normal

    Dear Maintainer,

    With the latest ovmf (2025.02-1) my rockylinuxbox and fedorabox (41) can no longer be booted. I can still see the grub menu for a short time and then it stops, black screen. Downgrade ovmf to 2024.11-5 and everything works again. Strangely enough, my Debianbox boots without errors.

    Thanks for the report. I can reproduce with the Fedora 41 install
    media.

    -dann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From NoisyCoil@21:1/5 to All on Fri Mar 21 20:50:02 2025
    This is a multi-part MIME message sent by reportbug.


    Package: ovmf
    Followup-For: Bug #1099500
    X-Debbugs-Cc: noisycoil@tutanota.com

    I am experiencing this bug with an arm64 Tails virtual machine. The current release of Tails is based on Debian bookworm live, and the image I'm using boots using bookworm's unsigned grub on the removable path (EFI/BOOT/BOOTAA64.EFI).
    The VM's libvirt configuration is in attachment. Reverting to 2024.11-5 works for me as well.

    I'm raising severity of this bug to important. I believe this should actually be an RC bug, but I'll leave it to the maintainer to decide whether to further raise severity.

    Thanks.

    <domain type="kvm">
    <memory unit="KiB">2621440</memory>
    <currentMemory unit="KiB">2621440</currentMemory>
    <vcpu placement="static">2</vcpu>
    <os firmware="efi">
    <type arch="aarch64" machine="virt-7.2">hvm</type>
    <!-- UEFI secure boot conflicts with v4l2loopback -->
    <firmware>
    <feature enabled="no" name="enrolled-keys"/>
    <feature enabled="no" name="secure-boot"/>
    </firmware>
    <boot dev='cdrom'/>
    </os>
    <features>
    <acpi/>
    <gic version="3"/>
    </features>
    <cpu mode="host-passthrough" check="none"/>
    <clock offset="utc"/>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>destroy</on_crash>
    <devices>
    <emulator>/usr/bin/qemu-system-aarch64</emulator>
    <controller type="usb" index="0" model="qemu-xhci" />
    <controller type="virtio-serial" index="0" />
    <controller type="scsi" index="0" model="virtio-scsi" />
    <interface type="network">
    <alias name='net0'/>
    <mac address="52:54:00:ac:dd:ee"/>
    <source network="TailsToasterNet"/>
    <model type="virtio"/>
    <link state="down"/>
    </interface>
    <input type="keyboard" bus="usb"/>
    <input type="tablet" bus="usb" />
    <channel type="spicevmc">
    <target type="virtio" name="com.redhat.spice.0"/>
    </channel>
    <graphics type='spice' port='-1' tlsPort='-1' autoport='yes'>
    <clipboard copypaste='yes'/>
    <mouse mode='client'/>
    </graphics>
    <sound model="ich6" />
    <video>
    <model type="virtio" vram="262144" heads="1" primary="yes"/>
    <address type="pci" domain="0x0000" bus="0x00" slot="0x02" function="0x0"/>
    </video>
    <memballoon model="virtio" />
    </devices>
    </domain>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dann frazier@21:1/5 to NoisyCoil on Sun Mar 23 18:30:01 2025
    On Fri, Mar 21, 2025 at 08:41:30PM +0100, NoisyCoil wrote:
    Package: ovmf
    Followup-For: Bug #1099500
    X-Debbugs-Cc: noisycoil@tutanota.com

    I am experiencing this bug with an arm64 Tails virtual machine. The current release of Tails is based on Debian bookworm live, and the image I'm using boots using bookworm's unsigned grub on the removable path (EFI/BOOT/BOOTAA64.EFI).
    The VM's libvirt configuration is in attachment. Reverting to 2024.11-5 works for me as well.

    This bug is for ovmf, which is the firmware for X64. Your
    information is about qemu-efi-aarch64, the firmware for AArch64. While
    it is possible that the issues are related, it is unlikely. Please
    open a new bug and provide the serial console log (`virsh console`)
    and the libvirt log file for the instance there.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fiona Ebner@21:1/5 to All on Tue Mar 25 18:10:02 2025
    Hi,
    I believe this is the same issue as reported here [0] and there doesn't
    seem much interest from upstream to provide a workaround unfortunately.
    So does the EFI_MEMORY_ATTRIBUTE_PROTOCOL need to be disabled/reverted
    like is already done for arm [1]?

    [0]: https://edk2.groups.io/g/devel/topic/110601533#msg120986
    [1]: https://salsa.debian.org/qemu-team/edk2/-/blob/debian/latest/debian/patches/ArmVirtPkg-disable-the-EFI_MEMORY_ATTRIBUTE-protocol.patch?ref_type=heads

    Best Regards,
    Fiona

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dann frazier@21:1/5 to f.ebner@proxmox.com on Wed Mar 26 15:50:02 2025
    On Tue, Mar 25, 2025 at 11:03 AM Fiona Ebner <f.ebner@proxmox.com> wrote:

    Hi,
    I believe this is the same issue as reported here [0] and there doesn't
    seem much interest from upstream to provide a workaround unfortunately.

    Thanks Fiona, I hadn't seen that specific discussion. To be fair,
    upstream has provided an interface to workaround this issue:
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/RUNTIME_CONFIG.md#security-optorgtianocoreuninstallmemattrprotocol

    And that can be set either as a build-time default or as runtime w/
    -fw_cfg, but I'm confused about why the -fw_cfg parameter didn't avoid
    the issue for me. I'll build a debug version to make sure I haven't
    just fat-fingered something.

    So does the EFI_MEMORY_ATTRIBUTE_PROTOCOL need to be disabled/reverted
    like is already done for arm [1]?

    What I propose is that we disable it at build time for the non-secboot
    variant, but leave it on for the secboot variant, for both
    architectures. This appears to be what Fedora is planning for Fedora
    42:
    https://src.fedoraproject.org/rpms/edk2/blob/f42/f/README.experimental#_15

    I fear that if we keep disabling it entirely, we'll just be adding to
    the problem. Users should be able to override this w/ the -fw_cfg
    setting, if I can figure out why that isn't working for me.

    -dann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Fiona Ebner@21:1/5 to All on Wed Mar 26 16:10:01 2025
    Am 26.03.25 um 15:40 schrieb dann frazier:
    On Tue, Mar 25, 2025 at 11:03 AM Fiona Ebner <f.ebner@proxmox.com> wrote:

    Hi,
    I believe this is the same issue as reported here [0] and there doesn't
    seem much interest from upstream to provide a workaround unfortunately.

    Thanks Fiona, I hadn't seen that specific discussion. To be fair,
    upstream has provided an interface to workaround this issue:
    https://github.com/tianocore/edk2/blob/master/OvmfPkg/RUNTIME_CONFIG.md#security-optorgtianocoreuninstallmemattrprotocol

    And that can be set either as a build-time default or as runtime w/
    -fw_cfg, but I'm confused about why the -fw_cfg parameter didn't avoid
    the issue for me. I'll build a debug version to make sure I haven't
    just fat-fingered something.


    AFAIU, for x86_64, this depends on the open pull request [0] that was
    also mentioned in the mailing list thread.

    So does the EFI_MEMORY_ATTRIBUTE_PROTOCOL need to be disabled/reverted
    like is already done for arm [1]?

    What I propose is that we disable it at build time for the non-secboot variant, but leave it on for the secboot variant, for both
    architectures. This appears to be what Fedora is planning for Fedora
    42:
    https://src.fedoraproject.org/rpms/edk2/blob/f42/f/README.experimental#_15

    I fear that if we keep disabling it entirely, we'll just be adding to
    the problem. Users should be able to override this w/ the -fw_cfg
    setting, if I can figure out why that isn't working for me.

    That is a good point!

    [0]: https://github.com/tianocore/edk2/pull/10667

    Best Regards,
    Fiona

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)