XOrg update causes crash in nvidia-settings when clicking "OpenGL/GLX Information"

English Hardware
1

I found that I wasn’t getting any openGL/GLX (3D) capabilities after XOrg updated.

Several crashes were happening on XFCE, KDE, GNOME and in all sorts of applications. Lots of segmentation faults.

On all of them, if I opened nvidia-settings and clicked on OpenGL/GLX Information in the left menu, the application crashed.

This seems to only be a problem on the computers I installed the proprietary NVIDIA driver “the hard way”. Those that had NVIDIA installed via the repo way were not affected.

XOrg updates remove a symlink that the NVIDIA manual install method creates. So Xorg tries to load it’s .so file instead of NVIDIA’s.

I just had to replace the symlink:


cd /usr/lib64/xorg/modules/extensions/
# Do next commands as root (ie, sudo)
mv libglx.so libglx.so.orig
ln -s libglx.so.304.60 libglx.so

Note that the version number that I used “304.60” will need to be whatever version of driver you are using. Once done, restart x.

This needs to be redone every time there is an XOrg update.

2

The right way is to uninstall nVidia drivers before update and reinstall them after. nVidia installer saves original libraries and restores them during uninstall. If you “just replace symlink” saved libraries are not updated. If you decide to uninstall nVidia later it may happen that saved versions are no more fully compatible with new Xorg, leading to hard to diagnose problems.

RPM avoids this issue by making it possible to not install original GLX libraries in the first place.

3

Are you sure Xorg is using this module? The one nvidia installs - at least from the rpm - is in /usr/lib64/xorg/modules/updates/extensions:

$ rpm -ql x11-video-nvidiaG02 | grep libglx
/usr/lib64/xorg/modules/updates/extensions/libglx.so
/usr/lib64/xorg/modules/updates/extensions/libglx.so.304.43

and this path is searched first:

$ grep ModulePath /var/log/Xorg.0.log
 20262.214] (==) ModulePath set to "/usr/lib64/xorg/modules/updates,/usr/lib64/xorg/modules"

Thus this module is loaded and not the one in /usr/lib64/xorg/modules/extensions :

$ grep libglx.so /var/log/Xorg.0.log
 20262.218] (II) Loading /usr/lib64/xorg/modules/updates/extensions/libglx.so

And it is a symlink which points to nvidia glx module:


$ readlink /usr/lib64/xorg/modules/updates/extensions/libglx.so
libglx.so.304.43

But I know what you are talking about, as I regularly recreate the symlink under Fedora and Ubuntu, also have functions in scripts to do that. If when you install the driver manually, it puts the module in /usr/lib64/xorg/modules/extensions/, try to move it to /usr/lib64/xorg/modules/updates/extensions/ and create the symlink there.

4

As I see it the problem is with libGL.so The packaged driver installs this module and it’s pointers under /usr/X11R6/lib or lib64, the “hard way” installs it under /usr/lib or lib64, thus overwriting the original xorg libGL.so and it’s pointers. And consequently and update of xorg-x11-server will overwrite the Nvidia libGL.so in the latter case.

5

Thanks for the extra info.

@PTA, is it possible the RPM is placing the modules in a different path than the one used for the manual/hard way? I don’t have openSUSE with me right now to check if that **updates **folder exists, or its contents.

Either way, on my laptop I uninstalled and re-installed the driver the hardway, then on my desktop just did a simple update on the symlink and both are performing as expected so far.

I got my desktop effect transparencies back, 3D effects and 3D capability in various programs so it’s all normal now.

The symlink trick was what the results from searching kept telling me, so I gave it a go, and it worked.