Project

General

Profile

Actions

action #35709

closed

[functional][y][hard] Improve auto-investigation in case the yast installer gets stuck

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

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Enhancement to existing tests
Target version:
SUSE QA (private) - Milestone 17
Start date:
2018-04-30
Due date:
2018-07-03
% Done:

0%

Estimated time:
8.00 h
Difficulty:
hard

Description

Observation

openQA test in scenario sle-15-Installer-DVD-x86_64-proxyscc_upgrade_sles12sp3+ha+geo+sdk+we@64bit fails in
installation_overview getting stuck and we do not know what exactly is going on. As apparently this was not reproduced manually so far the according product bug bsc#1082148 was closed as RESOLVED WONTFIX.

Acceptance criteria

  • AC1: We have a more generic post_fail_hook approach for the installer at least identifying where processes are stuck if any

Suggestion

locilka made nice suggestions in the aforementioned bug: "So I also propose to enhance that functionality to try to dig deeper, such as strace (you might need to detach it too) on the command that got stuck. Yes, getting a clue which one it is might be tough though. Maybe pstree helps. Maybe something more hipster-like, I don't know.". So I suggest the following:

  • Read the full comment stream in bsc#1082148 to get the complete picture
  • Take a look what we do with gdb in lib/y2snapper_common.pm when snapper gets stuck
  • Research if the interweb has any better suggestions of what to do when "unknown process gets stuck in linux"
  • Incorporate something into the yast installer post_fail_hook
  • If possible extend the generic failure_investigation approach used in other test modules as well

Further details

Always latest result in this scenario: latest


Related issues 1 (0 open1 closed)

Precedes openQA Tests (public) - action #37126: [functional][y] collect strace output for the installer to debug sporadic issuesRejectedokurz2018-07-04

Actions
Actions

Also available in: Atom PDF