QA » openQA Project » openQA Tests

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

This bug is still referenced in a failing openQA test: extra_tests_on_gnome
https://openqa.suse.de/tests/1683271

I can reproduce this issue on my local machine. So try to increase timeout for booting

send_key_until_needlematch("boot-menu-snapshot", 'down', 10, 30);

with '30' it looks much better and solve this timeout issue:

http://e13.suse.de/tests/6015#step/user_defined_snapshot

it seems on loewe remote worker it fails sporadic, increase more timeout to 60

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5311

http://e13.suse.de/tests/latest?distri=sle&machine=64bit&flavor=Server-DVD&test=extra_tests_on_gnome&version=12-SP4&arch=x86_64#next_previous

5 failed from 50 test runs, failure is still too high. Any suggestions?
I need to re-work on this issue anyway.

I think you are looking at this the wrong way. Your pull request tries to handle key presses within the grub menu but the test failures I could find from the link you provided are showing a different problem: http://e13.suse.de/tests/6574#step/user_defined_snapshot/17 as well as http://e13.suse.de/tests/6571#step/user_defined_snapshot/17 show the system never shut down before the reboot. So it is not about any timeout after grub has been reached but before. Please see my comment in #35011#note-10 where I already suggested to investigate the shutdown, not any problem in the boot menu.

@okurz yes, you're right. This is about shutdown, thanks.

http://e13.suse.de/tests/6661#step/user_defined_snapshot/18

shows still sporadic issue with shutdown after I increased timeout at shutdown_timeout = 120; in power_action in utils.pm

I think what you could try is to go really high with the timeout, e.g. 1200s. Could you do that?

@okurz okay, try with this.

http://e13.suse.de/tests/6791#next_previous

I have still same problem

I have one failure from 20 test runs:

http://e13.suse.de/tests/7372#step/user_defined_snapshot/19

This becomes sporadic issue now.

and no logs are available for this failure during shutdown/reboot.

# Create a new snapshot
$self->y2snapper_create_snapshot();
# Make sure the snapshot is listed in the main window
send_key_until_needlematch([qw(grub_comment)], 'pgdn');
# C'l'ose  the snapper module
send_key "alt-l";
power_action('reboot', keepconsole => 1, textmode => 1);

I think we need here post_fail_hook for selecting logs during shutdown. So we can be sure about the reason except known issue reported in bsc#980337.

working on this again after I talked with okurz:

opensusebasetest.pm

try to check following:

sub post_fail_hook {
my ($self) = @_;
return if testapi::is_serial_terminal();    # in case it is VIRTIO_CONSOLE=1 nothing below make sense
# just output error if selected program doesn't exist instead of collecting all logs
# set current variables in x11_start_program
if (get_var('IN_X11_START_PROGRAM')) {
my $program = get_var('IN_X11_START_PROGRAM');
select_console 'log-console';
my $r = script_run "which $program";
if ($r != 0) {
record_info("no $program", "Could not find '$program' on the system", result => 'fail') && die "$program does not exist on the system";
}
}
diag("in_wait_boot variable: $self->{in_wait_boot}");
return unless $self->{in_wait_boot};
if (wait_serial 'Reached target shutdown') {
record_info 'shutdown', 'At least we reached target shutdown';
}
if (wait_serial 'Requested transaction contradicts existing jobs: Transaction is destructive.') {
record_soft_failure 'bsc#980337';
}
# In case the system is stuck in shutting down or during boot up, press
# 'esc' just in case the plymouth splash screen is shown and we can not
# see any interesting console logs.
send_key 'esc';
save_screenshot;
}

http://e13.suse.de/tests/7443#step/user_defined_snapshot/20

shows that it goes into post_fail_hook for following changes (if we let assert_screen failed for test)

$self->{in_wait_boot} = 1;
assert_screen "grub2", 1;

What we now need, is a real scenarios where it takes too long time for shutdown/reboot. So following case should be true:

return unless $self->{in_wait_boot};
if (wait_serial 'Reached target shutdown') {
record_info 'shutdown', 'At least we reached target shutdown';
}
if (wait_serial 'Requested transaction contradicts existing jobs: Transaction is destructive.') {
record_soft_failure 'bsc#980337';
}

http://e13.suse.de/tests/7555#step/user_defined_snapshot/22

return unless $self->{in_wait_boot};
sleep 100; # waiting for reaching target shutdown
if (wait_serial qr/Reached target Shutdown/) {
record_info 'shutdown', 'At least we reached target Shutdown';
}

:)

PR:

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/5624

https://openqa.suse.de/tests/2029912#step/user_defined_snapshot/23 : At least we reached target Shutdown

This is exactly what we need and can in this case.
Actually we can only show this notification to reviewer for this sporadic issue, hte production issue is handled by another workaround however and will be showed at end of the end.

Again the same issue:
https://openqa.suse.de/tests/2187511#step/user_defined_snapshot/18