action #50297
closed[functional][y][investigation][timeboxed:6h] test fails in system_role, system doesn't get key pressed
0%
Description
Observation¶
Seems that issue is not sporadic, failed multiple times. In the logs we can see that alt-n is actually send to the SUT, but we don't get to the partitioning page.
We need to investigate and potentially apply workaround.
openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-allmodules+allpatterns@64bit fails in
system_role
Test suite description¶
Maintainer: jrauch
Perform an installation enabling all modules and selecting all patterns.
This test suite always registers to have access to all modules.
Reproducible¶
Fails since (at least) Build 212.1
Expected result¶
Last good: VR_iob (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by oorlov about 5 years ago
- Due date changed from 2019-05-07 to 2019-04-23
- Status changed from New to Workable
Updated by riafarov almost 5 years ago
- Due date changed from 2019-04-23 to 2019-05-07
Updated by ybonatakis almost 5 years ago
- Status changed from Workable to In Progress
- Assignee set to ybonatakis
Updated by riafarov almost 5 years ago
Similar issue with other page of the wizard: https://openqa.suse.de/tests/2823696
Updated by ybonatakis almost 5 years ago
- Status changed from In Progress to Resolved
I couldnt find the cause of it after multiple job executions. The cloned jobs passed successfully most of the times when i run against the local openqa, or they failed in different module than system_role. I am not sure that there is something to be done. The frame is blocked for a some time. Seems that sending the keys twice, the button is functional. I am going to resolve this ticket based on the above observations.
I cant say if this is a qemu issue related but my WS has qemu version 3.1.0-6.9 and OSD has version 2.9.1(SUSE Linux Enterprise 12) at the moment of the investigation.
feel free to reopen it in any case
Updated by JRivrain almost 5 years ago
- Status changed from Resolved to Feedback
This is still happening very frequently, a follow-up ticket should be created, or this one re-opened: probably a 6 hours investigation was not enough. I put this in feedback, since the investigation was done already. Then we can decide what to do next.
Updated by JERiveraMoya almost 5 years ago
According to @coolo:
3:42:23 PM - jrivera: hi! in case of this kind of warning raised by os-autoins " WARNING: check_asserted_screen took 0.87 seconds for 39 candidate needles - make your needles more specific" is any way to solve it without touching needles? it looks like is detecting too many candidates...
3:47:45 PM - coolo: jrivera: you need to tag the needles and exclude tags in the distribution - so no way without touching needles
3:51:36 PM - jrivera: it looks like this warning is avoid to send key alt-n: https://openqa.suse.de/tests/2854646#step/system_role/1 Could that be possible?
3:52:36 PM - jrivera: coolo: in particular this has: ENV-15ORLATER-1
3:54:01 PM - coolo: jrivera: the problem is that most of the candidates will not have 15ORLATER-0 so it's not discarded
3:54:09 PM - coolo: only sle12 will ignore the ORLATER
3:54:19 PM - coolo: but noone bothered to tag the sle12 needles to be ignored on 15
3:56:00 PM - jrivera: coolo: ENV-15ORLATER-0 means that the flag is false? I see, thanks, we will take a look
So according to that, tagging sle15 needles that should be ignored should help to avoid that "saturation".
Updated by JERiveraMoya almost 5 years ago
@JRivrain let's take a look together next working day, probably we need to ask some further questions and check carefully to not provoke any disaster with needles :) Feel free to change the assignee if we move forward with this idea.
Updated by JERiveraMoya almost 5 years ago
I did a cleanup of needles that were not matching in system_role module, removing the warning completely. I could not apply tag ENV-15ORLATER-0 due it applied to all candidate needles. Despite that the problem persists and alt-n does not take effect: https://openqa.suse.de/tests/2862785
Comparing previous successful result for allmodules+allpatterns test suite, I can see that we are including module phub now.
Updated by JERiveraMoya almost 5 years ago
- Assignee changed from ybonatakis to JERiveraMoya
Updated by JERiveraMoya almost 5 years ago
- Due date changed from 2019-05-07 to 2019-05-21
- Status changed from Feedback to Workable
- Assignee deleted (
JERiveraMoya)
Let's give opportunity to someone else to pick it.
Updated by riafarov almost 5 years ago
- Due date changed from 2019-05-21 to 2019-06-04
- Priority changed from Normal to High
We need to take a look before all the logs are vanished, as we might get same issue later on for SP2.
Updated by riafarov almost 5 years ago
- Status changed from Workable to Resolved
- Assignee set to riafarov
Same story as in #50399. As of now keep collecting occurrences, but not much we can do and issue is not that severe.