QA » openQA Project

mkittler wrote:

Yesterday I explored the possibility to use efivar or tools from efitools to update the pflash-vars file without having to spawn a VM. However, it didn't work (e.g. efivar --fromfile=… didn't allow to edit read/write to the file). So likely we cannot avoid spawning a VM for doing the settings.

Would you mind clarifying what didn't work? Which commands did you try? Did you get an error?

I tried efivar --fromfile=pflash-vars-overlay0 --list and it just returned my normal EFI vars (and not the ones from the QEMU image). Specifying /usr/share/qemu/ovmf-x86_64-ms-vars.bin directly didn't work either. I've checked the binaries from efitools but their --help-text didn't look like specifying a file would be possible at all.

I created a job which sets the resolution in the tianocore menu, then enters grub and types "halt".
It publishes the modified pflash file via PUBLISH_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2.
Now I need to test if I can use that in a second job.

openqa-clone-job --host localhost:9526 https://openqa.opensuse.org/tests/2536831 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 PAUSE_ON_SCREEN_MISMATCH=1 _SKIP_POST_FAIL_HOOKS=1 RETRY=0 SCHEDULE=tests/boot/boot_to_desktop _TRIGGER_JOB_DONE_HOOK=0 ISO=openSUSE-Tumbleweed-DVD-x86_64-Snapshot20220824-Media.iso HDD_1= PUBLISH_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2

...

Discussed in the Unblock. Marius suggested this could be done by moving the logic into a test module, come up with a jobs post command line and e.g. add this to a (masnual) gitlab pipeline.

Draft PRs:

• https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15454
• https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/782

I created a verification run:
https://openqa.opensuse.org/tests/2600931
Interestingly it worked with the openSUSE-Tumbleweed-NET-x86_64-Snapshot20220829-Media.iso while locally only DVD worked.
Next step: use the generated pflash vars on o3

This PR is needed as a first step, so that existing code does not fail if we use the prepared pflash vars image: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15471 - Allow already preselected resolution 800x600

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15471 merged

Verification run: https://openqa.opensuse.org/tests/2636971#step/bootloader_uefi/19

Setting: UEFI_PFLASH_VARS ovmf-x86_64-ms-vars-800x600.qcow2

Confirming that it is accepeted that the correct resolution is already set.

Verification run on openqaworker1 with an upgraded qemu-ovmf-x86_64-202202-150400.3.3.noarch: https://openqa.opensuse.org/tests/2637658

Downgraded and added zypper lock again

Ready for review:

• https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15454
• https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/782

Not sure about the CI error https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15454#issuecomment-1239431835

Still waiting for review:

• https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15454
• https://github.com/os-autoinst/os-autoinst-needles-opensuse/pull/782

I'm trying to figure out the right openqa-cli api -X POST jobs commandline
Marius pointed my to
https://github.com/os-autoinst/scripts/blob/master/trigger-openqa_in_openqa#L30

Then I need to create a new repo in gitlab and create a schedule.

Current working command:

openqa-cli api -X POST jobs --host https://openqa.opensuse.org
 TEST=ovmf-resolution 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
 SCHEDULE=tests/boot/tianocore_set_resolution.pm
 PUBLISH_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2
 DISTRI=openSUSE VERSION=Tumbleweed FLAVOR=NET
 ISO=openSUSE-Tumbleweed-NET-x86_64-Snapshot20220911-Media.iso

https://openqa.opensuse.org/tests/2647994

I moved the find_latest_published_tumbleweed_image from trigger-openqa_in_openqa into _common in smaller functions in order to test and reuse it. So far I pushed to a branch:
https://github.com/perlpunk/scripts/tree/trigger-pflash-test

Then I can use it in a new script to schedule the pflash job with the latest iso image.

We triggered a manual job from github actions which created an ovmf vars image with resolution 800x600. This created an image "ovmf-x86_64-ms-vars-800x600.qcow2" on o3 which I hard-linked to the "fixed" dir /var/lib/openqa/share/factory/hdd/fixed . We still plan to create an update on a weekly base.

tinita changed the definitions of openQA machines "uefi_win" and win10+win11 variants to use that file. I created a verification run with

openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org/tests/2664073 _GROUP=0 BUILD= TEST=gnome_dual_windows10_svga_ovmf_image

Created job #2669479: opensuse-Tumbleweed-DVD-x86_64-Build20220914-gnome_dual_windows10@uefi_win -> https://openqa.opensuse.org/t2669479

tinita removed the package locks on o3 workers and upgraded the package. I created https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15537 to only apply the resolution setting when necessary.

I downloaded the pflash vars image to OSD once manually with

cd /var/lib/openqa/factory/hdd/fixed
wget https://openqa.opensuse.org/tests/2669542/asset/hdd/ovmf-x86_64-ms-vars-800x600.qcow2

and tinita removed the locks from both o3+osd

EDIT: whoopsie, the above test job is missing the actual image setting. Retriggered with

openqa-clone-job --skip-chained-deps --within-instance https://openqa.opensuse.org/tests/2664073 _GROUP=0 BUILD= TEST=gnome_dual_windows10_svga_ovmf_image UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2

Created job #2670480: opensuse-Tumbleweed-DVD-x86_64-Build20220914-gnome_dual_windows10@uefi_win -> https://openqa.opensuse.org/t2670480

https://github.com/os-autoinst/scripts/pull/187 - Trigger test to generate pflash vars image (merged)

• Added toolsbot user and api key in o3
• Added api key to https://github.com/os-autoinst/scripts
• Added a workflow which is run by cron, but can also be manually started: https://github.com/os-autoinst/scripts/actions/workflows/schedule.yml
• Removed zypper lock and upgraded qemu-ovmf-x86_64 on all o3 and osd workers (except power8)
• Changed setting UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2 for machines uefi_win, win10_uefi, win11_uefi on o3 and osd so now they should pass again without having to downgrade the package

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/15537 merged. https://openqa.opensuse.org/t2670542 shows that tests work now with the new image without setting any different resolution in the firmware menu. I suggest to wait until tomorrow to resolve the ticket unless objections or regressions have been met.

@okurz @tinita
I see most uefi jobs failing now, specially in JeOS and SLE Micro... I tried restarting some of them with UEFI_PFLASH_VARS=ovmf-x86_64-ms-vars-800x600.qcow2 and seems to work... should we update this in uefi machine in OSD or should I specify this variable in all uefi tests that are broken?

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.

Please use the still open #111992 for any remaining problems.

Hi, I have updated the machine uefi-virtio-vga in OSD (which already had QEMUVGA=virtio) with UEFI_PFLASH_CODE=ovmf-x86_64-ms-vars-800x600.qcow2 .
Those are used in JeOS tests where we had the most bunch of tests failing in the bootloader.

@tinita:
I see that there still is a lock on the following worker:

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

    # | Name              | Type    | Repository | Comment
    --+-------------------+---------+------------+--------
    1 | qemu-uefi-aarch64 | package | (any)      |

is this expected or can we remove it?

Thanks a lot!

pstivanin wrote:

@tinita:
I see that there still is a lock on the following worker:

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

    # | Name              | Type    | Repository | Comment
    --+-------------------+---------+------------+--------
    1 | qemu-uefi-aarch64 | package | (any)      |

is this expected or can we remove it?

This is still expected, see #114523 for details regarding aarch64.