action #101030
closedTyping problems on aarch64
Description
Observation¶
I guess since this week there started to be failures on aarch64 due to mistyped commands.
https://openqa.suse.de/tests/7421722#step/textinfo/15
https://openqa.suse.de/tests/7412494#step/zypper_lifecycle/32
https://openqa.suse.de/tests/7411270#step/zypper_in/9
https://openqa.suse.de/tests/7410463#step/force_scheduled_tasks/18
https://openqa.suse.de/tests/7409878#step/textinfo/10
openQA test in scenario sle-15-Server-DVD-Updates-aarch64-qam-minimal+base@aarch64-virtio fails in
textinfo
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qa-maintenance/qam-openqa-yml.
Reproducible¶
Fails since (at least) Build 20211015-1 (current job)
Expected result¶
Last good: 20211014-1 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by dzedro about 3 years ago
- Project changed from openQA Tests (public) to openQA Project (public)
- Category deleted (
Bugs in existing tests)
Updated by dzedro about 3 years ago
- Subject changed from Typing problems problems on aarch64 to Typing problems on aarch64
Updated by okurz about 3 years ago
- Related to coordination #101048: [epic] Investigate and fix higher instability of openqaworker-arm-4/5 vs. arm-1/2/3 added
Updated by okurz about 3 years ago
- Category set to Regressions/Crashes
- Priority changed from Normal to Urgent
- Target version set to Ready
Might be related to #101048
Updated by livdywan about 3 years ago
Checking https://openqa.suse.de/tests/7421722#step/textinfo/15 I see this:
# Test died: command 'rm textinfo' failed at /usr/lib/os-autoinst/testapi.pm line 950.
testapi::_handle_script_run_ret(1, "rm textinfo", "quiet", undef, "timeout", 90, "fail_message", "") called at /usr/lib/os-autoinst/testapi.pm line 988
So it seems the timeout of 90 seconds was exceeded i.e. assert_script_run('rm textinfo');
. The same applies to https://openqa.suse.de/tests/7411270#step/zypper_in/9 (testapi::assert_script_run("rpm -e x3270")
).
https://openqa.suse.de/tests/7410463#step/force_scheduled_tasks/18 apparently stops here:
force_scheduled_tasks::settle_load() called at sle/tests/console/force_scheduled_tasks.pm line 67
The last screenshot shows -bash: /deev/ttyAMA0: No such file or directory
. It looks like there's an e
too many.
Updated by dzedro about 3 years ago
cdywan wrote:
Checking https://openqa.suse.de/tests/7421722#step/textinfo/15 I see this:
# Test died: command 'rm textinfo' failed at /usr/lib/os-autoinst/testapi.pm line 950. testapi::_handle_script_run_ret(1, "rm textinfo", "quiet", undef, "timeout", 90, "fail_message", "") called at /usr/lib/os-autoinst/testapi.pm line 988
So it seems the timeout of 90 seconds was exceeded i.e.
assert_script_run('rm textinfo');
. The same applies to https://openqa.suse.de/tests/7411270#step/zypper_in/9 (testapi::assert_script_run("rpm -e x3270")
).
Of course timeout exceeded when command was not typed properly -> mistyped.
Yes, looks like failures are happening on openqaworker-arm-4/5
Updated by livdywan about 3 years ago
dzedro wrote:
cdywan wrote:
Checking https://openqa.suse.de/tests/7421722#step/textinfo/15 I see this:
# Test died: command 'rm textinfo' failed at /usr/lib/os-autoinst/testapi.pm line 950. testapi::_handle_script_run_ret(1, "rm textinfo", "quiet", undef, "timeout", 90, "fail_message", "") called at /usr/lib/os-autoinst/testapi.pm line 988
So it seems the timeout of 90 seconds was exceeded i.e.
assert_script_run('rm textinfo');
. The same applies to https://openqa.suse.de/tests/7411270#step/zypper_in/9 (testapi::assert_script_run("rpm -e x3270")
).Of course timeout exceeded when command was not typed properly -> mistyped.
Yes, looks like failures are happening onopenqaworker-arm-4/5
Right, it says rrpm
and textinffo
respectively in the needles. It seems a bit odd to me, though, that it times out rather than an error from the zypper or bash. So I guess it times out before the command is finished.
Updated by nicksinger about 3 years ago
I'd rather try to solve poo#101048 to see if it eases the situation here too
Updated by okurz about 3 years ago
- Status changed from New to Blocked
- Assignee set to okurz
Updated by okurz about 3 years ago
- Status changed from Blocked to Resolved
We have identified the situation as caused by instabilities on openqaworker-arm-4/5 and have disabled the machine since then from production. Work to investigate the root cause and bring back the machine is done in #101048