OpenSuse 11.1 - Vnc black/white with X cursor

English Network/Internet
#1

I’ve read through the other threads here but most of the issues involve disconnect after a login and mouse settings. It does work fine for me, but after a few days of being up and using vnc on and off it will still connect, but show the black/white mesh screen with the big black X cursor, then if I wait 30 seconds it disconnects.

Heres the log when this problem starts happening

Mar 31 14:13:52 mycompname kdm_config[27009]: Multiple occurrences of key ‘UseTheme’ in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc
Mar 31 14:15:07 mycompname kdm: {mac address}:1[27014]: Cannot connect to {mac address}:1, giving up
Mar 31 14:15:07 mycompname kdm[3262]: Display {mac address}:1 cannot be opened

If I restart the computer it works again, however this message is still shown in the logs:

Mar 31 14:49:28 mycompname kdm_config[5497]: Multiple occurrences of key ‘UseTheme’ in section [X-*-Greeter] of /usr/share/kde4/config/kdm/kdmrc

So I guess the above message is trivial to the problem? The thing is, I am not using KDE4, I installed 3.5, and in sysconfig my display manager is set to KDM not KDM4.

I’m using VNC through remote administration, multiple users will be accessing this from the network and need to get to the login screen.

Please help!

#2

I hope someone can come up with an answer to this one. I’ve been using VNC on a regular basis for my users to remotely login to our computers in our lab. But, recently, they just started giving the grey background, black X cursor screen on connections and nothing more. Must have happened after some updates. It has affected 10 out of 12 opensuse machines in our lab. And I think the 2 remaining ones didn’t get updates during the same period as the other broken machines.

#3

>>>Re: [opensuse] VNC Issue Resolved w/ OpenSUSE 11.1<<<

Found something that looks promising. I kept having the issue repeatedly, I found this after yet another google search. I commented out the localhost line in /etc/hosts

special IPv6 addresses

::1 localhost ipv6-localhost ipv6-loopback

And instantly it started working. I hope this fixes it for good. If this helps anyone else make a quick blurb about it!

#4

Our OpenSuse 11.1 VMs have been having VNC issues of the same sort. I was thinking it was something more of KDE, since the actual VNC would connect and render the xwindows cursor. I’m going to try commenting out the IPV6 stuff and cross my fingers. Thanks!

#5

Using OpenSUSE 11.1, I found several locations in combination that may need to be looked at to get it all to work.

In YAST:
Software -> Software Management
[INDENT]Search for inet and install:
INDENT xinetd
(+) yast2-xinetd
[/INDENT]
Search for vnc and install:
INDENT LibVNCserver
(+) x11vnc
(+) xorg-x11-xvnc
[/INDENT][/INDENT]
Network Services -> Network Services (xinetd)
INDENT Enable
(ON) vnc1[/INDENT]
Security & Users -> Local Security
[INDENT]In Security Overview: Disable remote access to the X server (Disable)
In Login Settings: (X) Allow remote graphical login[/INDENT]

Hope this helps someone.

Guy

#6

I’ve been interacting with the TightVNC users list and one of the developers. I’m going to paste below my last message from that list. I managed to find a way to make a user’s X-Window desktop appear in TightVNC.

I have not tried the login because I don’t know how to start the X-login in OpenSUSE 11.2. The vncserver program could also be started when the system starts. Maybe the X-login as well. This success may provide some useful information.

Basically I had the black/blank X-Window with the X-cusor like others have reported. Instead of Xvnc in xinetd, I used the perl wrapper script /usr/bin/vncserver. It gave on a display, like :2, a user’s desktop. Here’s the pasted discussion…

OpenSUSE 11.2’s xinetd runs Xvnc, a compiled program, directly with parameters on the command line. Those parameters can be set using the Yast configuration utility. Some of the parameters, namely -query localhost and -once are not documented in the Xvnc documentation.

I tried a different method and have gotten some success. I used putty-ssh to sign onto the OpenSUSE box and run the perl script vncserver as a user. (Why perl not bash?) Here’s the command line I used…

vncserver :2 -geometry 1024x768 -depth 24
…which, I’m sure you know, sets a vnc server running for display :2.

I then started TightVNC’s on WinXP viewer and went to IPaddress:2. I got access to a full desktop as including all the prior user KDE setup.

The problem with this is that there is not a normal X-Windows sign-on, it bypasses the normal X sign-on I would expect to see. Can the normal X-Windows login start be used here?

Here’s the full vncserver perl script generated command line and screen output. I’ve added the line formatting…

Xvnc :2 -desktop ‘X’
-httpd /usr/share/vnc/classes
-auth /root/.Xauthority
-geometry 1024x768 -depth 24
-rfbwait 120000
-rfbauth /root/.vnc/passwd
-rfbport 5902
-fp /usr/share/fonts/misc:unscaled,/usr/share/fonts/local,/usr/share/fonts/75dpi:unscaled,/usr/share/fonts/100dpi:unscaled,/usr/share/fonts/Type1,/usr/share/fonts/URW,/usr/share/fonts/Speedo,/usr/share/fonts/truetype,/usr/share/fonts/uni,/usr/share/fonts/CID -noreset
>> ‘/root/.vnc/wwsrv030:2.log’ 2>&1

New ‘X’ desktop server:2

Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/server:2.log

The OpenSUSE.org xinetd Xvnc startup is not working vncserver is.

The entered Xvnc with parameters for xinetd startup taken from the Yast editing screen are…

Xvnc -inetd -once -query localhost -geometry 1024x768 -depth 24

Any ideas?

I left out a script called by vncserver. It is a modified /home/username/.vnc/xstartup(also in /root) which invokes startkde instead of the stark xterm only twm.

#!/bin/sh
xrdb $HOME/.Xresources
xsetroot -solid grey
xterm -geometry 80x24+10+10 -ls -title “$VNCDESKTOP Desktop” &
/usr/bin/startkde <<<=== Originally it was “twm &”

What is xrdb, xsetroot, and is xterm the xterm?

What is the X-login startup?

#7

Let me add this part of the log file as vncserver starts and runs Xvnc. Look at the inet6 error statment. There is a comment above about commenting out a IP 6 localhost line(s) in the /etc/hosts file.

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/wwsrv030:2
_XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6

#8

I just remembered that I had disabled IP 6 in the Yast>Network Devices>Network Settings>Global screen.

#9

I just deleted this /etc/hosts entry as mentioned above and the OpenSUSE 11.2 VNC access started working. I did this by going to Yast>Network Services>Hostnames screen and deleting the entry the same as the one below.

Why does this work? What needs fixing in 11.2?

#10

I can"t consider this solved until the Why of it is documented. Who at OpenSUSE maintaining the TichtVNC package can explain why this is a problem?

#11

Can’t answer your question, but I will confirm, it solved the issue on another system I have.

Thank you,
Guy in Las Vegas

#12

Well, I’ve got to finish this thread off. I got some words from the TightVNC users form but I can’t use the author’s name as he has not yet responded to my EMail to use his name. I’ll quote it as it came from an open form.

BTW who is maintaining the OpenSUSE TightVNC package?

I had gotten the vncserver script to work per user at a users command line prompt.

Others may have more information to add to the quoted comments. The parameters -query localhost and -once are undocumented in the original Xvnc documentation. Maybe this is an OpenSUSE omission.

Quote:
"The main difference between the Inetd setup and running “vncserver” is that the Inetd command-line is using XDMCP to find an XDM server to provide the familiar X login prompt. Running “vncserver” doesn’t need such a prompt because it already knows which user you are, since you’ve already logged-on in order to run it.

Your Inetd configuration tells the X server to request XDM service only from “localhost” - if you look at the hosts line you’re deleting, you’ll notice that it adds ::1] as an address for “localhost”. If the X server XDMCP client code is requesting service from the first address it finds for “localhost” then that will probably be the IPv6 one, whereas your XDM server may only be using IPv4 & so won’t respond. If that’s the case then replacing “localhost” with the explicit IPv4 127.0.0.1 in the Xvnc command-line should fix things."

The xterm error you reported against that display is, I think, a red herring - it simply indicates that the user you ran xterm as didn’t have the right Magic Cookie to authenticate to the X server, which is little surprise if they hadn’t got to the stage of logging on to it!"*

#13

Thanks for replying and giving the localhost tip… The hard ip4 address did the trick. You never know how many people you are helping… thanks again :slight_smile:

#14

Just worked Fine. Thanks allot! Was looking for this solution long time.

#15

Hi Folks,
I have been fighting with this problem all day. I have a Suse 11.2 machine here at home where xinetd->vnc works just fine “out of the box” without any tweaks – didn’t have to comment out the /etc/hosts ipv6 line, didn’t have to alias the ipv4 localhosts line, and didn’t have to hardcode 127.0.0.1 in /etc/xinetd.d/vnc. It just worked.
But now I’m trying to set up a vnc server at work that can be shared as a remote workstation. Same general platform (32-bit), same software install & config. The only difference is that the Linux box at work is a VMware virtual machine. No matter what I try (including the aforementioned tweaks), I get the infamous black screen with x cursor.
Following is a snip from the work console where we can see the session that starts when I try to connect. I follow that with a ping to the ipv4-localhost alias to show you that the alias is resolvable:

colewad@USPORAMAP17:~> ps -ef | grep vnc
nobody 3796 2183 0 00:32 ? 00:00:00 Xvnc -noreset -inetd -once -query ipv4-localhost -geometry 1024x768 -depth 16
colewad 4182 4160 0 00:34 pts/0 00:00:00 grep vnc
colewad@USPORAMAP17:~> ping ipv4-localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.637 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.043 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.059 ms

There is a workaround which I can implement (thanks to Swerdna’s great article), which involves invoking vncserver from a @reboot crontab, but I think it would be more elegant and robust for multiple users to get the xinetd solution to work.
Any new ideas on this subject? It seems to have been a problem for quite some time. The localhost ipv4 tweak seemed to work for many, but not for me. Could it be some unique problem with the fact that this is running on a virtual machine?
Thanks in advance for any help! – Wade

#16

Well, here is what I am thinking.

Changing localhost to 127.0.0.1 has nothing to do with this problem whatsoever.

The problem occurs on a virtual machines. In my case running SUSE Linux Enterprise Server as a guest.

In my case, it was Hyper-V host. It only supported a certain resolution: 1600:800 for example. The host literally support only this rest.

Therefore, if your vnc server is configured to initialize a listening on a different res, rather then a supported one - when you connect, VNC fails to show you the screen, since there is not screen of such resolution to show.

SO:

Log in to a host system. Open a virtual machine manager and connect to the screen of the virtual, problem computer.

See what screen resolution it has by default. Set VNC to start in this res and you should be well in TWM. Or, as I did, you can configure the VNC to start KDE, GNOME, etc.

Max Pavlov