VirtualGL is only working remotely when the same user is logged on to X locally. /etc/opt/VirtualGL/vgl_auth_key does not exist. Video card is nVidia GeForce GTX470. OS is Linux/amd64.
Stopped gdm.
Ran vglserver_config (Y/Y/n).
Restarted gdm.
VGL doesn't work.
Stopped gdm.
Ran vglserver_config (n/n/n).
Restarted gdm.
VGL doesn't work.
Stopped gdm.
Ran vglserver_config (Y/Y/n).
Deleted /etc/modprobe.d/virtualgl.conf and modified existing nvidia.conf instead.
Restarted gdm.
VGL doesn't work.
- Verified 750 permissions on /etc/opt/VirtualGL/
- Verified 660 permissions + vglusers group for Section DRI in xorg.conf
- Verified 660 permissions for root:vglusers on /dev/nvidia*
- Verified user is in vglusers group
- Verified X is running on :0
Here are the errors I get (after vglconnect'ing):
~ $ vglrun +v glxgears
NOTICE: Automatically setting VGL_CLIENT environment variable to
172.20.77.164, the IP address of your SSh client.
NOTICE: Replacing dlopen("/lib/libdl.so.2") with dlopen("libdlfaker.so")
Shared memory segment ID for vglconfig: 51249154
Opening local display :0
No protocol specified
ERROR: Could not open display :0.
~ $ glxinfo -display :0
No protocol specified
Error: unable to open display :0
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it might be related to xauth. The /etc/opt/VirtualGL/vgl_xauth_key file does not exist/is not created, and I get the following in Xorg.0.log when I try to "vglrun glxgears" (X is running with "-audit 4"):
~ $ tail -n0 -f /var/log/Xorg.0.log
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected
vglserver_config is supposed to modify the gdm or kdm startup files so that the "vglgenkey" script is invoked whenever the display manager starts up. If vgl_xauth_key is not being generated, that means that vglgenkey is not being invoked, which probably means that your system stores its gdm config files in a place that vglserver_config doesn't know about. The GDM startup script is usually called ":0" or "Default" - some systems have both, in which case one usually invokes the other. Most systems also have a file called "Xsetup" as well. Sometimes, :0 or Default are just symlinks to Xsetup, but other times they are different files. If you could examine your system and verify the locations of :0, Default, and Xsetup under /etc, that will help me determine whether vglserver_config knows about those locations. Since I've never tested Gentoo, it's possible that it doesn't.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah ha! Got it. vglgenkey was in the gdm Init/Default script, but it wasn't in the $PATH (if there even is one). I just needed to "absolutize" it - /usr/local/bin/vglgenkey.
The gdm startup script is /etc/X11/gdm/Init/Default in Gentoo. There are no :0 or Xsetup files under /etc. I'd gone through the config script and confirmed that it had done what it's supposed to do. The nvidia module config file was /etc/modprobe.d/nvidia.conf rather than just nvidia, so I altered it to match virtualgl.conf and deleted virtualgl.conf.
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, yes, vglserver_config on Linux does assume that vglgenkey is in the PATH, because vglgenkey is installed under /usr/bin in the VirtualGL binary packages. One of my hot projects is to overhaul the VGL build system using CMake (seeking funding for that project), and as soon as that happens, I can generate vglserver_config at build time and populate it with whatever install prefix the user selects.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Checked in a patch to CVS head which should hopefully address this problem. vglserver_config now looks for vglgenkey in the same directory as itself and will modify the GDM startup file to invoke vglgenkey using its full pathname. That should allow vglserver_config to work properly regardless of whether the vglgenkey directory is in the PATH. Also modified the default 'make install' prefix to /opt/VirtualGL, to more closely mimic the official binary packages.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That will also solve another issue I was going to mention - when connecting with the "-s" option, vglconnect looks for vgllogin in that location (/opt/VirtualGL/bin) while the default make install path is (was) /usr/local.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ugh. Yeah, that's one I may not be able to fix. The client doesn't have any knowledge of where things are on the server, so it has to assume that they're located in one standard location (/opt/VirtualGL.) I can make some of VirtualGL's functionality work from an arbitrary directory, but in order to make the whole system work, it really needs to be in /opt/VirtualGL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would an environment variable be a possible solution? Say VGL_REMOTE_PATH or VGL_LOGIN or something, which, if not set, would otherwise default to "/opt/VirtualGL".
I am facing the same problem as speckins. I am using ubuntu 10.10 with NVIDIA GTX 480.
1) sudo service gdm stop
2) sudo /opt/VirtualGL/bin/vglserver_config
3)sudo service gdm start
4)xdpyinfo -display :0 //unable to open :0
First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is now able to start. I tried the solution provided by speckins but didn't understand. So I might be wrong in doing what he said.
I am sorry in the earlier post it should be "First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is NOT able to start"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doubtful it's the same problem, since you can note from the posts above that his issue was related to the fact that he was installing VirtualGL in a non-standard directory, and we fixed that.
Your procedure above would never work if you answered "yes" to enabling vglusers access when you ran vglserver_config. If that was the case, then you would have needed to run 'xauth merge /etc/opt/VirtualGL/vgl_xauth_key' prior to testing access using xdpyinfo. You would have also needed to log out/log back in if your account was just added to the vglusers group. See the VirtualGL User's Guide, as it goes into detail about the procedure necessary to set up VirtualGL using vglserver_config. Please follow that procedure and see if it fixes your problem.
If that is not the problem, then you need to examine the GDM startup scripts as speckins did and figure out whether vglgenkey is being added to them and, if so, whether the correct path for it is being specified.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
VirtualGL is only working remotely when the same user is logged on to X locally. /etc/opt/VirtualGL/vgl_auth_key does not exist. Video card is nVidia GeForce GTX470. OS is Linux/amd64.
Stopped gdm.
Ran vglserver_config (Y/Y/n).
Restarted gdm.
VGL doesn't work.
Stopped gdm.
Ran vglserver_config (n/n/n).
Restarted gdm.
VGL doesn't work.
Stopped gdm.
Ran vglserver_config (Y/Y/n).
Deleted /etc/modprobe.d/virtualgl.conf and modified existing nvidia.conf instead.
Restarted gdm.
VGL doesn't work.
- Verified 750 permissions on /etc/opt/VirtualGL/
- Verified 660 permissions + vglusers group for Section DRI in xorg.conf
- Verified 660 permissions for root:vglusers on /dev/nvidia*
- Verified user is in vglusers group
- Verified X is running on :0
Here are the errors I get (after vglconnect'ing):
~ $ vglrun +v glxgears
NOTICE: Automatically setting VGL_CLIENT environment variable to
172.20.77.164, the IP address of your SSh client.
NOTICE: Replacing dlopen("/lib/libdl.so.2") with dlopen("libdlfaker.so")
Shared memory segment ID for vglconfig: 51249154
Opening local display :0
No protocol specified
ERROR: Could not open display :0.
~ $ glxinfo -display :0
No protocol specified
Error: unable to open display :0
What distribution and version is your OS?
Gentoo Linux 2.6.37 x86_64
Oh, also VirtualGL 2.2 w/ libjpeg-turbo 1.0.90 compiled from sources w/ gcc 4.5.2 and running xorg-server 1.9.2.
I think it might be related to xauth. The /etc/opt/VirtualGL/vgl_xauth_key file does not exist/is not created, and I get the following in Xorg.0.log when I try to "vglrun glxgears" (X is running with "-audit 4"):
~ $ tail -n0 -f /var/log/Xorg.0.log
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 rejected from local host ( uid=1001 gid=1002 pid=3010 )
AUDIT: Tue Jan 18 09:27:27 2011: 2782: client 4 disconnected
1002 is the user's group, not vglusers (1001).
~ $ ps aux | grep X
root 9701 0.1 0.0 143600 33324 tty8 Ss+ 11:23 0:01 /usr/bin/X :0 -audit 4 -auth /var/gdm/:0.Xauth -nolisten tcp vt8
vglserver_config is supposed to modify the gdm or kdm startup files so that the "vglgenkey" script is invoked whenever the display manager starts up. If vgl_xauth_key is not being generated, that means that vglgenkey is not being invoked, which probably means that your system stores its gdm config files in a place that vglserver_config doesn't know about. The GDM startup script is usually called ":0" or "Default" - some systems have both, in which case one usually invokes the other. Most systems also have a file called "Xsetup" as well. Sometimes, :0 or Default are just symlinks to Xsetup, but other times they are different files. If you could examine your system and verify the locations of :0, Default, and Xsetup under /etc, that will help me determine whether vglserver_config knows about those locations. Since I've never tested Gentoo, it's possible that it doesn't.
Ah ha! Got it. vglgenkey was in the gdm Init/Default script, but it wasn't in the $PATH (if there even is one). I just needed to "absolutize" it - /usr/local/bin/vglgenkey.
The gdm startup script is /etc/X11/gdm/Init/Default in Gentoo. There are no :0 or Xsetup files under /etc. I'd gone through the config script and confirmed that it had done what it's supposed to do. The nvidia module config file was /etc/modprobe.d/nvidia.conf rather than just nvidia, so I altered it to match virtualgl.conf and deleted virtualgl.conf.
Thanks!
Ah, yes, vglserver_config on Linux does assume that vglgenkey is in the PATH, because vglgenkey is installed under /usr/bin in the VirtualGL binary packages. One of my hot projects is to overhaul the VGL build system using CMake (seeking funding for that project), and as soon as that happens, I can generate vglserver_config at build time and populate it with whatever install prefix the user selects.
Checked in a patch to CVS head which should hopefully address this problem. vglserver_config now looks for vglgenkey in the same directory as itself and will modify the GDM startup file to invoke vglgenkey using its full pathname. That should allow vglserver_config to work properly regardless of whether the vglgenkey directory is in the PATH. Also modified the default 'make install' prefix to /opt/VirtualGL, to more closely mimic the official binary packages.
That will also solve another issue I was going to mention - when connecting with the "-s" option, vglconnect looks for vgllogin in that location (/opt/VirtualGL/bin) while the default make install path is (was) /usr/local.
Ugh. Yeah, that's one I may not be able to fix. The client doesn't have any knowledge of where things are on the server, so it has to assume that they're located in one standard location (/opt/VirtualGL.) I can make some of VirtualGL's functionality work from an arbitrary directory, but in order to make the whole system work, it really needs to be in /opt/VirtualGL.
Would an environment variable be a possible solution? Say VGL_REMOTE_PATH or VGL_LOGIN or something, which, if not set, would otherwise default to "/opt/VirtualGL".
VGL_REMOTE_PATH="/usr/local/bin" vglconnect -s hostname
Done and checked in. I used VGL_BINDIR as the variable name. You can also pass it as an argument (-b) to vglconnect.
I am facing the same problem as speckins. I am using ubuntu 10.10 with NVIDIA GTX 480.
1) sudo service gdm stop
2) sudo /opt/VirtualGL/bin/vglserver_config
3)sudo service gdm start
4)xdpyinfo -display :0 //unable to open :0
First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is now able to start. I tried the solution provided by speckins but didn't understand. So I might be wrong in doing what he said.
I did
1) sudo mv /etc/modprobe.d/nvidia-graphics-driver.conf /etc/modprobe.d/nvidia
2) sudo rm /etc/modprob.d/virtualgl.conf
Then again I tried executing above commands but the same error
I am sorry in the earlier post it should be "First I tried from my laptop dell studio 1555 it worked nicely but now I am doing from my desktop Area 51 with Ubuntu 10.10 and NVIDIA GeForce GTX 480 it is NOT able to start"
Doubtful it's the same problem, since you can note from the posts above that his issue was related to the fact that he was installing VirtualGL in a non-standard directory, and we fixed that.
Your procedure above would never work if you answered "yes" to enabling vglusers access when you ran vglserver_config. If that was the case, then you would have needed to run 'xauth merge /etc/opt/VirtualGL/vgl_xauth_key' prior to testing access using xdpyinfo. You would have also needed to log out/log back in if your account was just added to the vglusers group. See the VirtualGL User's Guide, as it goes into detail about the procedure necessary to set up VirtualGL using vglserver_config. Please follow that procedure and see if it fixes your problem.
If that is not the problem, then you need to examine the GDM startup scripts as speckins did and figure out whether vglgenkey is being added to them and, if so, whether the correct path for it is being specified.