Bug 802624

Seems to affect 02 as well. If you try rolling back, do you still get Nouveau?

Confirmed, the same situation exists with G02.

Some more information

* it's not the nouveau driver that's being loaded, since after uninstalling it I still get the same problem
* even after symlinking the driver to /lib/modules/3.4.11-2.16-desktop/weak-updates/updates I have to perform the insmod manually ; it is not loaded at startup

(In reply to comment #3)
> Some more information
> 
> * it's not the nouveau driver that's being loaded, 

Well that's what I see as loaded

Regardless if I use nvidia 02 or 03

I had the same problem today.

For some reason, Yast first installed G03 and afterwards removed G02 including the nouveau blacklist.
Therefore on reboot the nouveau kernel module was loaded which prevented the loading of the nvidia driver.

Workaround:
- Remove the driver completely with Yast
- Start Yast a second time and install your driver of choice

Now everything should work again...

(In reply to comment #5)
> I had the same problem today.
> 
> For some reason, Yast first installed G03 and afterwards removed G02 including
> the nouveau blacklist.
> Therefore on reboot the nouveau kernel module was loaded which prevented the
> loading of the nvidia driver.
> 
> Workaround:
> - Remove the driver completely with Yast
> - Start Yast a second time and install your driver of choice
> 
> Now everything should work again...

This does work.
It seemed to drag in some unnecessary crud in the process.
Something is pretty wrong IMO
This is just a workaround

(In reply to comment #6)
> It seemed to drag in some unnecessary crud in the process.

Didn't happen here, only nvidia-computeG03, x11-video-nvidiaG03 and nvidia-gfxG03-kmp-desktop got installed.
What unnecessary crud do you mean btw.? If it's gcc and its dependencies then that's needed because the kernel module is now compiled on installation.

> Something is pretty wrong IMO
> This is just a workaround

Well, AFAICT the only thing that does not work is directly switching from G02 to G03 or vice versa.
If you uninstall first and then install the other one everything works as expected. It did for me at least.

Yes, the workaround works. 

IMO though switching from G02 to G03 is a valid situation since there is a subset of chipsets they both support. And right now it's broken.

When trying to install nvidia-computeG03 and x11-video-nvidiaG03 with already installed nvidia-computeG02 and x11-video-nvidiaG02 packages this fails due to file conflicts (which is good).

Installing nvidia-gfxG03-kmp package in addition to already installed nvidia-gfxG02-kmp is possible since there can be no hard requirement to nvidia-computeG03/x11-video-nvidiaG02 (due to some customers only using the GPU for computing).

Seems you now have nvidia-gfxG03-kmp and nvidia-gfxG02-kmp installed, which results in that issue.

Could you confirm? Please add the output of 'rpm -qa|grep nvidia".

(In reply to comment #9) 
> Seems you now have nvidia-gfxG03-kmp and nvidia-gfxG02-kmp installed, which
> results in that issue.
> 
> Could you confirm? Please add the output of 'rpm -qa|grep nvidia".

$ rpm -qa | grep nvidia
nvidia-gfxG03-kmp-desktop-310.32_k3.4.6_2.10-5.1.x86_64
x11-video-nvidiaG03-310.32-5.1.x86_64
nvidia-computeG03-310.32-5.1.x86_64

I cleaned up my installation quite some time ago, but I don't recall seeing multiple driver versions installed at the same time.

> $ rpm -qa | grep nvidia
> nvidia-gfxG03-kmp-desktop-310.32_k3.4.6_2.10-5.1.x86_64
> x11-video-nvidiaG03-310.32-5.1.x86_64
> nvidia-computeG03-310.32-5.1.x86_64

And with that you still see the issue? Please check also the output of

  rpm -V $(rpm -qa | grep nvidia)

No, I don't see the issue. The manual fix from comment #5 worked for me, so I can't say what the exact state of my system was back then, just that the issue was with how the uninstall / install was handled, not with the installation procedure as such.

$ rpm -V $(rpm -qa | grep nvidia)
5S.T.....    /usr/bin/X.x11-video-nvidiaG03
...T.....    /usr/lib64/xorg/modules/updates/drivers/nvidia_drv.so

Ok. Although the workaround works, I believe the explanation is wrong. Most likely you've ended up in having the wrong kernel module installed and loaded (G03 one) and still running the G02 X driver. The file for blacklisting the nouveau module is in both packages, so this would not have been deleted by RPM.
Even if the G03 KMP package had replaced the G02 KMP. RPM installs the file from the new package and then removes the files of the old package, which are *not* part of the new package.

Anyway, what you've done has been a manual package (de)selection, i.e. removed the nvidia-gfxG02 package and installed the nvidia-gfxG03 package. *And* ignored
the other G02 packages,i.e. you didn't replace these as well. The result has been a driver messup.

Package autoselection is not affected here. There are only a few supplements
in the G03 package. And these are not part of the G02 package.

Closing as INVALID therefore. Feel free to reopen in case you manage to have
only G03 packages installed and the issue still exists.

(In reply to comment #13)
> Ok. Although the workaround works, I believe the explanation is wrong. Most
> likely you've ended up in having the wrong kernel module installed and loaded
> (G03 one) and still running the G02 X driver. The file for blacklisting the
> nouveau module is in both packages, so this would not have been deleted by RPM.

I reproduced the issue just now.
Yes, you are right, the blacklist file does not get removed. (that was a guess, sorry)

But I know now what is going wrong:
As I wrote in comment#5, YaST _first_ installs the new packages and _then_ removes the old ones afterwards.
In removing the old packages, also the link from /lib/modules/3.4.28-2.20-desktop/weak-updates/updates/nvidia.ko to /lib/modules/3.4.6-2.10-desktop/updates/nvidia.ko (where the kernel module is installed) gets removed.
Therefore the system doesn't find the nvidia kernel module any more and the nvidia driver cannot be loaded.

On a side note: When I select the X11 driver for installation, the kernel module  for kernel-default gets selected automatically although I am running kernel-desktop. I have to manually select the right kernel module.

Yeah. Seems in %postun of the old KMP the weak-update symlink to the installed kernel module gets removed. The issue is, that the %postun of the replaced KMP runs after %post of the new KMP. How to address that? No idea right now.

But then we would have run into this issue each time one just updated the KMP. But we didn't, did we?

(In reply to comment #15)
> Yeah. Seems in %postun of the old KMP the weak-update symlink to the installed
> kernel module gets removed. The issue is, that the %postun of the replaced KMP
> runs after %post of the new KMP. How to address that? No idea right now.

Since %postun is run _after_ the packaged files are removed, you could maybe check if nvidia.ko exists and only remove the link if it doesn't?
(Just an idea though, not sure if that would work...)
 
> But then we would have run into this issue each time one just updated the KMP.
> But we didn't, did we?

Well, on package updates %postun is not run, so this issue cannot happen.

(In reply to comment #16)
> (In reply to comment #15)
> > Yeah. Seems in %postun of the old KMP the weak-update symlink to the installed
> > kernel module gets removed. The issue is, that the %postun of the replaced KMP
> > runs after %post of the new KMP. How to address that? No idea right now.
> 
> Since %postun is run _after_ the packaged files are removed, you could maybe
> check if nvidia.ko exists and only remove the link if it doesn't?
> (Just an idea though, not sure if that would work...)

Well, the code, which does this is hardcoded im KMP framework. :-(

> > But then we would have run into this issue each time one just updated the KMP.
> > But we didn't, did we?
> 
> Well, on package updates %postun is not run, so this issue cannot happen.

Sure it *is* running.

(In reply to comment #17)
> Sure it *is* running.

When "updating" to the same version, %postun is not run (that's what I tried before writing this and I thought this was always the case). But yes, on update to a different version it _is_ running (after %post).
Anyway, I never had an issue during update, only when switching between G02 and G03.
So it seems /usr/lib/module-init-tools/weak-modules2 is handling the update case correctly.

But I guess in the switching case it gets confused because the filenames of the kernel modules are the same but the package names are different (nvidia-gfxG02 vs nvidia-gfxG03)...

So maybe this should be reported as bug against module-init-tools then?

Guys, I can't reproduce this issue at all. First I've installed the G02 packages. X works. Then I've selected the G03 packages and unselected the G02 packages. No files are missing afterwards (verified with "rpm -V <package_name>"). X works. 

Could it be that you still had the G02 packages with the prebuild kernel module installed, when you've updated to the G03 packages?

Still reproducible here:
- installed G02 drivers, made X work with nvidia driver (the issue also occurs on switching from G03 to G02)

rpm -qa|grep nvidia:
x11-video-nvidiaG02-304.64-27.1.i586
nvidia-gfxG02-kmp-desktop-304.64_k3.4.6_2.10-26.1.i586
nvidia-computeG02-304.64-27.1.i586

ls -l /lib/modules/3.4.28-2.20-desktop/weak-updates/updates/
insgesamt 0
lrwxrwxrwx 1 root root 49  4. Mär 09:42 nvidia.ko -> /lib/modules/3.4.6-2.10-desktop/updates/nvidia.ko

rpm -V $(rpm -qa | grep nvidia)
5S.T.....    /usr/bin/X.x11-video-nvidiaG02
...T.....    /usr/lib/xorg/modules/updates/drivers/nvidia_drv.so


- started YaST, marked the 3 G02 packages for deinstallation, selected the G03 packages for installation (kmp-default got selected automatically, I had to select kmp-desktop manually), clicked on "Accept", waited for installation to finish

- after reboot: X starts using the nouveau driver:

rpm -qa|grep nvidia:
nvidia-gfxG03-kmp-desktop-310.32_k3.4.6_2.10-15.1.i586
nvidia-computeG03-310.32-15.1.i586
x11-video-nvidiaG03-310.32-15.1.i586

ls -l /lib/modules/3.4.28-2.20-desktop/weak-updates/updates/
insgesamt 0

rpm -V $(rpm -qa | grep nvidia)
5S.T.....    /usr/bin/X.x11-video-nvidiaG03
...T.....    /usr/lib/xorg/modules/updates/drivers/nvidia_drv.so

If I then create the link manually and run depmod -a, after a reboot the system starts correctly, using the nvidia driver.

Another thing I just noticed:
When _no_ nvidia package is installed and I select x11-video-nvidiaG03 for installation, BOTH nvidia-gfxG02-kmp-default AND nvidia-gfxG03-default get selected automatically for installation (and kernel-default).

Ok. I could reproduce the issue with the removed weak-updates symlink (nvidia-gfxG02-kmp-desktop --> nvidia-gfxG03-kmp-desktop update) when the kernel has been updated first. Creating the weak-updates symlink and running "depmod -a" fixes the issue.

For some reason I don't see the issues when just updating nvidia-gfxG03-kmp-desktop package. I would have expected the same issue when looking at the %preun/%postun scripts.

Michal, could it be that wm2 removes the symlink although the kernel module still
exists, but only does that if it belongs to a different package? This would explain the behaviour.

(In reply to comment #21)
> Another thing I just noticed:
> When _no_ nvidia package is installed and I select x11-video-nvidiaG03 for
> installation, BOTH nvidia-gfxG02-kmp-default AND nvidia-gfxG03-default get
> selected automatically for installation (and kernel-default).

I don't see this issue (with only kernel-desktop installed). But I am testing on x86_64.

Michal, see comment #22.

Created attachment 530389 [details]
Screenshots of false autoselection after marking G03 drivers

This screenshot demonstrates the behaviour already reported by Wolfgang Bauer in comment 21.
The file 01-situationBefore.png shows how I have the appropriate G02 drivers installed on a (former) production system that has reached my desk.
In the 02* file, I selected the G03 desktop kernel module and nothing was autoselected. I deselected the file afterwards.
The 03* file shows the autoselected packages after selecting the G03 driver: the G02 default kernel module and the the G03 default kernel module are selected. Again, I deselected the driver afterwards.
Finally the 04* screenshot demonstrates how after selection of the nvidia-computeG03 package, again the G02 default kernel module as well as the G03 default kernel module are automatically selected.

Also note that none of the selections deselects the G02 packages.

First of all, I'm sorry for the delay.

(In reply to comment #22)
> For some reason I don't see the issues when just updating
> nvidia-gfxG03-kmp-desktop package. I would have expected the same issue when
> looking at the %preun/%postun scripts.

Did you test with the kernel that the KMP was built against? In this case the module is installed below /lib/modules/.../extra or .../updates and this is handled by rpm. Admittedly, rpm is lot smarter than the weak-modules2 script.


> Michal, could it be that wm2 removes the symlink although the kernel module
> still
> exists, but only does that if it belongs to a different package? This would
> explain the behaviour.

Yes. weak-modules2 --remove-kmp always removes all the symlinks, and then looks for the newest among other versions of the kmp to create new symlinks. I.e. package renames are not handled. I will change it to also consider packages that contain the same set modules, which should handle the nvidia case. It will not handle the case when you rename a KMP _and_ add or remove modules at the same time.

(In reply to comment #27)
> First of all, I'm sorry for the delay.
> 
> (In reply to comment #22)
> > For some reason I don't see the issues when just updating
> > nvidia-gfxG03-kmp-desktop package. I would have expected the same issue when
> > looking at the %preun/%postun scripts.
> 
> Did you test with the kernel that the KMP was built against? 

No, the kernel has been updated meanwhile. IIRC updating the kernel was necessary to reproduce the issue.

> In this case the module is installed below /lib/modules/.../extra or 
> .../updates and this is handled by rpm. Admittedly, rpm is lot smarter than
> the weak-modules2 script.

> > Michal, could it be that wm2 removes the symlink although the kernel module
> > still
> > exists, but only does that if it belongs to a different package? This would
> > explain the behaviour.
> 
> Yes. weak-modules2 --remove-kmp always removes all the symlinks, and then 
> looks for the newest among other versions of the kmp to create new symlinks. 
> I.e. package renames are not handled. I will change it to also consider 
> packages that contain the same set modules, which should handle the nvidia 
> case. It will not handle the case when you rename a KMP _and_ add or remove 
> modules at the same time.

Thanks. That would be great and covers perfectly this issue only containing 
one kernel module called "nvidia.ko".

Tried again today (on openSUSE 12.3 32bit now) since there were new nvidia packages.
Here's what I experienced:
- switching between G02 and G03 worked fine now

- in Yast the autoselection of the kernel module still doesn't work correctly:
  * when I select x11-video-nvidiaG03, nvidia-gfxG03-kmp-default is selected, although I'm running the desktop kernel
  * when I select x11-video-nvidiaG02, _both_ nvidia-gfxG03-kmp-default _and_ nvidia-gfxG02-kmp-default are selected!

Anyway, since this bug is about switching between G02 and G03, I'd say it can be closed as fixed.

Ok. Let's keep that one open as long as Michal didn't confirm that he adjusted weak-updates2 script.

(In reply to comment #23)
> (In reply to comment #21)
> > Another thing I just noticed:
> > When _no_ nvidia package is installed and I select x11-video-nvidiaG03 for
> > installation, BOTH nvidia-gfxG02-kmp-default AND nvidia-gfxG03-default get
> > selected automatically for installation (and kernel-default).
> 
> I don't see this issue (with only kernel-desktop installed). But I am testing
> on x86_64.
Just for your information:
I found out why this happens on my system (at least why nvidia-gfxG03-default gets selected instead of *-desktop; the G02 module doesn't get selected anymore but I guess the reason was related):

When I uninstall the nvidia packages, they get added to /var/lib/zypp/SoftLocks.
If I remove that file before I try to install x11-video-nvidiaG03 again, the correct kmp gets selected! (nvidia-gfxG03-kmp-desktop)

I think because of the soft lock on nvidia-gfxG03-kmp-desktop, the solver prefers to install nvidia-gfxG03-kmp-default, even though kernel-desktop is installed and not kernel-default.
And I think that's intended behaviour of the solver, because otherwise when you uninstall a recommended package it will get installed again automatically some time later.
But at least the result is unexpected in this case IMHO.

Anyway, that's no bug in the nvidia driver packages...

Interesting observation. Possibly Michael can explain the problem and how to resolve (or why it's not easily resolvable).

Another thing I'd like to add:
(In reply to comment #9)
> When trying to install nvidia-computeG03 and x11-video-nvidiaG03 with already
> installed nvidia-computeG02 and x11-video-nvidiaG02 packages this fails due to
> file conflicts (which is good).
That's not true.

YaST/zypper will happily install both side-by-side and there won't be a file conflict error because libzypp uses "rpm --force" to install packages AFAIK.

(In reply to comment #31)
> the G02 module doesn't get selected anymore
> but I guess the reason was related
I could reproduce the issue that BOTH G02 and G03 kernel modules get installed.

This happens when I try to install the G03 driver with SoftLocks on nvidia-gfxG02-kmp-desktop and nvidia-gfxG03-kmp-desktop.
Then BOTH nvidia-gfxG02-kmp-default and nvidia-gfxG03-kmp-default get selected (with kernel-desktop installed).

(In reply to comment #33)
> This happens when I try to install the G03 driver with SoftLocks on
> nvidia-gfxG02-kmp-desktop and nvidia-gfxG03-kmp-desktop.
> Then BOTH nvidia-gfxG02-kmp-default and nvidia-gfxG03-kmp-default get selected
> (with kernel-desktop installed).

Sorry that was a typo. It should read "This happens when I try to install the G02 driver"

(In reply to comment #30)
> Ok. Let's keep that one open as long as Michal didn't confirm that he adjusted
> weak-updates2 script.

Michal?

Michal, ping?

Not yet, sorry.

This is still a problem on 13.2 when switching from G03 in G04 in one go (marking G04 for installation and G03 for uninstallation in YaST at the same time).
I tried that now, and afterwards the link for nvidia.ko was missing (nvidia-uvm.ko was there though).
Reinstalling the nvidia kmp's fixed that.

Another aspect that was new now (and is specific to >=13.2):
The libglx.so link pointed to Xorg's libglx instead of nvidia's afterwards, so OpenGL was still not working. I had to reinstall nvidia-glG04 as well.

(In reply to Wolfgang Bauer from comment #38)
> This is still a problem on 13.2 when switching from G03 in G04 in one go
> (marking G04 for installation and G03 for uninstallation in YaST at the same
> time).
> I tried that now, and afterwards the link for nvidia.ko was missing
> (nvidia-uvm.ko was there though).
> Reinstalling the nvidia kmp's fixed that.

Thanks. Updated tags product/version tags and bugrepor description.

> Another aspect that was new now (and is specific to >=13.2):
> The libglx.so link pointed to Xorg's libglx instead of nvidia's afterwards,
> so OpenGL was still not working. I had to reinstall nvidia-glG04 as well.

If YaST installs G04 first, then uninstalls G03, the symlinks will be reset to
X.Org in %postun of G03 package. Not sure how this can be fixed at all. :-(

(In reply to Stefan Dirsch from comment #39)
> Thanks. Updated tags product/version tags and bugrepor description.

I probably should have done that myself, I guess...
Sorry.

> If YaST installs G04 first, then uninstalls G03, the symlinks will be reset
> to
> X.Org in %postun of G03 package. Not sure how this can be fixed at all. :-(

Right.
I have no idea either at the moment.

Maybe just declare the switch as unsupported finally, and mention on the Wiki page that one should deinstall the driver first before switching to a different version? (then this whole bug report could be closed as WONTFIX I suppose)

The Wiki page still doesn't even mention G04 yet, btw, nor offers an 1-click install... 
Should I file another bug report about this? Or how is this handled?

(In reply to Wolfgang Bauer from comment #40) 
> Maybe just declare the switch as unsupported finally, and mention on the
> Wiki page that one should deinstall the driver first before switching to a
> different version? (then this whole bug report could be closed as WONTFIX I
> suppose)
> 
> The Wiki page still doesn't even mention G04 yet, btw, nor offers an 1-click
> install... 
> Should I file another bug report about this? Or how is this handled?

Can you edit the wiki page yourself?

(In reply to Egbert Eich from comment #41)
> Can you edit the wiki page yourself?

Can I?
No idea, haven't tried yet.

Still, it would need a new ymp file as well, which I don't know how to supply.

(In reply to Wolfgang Bauer from comment #42)
> (In reply to Egbert Eich from comment #41)
> > Can you edit the wiki page yourself?
> 
> Can I?
> No idea, haven't tried yet.

Well, yes I can and just added a warning regarding this.

Please review, and change accordingly if you think it should be done in a different way.

My second question still stands though.

Sorry, missed this, as there was a bug in my needinfo search.

Can you give me a URL to the Wiki page you changed? Unfortunately there are a bunch of pages around on the openSUSE Wiki all addressing the NVIDIA driver.

Regarding your 2nd questions: none of the pages seem to be very up-to-date.
So it is likely that a lot of stuff is still missing.
Ideally all the information there should be consolidated into a single page, getting updated and later on being maintained.

(In reply to Egbert Eich from comment #44)
> Can you give me a URL to the Wiki page you changed? Unfortunately there are
> a bunch of pages around on the openSUSE Wiki all addressing the NVIDIA
> driver.
> 
This one: https://en.opensuse.org/SDB:NVIDIA_drivers

(In reply to Wolfgang Bauer from comment #45)
> 
> This one: https://en.opensuse.org/SDB:NVIDIA_drivers

Cool, you change the English one! I do prefer it as it reaches a more global audience ;) 

What you wrote seems OK. Thanks a lot!
(I just went and changed the formatting a bit.)

In fact, the underlying issue in the weak-modules2 script should be fixed ...
Looks like this is script is such a mess that one cannot find an eager taker for this job :/

Regarding the one-click install stuff: this should all be removed. For a 1-click install, you need to know your GPU model. The modules itself however come with dependencies so this happens automatically.
I think I will update the page accordingly.

(In reply to Egbert Eich from comment #46)
> (In reply to Wolfgang Bauer from comment #45)
> > 
> > This one: https://en.opensuse.org/SDB:NVIDIA_drivers
> 
> Cool, you change the English one! I do prefer it as it reaches a more global
> audience ;) 

Yes. I can/will add that to the german translation as well in the next days.
For other languages, I cannot help really...

> In fact, the underlying issue in the weak-modules2 script should be fixed ...
> Looks like this is script is such a mess that one cannot find an eager taker
> for this job :/

Well, but that's not the only problem now in 13.2 and up.
As mentioned before:
(In reply to Stefan Dirsch from comment #39)
> (In reply to Wolfgang Bauer from comment #38)
> > Another aspect that was new now (and is specific to >=13.2):
> > The libglx.so link pointed to Xorg's libglx instead of nvidia's afterwards,
> > so OpenGL was still not working. I had to reinstall nvidia-glG04 as well.
> 
> If YaST installs G04 first, then uninstalls G03, the symlinks will be reset
> to
> X.Org in %postun of G03 package. Not sure how this can be fixed at all. :-(

(In reply to Wolfgang Bauer from comment #47)
> (In reply to Egbert Eich from comment #46)
> > (In reply to Wolfgang Bauer from comment #45)
> > > 
> > > This one: https://en.opensuse.org/SDB:NVIDIA_drivers
> > 
> > Cool, you change the English one! I do prefer it as it reaches a more global
> > audience ;) 
> 
> Yes. I can/will add that to the german translation as well in the next days.
> For other languages, I cannot help really...
>
I've revamped the page pretty much now and got rid of the 1-Click install stuff.
Using this is not recommended and may cause issues.
I've reworded your warnings to be a bit stronger and extended the recommendations a bit so that the adventurous users know how to avoid problems.

We've spent a lot of thought to get the automatic mechanism right, anything else will introduce numerous corner cases one cannot catch all. This is why we don't recommend to use 1-Click or other ways for manual install.
  
> > In fact, the underlying issue in the weak-modules2 script should be fixed ...
> > Looks like this is script is such a mess that one cannot find an eager taker
> > for this job :/
> 
> Well, but that's not the only problem now in 13.2 and up.
> As mentioned before:
> (In reply to Stefan Dirsch from comment #39)
> > (In reply to Wolfgang Bauer from comment #38)
> > > Another aspect that was new now (and is specific to >=13.2):
> > > The libglx.so link pointed to Xorg's libglx instead of nvidia's afterwards,
> > > so OpenGL was still not working. I had to reinstall nvidia-glG04 as well.
> > 
> > If YaST installs G04 first, then uninstalls G03, the symlinks will be reset
> > to
> > X.Org in %postun of G03 package. Not sure how this can be fixed at all. :-(

Yes, this is however only an issue if one updates to G04 manually. On the same version of openSUSE we will never change the the 'Supplements:'. This will only happen from one version of openSUSE to the next - but in this case the new repos are only available after the installation: the old NVIDIA packages will be gone at that time anyway.
One can still run into this issue when updating the distro using 'zypper dup' after updation all repos (including the NVIDIA one).
This will be a problem for SLE12 in the future if not fixed as there these repos can be added before installing the packages. This however is of no major concern here.

(In reply to Egbert Eich from comment #48)
> Yes, this is however only an issue if one updates to G04 manually.

Yes, but that's exactly the use-case this bug report is about.
If you don't update to G04 manually, there won't be a problem with the kernel module either... ;-)

(In reply to Wolfgang Bauer from comment #49)
> (In reply to Egbert Eich from comment #48)
> > Yes, this is however only an issue if one updates to G04 manually.
> 
> Yes, but that's exactly the use-case this bug report is about.
> If you don't update to G04 manually, there won't be a problem with the
> kernel module either... ;-)

Right. For this case we now have warnings in the Wiki and procedures to circumvent it - thanks to you!
I do hope that fewer people with take this 'adventurous' path being that I have removed the information on how to do this (at least from this page).
The default path should be sufficient for most users and users who still want to go another route should have some experience.

As I said, we will have to solve it for SLE12 anyway and this solution will definitely find its way into openSUSE!
I'm sure that even once this is fixed other issues will appear when people manually change stuff in unforeseeable ways.

> (In reply to Wolfgang Bauer from comment #38)
> > Another aspect that was new now (and is specific to >=13.2):
> > The libglx.so link pointed to Xorg's libglx instead of nvidia's afterwards,
> > so OpenGL was still not working. I had to reinstall nvidia-glG04 as well.
> 
> If YaST installs G04 first, then uninstalls G03, the symlinks will be reset
> to
> X.Org in %postun of G03 package. Not sure how this can be fixed at all. :-(

I've addressed this issue now for updated version of G<n> drivers, i.e. if you freshly install G<n> in the future, then update later to G<n+1>, symlinks won't get reset to X.Org any longer. Of course it won't help for already installed G<n> drivers ...

And the repos aren't updated yet. Won't happen before next driver release update.

EOL