Project

General

Profile

action #115622

Install kdumptool where needed and fix synchronization failure in yast kdump module

Added by geor 3 months ago. Updated 21 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
Start date:
2022-08-22
Due date:
% Done:

100%

Estimated time:

Description

Motivation

Kdump is not a dependency of yast2-kdump module in SLE15-SP5 and is no longer installed when yast2-kdump is installed.
This behavior is intended as can be seen in bsc#1202535 and is a feature, not a bug.
However this may be the cause of failures on our yast2_kdump testsuite, which need to be investigated (they are differ by architecture).

  • aarch64 and x86_64: both fail because kdumptool is not available, which makes sense since kdump has not been installed. Even when installing kdump however, the testsuites fail because no crashkernel arguments have been added in grub config.
  • ppc64le : test does not catch the expected restart popup
  • s390x : code execution finished too early

Scope

https://openqa.suse.de/tests/overview?arch=&flavor=&machine=&test=&modules=yast2_kdump&module_re=&distri=sle&version=15-SP5&build=15.2&groupid=129#
ppc64le-spvm is hit by a libyui bug (bsc#1202575) but the rest architectures failures are within scope.

Acceptance criteria

AC1: Setup properly the kdump installing only for SLE-15-SP5 necessary tools and fix sync issues with reboot screen.
AC2: File found bugs if any.

Suggestions

When fixing sync issues, please take a look to Kernel squad where this module is used for real, doing a real kdump, not just configuring it.
Perhaps we need to install development module, this test suite is still linked to Functional job group to an interactive installation, we should aim to have a textmode installation with development module included in the future.

History

#1 Updated by JERiveraMoya 3 months ago

  • Subject changed from Investigate yast2_kdump failures after change in behavior of the YaST kdump module to Install kdumptool where needed and fix synchronization failure in yast kdump module
  • Description updated (diff)

#2 Updated by JERiveraMoya 3 months ago

Check with Petr Cervinka from QE Kernel in case of doubt about kdump.

#3 Updated by JERiveraMoya 3 months ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable

#4 Updated by leli 3 months ago

  • Status changed from Workable to In Progress
  • Assignee set to leli

#5 Updated by leli 3 months ago

Create a branch to install kdump before yast2_kdump test, wait http://openqa.nue.suse.com/tests/9455788#live to verify.

#7 Updated by JERiveraMoya 3 months ago

could you please provide PR/MR?
Instead of polluting result in the job group using branch, we should use for example: openqa-clone-custom-git-refspec otherwise when checking history of failure of a job we cannot distinguish development from real failures to get conclusions. VRs just need to be pasted in PRs/MRs, no need here, except if you want to do it after merged (optionally)

#8 Updated by leli 3 months ago

JERiveraMoya wrote:

could you please provide PR/MR?
Instead of polluting result in the job group using branch, we should use for example: openqa-clone-custom-git-refspec otherwise when checking history of failure of a job we cannot distinguish development from real failures to get conclusions. VRs just need to be pasted in PRs/MRs, no need here, except if you want to do it after merged (optionally)

Here my VRs is just for debug of branch not for PR/MR, the jobs with CASEDIR is one way to run case with branch. I don't know the difference from CASEDIR and openqa-clone-custom-git-refspec, if you think openqa-clone-custom-git-refspec is better I will use it instead(no proper env for openqa-clone-custom-git-refspec so recently I just use CASEDIR to run job with branch).

#9 Updated by leli 3 months ago

The failure on s390x seems need more time to wait, http://openqa.nue.suse.com/tests/9456587#step/yast2_kdump/21
Add timeout value, wait http://openqa.nue.suse.com/tests/9462108#live

#10 Updated by leli 3 months ago

leli wrote:

The failure on s390x seems need more time to wait, http://openqa.nue.suse.com/tests/9456587#step/yast2_kdump/21
Add timeout value, wait http://openqa.nue.suse.com/tests/9462108#live

Add some debug info in branch to see whether it failed for the variable of expect_restart_info != 1 which caused it won't send alt-o to close the warning of reboot needed to apply the config. Wait http://openqa.nue.suse.com/tests/9467877

#11 Updated by leli 3 months ago

It is ok if we deal with the warning msg for reboot, https://openqa.nue.suse.com/tests/9468136#step/yast2_kdump/19

#15 Updated by leli 3 months ago

Filed a bug for the reboot message popup, https://bugzilla.suse.com/show_bug.cgi?id=1203237 to confirm this is a feature or bug.

#17 Updated by leli 2 months ago

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

PR merged.

#18 Updated by openqa_review 24 days ago

  • Status changed from Resolved to Feedback

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

This bug is still referenced in a failing openQA test: yast2_ncurses_textmode
https://openqa.suse.de/tests/9861307#step/yast2_kdump/1

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" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

#19 Updated by leli 21 days ago

  • Status changed from Feedback to Resolved

openqa_review wrote:

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

This bug is still referenced in a failing openQA test: yast2_ncurses_textmode
https://openqa.suse.de/tests/9861307#step/yast2_kdump/1

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" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

It failed for the clone with a branch of https://github.com/coolgw/os-autoinst-distri-opensuse#hmc, no issue for the fix of the ticket.

Also available in: Atom PDF