action #111992
closedDeal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl size:M
Added by favogt almost 2 years ago. Updated about 1 year ago.
0%
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¶
- Confirm in dedicated test
- Check different QEMUVGA settings, e.g. (none), std, cirrus, qxl, virtio
- Add test steps to change the resolution in OVMF
- Configure and resize a window on the host to change the resolution that way
- See https://developer.fedoraproject.org/tools/virtualization/setting-viewport-resolution-using-ovmf-bios.html step 12
- Find out where the qxl vga is being used and consider changing those tests
Workaround¶
- Option 1: Downgrade OVMF to <= 202008-150300.10.14.1
- Option 2 (TBC): Use a different graphics setting than
QEMUVGA=qxl
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! :)
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?
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.
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
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
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
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.
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.
Updated by okurz almost 2 years 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.
Updated by tinita almost 2 years 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
Updated by tinita almost 2 years 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
Updated by okurz almost 2 years ago
- Related to action #111866: Upgrade osd workers and openqa-monitor to openSUSE Leap 15.4 added
Updated by okurz almost 2 years ago
- Related to action #111863: Upgrade o3 workers to openSUSE Leap 15.4 size:M added
Updated by tinita almost 2 years ago
I was able to enter the tianocore-devicemanager and select a different resolution. Created some needles.
Next: trying to enter the openSUSE bootmenu
Updated by favogt almost 2 years 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?
Updated by okurz almost 2 years 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 bootmenuWhat'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
Updated by tinita almost 2 years ago
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15184 - Select resolution in Tianocore bootloader
https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/774 - Select resolution in Tianocore bootloader
Updated by okurz almost 2 years 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
Updated by okurz almost 2 years 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
Updated by tinita almost 2 years 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
Updated by tinita almost 2 years ago
- Status changed from In Progress to Feedback
Updated by tinita almost 2 years ago
- Status changed from Feedback to In Progress
Will try it out on a worker
Updated by tinita almost 2 years ago
Verification run on openqaworker4 with upgraded qemu-ovmf-x86_64 package: https://openqa.opensuse.org/tests/2467536
Looks good
Updated by tinita almost 2 years ago
- Status changed from In Progress to Feedback
Both PRs merged.
Is there anything left to do? Remove some zypper locks elsewhere?
Updated by okurz almost 2 years 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.
Updated by tinita almost 2 years 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
Updated by favogt almost 2 years 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.
Updated by livdywan almost 2 years ago
- Copied to action #113794: Use prepared OVMF image with expected settings size:M added
Updated by okurz almost 2 years ago
- Status changed from Workable to Blocked
- Assignee changed from tinita to okurz
- % Done changed from 20 to 0
-> #113794
Updated by okurz almost 2 years ago
- Copied to action #114523: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl, but on aarch64 size:M added
Updated by tinita over 1 year ago
- Priority changed from High to Normal
#113794 is in backlog with high priority
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.
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.
Updated by okurz over 1 year ago
- Related to action #116914: [qe-core] recent uefi changes makes test fail added
Updated by okurz over 1 year ago
- Related to action #116812: [qe-core] Leap 15.5 uefi console switch fail size:M added
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
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.
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.
Updated by tinita over 1 year ago
- Status changed from Workable to In Progress
- Assignee set to tinita
- #116674 is already fixed
- #116671 is already fixed
- #116812 setting UEFI_PFLASH_VARS changed, still waiting for a new uefi-2G schedule to confirm
- #116914 unclear
- #116704 tried https://openqa.opensuse.org/tests/2677570 with UEFI_PFLASH_VARS=/usr/share/qemu/ovmf-x86_64-ms-vars.bin. https://openqa.opensuse.org/tests/2764890 also failed
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
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.
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).
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
Updated by tinita over 1 year ago
I downgraded qemu-ovmf-x86_64 on all workers again.
Updated by tinita over 1 year ago
- Due date changed from 2022-10-14 to 2022-10-21
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.
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.
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?
Updated by tinita over 1 year ago
I also now downgraded all osd workers (that didn't already have the downgrade).
Updated by tinita over 1 year ago
Updated by livdywan over 1 year ago
- Status changed from Feedback to Blocked
Blocked by https://bugzilla.opensuse.org/show_bug.cgi?id=1204067 for now
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"; doneMaybe 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.
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)
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.
Updated by okurz about 1 year ago
- Tags changed from reactive work to reactive work, infra
- Priority changed from Normal to High
Updated by livdywan about 1 year ago
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
- check/re-run the test from https://bugzilla.opensuse.org/show_bug.cgi?id=1204067
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.
Updated by tinita about 1 year ago
- Status changed from Workable to In Progress
- Assignee set to tinita
Updated by tinita about 1 year 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.
Updated by tinita about 1 year 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
Updated by okurz about 1 year 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.
Updated by pstivanin about 1 year 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