cleaning residues of old nvidia installation

if i want to use nouveau driver .
then
i uninstall nvidia 340.365
then
i restart pc
then
i can’t open a kde sesssion
then
i open an icewm session
then
i launch dolphin or firefox
then
it fails because firefox or dolphin wants to use a nvidia file <prefix>331.49<suffix> somewhere in /usr/ which does not exist (i checked this) and this file is about a very old version of nvidia driver .

this old version was installed in the past with dkms technology . i uninstalled it but it’s clear it remains some residues .
i deleted in /etc/ and /usr/ all files named with <prefix>nvidia<suffix> .

i assume firefox or dolphin uses links which point to file <prefix>331.49<suffix> .

how to uninstall residue of 331.49 nvidia driver ?
how to search such links pointing to <prefix>331.49<suffix> ?

thanks

If you installed the driver via the .run installer, you should be able to completely uninstall it via “sudo nvidia-installer --uninstall”.
If that doesn’t exist (likely if you installed other driver versions in the meantime), download the 331.49 .run installer again and run “sudo NVIDIA-Linux-x86_64-331.49.run --uninstall”.

If that still leaves behind stuff, maybe try to search for files containing “331.49” in the filename?

sudo find / -name *331.49*

And this should search for symlinks pointing to something with “331.49” in the name:

sudo find / -lname *331.49*

From “man find”:

      -lname pattern
              File  is a symbolic link whose contents match shell pattern pat-
              tern.  The metacharacters do not treat `/' or `.' specially.  If
              the  -L  option  or  the  -follow option is in effect, this test
              returns false unless the symbolic link is broken.

But I suppose they should be in /usr/lib64/xorg/modules/ or /usr/lib64/ (for libGL) somewhere.
Have a look at the directories with “ls -l /usr/lib64/” e.g. dangling symlinks should be displayed in red.

What exact message do you get as error?
This should narrow the search…

success

i executed NVIDIA-Linux-x86_64-331.49.run --uninstall

i chose not to restore the x conf file (this the default setting) .

now i can run firefox , dolphin with icewm and i can open a kde session .

i don’t konw if it is a pb in the nvidia installer log http://paste.opensuse.org/5417883
i found this :

ERROR: File ‘/usr/lib64/xorg/modules/extensions/libglx.so’ is not a symbolic link.

-> Uninstalling NVIDIA Accelerated Graphics Driver for Linux-x86_64 (1.0-33149 (331.49)):
-> Unable to restore symbolic link /usr/lib/libGL.so.1.2 -> libGL.so.1.2.0 (File exists).
-> Unable to restore symbolic link /usr/lib64/libGL.so.1.2 -> libGL.so.1.2.0 (File exists).

the errror messages for firefox and dolphin was :

@linux-b4lz:~> firefox
XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
libnvidia-tls.so.331.49: cannot open shared object file: No such file or directory
Couldn’t load XPCOM.
@linux-b4lz:~>

@linux-b4lz:~> dolphin
dolphin: error while loading shared libraries: libnvidia-tls.so.331.49: cannot open shared object file: No such file or directory
@linux-b4lz:~>

thank you very much

Upto and including 13.1 /usr/lib64/xorg/modules/extensions/libglx.so is Xorg’s libglx.so, and no symlink. This is normal and how it should be.
The nvidia .run installer replaces it with a symlink to its own libglx though, that’s the reason why you have to reinstall the driver after an update to xorg-x11-server if you installed it that way. (the nvidia rpm packages install the nvidia libglx to a different location, so avoid this problem)

-> Uninstalling NVIDIA Accelerated Graphics Driver for Linux-x86_64 (1.0-33149 (331.49)):
-> Unable to restore symbolic link /usr/lib/libGL.so.1.2 -> libGL.so.1.2.0 (File exists).
-> Unable to restore symbolic link /usr/lib64/libGL.so.1.2 -> libGL.so.1.2.0 (File exists).

In this case the same applies as above. The nvidia driver replaces Mesa’s libGL with its own version. As you hopefully have reinstalled Mesa-libGL1 upto now, it cannot restore that, and doesn’t need to anyway.

But better check that your libGL is indeed correct:

ls -l /usr/lib/libGL* /usr/lib64/libGL*

Although this shouldn’t matter as long as you use the nvidia driver.

Again, this fact causes the driver to break whenever you install an update to Mesa-libGL1, and also this is prevented by the nvidia rpm packages by installing the files to a different location.

the errror messages for firefox and dolphin was :

@linux-b4lz:~> firefox
XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so:
libnvidia-tls.so.331.49: cannot open shared object file: No such file or directory
Couldn’t load XPCOM.
@linux-b4lz:~>

@linux-b4lz:~> dolphin
dolphin: error while loading shared libraries: libnvidia-tls.so.331.49: cannot open shared object file: No such file or directory
@linux-b4lz:~>

Ok, so this was about libnvidia-tls.so.
Probably you still have/had nvidia’s 331.49 libglx somehow? I think this is what needs libnvidia-tls.so.
What does the following say? (no output means that everything’s ok)

rpm -V xorg-x11-server Mesa-libGL1

i have just reintsalled nvidia 340.65 to see if there is no pb .

anyway here is


linux-b4lz:~ # ls -l /usr/lib/libGL* /usr/lib64/libGL*
lrwxrwxrwx 1 root root     14 Dec 31 12:18 /usr/lib/libGL.so.1 -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Dec 28 21:16 /usr/lib/libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 361980 Nov 28  2013 /usr/lib/libGL.so.1.2.0
lrwxrwxrwx 1 root root     15 Dec 28 21:30 /usr/lib/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 550668 Sep 28  2013 /usr/lib/libGLU.so.1.3.1
lrwxrwxrwx 1 root root     14 Dec 31 11:37 /usr/lib64/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Dec 31 11:37 /usr/lib64/libGL.so.1 -> libGL.so.1.2.0
lrwxrwxrwx 1 root root     14 Dec 28 21:15 /usr/lib64/libGL.so.1.2 -> libGL.so.1.2.0
-rwxr-xr-x 1 root root 384976 Nov 28  2013 /usr/lib64/libGL.so.1.2.0
lrwxrwxrwx 1 root root     18 Dec 28 21:24 /usr/lib64/libGLESv2.so.2 -> libGLESv2.so.2.0.0
-rwxr-xr-x 1 root root  30568 Nov 28  2013 /usr/lib64/libGLESv2.so.2.0.0
lrwxrwxrwx 1 root root     16 Dec 28 21:28 /usr/lib64/libGLEW.so.1.9 -> libGLEW.so.1.9.0
-rwxr-xr-x 1 root root 546928 Sep 28  2013 /usr/lib64/libGLEW.so.1.9.0
lrwxrwxrwx 1 root root     18 Dec 28 21:28 /usr/lib64/libGLEWmx.so.1.9 -> libGLEWmx.so.1.9.0
-rwxr-xr-x 1 root root 489576 Sep 28  2013 /usr/lib64/libGLEWmx.so.1.9.0
lrwxrwxrwx 1 root root     15 Jun 23  2014 /usr/lib64/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root     15 Dec 28 21:29 /usr/lib64/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 518952 Sep 28  2013 /usr/lib64/libGLU.so.1.3.1
linux-b4lz:~ # rpm -V xorg-x11-server Mesa-libGL1
S.5....T.    /usr/lib64/xorg/modules/extensions/libglx.so
linux-b4lz:~ # 


after installing nvidia 340.65 i get this :

  • first startup -> text console with login pormpt
  • second startup -> text console with login prompt
  • third startup with adding nomodeset -> kdm template
  • fourth startup without adding nomodeset -> kdm template and opened kde session with success

my conclusion :

  • it remains an installation pb . perhaps it remains a bug in the process when installing nvidia packets .
  • it’s strange we must add nomodeset one time and after no need to add nomodeset

This is probably still nvidia’s 331.49 version.
Reinstall xorg-x11-server:

sudo zypper in -f xorg-x11-server

my conclusion :

  • it remains an installation pb . perhaps it remains a bug in the process when installing nvidia packets .
  • it’s strange we must add nomodeset one time and after no need to add nomodeset

I never had such a problem here.
But then, I never installed the driver in different versions from 3 (or more) different places either (official nvidia packages, .run installer, a package from the home:Knurpht repo)… :wink:

If NO_KMS_IN_INITRD=“yes” (as set by the nvidia packages, and again you have to run mkinitrd afterwards if you change that manually) and nvidia-uvm-kmp-desktop is installed, it always worked fine here on first boot after installation, even on 13.1.
If one of those conditions were not met, the driver failed to start on first boot after installation/update. But AIUI there’s no way to fix that in the nvidia packages without breaking CUDA support again.

PS: You can just keep “nomodeset” in the boot options as long as you use the nvidia driver (although it should not be necessary). This basically does the same as NO_KMS_IN_INITRD but is even more strict, as it completely prevents nouveau from being loaded on boot (NO_KMS_IN_INITRD only does not add it to the initrd so it shouldn’t be found at early boot).
Then you shouldn’t have a problem anymore in the future in any case.
If you do want to switch to nouveau (or any other KMS driver, like radeon or intel), you’d have to remove it of course.

i install again xorg server

The following package is going to be reinstalled:
xorg-x11-server

1 package to reinstall.
Overall download size: 1.4 MiB. No additional space will be used or freed after the operation.
Continue? [y/n/? shows all options] (y):
Retrieving package xorg-x11-server-7.6_1.14.3.901-12.1.x86_64 (1/1), 1.4 MiB ( 5.2 MiB unpacked)
Retrieving: xorg-x11-server-7.6_1.14.3.901-12.1.x86_64.rpm …[done (559.7 KiB/s)]
(1/1) Installing: xorg-x11-server-7.6_1.14.3.901-12.1 …[done]
Additional rpm output:
Updating /etc/sysconfig/displaymanager…

I never installed the driver in different versions from 3 (or more) different places either (official nvidia packages, .run installer, a package from the home:Knurpht repo

i never installed nvidia driver using .run
i assume this is the installation of the packet from knurpht which does this .

i only used these methods :

  • one click
  • knurpht
  • manualy select the nvidia packet as you learned to me

after installing nvidia packets before to restart i always check nvidia conf files in modprobe.d and no_kms_in_initrd = yes
and i must add nomodeset .

Right. AFAIR that package just downloaded the .run driver and ran it.
And it is a fact that you still had files from that all over your hard disk.

after installing nvidia packets before to restart i always check nvidia conf files in modprobe.d and no_kms_in_initrd = yes
and i must add nomodeset .

Add “nomodeset” in YaST->Boot Loader->Boot Loader Options, and you should never have a problem any more.
I have no idea what’s still wrong on your system.