Project

General

Profile

Actions

action #111992

closed

Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M

Added by favogt almost 2 years ago. Updated 11 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Feature requests
Target version:
Start date:
2022-06-03
Due date:
% Done:

0%

Estimated time:

Description

Observation

With QEMU 7, the default video resolution was changed to 1280x800
OVMF 202202, which is in Leap 15.4, did the same change: https://github.com/tianocore/edk2/commit/862ea6e83614066efdc2436f3727615ca37d9691
The default "-vga VGA" doesn't appear to be affected for some reason, but at least qxl is: https://openqa.opensuse.org/tests/2400506#step/bootloader_uefi/9

I tried various ways to get the resolution back to 800x600 or 1024x768 as expected by openQA, but failed.
The xres/yres properties appear to be ignored by OVMF. What works is to explicitly change the resolution in the OVMF configuration.

For now I downgraded OVMF on ow4 to the version in 15.3 (202008-150300.10.14.1).

Acceptance criteria

  • AC1: Default resolution with qxl is restored, or qxl is not used anymore
  • AC2: Use of the new firmware image is not known to cause any test failures

Suggestions

Workaround

  • Option 1: Downgrade OVMF to <= 202008-150300.10.14.1
  • Option 2 (TBC): Use a different graphics setting than QEMUVGA=qxl

Related issues 7 (3 open4 closed)

Related to openQA Infrastructure - action #111866: Upgrade osd workers and openqa-monitor to openSUSE Leap 15.4Resolvedokurz

Actions
Related to openQA Infrastructure - action #111863: Upgrade o3 workers to openSUSE Leap 15.4 size:MResolvedtinita

Actions
Related to openQA Tests - action #116914: [qe-core] recent uefi changes makes test failWorkable2022-09-21

Actions
Related to openQA Tests - action #116812: [qe-core] Leap 15.5 uefi console switch fail size:MBlockedokurz2022-09-19

Actions
Related to openQA Tests - action #116704: [qe-core] nvme@uefi: boot from DVD post install instead of from HDDResolvedtinita2022-09-16

Actions
Copied to openQA Project - action #113794: Use prepared OVMF image with expected settings size:MResolvedtinita2022-06-03

Actions
Copied to openQA Infrastructure - action #114523: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl, but on aarch64 size:MWorkable2022-06-03

Actions
Actions #1

Updated by okurz almost 2 years ago

  • Tags set to reactive work
  • Category set to Feature requests
  • Priority changed from Normal to High
  • Target version set to Ready

I did not know that zypper locks can take comments. I saw that you added a zypper lock referencing this ticket which is awesome! :)

Actions #2

Updated by okurz almost 2 years ago

  • Subject changed from Deal with QEMU and OVMF default resolution being 1280x800 to Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl
  • Description updated (diff)

The only thing remotely helpful I found seems to be https://developer.fedoraproject.org/tools/virtualization/setting-viewport-resolution-using-ovmf-bios.html . So I wonder, to keep XGA resolution, maybe we need to supply our own patched version of OVMF? Is there no way to configure the viewport by qemu parameters? That feels strange.

However, can you confirm it's really only QXL affected?

Actions #3

Updated by livdywan almost 2 years ago

  • Description updated (diff)

okurz wrote:

The only thing remotely helpful I found seems to be https://developer.fedoraproject.org/tools/virtualization/setting-viewport-resolution-using-ovmf-bios.html . So I wonder, to keep XGA resolution, maybe we need to supply our own patched version of OVMF? Is there no way to configure the viewport by qemu parameters? That feels strange.

I did a little bit of research, and it seems that the resolution can only be changed 1) within the guest 2) by resizing the window on the host. And even though the original code changes say it's important to have the right resolution from the start the numbers are all hard-coded.

Actions #4

Updated by tinita almost 2 years ago

  • Subject changed from Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl to Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M
  • Description updated (diff)
  • Status changed from New to Workable
Actions #5

Updated by livdywan almost 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to livdywan

Maybe what we want to do is as simple as not using qxl and failing early if somebody tries to do that: https://github.com/os-autoinst/os-autoinst/pull/2082

Actions #6

Updated by openqa_review almost 2 years ago

  • Due date set to 2022-06-24

Setting due date based on mean cycle time of SUSE QE Tools

Actions #7

Updated by mkittler almost 2 years ago

The following PR should fix the issue: https://github.com/os-autoinst/os-autoinst/pull/2083 It doesn't work, see @favogt's comment on GitHub.

Actions #8

Updated by livdywan almost 2 years ago

cdywan wrote:

Maybe what we want to do is as simple as not using qxl and failing early if somebody tries to do that: https://github.com/os-autoinst/os-autoinst/pull/2082

I count at least two votes against not supporting qxl, hence closing my PR.

So this probably means adapting the tests to use 1280x800 needles in the first steps.

Actions #9

Updated by okurz over 1 year ago

  • Due date changed from 2022-06-24 to 2022-07-15
  • Status changed from In Progress to Workable
  • Assignee changed from livdywan to tinita

as discussed in weekly 2022-06-24 tinita is happy to use this as a learning exercise to update tests.

Actions #10

Updated by tinita over 1 year ago

  • Status changed from Workable to In Progress

Marius and I tried several things to locally get into this step with the menu: https://openqa.opensuse.org/tests/2400506#step/bootloader_uefi/12

but so far no success, it always gets into the suse boot menu directly: https://openqa.opensuse.org/tests/2400506#step/bootloader_uefi/17

The last command I tried was

script/openqa-clone-job --host localhost:9526 https://openqa.opensuse.org/tests/2449859 QEMUVGA=qxl UEFI=1 UEFI_PFLASH_CODE=/usr/share/qemu/ovmf-x86_64-ms-code.bin UEFI_PFLASH_VARS=/usr/share/qemu/ovmf-x86_64-ms-vars.bin   DUALBOOT=1 MACHINE=uefi_win
Actions #11

Updated by tinita over 1 year ago

BOOT_MENU=1 helps:

script/openqa-clone-job --host localhost:9526 https://openqa.opensuse.org/tests/2449859 QEMUVGA=qxl UEFI=1 UEFI_PFLASH_CODE=/usr/share/qemu/ovmf-x86_64-ms-code.bin UEFI_PFLASH_VARS=/usr/share/qemu/ovmf-x86_64-ms-vars.bin DUALBOOT=1 BOOT_MENU=1
Actions #12

Updated by okurz over 1 year ago

  • Related to action #111866: Upgrade osd workers and openqa-monitor to openSUSE Leap 15.4 added
Actions #13

Updated by okurz over 1 year ago

  • Related to action #111863: Upgrade o3 workers to openSUSE Leap 15.4 size:M added
Actions #14

Updated by tinita over 1 year ago

I was able to enter the tianocore-devicemanager and select a different resolution. Created some needles.
Next: trying to enter the openSUSE bootmenu

Actions #15

Updated by favogt over 1 year ago

tinita wrote:

I was able to enter the tianocore-devicemanager and select a different resolution. Created some needles.
Next: trying to enter the openSUSE bootmenu

What's the plan on how to use this in production? Change the resolution on each (initial) boot or run this module once to generate a vars image and use that in all tests?

Actions #16

Updated by okurz over 1 year ago

favogt wrote:

tinita wrote:

I was able to enter the tianocore-devicemanager and select a different resolution. Created some needles.
Next: trying to enter the openSUSE bootmenu

What's the plan on how to use this in production? Change the resolution on each (initial) boot or run this module once to generate a vars image and use that in all tests?

I would say we should have an openQA test code implementation which is able to change the resolution first. And the configuration can be saved in an uefi-pflash-vars file that we could upload from openQA and reuse in other or all tests.

What I did locally to select the resolution manually and save that in the vars file:

/usr/bin/qemu-img create -f qcow2 -F raw -b /usr/share/qemu/ovmf-x86_64-ms-code.bin pflash-code-overlay0 1966080
/usr/bin/qemu-img create -f qcow2 -F raw -b /usr/share/qemu/ovmf-x86_64-ms-vars.bin pflash-vars-overlay0 131072
/usr/bin/qemu-system-x86_64 -vga qxl -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.fdtypeA=none -m 2048 -cpu host -netdev user,id=qanet0 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -device qemu-xhci -device usb-tablet -smp 1 -enable-kvm -no-shutdown -vnc :101,share=force-shared -drive id=pflash-code-overlay0,if=pflash,file=pflash-code-overlay0,unit=0,readonly=on -drive id=pflash-vars-overlay0,if=pflash,file=pflash-vars-overlay0,unit=1
Actions #17

Updated by tinita over 1 year ago

Actions #18

Updated by okurz over 1 year ago

Both PRs merged. I will upgrade ovmf on one o3 worker and trigger tests specifically there to crosscheck if this is enough.

EDIT: Removed zypper lock on openqaworker4 and cloned a specific test:

openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org/tests/2462733 WORKER_CLASS=openqaworker4 _GROUP=0 BUILD= TEST=okurz-gnome_dual_windows10_poo111992

Created job #2462909: opensuse-Tumbleweed-DVD-x86_64-Build20220710-gnome_dual_windows10@uefi_win -> https://openqa.opensuse.org/t2462909

Actions #19

Updated by okurz over 1 year ago

https://openqa.opensuse.org/tests/2462909#step/bootloader_uefi/40 failed so not good enough.

As I could not find older versions of qemu-ovmf-x86_64 I rolled back to an older snapshot:

# snapper ls
  # | Type   | Pre # | Date                     | User | Used Space | Cleanup | Description            | Userdata    
----+--------+-------+--------------------------+------+------------+---------+------------------------+-------------
 0  | single |       |                          | root |            |         | current                |             
21  | single |       | 2022-06-23T00:02:59 CEST | root | 116.28 MiB | number  | Snapshot Update of #20 |             
22  | single |       | 2022-06-24T00:59:13 CEST | root | 105.86 MiB | number  | Snapshot Update of #21 |             
23  | single |       | 2022-07-05T01:26:00 CEST | root |  97.38 MiB | number  | Snapshot Update of #22 |             
24  | pre    |       | 2022-07-06T14:28:10 CEST | root |   2.58 MiB | number  | zypp(zypper)           | important=no
25  | post   |    24 | 2022-07-06T14:28:23 CEST | root |   3.06 MiB | number  |                        | important=no
26  | single |       | 2022-07-07T00:57:17 CEST | root |  96.66 MiB | number  | Snapshot Update of #23 |             
27  | pre    |       | 2022-07-07T03:00:06 CEST | root | 560.00 KiB | number  | zypp(zypper)           | important=no
28  | post   |    27 | 2022-07-07T03:00:52 CEST | root |   4.07 MiB | number  |                        | important=no
29* | single |       | 2022-07-08T01:46:38 CEST | root |  57.60 MiB |         | Snapshot Update of #26 |             
30  | pre    |       | 2022-07-08T03:15:53 CEST | root | 448.00 KiB | number  | zypp(zypper)           | important=no
31  | post   |    30 | 2022-07-08T03:15:57 CEST | root |   3.40 MiB | number  |                        | important=no
32  | pre    |       | 2022-07-11T11:48:19 CEST | root | 240.00 KiB | number  | zypp(zypper)           | important=no
33  | post   |    32 | 2022-07-11T11:48:25 CEST | root | 708.00 KiB | number  |                        | important=no
# snapper rollback 31 && reboot
Actions #20

Updated by tinita over 1 year ago

https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/775 - Select 800x600 resolution in Tianocore bootloader
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15209 - Select 800x600 resolution in Tianocore bootloader

Actions #21

Updated by tinita over 1 year ago

  • Status changed from In Progress to Feedback
Actions #22

Updated by tinita over 1 year ago

  • Status changed from Feedback to In Progress

Will try it out on a worker

Actions #23

Updated by tinita over 1 year ago

Verification run on openqaworker4 with upgraded qemu-ovmf-x86_64 package: https://openqa.opensuse.org/tests/2467536

Looks good

Actions #24

Updated by tinita over 1 year ago

  • Status changed from In Progress to Feedback

Both PRs merged.

Is there anything left to do? Remove some zypper locks elsewhere?

Actions #25

Updated by okurz over 1 year ago

tinita wrote:

Is there anything left to do? Remove some zypper locks elsewhere?

Yes, remove the according zypper lock on all o3 machines and upgrade.

Actions #26

Updated by tinita over 1 year ago

  • Status changed from Feedback to Resolved

Checked all other o3 workers, and they are still on leap 15.3, so I resolve this now

Actions #27

Updated by favogt over 1 year ago

  • Due date deleted (2022-07-15)
  • Status changed from Resolved to Workable
  • % Done changed from 0 to 20

Unfortunately the PR only dealt with jobs which enter the OVMF menu anyway, like DUALBOOT cases. In e.g. BOOT_FROM_HDD cases, the firmware has autoboot enabled and the menu is not automatically entered, so the first screen is GRUB2 with the high resolution:
https://openqa.opensuse.org/tests/2470022#step/bootloader_uefi/1
https://openqa.opensuse.org/tests/2472141#step/bootloader_uefi/1

One approach to fix that is to try to enter the menu forcibly and then configure the resolution. I attempted that but failed to get it working. Considering it's hard for a human to get the timing right, it's probably near impossible for openQA to get that done in a reliable fashion.

IMO the only reliable way is to do it like comment #16 and use a preconfigured OVMF NVRAM for all UEFI tests. Alternatively we could just ignore that the resolution is not native to openQA and just create blurry needles, but that's IMO not great either.

For now I downgraded OVMF on ow4 again so that we can address this properly.

Actions #28

Updated by livdywan over 1 year ago

  • Copied to action #113794: Use prepared OVMF image with expected settings size:M added
Actions #29

Updated by okurz over 1 year ago

  • Status changed from Workable to Blocked
  • Assignee changed from tinita to okurz
  • % Done changed from 20 to 0
Actions #30

Updated by okurz over 1 year ago

  • Copied to action #114523: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl, but on aarch64 size:M added
Actions #31

Updated by tinita over 1 year ago

  • Priority changed from High to Normal

#113794 is in backlog with high priority

Actions #32

Updated by okurz over 1 year ago

  • Status changed from Blocked to Feedback

#113794 was resolved. jlausuch reported a problem in https://suse.slack.com/archives/C02CANHLANP/p1663319308810629?thread_ts=1663246489.943929&cid=C02CANHLANP , waiting for their response.

Actions #33

Updated by okurz over 1 year ago

  • Due date set to 2022-09-30

Suggestion to all where tests still fail: Use the most downstream place where UEFI+QEMUVGA=qxl/virtio is set. So e.g. if UEFI is set by the machine and QEMUVGA in a job template then set in the job template. If QEMUVGA is set in a machine but UEFI in a job template (I advise against that combination setting) then in the job template. If UEFI+QEMUVGA are set in a machine definition (preferred solution) then please also set in the machine.

Actions #36

Updated by okurz over 1 year ago

  • Related to action #116914: [qe-core] recent uefi changes makes test fail added
Actions #37

Updated by okurz over 1 year ago

  • Related to action #116812: [qe-core] Leap 15.5 uefi console switch fail size:M added
Actions #38

Updated by okurz over 1 year ago

  • Related to action #116704: [qe-core] nvme@uefi: boot from DVD post install instead of from HDD added
Actions #39

Updated by okurz over 1 year ago

  • Subject changed from Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M to Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl
  • Due date deleted (2022-09-30)
  • Status changed from Feedback to New
  • Assignee deleted (okurz)

See related tickets. Apparently multiple related issues. Back to planning.

Actions #40

Updated by livdywan over 1 year ago

  • Subject changed from Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl to Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M
  • Description updated (diff)
  • Status changed from New to Workable

Putting back on the backlog. Let's confirm what the related issues are about with respect to AC2.

Actions #41

Updated by tinita over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to tinita
Actions #42

Updated by openqa_review over 1 year ago

  • Due date set to 2022-10-14

Setting due date based on mean cycle time of SUSE QE Tools

Actions #43

Updated by okurz over 1 year ago

Comparing opensuse-Tumbleweed-DVD-x86_64-Build20221003-upgrade_Leap_15.2_cryptlvm@uefi failing in bootloader_uefi with the custom OVMF vars file to opensuse-Tumbleweed-DVD-x86_64-cryptlvm_vanilla_upgraded_ovmf_okurz@uefi not failing in bootloader_uefi. It seems like the custom OVMF vars image is remembering "something" about boot selections hence preventing the system to behave as we expect it.

Actions #44

Updated by mkittler over 1 year ago

Considering @okurz's last findings we need to either tweak how we create the custom OVMF vars file (so it acts like the vanilla file and only changes the resolution) or we find a way to deal with the different resolution. Not sure what we can tweak when creating the custom vars file, though. Dealing with the different resolution would maybe be possible by creating specific needles but at least in the installer we should not need any specific needles anymore. We actually could look into setting XRES=1280 and YRES=800 in accordance to the new defaults for qxl tests. With a bit of luck it doesn't need to many needle changes (at least less than dealing with distorted/resized images).

Note that the only really problematic case was the case where GRUB then booted with a resolution of 1280x800 and even the installer continued using that wrong resolution. I suppose these problematic cases are specific to the qxl backend. Considering only qxl is the really problematic case we should also restrict the use of a custom OVMF vars file (or any other workarounds) to that scenario in any case. I suppose dealing with GRUB booting at 1024x768 (as we see it in other graphics backends) by editing some needles is acceptable (we don't need to force GRUB to 800x600).

Actions #45

Updated by tinita over 1 year ago

Just copying from #116704:

I created this product bug report: https://bugzilla.opensuse.org/show_bug.cgi?id=1204067


I ran a test with the downgraded and with the current package:

current: https://openqa.opensuse.org/tests/2778306#step/bootloader_start/2
downgraded: https://openqa.opensuse.org/tests/2778580#step/bootloader_start/2
I tested with the branch that removes all old grub2-tw needles:
NEEDLES_DIR=https://github.com/perlpunk/os-autoinst-needles-opensuse.git#remove-bootloader-needles

My newly created needles are matching 100% in both cases.

PR: https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/784

Actions #46

Updated by tinita over 1 year ago

I downgraded qemu-ovmf-x86_64 on all workers again.

Actions #47

Updated by tinita over 1 year ago

  • Status changed from In Progress to Feedback
Actions #48

Updated by tinita over 1 year ago

  • Due date changed from 2022-10-14 to 2022-10-21
Actions #49

Updated by favogt over 1 year ago

https://gitlab.com/kraxel/virt-firmware has some support for modifying EFI variable store files. With that it's possible to see the change in the file itself:

name=PlatformConfig guid=7235c51c-0c80-4cab-87ac-3b084a6304b1 size=8
  qword: 0x0000025800000320

The format is defined here: https://github.com/tianocore/edk2/blob/c05a218a9758225ddf94eedb365633f2154551da/OvmfPkg/PlatformDxe/PlatformConfig.h#L21
A uint32_t of the horizontal resolution (800 -> 0x320) followed by an uint32_t of the vertical resolution (600 -> 0x258).

With some modification to also support writing PlatformConfig alongside bootorder and certificates, it should be possible to set the preferred resolution in var images directly.

Actions #50

Updated by favogt over 1 year ago

tinita wrote:

I downgraded qemu-ovmf-x86_64 on all workers again.

Looks like ow1 had the new one still, I downgraded it.

Actions #51

Updated by tinita over 1 year ago

That's weird, I did

for i in openqaworker1 openqaworker4 openqaworker7 openqaworker19 rebel; do echo $i; ssh root@$i "zypper in --oldpackage http://download.opensuse.org/update/leap/15.3/sle/noarch/qemu-ovmf-x86_64-202008-150300.10.14.1.noarch.rpm; zypper al -m 'poo#116914' qemu-ovmf-x86_64; zypper locks"; done

Maybe someone upgraded it again?

Actions #52

Updated by tinita over 1 year ago

I also now downgraded all osd workers (that didn't already have the downgrade).

Actions #54

Updated by livdywan over 1 year ago

  • Status changed from Feedback to Blocked
Actions #55

Updated by favogt over 1 year ago

tinita wrote:

That's weird, I did

for i in openqaworker1 openqaworker4 openqaworker7 openqaworker19 rebel; do echo $i; ssh root@$i "zypper in --oldpackage http://download.opensuse.org/update/leap/15.3/sle/noarch/qemu-ovmf-x86_64-202008-150300.10.14.1.noarch.rpm; zypper al -m 'poo#116914' qemu-ovmf-x86_64; zypper locks"; done

Maybe someone upgraded it again?

And today I also had to downgrade it on ow4 and ow7. /var/log/zypp/history does not show your downgrade attempt, which is strange.

Actions #56

Updated by tinita over 1 year ago

  • Due date deleted (2022-10-21)
Actions #57

Updated by ggardet_arm over 1 year ago

I did few tests on aarch64 o3 workers and found that:

  • qemu 6.2.0 + qemu-uefi-aarch64 2022.02: is broken with distorted image, visible on fonts of grub (known already)
  • qemu 6.2.0 + qemu-uefi-aarch64 2022.05 (from virt repo): works, but grub is displayed with a higher resolution
  • qemu 7.1.0 (from TW) + qemu-uefi-aarch64 2022.02: is broken with distorted image, visible on fonts of grub
  • qemu 7.1.0 (from TW) + qemu-uefi-aarch64 2022.05 (from virt repo): works, but grub is displayed with a higher resolution

So, I updated qemu-uefi-aarch64 and qemu-uefi-aarch32 to version 2022.05 from virt repo for all aarch64 o3 workers. (It should also be safe for boo#1197458)

Actions #58

Updated by tinita about 1 year ago

  • Status changed from Blocked to Workable
  • Assignee deleted (tinita)

I unblock and unassign myself, since there have been more urgent tickets and tasks repeatedly.

See also the comment https://progress.opensuse.org/issues/116812#note-24

https://bugzilla.opensuse.org/show_bug.cgi?id=1204067

The symptom looks the same as bsc#1203825.

Please try to upgrade qemu-ovmf-x86_64 that at least contains the following change:

So upgrading might be working now.

Actions #59

Updated by okurz about 1 year ago

  • Tags changed from reactive work to reactive work, infra
  • Priority changed from Normal to High
Actions #60

Updated by livdywan about 1 year ago

Concrete steps:

Actions #61

Updated by tinita about 1 year ago

cdywan wrote:

Concrete steps:

  • Pick an o3 worker
  • remove the zypper lock
  • Install the package
  • Check if rpm -q --changelog qemuvmfx86_64 contains the change from comment #1

I just checked on a fresh 15.4 container that the patch is there:

% cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.4"
...
% zypper in qemu-ovmf-x86_64
...
% zypper info qemu-ovmf-x86_64
...
Information for package qemu-ovmf-x86_64:
-----------------------------------------
Repository     : Update repository with updates from SUSE Linux Enterprise 15
Name           : qemu-ovmf-x86_64
Version        : 202202-150400.5.5.1
Arch           : noarch
Vendor         : SUSE LLC <https://www.suse.com/>
Installed Size : 59.0 MiB
Installed      : Yes
Status         : up-to-date
Source package : ovmf-202202-150400.5.5.1.src
Upstream URL   : https://github.com/tianocore/edk2
Summary        : Open Virtual Machine Firmware - QEMU rom images (x86_64)
...
% rpm -ql qemu-ovmf-x86_64 --changelog | head
* Fri Oct 07 2022 jlee@suse.com
- Add patches to fix detection issue of NVME controller (bsc#1203825)
  - ovmf-MdeModulePkg-NvmExpressDxe-fix-check-for-Cap.Css.patch
  - ovmf-MdeModulePkg-NvmExpressPei-fix-check-for-NVM-command.
Actions #62

Updated by tinita 12 months ago

  • Status changed from Workable to In Progress
  • Assignee set to tinita
Actions #63

Updated by tinita 12 months ago

  • Status changed from In Progress to Workable
  • Assignee deleted (tinita)

Seems I never can work on this ticket.
I just got a short notice of a meeting tomorrow that I have to prepare for.

Actions #64

Updated by tinita 12 months ago

  • Status changed from Workable to In Progress
Actions #65

Updated by tinita 12 months ago

@favogt could you run the tests that were previously failing, on openqaworker19?
I upgraded there to ovmf-202202-150400.5.5.1.src which has several patches that might fix the issues.

I'm not sure how to run tests because all the linked tests are deleted by now. The only one I ran was https://openqa.opensuse.org/tests/3189827

Actions #66

Updated by okurz 12 months ago

  • Assignee set to tinita
Actions #67

Updated by okurz 12 months ago

  • Status changed from In Progress to Resolved

Talked with tinita. https://openqa.opensuse.org/tests/3189827 looks good. Did

for i in aarch64 openqaworker4 openqaworker7 openqaworker19 openqaworker20 qa-power8-3 rebel; do echo $i && ssh root@$i "zypper rl qemu-ovmf-x86_64 && zypper -n in qemu-ovmf-x86_64" ; done

we also have the zypper lock on OSD workers so I did

sudo salt --no-color --state-output=changes -C 'G@roles:worker' cmd.run 'zypper rl qemu-ovmf-x86_64 && zypper -n in qemu-ovmf-x86_64 && rpm -q qemu-ovmf-x86_64'

but as I found no OSD tests linked here I did not retrigger any tests for verification.
I also VERIFIED FIXED https://bugzilla.opensuse.org/show_bug.cgi?id=1204067 now.

So this should suffice for the work here.

Actions #68

Updated by pstivanin 11 months ago

@Oliver: I see that on both arm-1 and arm-3 there are still some locks:

pstivanin@openqa:~> sudo salt 'openqaworker-arm-1.suse.de' cmd.run 'zypper ll'
openqaworker-arm-1.suse.de:

    # | Name              | Type    | Repository | Comment
    --+-------------------+---------+------------+-----------
    1 | qemu-ovmf-x86_64  | package | (any)      | poo#116812
    2 | qemu-uefi-aarch64 | package | (any)  
pstivanin@openqa:~> sudo salt 'openqaworker-arm-3.suse.de' cmd.run 'zypper ll'
openqaworker-arm-3.suse.de:

    # | Name              | Type    | Repository | Comment
    --+-------------------+---------+------------+-----------
    1 | qemu-ovmf-x86_64  | package | (any)      | poo#116812
    2 | qemu-uefi-aarch64 | package | (any)      |

is this expected?

Thanks

Actions #69

Updated by okurz 11 months ago

pstivanin wrote:

@Oliver: I see that on both arm-1 and arm-3 there are still some locks:
[...]
is this expected?

Yes, see #114523 and #116812

Actions

Also available in: Atom PDF