action #57698
closed[QAM] test fails in gdb
0%
Description
Observation¶
openQA test in scenario sle-15-SP1-Server-DVD-Updates-s390x-mau-extratests@zkvm fails in
gdb
Test suite description¶
Run console tests against aggregated test repo
Reproducible¶
Fails since (at least) Build 20190911-1
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by apappas over 4 years ago
I don't think that this is a bug in the test, but a bug in openQA. The serial console is not working again, so the wait_serial
function is failing.
Updated by okurz over 4 years ago
@apappas I think it simply never worked. It's unfortunate that it seems there is so little care for failing tests hence this was never detected because on s390x there is no (easy) way to revert to snapshots so the job failed for very long in #56969 and never reached gdb. I do not know how this is supposed to ever work, to just start gdb and assume that string would show up on the serial port as it's never forwarded there.
Updated by okurz over 4 years ago
- Related to action #56969: [qam] test fails in java added
Updated by apappas over 4 years ago
I think it's best that I rewrite the test as a python script to be interpreted by gdb.
It will not then be interactive and I will be able to just use assert_script_run.
What do you think @okurz?
Updated by okurz over 4 years ago
Makes sense. As an alternative you might want to log all output of gdb to /dev/$serialdev which allows to still use wait_serial
. Both approaches sound easy to me.
Updated by coolo over 4 years ago
As it's Urgent now: if you can't get this done today, please take the test out of QAM (and keep the ticket open)
Updated by apappas over 4 years ago
- Subject changed from [QAM] test fails in gdb to test fails in gdb
- Assignee deleted (
apappas)
Updated by apappas over 4 years ago
- Subject changed from test fails in gdb to [QAM] test fails in gdb
- Assignee set to apappas
- Priority changed from Urgent to Normal
Updated by tjyrinki_suse over 4 years ago
Passing on x86_64, and s390x already disabled currently:
https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=20191010-2&groupid=232
vs where this was linked from https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=20190911-1&groupid=232
Updated by coolo over 4 years ago
Your link is misleading as it 10-2 wasn't tested for s390x (for whatever reason): https://openqa.suse.de/tests/overview?distri=sle&version=15-SP1&build=20191013-1&groupid=232 fails
I worked around it now by setting EXCLUDE_MODULES=gdb. So please fix and validate with care :)
Updated by okurz over 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: extra_tests_in_textmode
https://openqa.suse.de/tests/3575790
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 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: extra_tests_in_textmode
https://openqa.suse.de/tests/3575790
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by apappas over 4 years ago
- Status changed from New to Resolved
Fixed with this PR https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8709