action #54251
closed[functional][u][s390x] test fails in welcome: Installer can not start in Xvnc version which is installed on worker - broken connection
0%
Description
Observation¶
openQA test in scenario sle-12-SP5-Server-DVD-s390x-ssh-X@s390x-zVM-vswitch-l3 fails in
welcome
Test suite description¶
Maintainer: okurz, mgriessmeier
Conduct an installation using ssh with X-Forwarding. Might only be effective for s390x and spvm
Reproducible¶
Fails since (at least) Build 0211
Expected result¶
Last good: 0211 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by mgriessmeier over 5 years ago
- Subject changed from [functional][u][s390x] test fails in welcome, ssh installer seems to die - but not reproducible manually so assumed openQA issue to [functional][u][s390x] test fails in welcome, ssh installer seems to die - but not reproducible manually so assumed openQA issue
- Category changed from Bugs in existing tests to Infrastructure
- Status changed from New to In Progress
- Assignee changed from mgriessmeier to nicksinger
works with Xvnc Version 1.6.0 - X server release 11803000
does not work with
Xvnc TigerVNC 1.9.0 - built ??? ?? ???? ??:??:??
Copyright (C) 1999-2018 TigerVNC Team and many others (see README.rst)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 12003000, The X.Org Foundation
Updated by mgriessmeier over 5 years ago
- Subject changed from [functional][u][s390x] test fails in welcome, ssh installer seems to die - but not reproducible manually so assumed openQA issue to [functional][u][s390x] test fails in welcome: Installer can not start in Xvnc version which is installed on worker - broken connection
Updated by nicksinger over 5 years ago
I was able to reproduce this on several machines running the newer XVnc version.
- Start XVnc like the worker does:
Xvnc -depth 16 -SecurityTypes None -ac :1337
- Start a console in there:
DISPLAY=:1337 xterm
- Connect over vnc to this display:
vncviewer localhost:7237
- Connect to the SUT over ssh with X-forwarding inside the VNC display:
ssh root@s390vsw157 -X
- Start yast with
yast.ssh
and observe how it crashes/does not start
Until now I was unable to find any logs to pinpoint the component which is responsible for this. I guess since other X applications (glxgears, firefox, etc) work just fine this is a combination issue with libyui and X/Xvnc.
Updated by coolo over 5 years ago
As discussed with Nick: I rather suspect the openssh client, not so much Xvnc. Please try if you can start ssh -X installations when coming from 15.
Updated by mgriessmeier over 5 years ago
Updated by okurz over 5 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: ssh-X@s390x-zVM-vswitch-l3
https://openqa.suse.de/tests/3204907
Updated by okurz over 5 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: ssh-X@s390x-zVM-vswitch-l3
https://openqa.suse.de/tests/3262572
Updated by SLindoMansilla over 5 years ago
PR with workaround suggested in bug ticket: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8287
Merged.
We should use this ticket to re-needle the test suite, since the workaround causes different window borders: https://openqa.suse.de/tests/3288459#step/welcome/2
Should this land into U-Team product backlog?
Updated by nicksinger over 5 years ago
- Status changed from In Progress to Feedback
- Assignee changed from nicksinger to mgriessmeier
SLindoMansilla wrote:
PR with workaround suggested in bug ticket: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/8287
Merged.
Nice. I'll assign the ticket to @mgriessmeier and set it to feedback since there is not much we can do from the tools-team and a workaround is already merged.
SLindoMansilla wrote:
We should use this ticket to re-needle the test suite, since the workaround causes different window borders: https://openqa.suse.de/tests/3288459#step/welcome/2
Should this land into U-Team product backlog?
I'd not pollute this bug here too much and better offload the re-needling-task into a related ticket.
Updated by SLindoMansilla about 5 years ago
Should this ticket be marked as resolved?
Updated by SLindoMansilla almost 5 years ago
- Status changed from Feedback to Resolved
Was verified on OSD and no new complaint