QA (public) » openQA Project (public) » openQA Tests (public)

if it ever actually reboots and not just shut down, will investigate next week

it looks like it is hanging in grub, and we dont press return: https://openqa.suse.de/tests/3796544#step/reboot_gnome/27

sorry my mistake, we already miss grub in serial, but in fact it is shown, just too late - so yeah most likely timeout issue

Hello mgriessmeier and zluo,

May I treat the s390x reboot problem from my test case are the related issue with this one?
https://openqa.nue.suse.com/tests/3987551#step/fips_setup/28

The issue was reproduced from new build (155.1) and it is also the problem about boot fail after rebooting s390x.

Thanks a lot for your information in advance.

I have tired "time_out=300s" security test case still failed on the same reason:
"echo >$pty" got "-bash:/dev/pts/5: permission denied"

FYI:
http://openqa.nue.suse.com/tests/4004166#
in lib/opensusebasetest.pm:
...

wait_serial('GNU GRUB', 180) || diag 'Could not find GRUB screen, continuing nevertheless, trying to boot';
wait_serial('GNU GRUB', 300) || diag 'Could not find GRUB screen, continuing nevertheless, trying to boot';


llzhao wrote:

I have tired "time_out=300s" security test case still failed on the same reason:
"echo >$pty" got "-bash:/dev/pts/5: permission denied"

FYI:
http://openqa.nue.suse.com/tests/4004166#
in lib/opensusebasetest.pm:
...

wait_serial('GNU GRUB', 180) || diag 'Could not find GRUB screen, continuing nevertheless, trying to boot';
wait_serial('GNU GRUB', 300) || diag 'Could not find GRUB screen, continuing nevertheless, trying to boot';


FYI:
Sometimes we got error "ambiguous redirect" too as the "$pty" became NULL after reboot, it seems the vm is not rebooted successfully even waited more than 300s.

that is actually: https://bugzilla.suse.com/show_bug.cgi?id=1167210
but Yast team has a workaround with softfail implemented for AutoYaST tests, I will do the same for all the other tests

the last good one is not available anymore, I would like to compare with successful run at first.

As I can remember that kvm was not stable on Power8 and it never does reboot successfully. zkvm could be different and stable. Question: reboot needs to be handed over to libvirt and host, right?

mgriessmeier wrote:

that is actually: https://bugzilla.suse.com/show_bug.cgi?id=1167210
but Yast team has a workaround with softfail implemented for AutoYaST tests, I will do the same for all the other tests

Thanks Matthias/Zaoliang, so it can explain that we hit "echo >$pty" got "-bash:/dev/pts/5: permission denied" during the fips tests which run in openQA.

However, the issue is gone with the latest RC1 drop. https://openqa.nue.suse.com/tests/4022816#step/fips_setup/31
So seems the bug 1167210 is fixed?

Hello,
The issue is gone at build 162.1/163.1, but it can be reproduced again from 163.11 and 164.1 newer build ( Regression ). Base one the bsc#1167210 - [Build 160.1] System shuts down instead of reboot on zkvm, we think it could be a real product bug. In our test run in openQA, the reboot function block most of our s390x cases. Is there any workaround that can be applied for this point? Thanks a lot.

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

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

To prevent further reminder comments one of the following options should be followed:

1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
2. The openQA job group is moved to "Released"
3. The label in the openQA scenario is removed

The issue can be seen again with drop 176.1, after reboot a vm. I saw qemu crash

2020-04-13 01:43:59.146+0000: shutting down, reason=crashed
2020-04-13T01:43:59.147443Z qemu-system-s390x: terminating on signal 15 from pid 1712 (/usr/sbin/libvirtd)

Most of fips cases are failed due to this:
https://openqa.nue.suse.com/tests/overview?distri=sle&version=15-SP2&build=176.1&groupid=268

Thanks much Liang for providing the setup. it helped much.

The issue can not be seen on s390zp12 with different(newer) OS/qemu/libvirt version.

s390zp12:~ # uname -r
5.3.18-10-default
s390zp12:~ # cat /etc/*release
NAME="SLES"
VERSION="15-SP2"
VERSION_ID="15.2"
PRETTY_NAME="SUSE Linux Enterprise Server 15 SP2"
ID="sles"
ID_LIKE="suse"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:15:sp2"
s390zp12:~ # virsh version
Compiled against library: libvirt 6.0.0
Using library: libvirt 6.0.0
Using API: QEMU 6.0.0
Running hypervisor: QEMU 4.2.0

After the os installation, vm can boot up successfully. and no issue seen if I reboot it again.

That means 2 issues mentioned in the bug is not seen on this hypervisor.

BR//Richard.