|
TIP - re-enable GLX when broken after an upgrade (NVIDIA/Debian).
The NVIDIA driver replaces libraries from at least two packages so when these packages are upgraded, they reinstate these libraries and break GLX support. Below is how to re-enable the support without having to re-install the driver.
xserver-xorg-core is a basic package that breaks GLX from the NVIDIA driver when upgraded. To re-enable it: :: Code :: # cd /usr/lib/xorg/modules/extensions/
# rm libglx.so # ln -s libglx.so.290.10 libglx.so (290.10 is the NVIDIA driver version used) libgl1-mesa-glx is a package that isn't needed by everyone but also breaks GLX support when upgraded. To re-enable it: :: Code :: # rm /usr/lib/i386-linux-gnu/libGL.so.1*In my system I have libgl1-mesa-glx because google-talkplugin depends on it. Since the NVIDIA driver takes care of the libGL.so library I suppose one can just keep libgl1-mesa-glx on hold so it won't give more trouble when upgraded. Back to top |
|
this looks like it could be added as a post du fix, without a huge amount of problems.
Back to top |
|
Yes, I think it would be useful for smxi/NVIDIA users. Better than reinstalling the driver for such a simple thing.
Back to top |
|
Check this logic:
If driver module loaded nvidia or if driver listed in xorg.conf since you can run smxi without nvidia loading at a different runlevel, then if libglx.so is a symbolic link to an nvidia driver then post upgrade recreate it and if libGL.so.1* does not exist pre upgrade then remove it if it exists post. What does the * stand for, in other words, what values can that have, can you should them all from your system? this should not be hard to do, just set a pre du flag, smxi already does that anyway for xorg updates, this just needs to be a different one that also tells it to redo the stuff post du. Back to top |
|
libGL.so.1* from libgl1-mesa-glx are
/usr/lib/i386-linux-gnu/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so.1.2 The ones the NVIDIA driver installs are (IIRC, but the files should be listed in the driver docs) /usr/lib/libGL.la /usr/lib/libGL.so -> /usr/lib/libGL.so.1 /usr/lib/libGL.so.1 -> /usr/lib/libGL.so.290.10 /usr/lib/libGL.so.290.10 EDIT: from /usr/share/doc/NVIDIA_GLX-1.0/html/installedcomponents.html :: Quote :: Problems will arise if applications use the wrong version of a library. This can be the case if there are either old libGL libraries or stale symlinks left lying around. If you think there may be something awry in your installation, check that the following files are in place (these are all the files of the NVIDIA Accelerated Linux Graphics Driver, as well as their symlinks):
/usr/lib/xorg/modules/drivers/nvidia_drv.so /usr/lib/xorg/modules/libwfb.so (if your X server is new enough), or /usr/lib/xorg/modules/libnvidia-wfb.so and /usr/lib/xorg/modules/libwfb.so -> libnvidia-wfb.so /usr/lib/xorg/modules/extensions/libglx.so.x.y.z /usr/lib/xorg/modules/extensions/libglx.so -> libglx.so.x.y.z (the above may also be in /usr/lib/modules or /usr/X11R6/lib/modules) /usr/lib/libGL.so.x.y.z /usr/lib/libGL.so.x -> libGL.so.x.y.z /usr/lib/libGL.so -> libGL.so.x /usr/lib/libnvidia-glcore.so.x.y.z /usr/lib/libcuda.so.x.y.z /usr/lib/libcuda.so -> libcuda.so.x.y.z /lib/modules/`uname -r`/video/nvidia.{o,ko}, or /lib/modules/`uname -r`/kernel/drivers/video/nvidia.{o,ko} If there are other libraries whose "soname" conflicts with that of the NVIDIA libraries, ldconfig may create the wrong symlinks. It is recommended that you manually remove or rename conflicting libraries (be sure to rename clashing libraries to something that ldconfig will not look at -- we have found that prepending "XXX" to a library name generally does the trick), rerun 'ldconfig', and check that the correct symlinks were made. An example of a library that often creates conflicts is "/usr/X11R6/lib/libGL.so*". Back to top |
|
All times are GMT - 8 Hours |