QA » openQA Project » openQA Tests

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

This bug is still referenced in a failing openQA test: default
https://openqa.suse.de/tests/1706798

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

This bug is still referenced in a failing openQA test: default
https://openqa.suse.de/tests/1795627

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

This bug is still referenced in a failing openQA test: lvm-full-encrypt
https://openqa.suse.de/tests/1825212

recent failure in sle-12-SP4-Server-DVD-s390x-Build0286-lvm-encrypt-separate-boot@s390x-kvm-sle12 -> https://openqa.suse.de/tests/1825231#step/reboot_gnome/22

Also related is https://bugzilla.suse.com/show_bug.cgi?id=1085181 about "openQA test fails in reboot_gnome - stuck in evaluating the password"

It is not just related. It is the same issue.

@okurz, Is it not the same case as you described here ?

Why we are keeping both progress and bugzilla tickets in that case?

I've investigated the issue with the DEBUG_SHUTDOWN variable and 6000 timeout.

The test stuck after pressing 'Authenticate' button while entering the password on reboot.

So, it seems like the reboot itself is not called, so /usr/lib/systemd/system-shutdown/debug.sh is not executed and there are no logs in the serial console.

So, I've investigated the issue more and find out, that the test fails due to infrastructure/tests design. It is not a product issue.

The following line in bootloader_zkvm.pm:

$svirt->change_domain_element(on_reboot => 'destroy');

was removed from:

71        if (get_var('ZDUP') or get_var('ONLINE_MIGRATION') or get_var('BOOT_HDD_IMAGE') or get_var('AUTOYAST')) {
72            $svirt->change_domain_element(on_reboot => undef);
            $svirt->change_domain_element(on_reboot => 'destroy');
73        }

That makes the vm to not change the status from 'running' to 'shut off' while rebooting, but in os-autoinst/backend/svirt.pm test checks for 'shut off' state

143        $rsp = $self->run_cmd("! virsh dominfo $vmname | grep -w 'shut off'");

I've changed that, but I've got: error: internal error: qemu unexpectedly closed the monitor

[2018-08-15T16:31:25.0836 CEST] [debug] Command executed: virsh  start openQA-SUT-7
[2018-08-15T16:31:26.0113 CEST] [debug] GET "/UfM8yXmYHaqLB1YY/isotovideo/status" (6ec93a98)
[2018-08-15T16:31:26.0114 CEST] [debug] Routing to a callback
[2018-08-15T16:31:26.0114 CEST] [debug] 200 OK (0.000897s, 1114.827/s)
[2018-08-15T16:31:26.0200 CEST] [debug] Command's stderr:
error: Failed to start domain openQA-SUT-7
error: internal error: qemu unexpectedly closed the monitor

• $ sudo virsh -c qemu:///system version --daemon

Compiled against library: libvirt 3.3.0
Using library: libvirt 3.3.0
Using API: QEMU 3.3.0
Running hypervisor: QEMU 2.9.1
Running against daemon: 3.3.0

• vim /etc/os-release

PRETTY_NAME="SUSE Linux Enterprise Server 12 SP3"

I guess, that the QEMU error might be because of out-of dated version of QEMU itself (e.g. see https://bugzilla.redhat.com/show_bug.cgi?id=1571546)

Still cannot resolve the ticket as on the last build, reboot_gnome module is not reached due to fails in the modules before it. So, waiting for a passed one.

I've checked the last builds and reboot_gnome fails but by the other reason, on wait_serial. My first assumption is that the current timeout is not enough.

Currently, I'm not able to test the issue on my local environment due to https://progress.opensuse.org/issues/39503

okurz wrote:

Haven't we mentioned that today in the daily meeting?

This is why I wanted to proceed further with the issue. I've updated all the packages including openQA and os-autoinst from devel-openQA repo (tha I've mentioned in 39503#note-22), but os-autoinst does not contain the fix.

coolo has removed the "blocker" ticket

Why it is removed, though the fix is not in the repo yet? My ticket is still blocked by the encoding issue. Will try to use workaround mentioned by coolo.

oorlov wrote:

[…] the fix is not in the repo yet?

It is. See #39503#note-23 mentioning that you used an old version. #39503#note-21 provides more details. Are you sure you use the fix from devel:openQA? If you use the package from Tumbleweed oss repos you need to wait for the openQA-in-openQA tests to be fixed or provide help yourself: #41465

Executed: https://openqa.suse.de/tests/overview?distri=sle&version=12-SP4&build=_poo36279_install_only&groupid=132
5 of 5 passed.

@okurz, should we close that ticket? Or we'll continue working on it as on 'New Test'?

oorlov wrote:

Executed: https://openqa.suse.de/tests/overview?distri=sle&version=12-SP4&build=_poo36279_install_only&groupid=132
5 of 5 passed.

Well, please check also other scenarios for the same test suite as we changed a setting in the test suite, e.g. SLE15 as well, x86_64, as well. By now I guess new builds including these scenarios have been triggered, at least for SLE15, already.

@okurz, should we close that ticket? Or we'll continue working on it as on 'New Test'?

After you checked the above set it to "Resolved". It is acceptable to have reduced test coverage in this case.