Project

General

Profile

action #111992

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

Added by favogt 3 months ago. Updated 29 days ago.

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

0%

Estimated time:
Difficulty:

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

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

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

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

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

Copied to openQA Infrastructure - action #114523: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl, but on aarch64, auto_review:"(?s)aarch64.*uefi.*no candidate needle.*grub":retryBlocked2022-06-03

History

#1 Updated by okurz 3 months 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! :)

#2 Updated by okurz 3 months 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?

#3 Updated by cdywan 2 months 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.

#4 Updated by tinita 2 months 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

#5 Updated by cdywan 2 months ago

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

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

#6 Updated by openqa_review 2 months ago

  • Due date set to 2022-06-24

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

#7 Updated by mkittler 2 months 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.

#8 Updated by cdywan 2 months 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.

#9 Updated by okurz about 2 months ago

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

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

#10 Updated by tinita about 1 month 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

#11 Updated by tinita about 1 month 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

#12 Updated by okurz about 1 month ago

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

#13 Updated by okurz about 1 month ago

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

#14 Updated by tinita about 1 month ago

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

#15 Updated by favogt about 1 month 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?

#16 Updated by okurz about 1 month 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

#17 Updated by tinita about 1 month ago

#18 Updated by okurz about 1 month 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

#19 Updated by okurz about 1 month 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

#20 Updated by tinita about 1 month 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

#21 Updated by tinita about 1 month ago

  • Status changed from In Progress to Feedback

#22 Updated by tinita about 1 month ago

  • Status changed from Feedback to In Progress

Will try it out on a worker

#23 Updated by tinita about 1 month ago

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

Looks good

#24 Updated by tinita about 1 month ago

  • Status changed from In Progress to Feedback

Both PRs merged.

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

#25 Updated by okurz about 1 month 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.

#26 Updated by tinita about 1 month 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

#27 Updated by favogt 29 days 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.

#28 Updated by cdywan 29 days ago

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

#29 Updated by okurz 29 days ago

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

#30 Updated by okurz 26 days ago

  • Copied to action #114523: Deal with QEMU and OVMF default resolution being 1280x800, affecting (at least) qxl, but on aarch64, auto_review:"(?s)aarch64.*uefi.*no candidate needle.*grub":retry added

Also available in: Atom PDF