action #13216: [sles][functional][s390x] Run extratest on s390x
[sles][functional][s390x] Test fails in vnc_two_passwords
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)
openQA test in scenario sle-12-SP3-Server-DVD-s390x-extra_tests_on_gnome_s390x@zkvm fails in
Fails since (at least) Build 0257 (current job)
Last good: (unknown) (or more recent)
Always latest result in this scenario: latest
#5 Updated by okurz over 4 years ago
- 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.
#6 Updated by mkravec over 4 years ago
- Priority changed from High to Low
okurz: - .. really? ..
Second look: DISPLAY:1 is busy on s390 - https://openqa.suse.de/tests/964105#step/vnc_two_passwords/22
#8 Updated by mkravec over 4 years ago
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.
#9 Updated by okurz over 4 years ago
- 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.