action #77161
closed
test fails in await_install but there are no text results with the error details to copy
Added by okurz over 3 years ago.
Updated about 3 years ago.
Target version:
SUSE QA - SLE 15 SP3
Description
Observation¶
Motivation: As as QA engineer, I want to have as much information as possible in case of test failure, even parts of the system do not work, e.g. networking.
We should address 2 things:
- We should improve cases where postfail hook might fail and skip further steps
- We already have mechanism to output logs content to serial in case network connection is broken
openQA test in scenario opensuse-Tumbleweed-DVD-s390x-textmode@s390x fails in
await_install
Test suite description¶
Maintainer: okurz
Installation in textmode and selecting the textmode "desktop" during installation.
Reproducible¶
Fails since (at least) Build 20191010
Expected result¶
If the test fails I would still expect that the "post_fail_hook" can gather logs, e.g. /var/log/YaST2/y2log and extract the error details
Further details¶
Always latest result in this scenario: latest
- Project changed from openQA Tests to qe-yam
- Subject changed from [qe-yast] test fails in await_install but there are no text results with the error details to copy to test fails in await_install but there are no text results with the error details to copy
- Category deleted (
Bugs in existing tests)
- Target version set to future
Test never worked, and there are no tools like coredumpctl, etc, so parent post fail hook fails and prevents YaST logs collection.
Shouldn't be coredumpctl integrated in a base package? What is required?
AdaLovelace wrote:
Shouldn't be coredumpctl integrated in a base package? What is required?
hm. I don't know if coredumpctl is included in the installation medium here.
Please be aware that the original job in https://openqa.opensuse.org/tests/1464522/modules/await_install/steps/69 stopped on an obvious product issue as even the screen says "Internal error. Please report a bug report with logs". I think this bug report is not yet reported at all. However, without access to logs this will not be very helpful for the YaST development team to help. So either logs are gathered manually with manual reproduction or using the openQA developer mode to try to gather logs manually while the test is running in openQA or the post_fail_hook of the openQA test is fixed or extended to provide that automatically.
@riafarov I am also not sure now as you changed the progress project layout a bit with the newly introduced subproject: I assume a ticket in "qe-yast" and in "Target version" "future" means that you see the issue as in the scope of the team "qe-yast" in general but do not have a current plan to work on this so likely this will not be fixed by "qe-yast" within the next months/years, similar to how we handle tickets in SUSE QE Tools, e.g. for openQA, correct? The "missed opportunity" I see here is that e.g. the team SUSE QE Core might be able to help with this, especially as slindomansilla is very motivated to work on "s390x@openSUSE" but if the ticket is within "qe-yast" he is unlikely to see it. If it would be something like "[qe-yast][qe-core]" in "openQA Tests" than theoretically it has better visibility. I don't know either what's best :)
Any better or other hints that you could offer AdaLovelace what to do?
@okurz Somehow I've missed your last comment. I've assigned this ticket to our team, as we can improve logs collection after failures. Problem here is that seems that network didn't really work (https://openqa.opensuse.org/tests/1464522#step/await_install/121). But we can still put more info to the serial, like last 100 lines of YaST logs, which we already do, but it didn't work here. It's low prio, as issue is not visible anymore and can be reported by reproducing issue manually, as without network it's hard to provide all the info for the investigation.
So for our team scope is to make logs collection more flexible and provide as much info as possible to spend less time on investigation.
- Description updated (diff)
- Status changed from New to Workable
- Status changed from Workable to In Progress
- Assignee set to riafarov
- Status changed from In Progress to Feedback
- Status changed from Feedback to Closed
- Target version changed from future to SLE 15 SP3
Also available in: Atom
PDF