With tigervnc-server-module-1.0.0-1.fc12, xorg-x11-server-Xorg-1.7.0-1.fc12 and all other packages current as of today from Rawhide: (II) Loading /usr/lib/xorg/modules/extensions/libvnc.so dlopen: /usr/lib/xorg/modules/extensions/libvnc.so: undefined symbol: CoreDevicePrivateKey (EE) Failed to load /usr/lib/xorg/modules/extensions/libvnc.so (II) UnloadModule: "vnc" (EE) Failed to load module "vnc" (loader failed, 7)
Works for me on FC11 and the 1.0.0-2 versions. Next week I'll try FC12, but isn't there a -2 version for FC12 out?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is also present in the current testing version on F12: tigervnc-server-module-1.0.0-3.fc12.i686
(II) LoadModule: "vnc" (II) Loading /usr/lib64/xorg/modules/extensions/libvnc.so dlopen: /usr/lib64/xorg/modules/extensions/libvnc.so: undefined symbol: CoreDevicePrivateKey (EE) Failed to load /usr/lib64/xorg/modules/extensions/libvnc.so (II) UnloadModule: "vnc" (EE) Failed to load module "vnc" (loader failed, 7) Using : tigervnc-server-module-1.0.0-3.fc12.x86_64 Gave me same error with original version that comes with Fedora12 ETA ?
I am experiencing the same issue on a new install of Fedora 12 64 bit.
Ditto Please.... can you guys do a bit of QA before releasing - huh? - Just a little... like seeing that things actually work before releasing something as "gold"
We also have the same problem.
Main problem is the latest upstream release supports only X.Org 1.6 series, not 1.7. Port libvnc.so to 1.7 is non-trivial and I'm working on it. Please use, for example, the "vino" server (part of GNOME desktop) as a temporary workaround.
Vino server only starts after user logs in. Where as tigervnc-server-module starts with X so user can login. If vino is used one might have to enable auto login (may be security issue)
(In reply to comment #8) > Main problem is the latest upstream release supports only X.Org 1.6 series, not > 1.7. Port libvnc.so to 1.7 is non-trivial and I'm working on it. > > Please use, for example, the "vino" server (part of GNOME desktop) as a > temporary workaround. Thanks for that. Much appreciated.
Hi Adam, Any update on this issue? I have been using krfb under KDE as a replacment for libvnc, but it is painfully slow and the shift key is not working. I would be happy to help test any updated modules.
In case it helps others, yes, there definitely appear to be some libvnc.so issues. However, I found that in my case at least, the primary catalyst is to do with SELinux interaction with libvnc.so. SELinux is preventing Xvnc from obtaining a X11 hook in the call "ck-get-x11-serv". At first, TigerVNC was opening very slowly and the log was full of crash errors. Then, as a test, I temporarily set the SELinux policy to permissive. Once in permissive mode, TigerVNC now works, "mostly". Of course, you must install the package for libvnc.so too. As a note, I also find it works better for some reason over a ssh tunnel than with a remote native connection. The next step for me of course, is to try to create SELinux policy get around the ck-get-x11-serv issue. I hope this is of some help.
I have selinux disabled and I still have issues with livnc.
For those still struggling with TigerVNC and the issues with libvnc.so, I thought I would share a simple and fully working work-around: Summary: The problem is that libvnc.so is not able to attach to Xorg and that PolicyKit does not function properly either. This means that with the native vnc, you cannot do much of anything. The work-around is to manually start a TigerVNC session as the actual user in a ssh session and avoid the attach and start step all together. Steps for work-around: 1. ssh into the box 2. If this is your first time in, type: "vncpasswd" to setup a password 3. In the open ssh terminal, type: "vncserver -geometry <desired geometry> -depth <desired depth>" example: "vncserver -geometry 1280x800 -depth 16" The terminal will confirm something similar to: New 'venom:2 (tom)' desktop is venom:2 Starting applications specified in /home/tom/.vnc/xstartup Log file is /home/tom/.vnc/venom:2.log The session number corresponds to a port: 0 = 5900 1 = 5901 2 = 5902 etc.... 4. Connect to the session and use as normal. 5. To kill the vncserver session: "vncserver -kill :<session num>" example: "vncserver -kill :2" Again, TigerVNC in Fedora 12 now fully is functional and usable with the work-around for me. I hope this information is of help to others.
Not sure that helps those of us that want to connect to the server running on the main console...
First of all, the selinux and policykit stuff is a red herring; I have selinux completely disabled and I still have this problem. The problem is that the tigervnc X server module does not load cleanly into the X server; nothing more, nothing less. Second, the workaround you described does not solve the problem that this bug report is about, which is about the fact that people want to be able to connect to a VNC session displaying *their actual desktop that's displayed by Xorg on their actual monitor*, not some independent vncserver session accessible only over VNC. The tigervnc-server-module RPM contains an Xorg module which is supposed to make that possible, but (as noted above) that module doesn't load cleanly into Xorg, so this functionality is missing. A better workaround is to use vino, which does work in F12.
Henrique Martins said: "Not sure that helps those of us that want to connect to the server running on the main console..." I am not sure what you mean. If you follow the steps outlined above, you can remotely connect to a VNC session on another box. For example, you can connect with a client VNC viewer to a remote server and administer the server as if you were right in front of it. Jonathan Kamens said: "*their actual desktop that's displayed by Xorg on their actual monitor*," I think you may be confusing TigerVNC with Vino. Vino is the X11 VNC product that allows you to share the actual desktop. Plus, Vino is working just fine (as it was even offered as a work-around to the libvnc.so bug above). TigerVNC (or its predecessor TightVNC) spawn virtual desktop sessions and are not sharable.
(In reply to comment #17) > I think you may be confusing TigerVNC with Vino. I am afraid you are the one who is confused. I will try again to explain what I already explained above. Please listen this time. TigerVNC supports two different kinds of VNC server: one which serves an independent VNC session not associated with any physical console, AND one which serves the user's actual physical display. The latter functionality is what requires a module to be loaded into the X server. The latter functionality is what is not working because the module does not load. The latter functionality is what this bug is about.
What I mean is that after reboot the gdm screen shows up and I login and start an X session on the main display. I do this both on a work machine and my home machine, which are always on. With a working libvnc module I can connect to those sessions and manipulate the windows that are open on that session/main screen. I don't need yet another vnc session to do remote admin, I can use ssh/xterms and good old command line for most of the stuff, but once in a while I do want/need to interact with programs that are running on the main screen. vino is fine but it won't share the gdm/kdm/xdm screen, so restarting the X server remotely on the main console is iffy (one can auto-logon and immediately lock the screen, but that only works for one user).
Jonathan Kamens said: "I am afraid you are the one who is confused." You could be right. I am CentOS and Suse admin, thus mostly familiar with TightVNC server. This is my first time installing F12 and using TigerVNC. If Tiger introduces desktop sharing functionality, I certainly did not see that noted anywhere in the documentation link below and I apologize for any misinformation or confusion. https://fedoraproject.org/wiki/Features/TightVNC Also, if I am in the wrong bug, can somewhere suggest the bug # reporting that PolicyKit is not functional via a virtually spawned TigerVNC session? If you for example, connect to a virtual TigerVNC session and try to run anything with elevated privileges, such as 'Add/Remove Software', no dialog present and permissions for the action fail. A brief debugging session looked to me that the daemon process could not attach to the user X11 process and PolicyKit profile. In short, even the virtual TigerVNC functional is completely unusable.
(In reply to comment #20) > Also, if I am in the wrong bug, can somewhere suggest the bug # reporting that > PolicyKit is not functional via a virtually spawned TigerVNC session? If you > for example, connect to a virtual TigerVNC session and try to run anything with > elevated privileges, such as 'Add/Remove Software', no dialog present and > permissions for the action fail. A brief debugging session looked to me that > the daemon process could not attach to the user X11 process and PolicyKit > profile. In short, even the virtual TigerVNC functional is completely > unusable. Please open a different bug report for this issue. libvnc.so problems are definitely not related to PolicyKit/SELinux.
Hi Adam, I see where patches have been sent upstream: Re: [Tigervnc-devel] [patch] Add support for xorg 1.7.x Adam Tkac Mon, 21 Dec 2009 06:14:47 -0800 When are we going to see a Fedora update?
(In reply to comment #22) > Hi Adam, > I see where patches have been sent upstream: > > Re: [Tigervnc-devel] [patch] Add support for xorg 1.7.x > > Adam Tkac > Mon, 21 Dec 2009 06:14:47 -0800 > > When are we going to see a Fedora update? Yes. I have already built updated tigervnc in rawhide but there are still few unsolved problems which prevents F12 update. You can download & test Fedora 13 libvnc.so module from http://kojiweb.fedoraproject.org/koji/buildinfo?buildID=147967 if you are interested.
Hi Adam, Thanks for the update. I have downloaded the Fedora 13 packages and they load and work fine for me on Fedora 12. I am using it right now to type this message. Michael
i have tried the f13 packages on f12 and got this backtrace immediately after giving my vnc password to the viewer: If you'd like me to try anything or open this as a different bugzilla let me know. Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x49ea48] 1: /usr/bin/Xorg (0x400000+0x61a39) [0x461a39] 2: /lib64/libpthread.so.0 (0x7f2610469000+0xf0f0) [0x7f26104780f0] 3: /lib64/libc.so.6 (memcpy+0x15b) [0x7f260fce705b] 4: /usr/lib64/xorg/modules/drivers/radeon_drv.so (0x7f260e712000+0xb90a3) [0x7f260e7cb0a3] 5: /usr/lib64/xorg/modules/libexa.so (0x7f260e0d8000+0x82d8) [0x7f260e0e02d8] 6: /usr/bin/Xorg (0x400000+0x152e44) [0x552e44] 7: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN14XserverDesktop10grabRegionERKN3rfb6RegionE+0x116) [0x7f260ea68d76] 8: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb11VNCServerST11checkUpdateEv+0x23a) [0x7f260ea9ef7a] 9: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb16VNCSConnectionST22writeFramebufferUpdateEv+0xbc) [0x7f260ea9c5ac] 10: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN3rfb16VNCSConnectionST15processMessagesEv+0xa8) [0x7f260ea9d578] 11: /usr/lib64/xorg/modules/extensions/libvnc.so (_ZN14XserverDesktop13wakeupHandlerEP6fd_seti+0x11e) [0x7f260ea6934e] 12: /usr/lib64/xorg/modules/extensions/libvnc.so (0x7f260ea16000+0x4bf34) [0x7f260ea61f34] 13: /usr/bin/Xorg (WakeupHandler+0x4b) [0x4319eb] 14: /usr/bin/Xorg (WaitForSomething+0x1d7) [0x45bdf7] 15: /usr/bin/Xorg (0x400000+0x2c432) [0x42c432] 16: /usr/bin/Xorg (0x400000+0x21d5a) [0x421d5a] 17: /lib64/libc.so.6 (__libc_start_main+0xfd) [0x7f260fc82b1d] 18: /usr/bin/Xorg (0x400000+0x21909) [0x421909] Segmentation fault at address 0x7f260d80e000 Fatal server error: Caught signal 11 (Segmentation fault). Server aborting
*** Bug 570683 has been marked as a duplicate of this bug. ***
Not sure if I can point at it, but I've been running with the f13 module for a while with no major problems. However, maybe due to one of the recent yum updated xorg packages, my X server now crashes when I vnc connect to it, not always but it does happen on two machines. All I have is an X crash, and the following two lines in Xorg.0.log Fatal server error: Wrong event type 0.
Seems that the f13 modules above have been deleted from koji. Are they available anywhere else or where they deemed not working?
tigervnc-1.0.1-1.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/tigervnc-1.0.1-1.fc12
tigervnc-server-module-1.0.1-1.fc12 should finally work. It will hit updates-testing repo very soon but please make sure you also update your Xorg to at least xorg-x11-server-Xorg-1.7.6-3.fc12 to get libvnc.so working.
Thank you for your work on this Adam! I look forward to the update. I'll be installing and testing it as soon as it hits the updates-testing repo. I've been using RealVNC Free Edition on Fedora, RHEL, and MS Windoze for many years at our site with and without stunnel. Admins use it for remote administration. Engineers and developers use it to get X sessions on our multi-user RHEL development servers and Fedora Internet access machine. The transition to TigerVNC was transparent to us for all but the remote console display. Our users never knew the difference. Myself and my assistant admins, however, rely on the VNC xorg module for remote administration so we've had to physically touch the Fedora boxes for tasks that cannot be accomplished in a terminal window. Thanks to you there is light at the end of the stunnel. :-)
tigervnc-1.0.1-1.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update tigervnc'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/tigervnc-1.0.1-1.fc12
Works great for me! I now have my remote console back. No errors or warnings in Xorg.0.log or anywhere else that I can see. X Windows, GDM, XDMCP and all other related xorg functions are normal. I updated the six tigervnc and xorg-x11-server packages from the updates-testing repo. There was no update to the debuginfo package but it's apparently not needed since things seem to be working fine. kernel-2.6.32.11-99.fc12.x86_64 kmod-nvidia-2.6.32.11-99.fc12.x86_64-195.36.15-1.fc12.2.x86_64 tigervnc-server-module-1.0.1-1.fc12.x86_64 xorg-x11-drv-nvidia-195.36.15-1.fc12.x86_64 xorg-x11-server-Xorg-1.7.6-3.fc12.x86_64 Thank you!
tigervnc-1.0.1-1.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.