Project

General

Profile

Actions

action #14086

closed

[Build 2160] test zypper_patch fails to reboot on ppc64le

Added by okurz over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
Category:
Bugs in existing tests
Target version:
-
Start date:
2016-10-06
Due date:
% Done:

100%

Estimated time:
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP2-Server-DVD-ppc64le-om_proxyscc_sles12_allpatterns_full_update_by_yast_ppc@ppc64le fails in
http://openqa.suse.de/tests/601594#step/zypper_patch/13
not exiting the splash screen.

Reproducible

Fails since (at least) Build 2148

Expected result

We never tested reboot after calling zypper patch on ppc64le which we introduced with https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1877

This should be further investigated what went wrong, e.g. retrigger test and login to vnc manually, press esc during bootup, etc.

Further details

Always latest result in this scenario: latest


Related issues 1 (0 open1 closed)

Related to openQA Tests - action #14068: [tools] Gather more system information and logs in case of boot/reboot times outResolvedokurz2016-09-23

Actions
Actions #2

Updated by okurz over 7 years ago

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

Actions #3

Updated by mitiao over 7 years ago

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...

Actions #4

Updated by okurz@suse.de over 7 years ago

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.

Actions #5

Updated by okurz over 7 years ago

  • Related to action #14068: [tools] Gather more system information and logs in case of boot/reboot times out added
Actions #6

Updated by zluo over 7 years ago

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...

Actions #7

Updated by zluo over 7 years ago

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

Actions #8

Updated by mitiao over 7 years ago

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...

Actions #9

Updated by mitiao over 7 years ago

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.

Actions #10

Updated by mitiao over 7 years ago

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

Actions #11

Updated by mitiao over 7 years ago

  • Status changed from New to In Progress
  • Assignee set to mitiao
Actions #12

Updated by mitiao over 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

2 new images with correct settings created:

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

and all tests were passed with GREEN:
om_proxyscc_sles12_allpatterns_full_update_by_yast_ppc
https://openqa.suse.de/tests/620623

om_proxyscc_sles12_sdk_full_update_by_yast_ppc
https://openqa.suse.de/tests/621461

om_proxyscc_sles12_sdk+allpatterns_full_update_by_zypper_ppc
https://openqa.suse.de/tests/621529

Actions

Also available in: Atom PDF