QA » openQA Project » openQA Tests

might be related to #39695 and introduced by https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5598

might be also worth a look on https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5563 and ask richie for support

jorauch wrote:

Taking a look

any findings? :)

mgriessmeier wrote:

jorauch wrote:

Taking a look

any findings? :)

I cannot reproduce it locally since the job won't start due to too old version of some perl stuff on the worker
Should we set it to blocked until Sergio returns?
zypper in perl-Mojo-IOLoop-ReadWriteProcess=0.23-lp150.13.1

jorauch wrote:

mgriessmeier wrote:

jorauch wrote:

Taking a look

any findings? :)

I cannot reproduce it locally since the job won't start due to too old version of some perl stuff on the worker
Should we set it to blocked until Sergio returns?

could you ask Santi about the outdated perl stuff?

Updated the package, still not working

Finally this is reproducible:
http://pinky.arch.suse.de/tests/1422
Will check tomorrow the mentioned PR

Even with the reverted commit it is not working:
http://pinky.arch.suse.de/tests/1426

Actually it is not booting from the iso but from the system

While looking at this with jrauch we found out that BOOTFROM=d is needed, as the UEFI_PFLASH variables come with the bootorder from an already installed system, so in this case... either BOOTFROM=d or use UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin but always you can check the manpage of qemu :) which helped us to figure it out

Will go for the UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin way since it feels more natural.

Working setting:
UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-aarch64-vars.bin
UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-%ARCH%-vars.bin (?)

Broken Setting:
UEFI_PFLASH_VARS=sle-12-SP4-aarch64-Build0366-Server-DVD@aarch64-gnome-encrypted-uefi-vars.qcow2
UEFI_PFLASH_VARS=%DISTRI%-%VERSION%-%ARCH%-Build%BUILD%-%FLAVOR%@%MACHINE%-%DESKTOP%-encrypted-uefi-vars.qcow2

Or you can use BOOTFROM=cdrom. If it overrides the bootorder stored in the vars file then you don't need to change the vars file. However I think this is controlled by the UEFI firmware and I am not entirely sure what behaviour to expect.

To be honest, I don't like the idea of using a blank vars file on a system where an OS is supposed to be already installed just because it is not realistic. So I would only recommend that as a last resort.

UEFI_PFLASH_VARS=/usr/share/qemu/aavmf-%ARCH%-vars.bin

This file name is decided by the firmware package. Unfortunately only the ARM firmware starts with aavmf IIRC, see the machine definitions.

x86: https://openqa.suse.de/tests/2029889#
Works just fine, so this is still an architecture specific problem and not broken in general by adding BOOTFROM=cdrom
Sadly we cannot see which entry is booted on the video

#36408 is at least related after oorlov reopened it :)

I don't think so, since #36408 is about the firmware taking too long to boot (which can imho barely be fixed on test side) this is about either booting in the wrong medium (if mgriessmeier is right) or booting cryptlvm on aarch64 being broken (if I am correct)

According to the logs (https://openqa.suse.de/tests/2029202/file/serial0.txt):

>>> SUSE Linux Enterprise 12 SP4 installation program v5.1.14.0 (c) 1996-2018 SUSE LLC <<<
Starting udev... [ 6.030318] alua: device handler registered

(Lower quarter, definitely the second boot process)

Mgriessmeier is right here and we need to adapt grub_test for aarch64 and cryptlvm

Also the needle content of inst-bootmenu varies between the architectures
For UEFI we already have a boot mechanism that presses up, but it is not applied since it comes after the bootfrom=d branch -> the BOOTFROM=cdrom changed the behaviour here
-> either we go back one step and try to adapt the uefi variables (best when generating them)
-> or we accept the new behaviour and work around it
It looks to me that we are only lucky on the other architectures that the harddisk is selected by default and we have bad luck on aarch64.

For a workaround we would need to identify the specific variables that determine these suites and add another branch in handle_installer_medium_bootup

This is the reason for the messup:
https://progress.opensuse.org/issues/11948

Need to use handle_uefi_boot_disk_workaround without breaking stuff

New version of PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5821

great, thank you!

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: cryptlvm+cancel_existing
https://openqa.suse.de/tests/2163827

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: cryptlvm+cancel_existing
https://openqa.suse.de/tests/2212543