The script /usr/bin/vglconnect has still /opt/VirtualGL/bin ------ if [ -z $VGL_BINDIR ]; then VGL_BINDIR=/opt/VirtualGL/bin fi ------ as default path but the VirtualGL scripts are now in /usr/bin so the default path should be /usr/bin Because of the wrong default path 'vglconnect' fails when you try to connect to a remote VirtualGL-Server. In the moment the workaround is to set VGL_BINDIR on the client e.g. 'export VGL_BINDIR=/usr/bin' but I think a better way would be to change the default path in /usr/bin/vglconnect because /opt/VirtualGL/bin does not exists.
Forgot to mention the version, it's VirtualGL-2.3.2-3.fc18
Hello JM. I think I've got a patch created for this bug now. I need to do further testing but hopefully I should be able to push this to fedora-updates-testing repository some time tomorrow. Thanks for reporting this problem.
VirtualGL-2.3.2-4.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-4.fc17
VirtualGL-2.3.2-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-4.fc18
Package VirtualGL-2.3.2-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing VirtualGL-2.3.2-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4459/VirtualGL-2.3.2-4.fc18 then log in and leave karma (feedback).
The path is now correct, so I assume the patch works :-). I still get the error ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored. ERROR: ld.so: object 'librrfaker.so' from LD_PRELOAD cannot be preloaded: ignored. when I use (for example) vglrun glxgears on the server. Should I open a separate Bugreport for this?
Hello JM, We can work on it in this bugzilla report. What happens if you add: LD_LIBRARY_PATH=/usr/lib64/VirtualGL:/usr/lib/VirtualGL:$LD_LIBRARY_PATH to the end of if [ -z $VGL_BINDIR ]; then VGL_BINDIR=/usr/bin fi in the shell script vglconnect? The problem here is that I am unsure how to fix this particular bug or how to reproduce it. I only use VirtualGL with my hybrid graphics setup. I can arrange to have two fedora 18 machines on the network if you could provide detailed instructions on how to run the test? That might allow me to try various things to see if they fixed your issue. Thanks,
I tried it with LD_LIBRARY_PATH=/usr/lib64/VirtualGL:/usr/lib/VirtualGL:$LD_LIBRARY_PATH in the vglconnect script but I still get the error message. I have no need for the hybrid graphics setup. I use it (since years) to execute OpenGL programs on a remote server, the remote server has multiple high end graphic cards, this way the clients can use simple (inexpensive) graphic cards. It is very simple to create this configuration, you can use a system with a real hardware graphic card (NVIDIA, AMD, doesn't matter) as VirtualGL-Server and for example a VM-System (on the same system if necessary) as client... the VM-System has no real graphic card and so you have to connect to the server for OpenGL programs. Run on the VirtualGL-Server the script 'vglserver_config' and then you can connect from the client to the server with vglconnect -s <hostname of the VirtualGL-Server> On the VirtualGL-Server you run vglrun glxgears and the output goes to the client but the server renders the graphic. On the client and server I installed the 32bit and 64bit version of VirtualGL because some OpenGL programs are 32bit and some 64bit. I think the error message is not really an error (at least I hope so :-)) because the OpenGL program on the server works and the output goes to the client but I can't find the reason why I get the error message with libdlfaker.so and librrfaker.so.
I removed the 32bit version of VirtualGL from the server and the client (because I thought that could be the problem) but the result is the same.
I was wrong, the error actually means that VirtualGL is broken, I switched back to the original VirtualGL version from http://www.virtualgl.org/ and now it works, the error is gone and the server now renders the graphic... so whatever you did, it actually broke VirtualGL. I hope I have more time during the weekend to see what is causing the problem.
Ok. Cool. Let me know if you can find out anything and I could make another patch. Some libraries (libdlfaker.so,libgefaker.so, and librrfaker.so) now in /usr/$lib/VirtualGL/ had to be moved there to meet fedora packaging guidelines. So that is probably what is causing the issues you found. So we need to figure out how to add them to the LD_LIBRARY_PATH I think. You can see the reasoning behind that change in bugzilla 834127. (https://bugzilla.redhat.com/show_bug.cgi?id=834127#c2) Using VirtualGL-2.3.2-4.fc18 does still seem to work ok with a hybrid graphics setup. I will try to set up a pair of test systems this weekend or early next week to see if I can reproduce your problem. Is there a difference between VirtualGL-2.3.2-3.fc18 and VirtualGL-2.3.2-4.fc18 or are they both equally broken? Thanks,
Just for reference, the comment, number 2 referred to this problem: https://fedoraproject.org/wiki/Common_Rpmlint_issues#invalid-soname Cheers,
I found a new bug (VirtualGL-2.3.2-4.fc18), the symlink libGL.so inside /usr/lib/fakelib/ and /usr/lib64/fakelib/ is broken, in the moment it's /usr/lib/librrfaker.so and /usr/lib64/librrfaker.so but you moved librrfaker.so to /usr/lib/VirtualGL and /usr/lib64/VirtualGL. So libGL.so inside /usr/lib[64]/fakelib/ should point to /usr/lib[64]/VirtualGL/librrfaker.so But even with this fix VirtualGL is still broken.
How did you install a working version? For example, did you install the Red Hat Enterprise Linux 6 RPM into a fedora 18 box? I followed the instruction here: http://www.virtualgl.org/vgldoc/2_2_1/#hd007 for configuring the server. I could not find more current documentation on the web site. I have never used VirtualGL other than with Hybrid graphics on a single Optimus laptop. So I am starting from 0% experience. I set it up just now so that "any users" can run 3d apps as specified in setting up the server with vglserver_config. Nothing I have tried has helped. I do not know what to try next. I do not think we are allowed to place the libraries in /usr/lib/ or /usr/lib64 due to packaging guidelines. But even if I create symlinks there then the app just crashes with "247: No route to host" [gsgatlin@localhost ~]$ vglrun glxgears [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to [VGL] 192.168.1.6, the IP address of your SSh client. [VGL] ERROR: Could not connect to VGL client. Make sure that vglclient is [VGL] running and that either the DISPLAY or VGL_CLIENT environment [VGL] variable points to the machine on which vglclient is running. [VGL] ERROR: in connect-- [VGL] 247: No route to host Can I test this with an Intel graphics adaptor on both systems or must one of the systems be an NVidia desktop type system? If a desktop type system with NVidia is required, does the NVidfia driver need to be installed or will nouveau work just as well?
VirtualGL-2.3.2-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-5.fc19
VirtualGL-2.3.2-5.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-5.fc18
VirtualGL-2.3.2-5.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/VirtualGL-2.3.2-5.fc17
Sorry for the delay in getting back to you on this issue. I now have the hardware I would need to test any further issues. My tests indicate when this hits testing it should fix the issues you reported. How I tested it: Log into remote desktop server with nvidia graphics rpms from rpmfusion already installed and working. Become root. init 3 vglserver_config 1 [hit Enter] Restrict 3D X server access to vglusers group (recommended)? [Y/n] n [hit enter] Restrict framebuffer device access to vglusers group (recommended)? [Y/n] n [hit enter] Disable XTEST extension (recommended)? [Y/n] n [hit enter] x [hit Enter] init 5 logout vglconnect -s gsgatlin@serverhostname vglrun glxgears I think there will be another comment from the build system soon when this is ready to be tested.
Ok. Slight correction in steps for testing for fedora 18... ;) replace "init 3" with: systemctl isolate runlevel3.target and replace "init 5" with: systemctl isolate runlevel5.target Which actually did not work for me with the rpmfusion nvidia packages. So I had to reboot after switching to 5 and noticing gdm wasn't started. But after that it worked. (Otherwise vglrun complains about not being able to open display :0.) Tested connecting from a RHEL 6 desktop and a fedora 18 desktop connecting to a fedora 18 server. (RHEL 6 server tested yesterday) Still hasn't hit testing repo for me yet but should be ready for testing soon.
Package VirtualGL-2.3.2-5.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing VirtualGL-2.3.2-5.fc18' as soon as you are able to. Let me know if this fixes the problems you reported. Thanks.
VirtualGL-2.3.2-5.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
VirtualGL-2.3.2-5.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
Works for me as well, so the version 2.3.2-5.fc18 fixed the problem for me. Thank you for the work!
Thanks for the bug report and the feedback. Cheers,
VirtualGL-2.3.2-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.