Nvidia repo drivers issues

English Hardware
1

I recently decided to once again install my favourite linux distro on my new PC (13.2 , last one was 12.3).
I must note that installation did not go smoothly, as several packages failed to install, leaving me with a completely broken KDE desktop. The first pack of zypper updates though apparently fixed everything (?). Also note that I’m still learning so bear with me if I’m ignorant / wrong / didn’t look properly.
Installing the latest nvidia drivers (346.35) through the repos doesn’t work for me unfortunately.
(that would be the following 5 packages, correct me if I’m wrong: x11-video-nvidiaG04, nvidia-glG04, nvidia-computeG04, nvidia-gfxG04-kmp-desktop, nvidia-uvm-gfxG04-kmp-desktop)

After rebooting, the driver appears installed, but I get no 3d capabilities.
Basic google search troubleshooting led me to the following:

glxinfo output > xlib: extension “GLX” missing on display 0 (something like that, not 100% accurate)

here are two relevant snipets on the xorg.0.log


    16.736] (II) LoadModule: "glx"
    16.757] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so
    17.217] (II) Module glx: vendor="X.Org Foundation"
    17.217]    compiled for 1.16.1, module version = 1.0.0



    17.220] (**) NVIDIA(0): Enabling 2D acceleration
    17.220] (EE) NVIDIA(0): Failed to initialize the GLX module; please check in your X
    17.220] (EE) NVIDIA(0):     log file that the GLX module has been loaded in your X
    17.220] (EE) NVIDIA(0):     server, and that the module is the NVIDIA GLX module.  If
    17.220] (EE) NVIDIA(0):     you continue to encounter problems, Please try
    17.220] (EE) NVIDIA(0):     reinstalling the NVIDIA driver.

I also did try to avoid conflicts with nomodeset, explicitely blacklisting nouveau in modprobe, and most suggestions I could find in google, with no luck.

Searching some more, the package “nvidia-glG04-346.35-4.1.x86_64.rpm” does contain a file “nvidia-libglx.so”. Shouldn’t it automatically replace the above default glx module? Is that the cause of my problems?

After many failed reinstalls trying to get it working, I currently have uninstalled the repo drivers, installed the binary from nvidia site, and everything works perfectly. However, I realise the repository solution is infinitely more convenient, and I would greatly appreciate your help in order to get it working. Thank you for any assistance.

2

First of all, which graphics card do you have?
The latest G04 drivers do not support older cards <GTX420.

Although that doesn’t seem to be your problem anyway.

(that would be the following 5 packages, correct me if I’m wrong: x11-video-nvidiaG04, nvidia-glG04, nvidia-computeG04, nvidia-gfxG04-kmp-desktop, nvidia-uvm-gfxG04-kmp-desktop)

Yes, if you use kernel-desktop.

Searching some more, the package “nvidia-glG04-346.35-4.1.x86_64.rpm” does contain a file “nvidia-libglx.so”. Shouldn’t it automatically replace the above default glx module? Is that the cause of my problems?

Yes.
According to your Xorg log, the normal libglx included in xorg-x11-server is still loaded, not nvidia’s.

In 13.2 libglx is not replaced, but it is only a symlink that points to the one you want to use (either xorg-libglx.so or nvidia-libglx.so).
Apparently this symlink pointed to the wrong one in your case. You can change it with “update-alternatives”, but this should be done automatically when you install the nvidia driver packages.

So I would suggest to remove the manually installed driver again, and retry with the packages.
If the problem re-occurs, ask back and I’ll tell you how to correctly change that symlink…

3

Yes, I have a GTX760, so it is supported, right? I noticed something strange though. Both the 1-click-install and yast after adding the nvidia repo suggest I install the G03 packages. Is that simply out of date, a general safe approach, or could the new drivers have issues?

Did the uninstall. During the process, nvidia prompted me to revert xorg.conf to the one before the installation, so I naturally accepted. Is there any chance of misconfiguration in the backup that caused my issues? (I have otherwise never touched xorg.conf)
Right after rebooting, I installed the G04 packages and rebooted once more. No luck. The log lines show the same issue.
One tiny difference though, kwin compositing had somehow changed to xrender, with quite a few desktop effects active, giving me a false sense of success before mercilessly crushing my hopes… :cry:

Another, maybe relevant piece of information I had overlooked and omitted in my original post: In my first attempts to get the repo drivers working, I installed and deinstalled the packages more than once. During the latter, the yast gui logged these peculiar lines:


Deleting nvidia-glG04
Additional rpm output:
update-alternatives: warning: alternative /usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so (part of link group libglx.so) doesn't exist; removing from list of alternatives

I am not familiar with update-alternatives, so I don’t really understand what’s going on, but that doesn’t look normal, does it? Was the object supposed to be copied to that directory during installation, but failed?

4

Yes.

I noticed something strange though. Both the 1-click-install and yast after adding the nvidia repo suggest I install the G03 packages. Is that simply out of date, a general safe approach, or could the new drivers have issues?

That page is outdated.
The G04 drivers have been added to the repo just recently, and apparently nobody updated that wiki page yet.

Did the uninstall. During the process, nvidia prompted me to revert xorg.conf to the one before the installation, so I naturally accepted. Is there any chance of misconfiguration in the backup that caused my issues? (I have otherwise never touched xorg.conf)

Normally you shouldn’t need any xorg.conf at all. The nvidia is automatically used if installed since years (on openSUSE at least).
And the openSUSE packages don’t even create one.

The .run installer might create one, but you can just safely delete it.

But I don’t think an xorg.conf could have caused your problem, at least not as you described it.

Right after rebooting, I installed the G04 packages and rebooted once more. No luck. The log lines show the same issue.
One tiny difference though, kwin compositing had somehow changed to xrender, with quite a few desktop effects active, giving me a false sense of success before mercilessly crushing my hopes… :cry:

Yeah.
KDE tries to adapt in such a case, in difference to GNOME which requires OpenGL and would just display a “Oh no, something has gone wrong” dialog otherwise… :wink:

You might have to set back KDE’s settings to OpenGL and Raster manually afterwards (when the nvidia driver is working correctly) though.

Another, maybe relevant piece of information I had overlooked and omitted in my original post: In my first attempts to get the repo drivers working, I installed and deinstalled the packages more than once. During the latter, the yast gui logged these peculiar lines:

Deleting nvidia-glG04
Additional rpm output:
update-alternatives: warning: alternative /usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so (part of link group libglx.so) doesn’t exist; removing from list of alternatives

I am not familiar with update-alternatives, so I don’t really understand what’s going on, but that doesn’t look normal, does it? Was the object supposed to be copied to that directory during installation, but failed?

Well, this might really be the problem.
No idea why it says " /usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so" though, it should be /usr/lib64/xorg/modules/extensions/nvidia-libglx.so I think?

Can you please post the output of:

update-alternatives --display libglx.so

And do you have a directory /usr/lib64/xorg/modules/extensions/nvidia? Try to remove it if it’s there, but it shouldn’t.

5 

libglx.so - manual mode
  link currently points to /usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so
/usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so - priority 100
/usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so - priority 50
Current 'best' version is '/usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so'.

OK, I don’t really grasp anything, that “manual mode” bothers me, as I did nothing manually :?

For (mostly my) reference, the structure apprears to be the following:
/usr/lib64/xorg/modules/extensions/ containts a link libglx.so -> /etc/alternatives/libglx.so
It also has the following two subdirectories
/usr/lib64/xorg/modules/extensions/nvidia/
/usr/lib64/xorg/modules/extensions/xorg/
which both contain the actual objects “nvidia-libglx.so” and “xorg-libglx.so” respectively.
what I don’t understand is how update-alternatives has a highest priority “best” option of an existing shared library, and yet overrides it with the second best.

/etc/alternatives/libglx.so is indeed a link pointing to “xorg-libglx.so” , as indicated by your command.

I presume the “manual” is key here?

Even though I have no idea how update-alternatives works, the logical structure seems solid from an outsider perspective.
How do you suggest I proceed?
Would deleting the nvidia (and xorg?) subdirectory involve moving the object(s) to the parent folder? And how would I reprogram update-alternatives to point to the new locations?

I hope we are at a point where things get less confusing!
As you hinted earlier, I have a hunch that a simple (manual?) change to that symlink will suffice, but I’m afraid I will break things.

6

Do not delete the xorg directory You can rename the /etc/X11/xorg.conf file leave the xorg.conf.d directory

For best results always uninstall before trying another driver. Installing one flavor on to another can leave odd files and links laying around.

7

Yeah. As indicated (and set by the nvidia driver packages) the nvidia libglx has a higher priority, and should be selected by default.

Set it back to “auto”, and the driver should work I suppose.

sudo update-alternatives --auto libglx.so

No idea why this would be set to “manual” on your system. It shouldn’t be by default.

For (mostly my) reference, the structure apprears to be the following:
/usr/lib64/xorg/modules/extensions/ containts a link libglx.so -> /etc/alternatives/libglx.so
It also has the following two subdirectories
/usr/lib64/xorg/modules/extensions/nvidia/
/usr/lib64/xorg/modules/extensions/xorg/
which both contain the actual objects “nvidia-libglx.so” and “xorg-libglx.so” respectively.
what I don’t understand is how update-alternatives has a highest priority “best” option of an existing shared library, and yet overrides it with the second best.

/etc/alternatives/libglx.so is indeed a link pointing to “xorg-libglx.so” , as indicated by your command.

I presume the “manual” is key here?

Yes.
With this you could force the use of Xorg’s libglx even while nvidia is installed (if you wanted to temporarily switch back to nouveau e.g.).

Even though I have no idea how update-alternatives works, the logical structure seems solid from an outsider perspective.
How do you suggest I proceed?
Would deleting the nvidia (and xorg?) subdirectory involve moving the object(s) to the parent folder? And how would I reprogram update-alternatives to point to the new locations?

As gogalthorp already mentioned, you should not delete anything.

/usr/lib64/xorg/modules/extensions/xorg/xorg-libglx.so is in fact the correct location (I confused that, sorry), so I guess /usr/lib64/xorg/modules/extensions/nvidia/nvidia-libglx.so is ok too (I don’t have the nvidia driver installed here so cannot check, but you wrote yourself that this file exists).

I hope we are at a point where things get less confusing!
As you hinted earlier, I have a hunch that a simple (manual?) change to that symlink will suffice, but I’m afraid I will break things.

It would work as well to manually set the symlink, yes.
But you would probably get a problem again after some update (nvidia or xorg-x11-server), because update-alternatives (which is called by the packages’ scripts) would set it back I suppose.

8

Thank you very very much, the command

sudo update-alternatives --auto libglx.so

did the trick, and everything works now!

This bizzare manual setting still puzzles me, as it is a pretty straightforward process, and I did that right after the first updates. Oh well.

9

Hello,

something mysterious happened to my attempt to update to 13.2:
I did zypper dup with 13.2 repos including nvidia’s.
My method is to clone my working partition into a empty partition with yast live-install, boot from that cloned partition, and then do the zypper dup.
has worked for me since 10.3 or so…

I had the manual nvidia blob installed, which I deinstalled before doing the dup.

I have a Nvidia 450 gts fanless card.

The zypper dup went well. G04 rpm were installed and everything is fine.

However, on the first occassion I wanted to install some piece of software with yast2, yast tells me there’s a lot of other stuff needing to be installed,
including G03 drivers AND nouveau drivers.
I didnot notice, hit enter, and after the first reboot of course no X desktop.

I tried to fix this mess, but that didnt work. In the end, (I need my desktop, havent got time for this kind of ****)
I had to install with the nvidia blob again, bypassing package management. Which as usual, did work.
I also had to ban / blacklist nouveau and nvidia G03 in yast, or yast would corrupt my system again with 2 different extra driver sets (G03 and nouveau)

Don’t get me wrong, I would love to have the nvidia repo working, turn automatic updates on and get rid of that nouveau bs that maybe works, but in terms of (gaming) performance is still nowhere close to the proprietary nvidia stuff…

Has anyone any clues why my yast tries to install Nouveau AND nvidia G03 AND nvidia G04 ???:(:sarcastic:

much appreciated,

rensg

10

Probably because all of them support your graphics card?

Installing nouveau is ok and does not cause any problems, even when using the nvidia driver. (actually only the kernel module can cause problems, and you cannot uninstall that anyway as it is part of the standard kernel package, but the module is blacklisted by the nvidia RPMs)

YaST should not install G03 and G04 though. And actually in 13.2 it should detect a file conflict when both are trying to be installed and report that.

I would suggest to mark x11-video-nvidiaG03 as “Taboo - Never install” in YaST, and file a bug report.

BUT: you should remove the nvidia blob before you install the driver RPMs. If you want to keep the nvidia blob, you should disable/remove the nvidia repo, then YaST wouldn’t try to install the RPMs either… :wink:

PS: If you use the nvidia installer, you have to blacklist nouveau (the kernel module) yourself (uninstalling xf86-video-nouveau is not sufficient), or add “nomodeset” to the boot options.

11

perhaps they do both, perhaps not. ( support my card)
I do not think yast should want to install both, makes no sense.
I did taboo the g03 / nouveau and blacklisted the mods I have the G04 still according to yast, but actually I installed the blob.
No time to fix it right now, work needs to get done…

I will try find sometime this weekend to see if I can reproduce the whole thing with a repeat upgrade action on my old 12.3 install, since I have 13.2 working
now…

I’m a bit busy right now, cannot afford to loose my desktop at this moment…

thanks for the response, I will post back here :slight_smile:

12

Yes, they do.

I do not think yast should want to install both, makes no sense.

Yes, it should not. It makes no sense, and even breaks the installation.

But again, YaST should warn you about a file conflict even if you try to install them both manually.

I did taboo the g03 / nouveau and blacklisted the mods I have the G04 still according to yast, but actually I installed the blob.

You should never install the driver in more than one way (i.e. the RPMs and nvidia’s installer). This will give you problems/break your system sooner or later.

And as I mentioned already, if you install the driver via nvidia’s installer, you’d better remove or disable the nvidia repo.
But be prepared to re-install the driver after any update to Mesa-libGL1 or the Kernel.

Btw, if the driver is not working for some reason, you should still get a graphical system by selecting “Recovery Mode” (the 2nd entry) in “Advanced Options” in the boot menu.

13

I have a Geforce GTX 650 card, can someone tell me which one of these new drivers is compatible if any with my older card? I let the regular updates install, the Go4 and it borked my system to the point I had to do a total reinstall of openSUSE, it was not booting up. It would just hang with before the WM started up. I’m using Leap and KDE. Right now I tried running my old driver from nvidia’s website but it said it could not install because of Nouveau. So I probably installed another blob that is going to bork me again. It said the install script worked however the nouveau driver has to be removed first.

As you can tell from my post I’m not to well versed in Suse. In other distros I just opened up a control panel and installed my nvidia driver, but the older driver isn’t even coming up as a choice in YaST, just the 2 new ones. So I am presuming one of them is compatible with my card??

I don’t know what to do, I’m not going to make any more tweaks to get my system up to the way I had it until I get this problem figured out, the nouveau drivers stink, I need nvidia drivers, this is ridiculous. It came up in an update, the very first time after running Leap since it came out that it gave me a driver or any update for that matter that wasnt compatible, with any of my hardware. First update that ever borked my system for that matter…

Luckily I use a different drive for my /Home partition so I never lose files, just have to replace apps, and tweak settings. So it’s not like any other distro didn’t do this to me before, I’m just surprised that Leap did it to me…

I would appreciate any help or suggestions.

Thanks

14

I have a 630 card and it does not like the GO4 either even though it is supposedly supported in GO4. I use GO3 no problem

15

GTX650 here, on oS 13.2 64-bit, still on driver version 340.65 G03 from nvidia repo, installed through YAST. Works fine, so I didn’t update it.

16

I installed G03 from YaST, and presto I have my nvidia driver back…One thing different, I may have installed the wrong G03, I have PV after my kernel number now when it boots, there seemed to be 2 different G03’s to choose from…Can someone let me know if PV is going to cause me borkness in the future??

BTW - Thank You so much for the tip!

17

Full kernel listed as 4.1.21-14-pv

18

My bad…uninstalled pv kernel, now boots into default 4.1.21-14, driver still intact…Man YaST screws me up bad…It is a powerful tool that can be so useful and so dangerous at the same time… Thank you all for the help , I got my NVIDIA driver back to what it was and I will be very careful of accepting updates from now on…

19

You need to match the driver to the kernel you use. In 13.2 and under the default installed kernel is desktop unless you change it in LEAP and above it is now called default. PV is I believe is for paravirtualization ie Xen and other VMs

20

gogalthrop, Yah I kinda got it straightened out. but now have just the one kernel installed. 4.1.21-14-default, I deleted the pv kernel through YaST. I would love to have a backup kernel ( which is usually in the advanced mode during boot time, but only the one kernel is on my system now), but not sure where to find one or how to install one. but for now I at least have the correct default kernel loading up, just got no back up kernel…It’s always god to have a back up kernel to have in case of a borked system, in the advanced choice…Any idea on how to install one or which version to even install, but I would like to keep this kernel as my default kernel that loads automatically upon boot unless I highlight down to advanced and choose the backup, which is the way my system always was, perhaps when a newer kernel gets released it will move up to default and this one will be my back up…I’m probably wrong but still trying to get this back to the way it was before NVIDIA screwed everything up on me…grrrr…