focal change to 4M images changes virtinst default flavor

Bug #2004618 reported by dann frazier
20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
edk2 (Ubuntu)
Confirmed
Undecided
Unassigned
Focal
Confirmed
Undecided
Unassigned
virt-manager (Ubuntu)
Invalid
Undecided
Unassigned
Focal
Fix Released
Undecided
Mustafa Kemal Gilor

Bug Description

[ Impact ]

  * The fix for bug 1885662 has caused a regression in virt-install, where the default "--boot uefi" firmware image has changed from "OVMF_CODE.fd" (no secure boot) to "OVMF_CODE_4M.ms.fd" (secure boot, enrolled)

  * This is related to how virt-install selects a firmware from the offered firmwares. virt-install uses a hard-coded UEFI firmware pattern list to match against the offered patterns. The pattern list can be found in virtinst/domcapabilities.py (search for _uefi_arch_patterns). The current x86_64 pattern list is as follows:

   _uefi_arch_patterns = {
      /*...*/
      "x86_64": [
          r".*edk2-x86_64-.*\.fd", # upstream qemu
          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
      ],
      /*...*/
    }

  * virt-install uses `find_uefi_path_for_arch` function to select a UEFI FW path from the firmware descriptor list. The OVMF firmware descriptor list before the update that caused the regression was looking like this:

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

  * Looking at the implementation of `find_uefi_path_for_arch`, it iterates over the UEFI arch pattern list to match against the offered firmwares:

    domcapabilities.py/find_uefi_path_for_arch:
    /* ... */
    for pattern in patterns:
            for path in firmware_files:
                if re.match(pattern, path):
                    return path
    /* ... */

   The first pattern r".*edk2-x86_64-.*\.fd" matches to none, the second pattern r".*OVMF_CODE\.fd", matches to the OVMF_CODE.fd, OVMF_CODE.fd is selected.

  * The fix for LP#1885662 has changed the offered firmware names as follows:

    40-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd
    50-edk2-x86_64-secure.json - OVMF_CODE_4M.secboot.fd
    60-edk2-x86_64.json - OVMF_CODE_4M.fd

    The pattern r".*OVMF_CODE\.fd" no longer matches to anything, and the loop proceeds to the next pattern until a match is found. The last pattern ".*OVMF.*" matches, but it matches to first offered firmware now instead of the last one, and returns OVMF_CODE_4M.ms.fd as UEFI firmware path. The returned OVMF_CODE_4M.ms.fd is a secure boot capable/key enrolled firmware file, where the old one was non-secure boot firmware; hence the regression.

  * This SRU fixes the issue by updating the r".*OVMF_CODE\.fd" pattern as r".*OVMF_CODE(_4M)?\.fd" to reflect the changes made to OVMF and restore the old behavior back.

  * Note that this regression affects only the new VMs, not the existing VMS.

[ Test Plan ]

 * To see the old behavior:

   - lxc launch ubuntu:focal test-ovmf-r # or equivalent vm/container choice
   - lxc shell test-ovmf-r
   - apt install ovmf=0~20191122.bd85bf54-2ubuntu3.3 virtinst # OVMF version before the regression
   - apt install qemu-kvm libvirt-daemon-system
   - systemctl restart libvirtd # ensure fw descriptors are reloaded
   - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
   - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
   - # selected default firmware is non-secure boot kind

 * To see the new behavior (regression):
   - lxc launch ubuntu:focal test-ovmf-r # or equivalent vm/container choice
   - lxc shell test-ovmf-r
   - apt install ovmf=0~20191122.bd85bf54-2ubuntu3.4 virtinst
   - apt install qemu-kvm libvirt-daemon-system
   - systemctl restart libvirtd # ensure fw descriptors are reloaded
   - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
   - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>
   - # selected default firmware is different kind (secure boot capable/key enrolled) than the previous
   - # version

 * Test the fix:
   - Execute steps under "To see the new behavior (regression)"
   - # Enable the PPA that contains the virt-install with the fix
   - # and upgrade the virt-install package:
   - sudo add-apt-repository ppa:mustafakemalgilor/lp-2004618
   - sudo apt update
   - sudo apt upgrade
   - # Check "virt-install" output again:
   - virt-install --boot uefi --print-xml --memory 1 --disk none --machine q35 | grep "/usr/share/OVMF"
   - # should output: <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
   - # selected default firmware is non-secure boot kind

[ Where problems could occur ]

  * The change is localized and it compliments the changes made to the OVMF package, therefore the risk of regression is considered low.

  * This patch can only affect virt-install's behavior if other packages offer OVMF firmware files with the new "_4M" suffix.

Related branches

Revision history for this message
dann frazier (dannf) wrote :

For reference, I'm attaching the logs I was looking at yesterday that pointed me to the virtinst issue. I collected it by turning on the following debug settings in libvirtd.conf:

log_filters="1:qemu_firmware"
log_outputs="3:syslog:libvirtd 1:stderr"

And ran libvirtd in the foreground to collect it.

You'll see that the probing pattern between old ovmf and new ovmf changed. After applying a patch to virtinst that also matches the 4M variants, the probing pattern when using the new ovmf now matches the old one.

Revision history for this message
dann frazier (dannf) wrote :
Revision history for this message
dann frazier (dannf) wrote :
Revision history for this message
dann frazier (dannf) wrote :
Revision history for this message
dann frazier (dannf) wrote :
tags: added: patch
Revision history for this message
dann frazier (dannf) wrote :

I'm told that jammy's behavior appears to match the behavior of focal + the updated ovmf - i.e., it will default to the ms.fd variant. Which makes sense - jammy has always advertised only the _4M variants in its descriptors. And same as focal, jammy's virtinst doesn't match the 4M images in its "_uefi_arch_patterns" regex map. In fact, this is still true in virtinst upstream.

So this puts us in a weird situation. AIUI:

focal/before the ovmf SRU: Behaves as upstream intended
focal/after the ovmf SRU: Broken per upstream's intention
>= jammy: Broken per upstream's intention
upstream: Broken per upstream's intention

So we could submit a fix upstream to add 4M images to the regex map and backport that everywhere. That would restore upstream's intended behavior and fix this focal regression. But correcting that in jammy and kinetic would change the behavior of those stable releases.

We could fix focal and upstream (and therefore future Ubuntu releases) and skip jammy and kinetic. But doing so would make jammy and kinetic's behavior different than the releases before and after them.

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :

Hello Dann,

It's indeed quite a weird situation. I've looked at how different distros handled this:

Centos-stream is only shipping 4m images (no suffix), so it's not affected.

Fedora is shipping 4m images in a different folder with the exact same file names, so it's not affected.

Arch Linux provides 4m images, and advertises the 4m image and 2m image together, 4M image's name does not match the pattern but 2M's does, so while it does not use the image intended by the pkg maintainer, it uses the correct kind of image (secure boot capable, but not enforced).

Debian Bullseye/Ubuntu Jammy advertises only the 4m images, and the names do not match the pattern, so virt-install is using the incorrect kind of image by default.

I think the safest and hassle-free way forward for Focal would be:

- create /usr/share/OVMF/4M sub-folder
- create symlinks for 4M images, e.g. /usr/share/OVMF/4M/OVMF_CODE.fd -> ../OVMF_CODE_4M.fd
- update fw descriptor to refer to symlinks instead

For Jammy and any future series, I think we already caused an unintended regression between Focal->Jammy but nobody has reported it (yet). So, IMO we should be better off correcting it.

Revision history for this message
dann frazier (dannf) wrote :

Hi Mustafa,

I think the symlink approach is a clever solution that avoids having to touch virtinst. However, I'm not excited about carrying more things in OVMF to resolve it. It seems like a nice solution if we could do it for *just focal*, but once VM XML starts including those symlink paths, we're basically stuck shipping them forever. So I think I prefer the virtinst regex update - unless you see some downsides I'm missing.

If we *do* end up using the symlink solution, I suggest one tweak to it. If we go that way, I think we'd be conceding that subdirectories - not filenames - are the correct way to distinguish new variants in the future. I think it would therefore make sense that we make the new files the "real" files, and use symlinks for the old paths, e.g. /usr/share/OVMF/OVMF_CODE_4M.fd -> ../4M/OVMF_CODE.fd. That should help imply to a future maintainer that these are just for backwards compat, and the directory approach should be used for new variants.

As for jammy - even though the current behavior is not *intended*, it doesn't seem necessarily *wrong*. Users may have grown accustomed to getting a SecureBoot VM by default, and changing that default in an SRU to "correct it" feels wrong, even if it makes jammy more consistent with focal and future releases (assuming we restore upstream-intended behavior there).

I've subscribed ubuntu-server to see if they have any preferences on how we proceed.

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :

Hi Dann,

I have no objections to upstreaming the pattern. But I wonder, if we add the pattern to the upstream and backport it, are we going to skip backporting it to Jammy? If we decide to do so, it means another behavior change and we'll find ourselves dealing with the same dilemma again.

Regardless, having the pattern in the list does not dictate which FW images we want existing/future series to use by default, so I'm going to submit a patch to the upstream virt-manager to get the ball rolling.

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :

So, I was reviewing the patterns and I noticed that the pattern list also contains the following:

".*OVMF.*"

which means, even if ".*OVMF_CODE\.fd" pattern does not match the new OVMF_CODE_4M.fd filename, ".*OVMF.*" pattern should, but guess what, it lacks an `r` at the beginning so the string is not interpreted as a raw string... Adding that fixes our problem.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote (last edit ):

Thanks for subscribing Dann, but I do not have much more to add other than that I've outlined this kind of issues in the discussion with Mustafa upfront. Sadly we didn't pre-identify this particular version thereof, but it belongs to the same category of issues.

I do not have a great alternative suggestion right now, but just wanted to mention a recent change as firmware selection dynamics have been a pain for many for too long. Upstream just today got this series [1] submitted which tries to address that through updates/changes this would not change anymore. It will not help the current situation, but it affects any long term plan or upstreaming thoughts.

[1]: https://listman.redhat.com/archives/libvir-list/2023-February/237824.html

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :
Revision history for this message
dann frazier (dannf) wrote :

@Mustafa lol, I should start a file of interesting 1 character fixes, they're my favorite :)

@Christian: Thanks for taking a look and providing a link to that discussion. TBH, I thought firmware was always locked down at domain definition time already, so I realize I need to learn more about these "autoselection" modes.

@Christian: Also curious if server has any opinion on what we do wrt jammy here.

Revision history for this message
trya uuum (tryauuum) wrote :

@Mustafa could you explain the patch please? (because I don't understand it and I'm curious).
I understand the difference between normal and raw strings in python, but isn't the target string the same with and without "r"?

```
>>> ".*OVMF.*" == r".*OVMF.*"
True
```

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in edk2 (Ubuntu Focal):
status: New → Confirmed
Changed in edk2 (Ubuntu):
status: New → Confirmed
Changed in virt-manager (Ubuntu Focal):
status: New → Confirmed
Changed in virt-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote (last edit ):
Download full text (4.5 KiB)

Hello @trya,

Yes, you are correct, thanks for pointing that out! I believe I somehow mixed the test results while I was fiddling with the code and the test cases. I've re-checked and confirmed that the `r` does not have any effect on this specific pattern. Given that it contains no escaped characters, it makes sense.

After @trya pointed that out, I went back to the drawing board. I've re-read the @dannf's original diagnosis and extended mine. The pattern set covers for ".*OVMF.*", so what we're seeing here is not related to the lack of a pattern in virt-install's internal pattern set as stated. virt-install processes the offered firmware descriptors in order (i.e. 40-50-60), and stops whenever a firmware descriptor is found suitable. The name "OVMF_CODE_4M.ms.fd" is offered first and matches the pattern set, so it's picked. virt-install is behaving as expected here.

As for the original code before the patch, the first offered firmware name `OVMF_CODE.ms.fd` should've matched the ".*OVMF.*" pattern as well, but why it doesn't get picked as FW? Because even though the OVMF_CODE.ms.fd is offered first, the implementation iterates over *patterns* and matches them against the firmware list, not the other way around. Therefore, it picks the first firmware that matches the first pattern, which is "OVMF_CODE.fd". It seems that the order of patterns matters here. The order of FW descriptors matters when they're going to match the same pattern.

As for the updated code, the _4M suffix caused "OVMF_CODE\.fd" pattern match to fail, so now the subsequent patterns are also evaluated, one of them being ".*OVMF.*", and not to your surprise, it matches the first offered firmware name. No capability-based search is made.

The question here is if we *want* firmware descriptor consumers to pick up non-"secure boot enforced" FW first, shouldn't we offer it first (i.e. 40-edk2-x86_64.json)? If we want to keep the original behavior, I think it is the most solid way to go.

To conclude, my opinion on this is to reflect the FW order we want to firmware descriptor files. We can fix Focal by offering non-secure boot firmware first, and I believe it would be better to offer non-ms specific firmware first in Jammy and above:

-- my proposal --

Focal:

40-edk2-x86_64.json - OVMF_CODE_4M.fd
50-edk2-x86_64-secure.json - OVMF_CODE_4M.secboot.fd
60-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd

Jammy and above:

40-edk2-x86_64-secure.json - OVMF_CODE_4M.secboot.fd
50-edk2-x86_64.json - OVMF_CODE_4M.fd
60-edk2-x86_64-secure-enrolled.json - OVMF_CODE_4M.ms.fd

@dannf any opinions?

------------------------------

Test steps for reference:

# /usr/share/OVMF/OVMF_CODE_4M.ms.fd supports: "pc-q35-*"
# /usr/share/OVMF/OVMF_CODE_4M.secboot.fd "pc-q35-*"
# /usr/share/OVMF/OVMF_CODE_4M.fd supports : "pc-i440fx-*", "pc-q35-*"

lxc launch ubuntu:focal test-ovmf-virtinst
lxc shell test-ovmf-virtinst
apt update

#### Focal new ovmf ####
apt install ovmf=ovmf=0~20191122.bd85bf54-2ubuntu3.4 virtinst
apt install qemu-kvm libvirt-daemon-system

# Just --boot uefi
virt-install --boot uefi --print-xml --memory 1 --disk none | grep "/usr/share/OVMF"
# prints <loader readonly="y...

Read more...

Changed in edk2 (Ubuntu Focal):
assignee: nobody → Mustafa Kemal Gilor (mustafakemalgilor)
Revision history for this message
dann frazier (dannf) wrote :

Thanks for the deeper investigation Mustafa!

fwiw, I believe I came up with the descriptor ordering of secure+enrolled > secure > non-secure just by cargo culting from another package - probably Fedora's. I'm certainly open to rethinking that ordering for 23.10, but I'd prefer to not change the behaviors of existing stable releases. That feels like digging ourselves into a deeper hole instead of just climbing out of this one.

If I understand your findings correctly, it seems like we could restore the original behavior simply by making the first pattern match the 4M images as well, i.e.:

- r".*OVMF_CODE\.fd", # RHEL
+ r".*OVMF_CODE(_4M)?\.fd", # RHEL

That seems like the smallest/safest change we could make for focal to restore existing behavior. If we do that for just focal, it would seem to restore the status quo, where focal behaves differently than >= jammy. IMO, that'd be enough to resolve this issue - what do you think?

Let's also continue conversation about correcting the behavior for future release - and upstream - ideally in a new LP bug.

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :

Hi Dann,

> If I understand your findings correctly, it seems like we could
> restore the original behavior simply by making the first pattern
> match the 4M images as well, i.e.:

Yes, I think that'll work. Let's deal with the Focal first as you've suggested. I'll submit a patch to virt-install/focal.

I'll open a new ticket for discussing the behavior for future release(s).

Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote (last edit ):

I built a test PPA[1], and it restores the old behavior. I'll go ahead and convert this issue to an SRU.

[1] https://launchpad.net/~mustafakemalgilor/+archive/ubuntu/lp-2004618

description: updated
description: updated
Changed in virt-manager (Ubuntu Focal):
assignee: nobody → Mustafa Kemal Gilor (mustafakemalgilor)
Changed in edk2 (Ubuntu Focal):
assignee: Mustafa Kemal Gilor (mustafakemalgilor) → nobody
Robie Basak (racb)
tags: added: regression-update
Robie Basak (racb)
description: updated
Revision history for this message
Robie Basak (racb) wrote :

For the SRU, please edit the test plan to ensure that it uses the archive -proposed version and not a PPA, and make it clear in your SRU verification report that the proposed version was definitely used during testing.

Please could you also add to the test plan a test to ensure that the new virt-manager works as expected against the old edk2? From the code change, I think this should work, but it should be tested. Since we're not enforcing anything via dependency versions, it's possible that users will have the old edk2 but the new virt-manager under some scenarios.

Changed in virt-manager (Ubuntu Focal):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-focal
Revision history for this message
Robie Basak (racb) wrote : Please test proposed package

Hello dann, or anyone else affected,

Accepted virt-manager into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/virt-manager/1:2.2.1-3ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Revision history for this message
Joao Andre Simioni (jasimioni) wrote :

Before the package update:

$ dpkg -l | grep -ie ovmf -e virtinst
ii ovmf 0~20191122.bd85bf54-2ubuntu3.4
ii virtinst 1:2.2.1-3ubuntu2.1

$ virt-install --boot uefi --machine q35 --name focal --memory 1024 \
               --vcpus 1 --disk none --print-xml | grep OVMF

    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>

Selects the wrong firmware (OVMF_CODE_4M.ms.fd)

After package update from proposal:

$ dpkg -l | grep -ie ovmf -e virtinst
ii ovmf 0~20191122.bd85bf54-2ubuntu3.4
ii virtinst 1:2.2.1-3ubuntu2.2

$ virt-install --boot uefi --machine q35 --name focal --memory 1024 \
               --vcpus 1 --disk none --print-xml | grep OVMF

    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>

Selects the correct firmware (OVMF_CODE_4M.fd)

tags: added: verification-done-focal
removed: verification-needed-focal
Revision history for this message
Mustafa Kemal Gilor (mustafakemalgilor) wrote :
Download full text (3.4 KiB)

In addition to the verification that Joao has made, I also verified that the proposed virt-install works as intended for both the old(ovmf<=0~20191122.bd85bf54-2ubuntu3.3) and the new ovmf(>=0~20191122.bd85bf54-2ubuntu3.4) OVMF versions:

Test patch:

diff --git a/debian/tests/control b/debian/tests/control
index 8d84dc8..8e526b0 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -7,3 +7,11 @@ Restrictions: superficial
 Depends: virt-manager,
  xvfb,
  xauth,
+
+Test-Command: bash debian/tests/virt-manager-uefi-img-ovmf.sh "--allow-downgrades install ovmf=0~20191122.bd85bf54-2ubuntu3.3" "OVMF_CODE.fd"
+Restrictions: superficial, needs-root
+Depends: @
+
+Test-Command: bash debian/tests/virt-manager-uefi-img-ovmf.sh "satisfy ovmf(>=0~20191122.bd85bf54-2ubuntu3.4)" "OVMF_CODE_4M.fd"
+Restrictions: superficial, needs-root
+Depends: @
\ No newline at end of file
diff --git a/debian/tests/virt-manager-uefi-img-ovmf.sh b/debian/tests/virt-manager-uefi-img-ovmf.sh
new file mode 100644
index 0000000..e92078b
--- /dev/null
+++ b/debian/tests/virt-manager-uefi-img-ovmf.sh
@@ -0,0 +1,9 @@
+#!/bin/sh
+
+set -e
+
+sudo DEBIAN_FRONTEND=noninteractive apt-get -y --allow-downgrades install libvirt-daemon-system qemu-system-x86
+sudo DEBIAN_FRONTEND=noninteractive apt-get -y $1
+sudo systemctl restart libvirtd # restart libvirtd to make it pick up the new fw descriptor file
+virt-install --name focal-post-v --boot uefi --ram 128 --vcpus 1 --machine q35 --graphics none --disk none --print-xml | grep "OVMF"
+virt-install --name focal-post-v --boot uefi --ram 128 --vcpus 1 --machine q35 --graphics none --disk none --print-xml | grep "/usr/share/OVMF/$2"

Results:

dpkg: warning: downgrading ovmf from 0~20191122.bd85bf54-2ubuntu3.4 to 0~20191122.bd85bf54-2ubuntu3.3
(Reading database ... 119733 files and directories currently installed.)
Preparing to unpack .../ovmf_0~20191122.bd85bf54-2ubuntu3.3_all.deb ...
Unpacking ovmf (0~20191122.bd85bf54-2ubuntu3.3) over (0~20191122.bd85bf54-2ubuntu3.4) ...
Setting up ovmf (0~20191122.bd85bf54-2ubuntu3.3) ...
    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE.fd</loader>
autopkgtest [11:10:02]: test command1: -----------------------]
autopkgtest [11:10:03]: test command1: - - - - - - - - - - results - - - - - - - - - -
command1 PASS (superficial)
autopkgtest [11:10:03]: test command2: preparing testbed
autopkgtest [11:10:11]: test command2: bash debian/tests/virt-manager-uefi-img-ovmf.sh "satisfy ovmf(>=0~20191122.bd85bf54-2ubuntu3.4)" "OVMF_CODE_4M.fd"
autopkgtest [11:10:11]: test command2: [-----------------------
Unpacking ovmf (0~20191122.bd85bf54-2ubuntu3.4) over (0~20191122.bd85bf54-2ubuntu3.3) ...
Setting up ovmf (0~20191122.bd85bf54-2ubuntu3.4) ...
    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
    <loader readonly="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.fd</loader>
autopkgtest [11:10:13]: test command2: -----------------------]
command2 PASS (superficial)
autopkgtest [11:10:14]: test command2: - - - - - - - - - - results - - - - - - - - - -
...

Read more...

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package virt-manager - 1:2.2.1-3ubuntu2.2

---------------
virt-manager (1:2.2.1-3ubuntu2.2) focal; urgency=medium

  * d/p/lp-2004618-add-4m-pattern.patch: added OVMF_CODE_4M.fd to patterns:
    Focal OVMF package has started shipping 4M firmware images with _4M
    suffix. This patch updates the UEFI x86_64 arch pattern list to cover
    these firmware images. (LP: #2004618)

 -- Mustafa Kemal GILOR <email address hidden> Mon, 06 Mar 2023 17:02:51 +0300

Changed in virt-manager (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Robie Basak (racb) wrote : Update Released

The verification of the Stable Release Update for virt-manager has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Changed in virt-manager (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.