action #17420
closed
action #13216: [sles][functional][s390x] Run extratest on s390x
[sles][functional][s390x] Test fails in vnc_two_passwords
Added by mkravec about 7 years ago.
Updated almost 7 years ago.
Description
Vnc fails to connect, maybe "Xvnc :1 -SecurityTypes=VncAuth -PasswordFile=/tmp/file.passwd" failed to start properly
Test needs some changes to make it more robust (easier to debug)
Observation¶
openQA test in scenario sle-12-SP3-Server-DVD-s390x-extra_tests_on_gnome_s390x@zkvm fails in
vnc_two_passwords
Reproducible¶
Fails since (at least) Build 0257 (current job)
Expected result¶
Last good: (unknown) (or more recent)
Further details¶
Always latest result in this scenario: latest
- Assignee changed from mkravec to mgriessmeier
- Subject changed from Test fails in vnc_two_passwords to [sles][functional][s390x] Test fails in vnc_two_passwords
- Parent task set to #13216
- Assignee deleted (
mgriessmeier)
unassigning, since I did not follow this issue and didn't see it in productive system
- Status changed from New to Closed
I don't see this test scheduled on s390 anymore, link is not working, please reopen if you see this problem again.
- Description updated (diff)
- Status changed from Closed to In Progress
- Assignee set to mkravec
- Priority changed from Normal to High
With a tiny amount of effort I found the job again. Just the machine changed from "zkvm" to "zkvm-image". And the issue is not gone.
@mkravec A test that "disappeared" should make you wonder and not just accept it. I see it as critical if we silently drop certain test coverage without an explicit decision. This did not happen here, just the machine assignment was changed. The latest failing example for exactly the reason of vnc_two_passwords is seen in https://openqa.suse.de/tests/964105#step/vnc_two_passwords/21
On first sight this looks like a product issue: "No matching security types". Please take a second look.
- Priority changed from High to Low
Why do you consider the priority low now? If you don't want to continue the work on this just unassign. If you say we should just not schedule vnc_two_passwords because of low risk we may also do this. We should still conduct the other extra tests on s390x then.
It's low priority because:
- test is in development group
- it was never working on s390
- I created it for x86_64
- the person who schedules it on s390 should fix / remove the test
- if it's assigned to me I don't mind, but on my list it's low priority
Please correct me if I am wrong and there is FATE / ISSUE saying otherwise.
When I have time to do local runs I can fix it, if someone want's to do it sooner - feel free to take over.
From error message it should be enough to use other display.
- Category changed from Bugs in existing tests to New test
- Assignee changed from mkravec to okurz
- Priority changed from Low to High
IMHO not low prio because this is blocking the full enablement of extra tests on s390x which we should have in place for sle15 at least which will probably rely much more on pre-generated installations. But you are right that it never worked so I changing it to "New test" now. As mentioned and as discussed, maybe we can just change the display port number for the vnc server to fix it. I will try the first step myself. If I read the error message correctly what the test is doing is to connect to the hardcoded display number assuming it is the vnc server it started itself but in this case it will be the internal VNC server in the SUT we use to interface with the SUT.
-> https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/3342
- Status changed from In Progress to Resolved
Also available in: Atom
PDF