action #55697
closed[functional][u] test fails in boot_to_desktop - screen resolution is inconsistent, probably due to switch to "std" graphics adapter
0%
Description
Observation¶
the screen resolution is inconsistent
Sugguestions¶
- Try with another graphic driver
Tasks¶
- Investigate what can be done to fix the issue.
- Fix the issue.
Reproducible¶
- In scenario opensuse-15.2-DVD-x86_64-gnome+do_not_import_ssh_keys@64bit-2G
- Fails since first run: Build 479.2
- Current occurrence: 497.4
Expected result¶
Last good from extra_tests_on_gnome: 497.4
Further details¶
Always latest result in this scenario: latest
Updated by SLindoMansilla over 4 years ago
- Subject changed from test fails in boot_to_desktop - screen resolution is inconsistent to [functional][u][sporadic] test fails in boot_to_desktop - screen resolution is inconsistent
- Priority changed from Normal to High
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: gnome+do_not_import_ssh_keys@64bit-2G
https://openqa.opensuse.org/tests/1027837
Updated by SLindoMansilla over 4 years ago
- Subject changed from [functional][u][sporadic] test fails in boot_to_desktop - screen resolution is inconsistent to [functional][u] test fails in boot_to_desktop - screen resolution is inconsistent
- Description updated (diff)
- Status changed from New to Workable
- Target version set to Milestone 28
- Estimated time set to 42.00 h
Updated by okurz over 4 years ago
- Subject changed from [functional][u] test fails in boot_to_desktop - screen resolution is inconsistent to [functional][u] test fails in boot_to_desktop - screen resolution is inconsistent, probably due to switch to "std" graphics adapter
AFAICS the switch to "std" can cause this as we boot an older, pre-installed setup first. As a mitigation one can try to start with "cirrus" instead, same as for the zdup cases.
Updated by okurz over 4 years ago
- Related to action #53729: [functional][u] test fails in setup_zdup - after switch to "std" graphics adapter? added
Updated by dheidler over 4 years ago
- Status changed from Workable to In Progress
- Assignee set to dheidler
Updated by dheidler over 4 years ago
It is really related to the fact that the image was installed with cirrus and booted with std afterwards.
It works fine when the job is cloned wuth QEMUVGA=cirrus: https://openqa.opensuse.org/tests/1053416
Updated by dheidler over 4 years ago
- Status changed from In Progress to Feedback
Added a machine 64bit_cirrus-2G and updated the jobgroup to schedule this job on that machine.
Let's see what happens on the next build.
Updated by dheidler over 4 years ago
- Status changed from Feedback to Resolved
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: gnome+import_ssh_keys@64bit-2G
https://openqa.opensuse.org/tests/1070913
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: gnome+import_ssh_keys@64bit-2G
https://openqa.opensuse.org/tests/1083577
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 dheidler over 4 years ago
openSUSE Leap 15 YAML
@@ -104,7 +104,7 @@
- kde-sddm:
machine: 64bit-2G
- gnome+import_ssh_keys:
- machine: 64bit-2G
- machine: 64bit_cirrus-2G
- gnome+do_not_import_ssh_keys: machine: 64bit_cirrus-2G
- autoyast_gnome:
I hope this fixes it completely.