Project

General

Profile

Actions

action #72184

open

[virtualization][y] Select_console fails sporadically for svirt-xen-hvm

Added by syrianidou_sofia about 4 years ago. Updated 9 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

There is a sporadic failure of approximately 17%, for prepare_data module for yast2_gui test suite. The SUT seems to be freezing with black screen, when select_console is called.

It is notable that by simplifying the module to:

sub run {
    select_console 'root-console';
}
1;

it still displays the same percentage of failure.

The issue is not present in case of using xterm and chvt 6.

sub run {
    x11_start_program('xterm');
    wait_still_screen(5);
    become_root;
    assert_script_run "chvt 6";
    assert_screen "tty6-selected";
}
1;

Unfortunately, the logs are not helpful. When successfully switching to tty6, the autoinst logs contain:
[2020-09-30T17:28:05.896 CEST] [debug] <<< testapi::select_console(testapi_console="root-console")
....
[ 82.601276] systemd[1]: Started Getty on tty6.

Looking at the logs from failed runs, the above phrase is missing.

openQA test in scenario sle-15-SP3-Online-x86_64-yast2_gui@svirt-xen-hvm fails in
prepare_test_data

Expected result

48.1

Further details

Always latest result in this scenario: latest

Actions #1

Updated by okurz about 4 years ago

  • Subject changed from [tools] Select_console fails sporadically for svirt-xen-hvm to [qam] Select_console fails sporadically for svirt-xen-hvm
  • Target version set to future

Hi syrianidou_sofia , I saw you added the "[tools]" keyword in the ticket. We within the SUSE QA Tools team struggle a bit to review tickets with this keyword as we primarily look into the project progress.opensuse.org/projects/openqav3/ . Please be aware that a special backend "svirt-xen-hvm" is out of scope for the tools team, see https://progress.opensuse.org/projects/qa/wiki#Out-of-scope . So setting "[qam]" keyword instead and asking you to take a look into this together with help of others that have experience with svirt-xen-hvm, e.g. the virtualization team. Sorry about this. However if you find out a bit more specifically that something is wrong within the backend, e.g. os-autoinst, then we might be able to help you further.

Actions #2

Updated by syrianidou_sofia about 4 years ago

Ok, no problem. Thanks.

Actions #3

Updated by tjyrinki_suse about 4 years ago

  • Subject changed from [qam] Select_console fails sporadically for svirt-xen-hvm to [virtualization][qam] Select_console fails sporadically for svirt-xen-hvm
  • Start date deleted (2020-10-01)

Adding [virtualization], and changing [qam] to [y] since this seems to be about SP3 (not releases in maintenance) and Yast, plus virtualization related.

Actions #4

Updated by tjyrinki_suse about 4 years ago

  • Subject changed from [virtualization][qam] Select_console fails sporadically for svirt-xen-hvm to [virtualization][y] Select_console fails sporadically for svirt-xen-hvm
Actions #5

Updated by okurz about 4 years ago

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

This bug is still referenced in a failing openQA test: yast2_gui@svirt-xen-hvm
https://openqa.suse.de/tests/5212770

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"
  3. The label in the openQA scenario is removed
Actions #6

Updated by xlai over 3 years ago

Virtualization group does not have any job running on svirt-xen-hvm, and we do not maintain code for this either.

Actions #7

Updated by livdywan over 2 years ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #8

Updated by slo-gin 9 months ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions

Also available in: Atom PDF