Bug 923961 - Wrong VGL_BINDIR path in script /usr/bin/vglconnect
Summary: Wrong VGL_BINDIR path in script /usr/bin/vglconnect
Alias: None
Product: Fedora
Classification: Fedora
Component: VirtualGL
Version: 18
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Gary Gatling
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-03-20 19:38 UTC by JM
Modified: 2013-05-24 20:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-20 15:20:52 UTC

Attachments (Terms of Use)

Description JM 2013-03-20 19:38:27 UTC
The script 


has still /opt/VirtualGL/bin

if [ -z $VGL_BINDIR ]; then

as default path but the VirtualGL scripts are now in


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.

Comment 1 JM 2013-03-20 19:40:03 UTC
Forgot to mention the version, it's


Comment 2 Gary Gatling 2013-03-20 20:55:08 UTC
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.

Comment 3 Fedora Update System 2013-03-25 20:41:57 UTC
VirtualGL-2.3.2-4.fc17 has been submitted as an update for Fedora 17.

Comment 4 Fedora Update System 2013-03-25 20:43:34 UTC
VirtualGL-2.3.2-4.fc18 has been submitted as an update for Fedora 18.

Comment 5 Fedora Update System 2013-03-27 00:46:54 UTC
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:
then log in and leave karma (feedback).

Comment 6 JM 2013-03-28 14:11:05 UTC
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?

Comment 7 Gary Gatling 2013-03-28 15:24:24 UTC
Hello JM,

We can work on it in this bugzilla report.

What happens if you add:


to the end of

if [ -z $VGL_BINDIR ]; then

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.


Comment 8 JM 2013-03-28 16:01:12 UTC
I tried it with 


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.

Comment 9 JM 2013-03-28 16:05:23 UTC
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.

Comment 10 JM 2013-03-28 16:44:37 UTC
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.

Comment 11 Gary Gatling 2013-03-28 18:29:05 UTC
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?


Comment 12 Gary Gatling 2013-03-28 18:39:21 UTC
Just for reference, the comment, number 2 referred to this problem:



Comment 13 JM 2013-04-02 23:01:10 UTC
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.

Comment 14 Gary Gatling 2013-04-07 21:54:44 UTC
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:


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], 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?

Comment 15 Fedora Update System 2013-05-06 21:04:59 UTC
VirtualGL-2.3.2-5.fc19 has been submitted as an update for Fedora 19.

Comment 16 Fedora Update System 2013-05-06 21:13:23 UTC
VirtualGL-2.3.2-5.fc18 has been submitted as an update for Fedora 18.

Comment 17 Fedora Update System 2013-05-06 21:23:40 UTC
VirtualGL-2.3.2-5.fc17 has been submitted as an update for Fedora 17.

Comment 18 Gary Gatling 2013-05-06 21:39:27 UTC
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


1 [hit Enter]

Restrict 3D X server access to vglusers group (recommended)?

n [hit enter]

Restrict framebuffer device access to vglusers group (recommended)?

n [hit enter]

Disable XTEST extension (recommended)?

n [hit enter]

x [hit Enter]

init 5


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.

Comment 19 Gary Gatling 2013-05-07 15:24:43 UTC
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.

Comment 20 Gary Gatling 2013-05-09 15:28:32 UTC
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.

Comment 21 Fedora Update System 2013-05-16 02:50:59 UTC
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.

Comment 22 Fedora Update System 2013-05-16 02:53:04 UTC
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.

Comment 23 JM 2013-05-18 15:27:38 UTC
Works for me as well, so the version 2.3.2-5.fc18 fixed the problem for me. Thank you for the work!

Comment 24 Gary Gatling 2013-05-20 15:18:26 UTC
Thanks for the bug report and the feedback. Cheers,

Comment 25 Fedora Update System 2013-05-24 20:38:23 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.