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

https://openqa.suse.de/tests/601605
https://openqa.suse.de/tests/601606

I cloned a job with openqa_clone_job_osd 607999 TIMEOUT_SCALE=10 => t#608602

okurz wrote:

I cloned a job with openqa_clone_job_osd 607999 TIMEOUT_SCALE=10 => t#608602

hmm... looks like reboot hang there over 30mins after fully patched.
need more investigation...

I guess that is the same problem then as for the other "reboot" steps:
https://progress.opensuse.org/issues/14068
"Gather more system information and logs in case of boot/reboot times out"
There should be error handling to press "esc" or something in the plymouth
screen.

tested on ppc64le:

install sles12 sp1 and add repo of sles12 sp2 rc3.
run zypper up and reboot. It reboot without problem. But I checked this system by cat /etc/issue. I still got:

Welcome to SUSE Linux Enterprise Server 12 SP1 (ppc64le) - Kernel \r (\l).
1a108:~ # cat /etc/YaST2/build
SLE-12-SP1-Server-DVD-ppc64le-Build3247

It seems that we have a problem with the update...

the new kernel has been installed however correctly...

1a108:~ # uname -a
Linux 1a108 4.4.21-64-default #1 SMP Mon Sep 19 14:30:51 UTC 2016 (0a5f717) ppc64le ppc64le ppc64le GNU/Linux

zluo wrote:

tested on ppc64le:

install sles12 sp1 and add repo of sles12 sp2 rc3.
run zypper up and reboot. It reboot without problem. But I checked this system by cat /etc/issue. I still got:

Welcome to SUSE Linux Enterprise Server 12 SP1 (ppc64le) - Kernel \r (\l).

After migration to sle12sp2 via scc/smt and then cat /etc/issue, the content should be updated to SP2 as well.
How did you perform migration?

1a108:~ # cat /etc/YaST2/build
SLE-12-SP1-Server-DVD-ppc64le-Build3247

This could not be changed and should remain source system build info after migration

It seems that we have a problem with the update...

After investigation, I think the issue may caused by the settings of /etc/sysconfig/displaymanager on source hdd images.

3 tests which were always failed:
om_proxyscc_sles12_allpatterns_full_update_by_yast_ppc
om_proxyscc_sles12_sdk_full_update_by_yast_ppc
om_proxyscc_sles12_sdk+allpatterns_full_update_by_zypper_ppc

all of them have following settings in /etc/sysconfig/displaymanager and remain same before and after fully patched:
DISPLAYMANAGER_REMOTE_ACCESS="yes"
DISPLAYMANAGER_STARTS_XSERVER="no"

with above settings displaymanager would not start local xserver.
just don't understand why it not affect source sles12 system before fully patch( is ok to boot system to desktop at the beginning), but do impact on the system after fully patched.

to compare 1 test were always passed:
om_proxyscc_sles12_full_update_by_zypper_ppc

its settings in /etc/sysconfig/displaymanager on source hdd image is inverse with above:
DISPLAYMANAGER_REMOTE_ACCESS="no"
DISPLAYMANAGER_STARTS_XSERVER="yes"

Solution:
Re-generate source hdd images for the 3 failed cases to see if the setting is correct, then that would work for rebooting after fully patched.

om_proxyscc_sles12_allpatterns_full_update_by_yast_ppc change to use existing image sle-12-Server-DVD-ppc64le-allpatterns.qcow2 instead of old one SLES-12-GM-allpatterns-ppc64le_new.qcow2, let's see result in next build.

And still need to re-create 2 images with sdk which are:

sle-12-Server-DVD-ppc64le-sdk.qcow2
sle-12-Server-DVD-ppc64le-sdk+allpatterns.qcow2