action #15418
closedkeypress potentially didn't reach SUT
0%
Description
Observation¶
openQA test in scenario sle-12-SP3-Server-DVD-x86_64-migration_offline_sle12sp2-sdk+allpatterns@64bit fails in
nautilus
nautilus window didn't get "alt+f4" keypress or qemu didn't bypass it to a SUT . Need investigate is it a product or infra issue
Reproducible¶
Fails since (at least) Build 0187 (current job)
Expected result¶
Last good: 0186 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by asmorodskyi about 8 years ago
- Project changed from openQA Tests (public) to openQA Project (public)
- Subject changed from test fails in nautilus to keypress potentially didn't reach SUT
- Category changed from Infrastructure to 132
Updated by asmorodskyi about 8 years ago
- Priority changed from Normal to High
Updated by asmorodskyi about 8 years ago
- Related to action #15164: ipmi: looks like 'alt-s' did not stop countdown in install_and_reboot added
Updated by asmorodskyi about 8 years ago
didn't work on this one till now. Will try to investigate it today
Updated by michalnowak about 8 years ago
- Related to action #15718: System not getting 'ctrl-alt-delete' on svirt backend added
Updated by michalnowak about 8 years ago
In POO#15718 I can see fairly regularly that 7 send_key 'ctrl-alt-del' won't reach the SUT under svirt backend. I even saw (a similar) issue in virtual console, sleep 19 helped to workaround it back then.
Updated by asmorodskyi about 8 years ago
- Related to action #15892: [aarch64] Terminal does not show up on select_console call added
Updated by asmorodskyi about 8 years ago
- Related to deleted (action #15892: [aarch64] Terminal does not show up on select_console call)
Updated by asmorodskyi about 8 years ago
- Related to action #15892: [aarch64] Terminal does not show up on select_console call added
Updated by asmorodskyi about 8 years ago
- Status changed from In Progress to New
- Assignee deleted (
asmorodskyi)
stop working on this issue , fail to find clear scenario how to reproduce it
Updated by coolo about 8 years ago
- Priority changed from High to Normal
obviously not high prio then
Updated by okurz about 8 years ago
- Status changed from New to Rejected
- Assignee set to okurz
- Priority changed from Normal to Low
Looking at the most recent jobs in the same scenario
https://openqa.suse.de/tests/717596?limit_previous=400#previous
I can find 22 jobs, 19 after the "first failing" which all passed this step (12) or failed even earlier (7). asmorodskyi confirmed that he has seen it like three times in the same review so probably other scenarios which we do not want to dig for. Considering the statistics I will reject that ticket and when it pops up again and we find a way to reproduce we can open it up again or reopen another one.