Comment 0 for bug 2004618

The fix for bug 1885662 changed the QEMU descriptors that ovmf provides to advertise the new 4M images instead of the old 2M images. That had an unintended side-effect with virtinst. Where previously '--boot uefi' would cause the VM to use OVMF_CODE.fd (the non-secure-boot, no-keys-enrolled variant), after the upgrade VMs are getting OVMF_CODE_4M.ms.fd (the secure-boot/MS-keys-enrolled variant).

Note: Users can override this by explicitly naming the loader file they want to use using:
  "--boot loader=<path>,loader_ro=yes,loader_type=pflash"

As best I can tell, this is happening because focal's virt-install has a hardcoded list of loader filename patterns it prefers if the user didn't explicitly specify one. From domcapbilities.py:

    _uefi_arch_patterns = {
        "i686": [
            r".*ovmf-ia32.*", # fedora, gerd's firmware repo
        ],
        "x86_64": [
            r".*OVMF_CODE\.fd", # RHEL
            r".*ovmf-x64/OVMF.*\.fd", # gerd's firmware repo
            r".*ovmf-x86_64-.*", # SUSE
            r".*ovmf.*", ".*OVMF.*", # generic attempt at a catchall
        ],

Before the upgrade, libvirt would advertise the OVMF_CODE.fd file found in the descriptor. That matches the ".*OVMF_CODE\.fd" regex. So while libvirt processed the descriptors in normal order, and while any of them should meet the feature requirements, it held out for one with a file name that matched the regex:

40-edk2-x86_64-secure-enrolled.json - OVMF_CODE.ms.fd - NO MATCH
50-edk2-x86_64-secure.json - OVMF_CODE.secboot.fd - NO MATCH
60-edk2-x86_64.json - OVMF_CODE.fd - MATCH!

After the upgrade, the advertised file paths changed to begin with OVMF_CODE_4M. So now none of them match virtinst's built-in pattern. Because of that, the negotiation seems to select an option based on capabilities alone. And what do you know? The first one works, so it stops there:

40-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd - MATCH!
50-edk2-x86_64-secure.json - OVMF_CODE_4M.secboot.fd - (no need to check)
60-edk2-x86_64.json - OVMF_CODE.fd - (no need to check)

Note that this is not a problem with jammy. I saw in the virtinst changelog that it has changed the interface it uses to request a UEFI firmware from libvirt, so perhaps that is why. We should confirm.

For focal, perhaps we need to restore the previous behavior by modifying the regex to also match the _4M variants.