VNC black screen 12.3

VNC connection is black and not showing desktop login.

Anyone have any ideas?

Searched other threads and found a few version specific solutions but none of them worked.

Joe

Did you try to lower your connection settings? Worked for me in an earlier version of opensuse.

That doesn’t seem to be the issue this time. Fascinating about this problem is that it doesn’t work initially, then one fusses with the box, logs in different users, does a bunch of errands – and then, at some otherwise un-understood moment, ta da – it works.

Suspicions are that this also has to do with a particular nasty security/PAM/kernel interaction BUG that haunts release 12.3 – that it is part of, or related to, the problem with logging in to VSFTPD. (The oddity in that case is that the same user can Pam-authenticate over Putty to the SSH deamon, but cannot get an FTP login/connection Pam-authenticating into VSFTPD (and it doesn’t seem to help to point VSFTPD at the sshd PAM-stack.)

In other words, it seems to be a problem having to do with the relative state of the kernel, on the one hand, and the app (I think whether it is VNC under Xinetd or VSFTPD) that is trying to make happy with the kernel to get going. But, more than that, I don’t know – and, after a bit of looking, haven’t found anybody who seems to have real information.

BUG in the Firewall. EVEN IF you have the VNC services shown in the little window in the Yast firewall manager, the firewall doesn’t let the VNC client in – try disabling the firewall.

Do not disable the firewall unless your machine is only connected to a totally trusted LAN. Using YaST to select “VNC Server” in the “Allowed Services” of
SuSEfirewall2 only opens port 5901. If you are listen on any other ports, you should use the “Advanced” option to add them.

Remember to restart xinetd and/or the firewall after making any changes.

Do You mean totally black and featureless, or can you see the X mouse pointer? How did you launch the VNC client? What happens if you use a terminal to:


: ~>  vncviewer  *yourserver*:1

or


: ~>  vncviewer  *yourserver*::5901

or screen 2 / port 5902 or as appropriate. Other options in man vncviewer or vncviewer --help. This should work. When I upgraded from 12.2 to 12.3 VNC was seamless apart from the password business.

Hi folks,

Haven’t had any free time to deal with this.

But yes I have tried to disable the firewall without any luck.

I am using ultra VNC viewer from a windows client. No problems with 12.2 or 12.1 but had this type of problem with a previous 11.xx version.

Waited after a few updates and it begun to work so not sure what was changed in the updates…

Be nice to figure out so as not to have to wait a couple software updates for the fix.

If anyone has further details on how to fix please pass on.

Thanks

Joe

I have no fix.

But with a different approach using a basic ssh and x11vnc/tightvnc it is possible to use 12.3 vnc (if both PCs use GNU/Linux):

What I do, to connect via vnc to a different PC is open a terminal on my PC, and type:


ssh -t -L 5900:localhost:5900 user@remote-pc-ip 'x11vnc -localhost -nolookup -nopw -display :0'

that starts up x11vnc on the remote PC and starts sending the display back to my PC via vnc. (where user@remote-pc-ip is the remote user’s login name and remote-pc-ip is the remote PC’s ip address)

Then I open a second terminal on my PC and type:


vncviewer -encodings "tight copyrect hextile" localhost:0

The above displays the remote desktop that is being sent back to my PC.

I had this method given to me years ago by user yaloki, and it was worked well for me over the years. I don’t know enough about this subject to help you debug the approach you are attempting (nor to debug the approach I use if that does not work for you).

Note ssh port needs to be open and ssh daemon started on remote PC for the above to work.

After a lot of searching for a solution to this silly issue, it seems that the problem is still old and hitting back since 11.3.

Basically it seems that the IPV6 implementation is faulty somewhere… so the solution is either configure tightvnc in xinetd through an IPV4 IP manually (I did not look up the manual on how to do this) or… just disable the IPV6 special record from /etc/hosts:

~>cat /etc/hosts

# special IPv6 addresses
**#::1             localhost ipv6-localhost ipv6-loopback**

This seemed to do the trick.

What is weird is that I did not get an error message regarding the connection problems until I tried to connect with the tightvnc client… That’s the only time I noticed kdm complaining that it can not connect to an IPV6 IP.

I encountered a similar issue in 12.1 or 12.2 but then I could fix it by re-installing the X and VNC related packages.

Cheers and hopefully you will find this useful.

Of course, oldcpu’s approach is more secure and more elegant. :slight_smile:

I have nothing to add to this except holy **** I am glad you posted the bit about IPv6. This black screen VNC thing was driving me batty…commenting out that line solved it.

thanks! I have no idea how you or whoever originally figured that out did it…but man…thanks…

Greetings!
Starting with a fresh install of 12.3 with the gnome desktop

Not yet successful using VNC server on OpenSuSe 12.3. Wanting to connect and control from a Windows 7 machine.
Followed the 12.3 VNC doc to start, planning on a persistent connection (but any would be an accomplishment :-). First issue was the “No Password Configured for VNC Auth”

Got by the “No Password Configured for VNC Auth” issue by

  1. logging in as root and issuing: vncpasswd command and entering a password. (probably not a good idea, but when it is working will deal with security)

  2. Then adding this: -rfbauth /root/.vnc/passwd to the server arguments in /etc/xinitd.d/vnc (I did this only for vnc1) This parameter may also be added by using YaST and going to Network Services, Network Services (xinetd) selecting vnc1 and clicking Edit then editing the Server Arguments field, adding -rfbauth /root/.vnc/passwd

Now, running the viewer on the Win7 machine it connects nicely using the password I installed.

But, I get the black screen with just the X cursor.

I have searched many forums, studied vnc doc, tried many things but have made no progress.

Perhaps someone out there has this working and will provide to me some guidance.

Have fun,
Paxton

Whoops! I forgot, when editing the vnc1 service be sure to change the user from “nobody” to “root”.

didn’t you read my post from a little bit above your posts? the one regarding IPV6 record disable? i.e. from here?

also, for the suggestions in your post - the vnc service does NOT have to run as root but it can ran as a normal user too from xinetd - search the forums about it (or google it - it was in first few results for “vnc opensuse problems”) or use oldcpu’s elegant solution above my post with ssh.

cheers and good luck.

[QUOTE=oldcpu;2542745What I do, to connect via vnc to a different PC is open a terminal on my PC, and type:


ssh -t -L 5900:localhost:5900 user@remote-pc-ip 'x11vnc -localhost -nolookup -nopw -display :0'

that starts up x11vnc on the remote PC and starts sending the display back to my PC via vnc. (where user@remote-pc-ip is the remote user’s login name and remote-pc-ip is the remote PC’s ip address)[/QUOTE]

:~> ssh -t -L 5900:localhost:5900 greyshark@192.168.12.7 'x11vnc -localhost -nolookup -nopw -display :0'Password: 
bind: Cannot assign requested address
channel_setup_fwd_listener: cannot listen to port: 5900
Could not request local forwarding.
30/07/2013 19:45:05 x11vnc version: 0.9.13 lastmod: 2011-08-10  pid: 10983
No protocol specified
30/07/2013 19:45:05 XOpenDisplay(":0") failed.
30/07/2013 19:45:05 Trying again with XAUTHLOCALHOSTNAME=localhost ...
No protocol specified


30/07/2013 19:45:05 ***************************************
30/07/2013 19:45:05 *** XOpenDisplay failed (:0)


*** x11vnc was unable to open the X DISPLAY: ":0", it cannot continue.
*** There may be "Xlib:" error messages above with details about the failure.


Some tips and guidelines:

(clip)

Connection to 192.168.12.7 closed.
:~>

VNC & VNC Server are allowed services in firewall
I’ve tried disabling both firewalls temporarily: same result
I’ve tried different users, even root: same result

Remote: 12.3 w/ KDE 4.10.5

:~ # uname -aLinux p580.cutbeach 3.7.10-1.16-desktop #1 SMP PREEMPT Fri May 31 20:21:23 UTC 2013 (97c14ba) x86_64 x86_64 x86_64 GNU/Linux
:~ #

Server: 12.2 w/ KDE 4.10.5

:~ # uname -aLinux p580.cutbeach 3.4.47-2.38-default #1 SMP PREEMPT Fri May 31 20:21:23 UTC 2013 (97c14ba) i686 i686 i 386 GNU/Linux
p580:~ #

Any thoughts?

I don’t know enough about this to interpret the error’s, but I do know that the method I use works. I used it last night , where my PC is in Germany and my mother’s PC in Canada. I used that the command in the exact form I recommended, to take over her desktop in Canada. I do NOT have ‘password’ on the same line as ssh as your code appears to suggest.

I have port #22 (via selecting ‘Secure Shell Server’ in YaST under Firewall Configuration) open on both my PC and my mother’s PC.

I have the ssh daemon running on both my PC and my mother’s PC.

I also have my mother’s router setup to forward any incoming connection to the router’s port #22 on to my mother’s PC on her home LAN. Without that none of this of course would work. Her router NEEDS to know where to send an incoming port#22 arrival. The command I us could also be modified to work for another port, which is not a bad idea if one wishes to improve security further.

For example on my home PC, I have port#22 closed on my home router. Instead I have a high port # (say for example port #60100 - I just made up that # for this example) setup on the router to forward all incoming requests on that #60100 to port #22 on my PC on my home LAN.

I note this for vnc versions on my PC (and my mother’s) where this works:


oldcpu@corei7-920:~> rpm -qa '*vnc*'
xorg-x11-Xvnc-7.6_1.0.1-3.8.1.x86_64
tightvnc-1.3.10-10.1.1.x86_64

There is an update to xorg-x11-Xvnc (to 7.6_1.0.1-3.12.1) and tightvnc (to 1.3.10-10.4.1) that I have not yet installed on either my PC nor on my mother’s.

Same here (seems to be a formatting error introduced during copy/paste, sorry for the confusion)

I have port #22 (via selecting ‘Secure Shell Server’ in YaST under Firewall Configuration) open on both my PC and my mother’s PC.

Same here (firewall disabled temporarily)

I have the ssh daemon running on both my PC and my mother’s PC.

Same here

… forward any incoming connection to the router’s port #22 on to my mother’s PC on her home LAN.

still just testing on LAN

For example on my home PC, I have port#22 closed on my home router. Instead I have a high port # (say for example port #60100 - I just made up that # for this example) setup on the router to forward all incoming requests on that #60100 to port #22 on my PC on my home LAN.

good suggestion, thanx

I note this for vnc versions on my PC (and my mother’s) where this works:

oldcpu@corei7-920:~> rpm -qa ‘vnc
xorg-x11-Xvnc-7.6_1.0.1-3.8.1.x86_64
tightvnc-1.3.10-10.1.1.x86_64

.

# rpm -qa '*vnc*'
libvnc-devel-20070501-6.1.1.x86_64
x11vnc-0.9.13-4.1.2.x86_64
xorg-x11-Xvnc-7.6_1.0.1-3.8.1.x86_64
x11vnc-frontend-0.9.13-4.1.2.x86_64
tightvnc-1.3.10-10.1.1.x86_64
:~ #

I tried removing possible conflicts (shotgun approach when all else fails)

:~ # rpm -qa '*vnc*'
libvnc-devel-20070501-6.1.1.x86_64
xorg-x11-Xvnc-7.6_1.0.1-3.8.1.x86_64
tightvnc-1.3.10-10.1.1.x86_64
:~ # 

At first glance the result looked promising, but I’m not so sure.
(I didn’t dare take out libvnc-devel-20070501-6.1.1.x86_64 as it would have taken out 14 more files, and I couldn’t remember why they’d been there in the first place. Didn’t want to create a disaster down the road.)

:~> ssh -t -L 5900:localhost:5900 root@192.168.12.7 'x11vnc -localhost -nolookup -nopw -display :0'
Password: 
bind: Cannot assign requested address
channel_setup_fwd_listener: cannot listen to port: 5900
Could not request local forwarding.
bash: x11vnc: command not found
Connection to 192.168.12.7 closed.
:~> 

do not use “root@192.168.12.7”. ssh by root is blocked by default in openSUSE.

Instead use an existing user name/password on that PC.

That’s not true:

wolfi@amiga:~> ssh root@localhost
Password: 
Last login: Wed Jul 31 17:14:23 2013 from localhost
Don't panic!
amiga:~ # 

And how do you think this could work, when you uninstalled x11vnc before? :wink:

Indeed you are correct. I just tested this on 12.3 after reading your reply.

This is a change from what I recollect.

My recollection is that MANY openSUSE versions back, root ssh was possible, and there were many user complaint about the lack of security, and hence by default it was changed to disallow root access. To enable one had to go to /etc/ssh/sshd_config and have the line:


PermitRootLogin yes

I can not recall when this was changed back to allow root access.

Its a surprise to me.

I’ve now gone back to all my home PCs and changed /etc/ssh/sshd_config line to


PermitRootLogin no

greyshark@D255:~> ssh -t -L 5900:localhost:5900 greyshark@192.168.12.7
Password: 
bind: Cannot assign requested address
channel_setup_fwd_listener: cannot listen to port: 5900
Could not request local forwarding.
Last login: Wed Jul 31 05:56:35 2013 from p580
Have a lot of fun...
greyshark@D255:~> 

It’s worth noting that at this point I can use CLI to do most anything I want on D255, however I’d still like to get the second half of the command to work

greyshark@D255:~> x11vnc -localhost -nolookup -nopw -display :0
31/07/2013 05:44:03 x11vnc version: 0.9.13 lastmod: 2011-08-10  pid: 3895
31/07/2013 05:44:03 Using X display :0
31/07/2013 05:44:03 rootwin: 0xaa reswin: 0x5a00001 dpy: 0x84615e0
31/07/2013 05:44:03 
31/07/2013 05:44:03 ------------------ USEFUL INFORMATION ------------------


(clip)


31/07/2013 05:44:03 --------------------------------------------------------
31/07/2013 05:44:03 
31/07/2013 05:44:03 Default visual ID: 0x21
31/07/2013 05:44:03 Read initial data from X display into framebuffer.
31/07/2013 05:44:03 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/4096
31/07/2013 05:44:03 
31/07/2013 05:44:03 X display :0 is 32bpp depth=24 true color
31/07/2013 05:44:03 
31/07/2013 05:44:03 Autoprobing TCP port 
31/07/2013 05:44:03 Autoprobing selected port 5902
31/07/2013 05:44:03 listen6: bind: Cannot assign requested address
31/07/2013 05:44:03 Not listening on IPv6 interface.
31/07/2013 05:44:03 
31/07/2013 05:44:03 Xinerama is present and active (e.g. multi-head).
31/07/2013 05:44:03 Xinerama: number of sub-screens: 1
31/07/2013 05:44:03 Xinerama: no blackouts needed (only one sub-screen)
31/07/2013 05:44:03 
31/07/2013 05:44:03 fb read rate: 157 MB/sec
31/07/2013 05:44:03 fast read: reset -wait  ms to: 10
31/07/2013 05:44:03 fast read: reset -defer ms to: 10
31/07/2013 05:44:03 The X server says there are 24 mouse buttons.
31/07/2013 05:44:03 screen setup finished.
31/07/2013 05:44:03 


The VNC desktop is:      localhost:2
PORT=5902


******************************************************************************
Have you tried the x11vnc '-ncache' VNC client-side pixel caching feature yet?


The scheme stores pixel data offscreen on the VNC viewer side for faster
retrieval.  It should work with any VNC viewer.  Try it by running:


    x11vnc -ncache 10 ...


One can also add -ncache_cr for smooth 'copyrect' window motion.
More info: http://www.karlrunge.com/x11vnc/faq.html#faq-client-caching


^Ccaught signal: 2
31/07/2013 05:44:53 deleted 32 tile_row polling images.
greyshark@D255:~>

lol! That was precisely my first thought, however I noted that x11vnc did not appear here

oldcpu@corei7-920:~> rpm -qa '*vnc*'
xorg-x11-Xvnc-7.6_1.0.1-3.8.1.x86_64
tightvnc-1.3.10-10.1.1.x86_64

so I thought it worth trying without. When the experiment didn’t work out I re-installed x11vnc