action #33199
closed[sle][functional][s390x][zkvm][u][hard] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
0%
Description
Updated by nicksinger almost 7 years ago
- Subject changed from [sle][functional][12sp4][s390x][zkvm]test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed? to [sle][functional][s390x][zkvm] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
Also happens in SLES15 now: https://openqa.suse.de/tests/1549296#step/kdump_and_crash/34
From what I saw the test is able to start yast2 kdump
but then fails to type after yast closes again. The test fail gets then triggered by power_action
but my suspicion is that the actual problems happens one step earlier in do_kdump
.
Updated by mgriessmeier almost 7 years ago
could be related to my recent changes in https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4585 :(
Updated by okurz almost 7 years ago
- Subject changed from [sle][functional][s390x][zkvm] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed? to [sle][functional][s390x][zkvm][u][fast] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
- Due date changed from 2018-04-10 to 2018-03-27
- Priority changed from Normal to High
ok, let's handle it in this sprint now because we assume most likely it's a recent test regression introduced by @mgriessmeier.
Updated by mgriessmeier almost 7 years ago
- Subject changed from [sle][functional][s390x][zkvm][u][fast] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed? to [sle][functional][s390x][zkvm][fast] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
as it could have been introduced recently, we should have a look already in this sprint
Updated by okurz almost 7 years ago
- Related to action #33616: [sle][functional][sle15][u][hard][xen] test fails in kdump_and_crash - because reboot doesn't work added
Updated by mgriessmeier over 6 years ago
- Due date changed from 2018-03-27 to 2018-04-10
Updated by riafarov over 6 years ago
- Related to action #33376: [sle][functional][ppc64le][easy][u] test fails in kdump_and_crash - kdumptool gets killed by OOM added
Updated by riafarov over 6 years ago
- Subject changed from [sle][functional][s390x][zkvm][fast] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed? to [sle][functional][s390x][zkvm][fast][u] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
- Status changed from New to Workable
Updated by okurz over 6 years ago
- Subject changed from [sle][functional][s390x][zkvm][fast][u] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed? to [sle][functional][s390x][zkvm][u][hard] test fails in kdump_and_crash - system does not shutdown or reboot? what is happening? better output needed?
Updated by okurz over 6 years ago
- Related to action #34003: [tools] Better logging and error handling in case of remote console connections in consoles or backends, e.g. ssh added
Updated by okurz over 6 years ago
- Related to action #33202: [sle][functional][s390x][zkvm][u][hard] test fails in boot_to_desktop - still insufficient error reporting, black screen with mouse cursor - we all hate it (was: I hate it) added
Updated by mgriessmeier over 6 years ago
- Status changed from Workable to In Progress
Updated by mgriessmeier over 6 years ago
afaics, the problem was introduced with my change regarding more robust reconnect -> PR
I've added the execution of assert_shutdown_and_restore_system
to S390-KVM:
- if (check_var('VIRSH_VMM_FAMILY', 'xen')) {
+ if (check_var('VIRSH_VMM_FAMILY', 'xen') || get_var('S390_ZKVM')) {
assert_shutdown_and_restore_system($action, $shutdown_timeout);
}
Here I've put in the logic of the former redefine_svirt_domain
, which is modifying the xml file
491 if (check_var('ARCH', 's390x') or get_var('NETBOOT')) {
492 $svirt->change_domain_element(os => initrd => undef);
493 $svirt->change_domain_element(os => kernel => undef);
494 $svirt->change_domain_element(os => cmdline => undef);
495 $svirt->change_domain_element(on_reboot => undef);
496 $svirt->define_and_start;
497 }
On initial definition in the xml files, the on_reboot flag is set to destroy, because we need to remodify the xml file - after this we set it to undef
Since we are booting an existing image in the toolchain testsuite, this parameter is by default set to reboot
.
The assert_shutdown
function which is called afterwards, tries to grep for shut off
of the machine, which obviously fails, because the machine was rebooting just normally.
So my guess is, that this issue will occur on all tests which are rebooting again during the testsuite execution. As we don't have that many, and those we have failed earlier, this wasn't (yet) spotted there.
I try to fix this issue by adding another logical statement to that call... or I find a better solution to handle those reboots
Updated by mgriessmeier over 6 years ago
- Status changed from In Progress to Feedback
- Assignee set to mgriessmeier
This PR fixes at least this particular issue
Updated by mgriessmeier over 6 years ago
- Status changed from Feedback to Resolved