action #55697
closed
[functional][u] test fails in boot_to_desktop - screen resolution is inconsistent, probably due to switch to "std" graphics adapter
Added by mlin7442 over 4 years ago.
Updated over 4 years ago.
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 28
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
- 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
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
- Description updated (diff)
- 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
- 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.
- Related to action #53729: [functional][u] test fails in setup_zdup - after switch to "std" graphics adapter? added
- Status changed from Workable to In Progress
- Assignee set to dheidler
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
- 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.
- Status changed from Feedback to Resolved
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
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
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.
Also available in: Atom
PDF