ViurtualGL 3.1.2 + Debian 12.9 + Nvidia driver 535.216
Alf Nilsson
I am at my wits end.
I have a Debian 12 that is running VirtualGL as a server.
I have a debian 12 that is running VirtualGL as a client (Only installed, not configured)
On the server:
I erased my xorg.conf and ran first : nvidia-xconfig
Then ran :
service gdm3 stop
/opt/VirtualGL/bin/vglserver_config option 1, Y to everthing.
service gdm3 start
And then just for safeteys sake I did a reboot.
SSH to server from client with -X
Tested according to documentation, section 6.2.1
Everything looks great.
Now....I want to test vglrun
$ vglrun xclock
[VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to
[VGL] 100.101.0.58, the IP address of your SSH client.
[VGL] ERROR: VirtualGL attempted to load the real
[VGL] xcb_poll_for_event function and got the fake one instead.
[VGL] Something is terribly wrong. Aborting before chaos ensues.
And here I am stuck.
I've tried setting the full path to libGL.so in LD_PRELOAD, tried setting the path with LD_LIBRARY_PATH.
Then out of desperation, tried using VGL_PRELOAD and VGL_LIBRARY_PATH.
Still the same error message.
Whatever I do, I still end up with the same error that it takes the "fake" libGL.so.
Note that nvidia is using the follwing libGL.so:
$ ls -l /usr/lib/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root 48 3 jan 2023 /usr/lib/x86_64-linux-gnu/libGL.so -> /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
$ ls -l /etc/alternatives/glx--libGL.so-x86_64-linux-gnu
lrwxrwxrwx 1 root root 48 3 jan 2023 /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
So can anyone give an idea what I should check next?
Regards,
Alf Nilsson
DRC
My guess is that a necessary package is missing. Make sure that the libxcb and libxcb-keysyms packages are installed.
Alf Nilsson --
You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to virtualgl-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/virtualgl-users/29deead2-b908-4b35-8877-81289c6a95d3n%40googlegroups.com.
DRC
Never mind. I tried force-uninstalling those packages, and that makes VirtualGL fail much earlier than what you are observing. I'm not sure what's causing the issue, but I am suspicious at the fact that libGL.so points to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so. That seems wrong for an nVidia installation.
Alf Nilsson
I did a deep dive in the Nvidia driver. It does not have it's own libGL.so, it uses the mesa-diverted libGL.so, which really should be called "generic" or "base" libGL.so.
Found this after searching for why the newer Nvidia drivers do not include a libGL.so file at all.
To view this discussion visit https://groups.google.com/d/msgid/virtualgl-users/e9686610-3747-428f-8770-91a419438e80%40virtualgl.org.
DRC
For posterity, we discovered after running 'strace vglrun xclock' that another interposer (/usr/local/lib/AppProtection/libAppProtection.so) was being inserted into the preload chain. Apparently that interposer is installed by the Citrix ICA client and referenced in /etc/ld.so.preload. Since LD_PRELOAD takes precedence over /etc/ld.so.preload, VirtualGL was inserted into the preload chain ahead of libAppProtection.so, so VirtualGL's attempts to load XCB functions from the "real" libxcb were intercepted by libAppProtection.so instead. The user uninstalled the Citrix client, and the problem went away. However, since app protection is not required in order to use the ICA client, another workaround would have been to simply remove /usr/local/lib/AppProtection/libAppProtection.so from /etc/ld.so.preload.
DRC
To view this discussion visit https://groups.google.com/d/msgid/virtualgl-users/CAHpKqnmoLQLozxomLXV7oR_0Ptq2iezuoHX2tj1UdWJNFBiY4g%40mail.gmail.com.