Project

General

Profile

action #66292

[functional][y] Investigate yast_keyboard test fail on aarch64, ppc64le

Added by oorlov 4 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA tests - SLE 15 SP2
Start date:
2020-04-30
Due date:
2020-06-02
% Done:

0%

Estimated time:
3.00 h
Difficulty:
Duration: 24

Description

Observation

openQA test in scenario sle-15-SP2-Online-aarch64-yast2_cmd@aarch64 fails in
yast_keyboard

The test started failing after https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10102 is introduced.
The PR removed timeout workaround for Sle15-SP2, but it seems like another problem exists on aarch64.

So we have 2 hypothesis, either changes do not get applied immediately or bug is still valid.
Therefore, we should either stabilize test execution or reopen the bug.

The fail in y2logs seems to be due Couldn't open /dev/ttyS0.

2020-04-30 03:51:34 <1> susetest(6287) [Ruby] lib/cheetah.rb:160 Executing "loadkeys -C /dev/ttyS3 -C /dev/ttyS2 -C /dev/ttyS1 -C /dev/ttyS0 us".
2020-04-30 03:51:34 <3> susetest(6287) [Ruby] lib/cheetah.rb:208 Error output: Couldn't open /dev/ttyS0
2020-04-30 03:51:34 <3> susetest(6287) [Ruby] lib/cheetah.rb:180 Status: 1
2020-04-30 03:51:34 <1> susetest(6287) [Ruby] strategies/kb_strategy.rb:63 Execution of "loadkeys -C /dev/ttyS3 -C /dev/ttyS2 -C /dev/ttyS1 -C /dev/ttyS0 us" failed with status 1: Couldn't open /dev/ttyS0.
2020-04-30 03:51:34 <1> susetest(6287) [Ruby] strategies/kb_strategy.rb:64 Error output:    Couldn't open /dev/ttyS0

Task

  1. Try to identify if it is a product issue;
  2. Raise an appropriate ticket;
  3. Implement workaround if it is applicable (e.g. it seems like the issue should not happen if the timeout will be reverted to the value before the PR was introduced.

Test suite description

QAM team has developed some tests using YaST cmd line, which is less costly to execute and maintain. This test suite is using those test modules for QA SLE functional.

Reproducible

Fails since (at least) Build 183.5

Expected result

Last good: 181.4 (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by riafarov 3 months ago

  • Priority changed from Normal to High

#2 Updated by riafarov 3 months ago

  • Subject changed from [functional][yast] Investigate yast_keyboard test fail on aarch64 to [functional][y] Investigate yast_keyboard test fail on aarch64
  • Due date changed from 2020-05-19 to 2020-06-02

#3 Updated by riafarov 3 months ago

I have missed that because we had no [y] tag, but [yast], so it wasn't shown in the sprint.

#4 Updated by riafarov 3 months ago

  • Target version set to SLE 15 SP2

#5 Updated by riafarov 3 months ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Estimated time set to 3.00 h

#6 Updated by ybonatakis 3 months ago

  • Assignee set to ybonatakis

#7 Updated by ybonatakis 3 months ago

  • Status changed from Workable to In Progress

#9 Updated by ybonatakis 3 months ago

  • Status changed from In Progress to Feedback

#10 Updated by ybonatakis 3 months ago

  • Status changed from Feedback to In Progress

the lastest patch didnt work. open it again

#11 Updated by ybonatakis 3 months ago

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10366 as the previous solution did not work exactly as expected

#12 Updated by ybonatakis 3 months ago

I will keep the ticket open for further investigation

#13 Updated by oorlov 3 months ago

  • Subject changed from [functional][y] Investigate yast_keyboard test fail on aarch64 to [functional][y] Investigate yast_keyboard test fail on aarch64, ppc64le

The issue is also occurred on ppc64le: https://openqa.suse.de/tests/4280384.

So, this is not only related to aarch64.

#14 Updated by favogt 3 months ago

AFAICT this is a race in the yast_keyboard test module.

The preceding yast keyboard set didn't finish before type_string + wait_still_screen completed, so it consumes the "Ctrl-D".
This means that the "cat -" waits for input indefinitely and the script is never executed.

This is visible in the screenshot and also the video: https://openqa.suse.de/tests/4288060#step/yast_keyboard/17

#15 Updated by ybonatakis 3 months ago

favogt wrote:

AFAICT this is a race in the yast_keyboard test module.

The preceding yast keyboard set didn't finish before type_string + wait_still_screen completed, so it consumes the "Ctrl-D".
This means that the "cat -" waits for input indefinitely and the script is never executed.

This is visible in the screenshot and also the video: https://openqa.suse.de/tests/4288060#step/yast_keyboard/17

This seems to explain why when the module runs successful it does not show the error.
Thus, i have remove the workaround and i also replaced the type_string with assert_script_run. I am waiting the VRs against aarch64 and s390x finish and i am creating PR.
favogt thanks a lot for the help.

#16 Updated by ybonatakis 3 months ago

In additional i filed a bug ticket[0] to address another finding. in aarch64(ttyAMA* is the default unless you define otherwise) and in s390x(hvc) different devices are used other than tty and ttyS. But investigating the code the language is not set for those devices.

[0] https://bugzilla.suse.com/show_bug.cgi?id=1172180

#17 Updated by ybonatakis 3 months ago

just to add that the bug that the https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10102 addressed never appeared to me. the issue from that bug has been resolved.

#18 Updated by ybonatakis 3 months ago

https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10397
At the end type_string is used. there are other issues with the assert_script_run as the language has shifted to german, which makes the test fail as it impacts the keymap which in turn affects the return code and the serial device as output.

#19 Updated by ybonatakis 3 months ago

  • Status changed from In Progress to Feedback

So i tried to reproduce the bug in sle12-sp5 with SLES-12-SP5-x86-64-20200529-1@64bit. the kdb runs in it.

susetest:~ # kbd_mode
The keyboard is in Unicode (UTF-8) mode

In this case the restart is happening when you set language but no error appears in the logs.
as that, bsc#1170292 was only for sle15 and it did not affect sle12 where the kbd is expecting to run.

#20 Updated by riafarov 2 months ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF