I use a computer with an Nvidia graphics card: NVIDIA GK104 [GeForce GTX 760]
Here on the forums I read a lot about problems with Nvidia drivers and kernels. When a new kernel is used it seems I have to install the driver again.
At the moment I use Leap in a VM, using the VM driver and things are going very well. I do want to use it as my main system and then I would be using the Nvidia driver. At the moment I use LinuxMint 17.3 KDE-64 with the latest Nvidia driver and when I change the kernel I don’t need to re-install the driver. It just works. Why is it that in OpenSuse it is so difficult to keep things working?
What is the best (only?) way to keep things working in Leap? How can I install a driver, should I install it from the Nvidia website or are there other ways to do that? I don’t see it in the repos.
Who can tell me how to do those things in OpenSuse?
Thanks.
[EDIT] Sorry, heb het verkeerde forum gebruikt. Kan iemand dit verhuizen naar de engelstalige versie? Bedankt.
Yast - Software - Repositories - Add - Repositories maintained by the community
Check the box for the nvidia repo
You can use Yast’s Software Manager to install the recommended packages, which would include the NVIDIA driver packages.
Another way is to use zypper:
zypper ref && zypper inr
Yet another way is the manual install using the NV…run one can download at NVIDIA’s website.
This is a good starting point if you want extended info on this.
On a kernel update the packages in the NVIDIA repo will be rebuilt and show up as updates as well.
If you opt for the manual way, you can install dkms and use the --dkms option when running the installer.
So, when I understand you well, after a kernel update I have to install driver updates which will appear in the repos. That’s not so bad.
Installing using the nvidia run file from their website is not my favorite. I have done it in the past, but it doesn’t always work (in other distro’s than OpenSuse, but still)
Okay, one more step conquered before leaping into Leap. These virtual machines are wonderful, aren’t they? Such a great way of testing a distro before shutting down the old setup and installing a new one with who knows how many problems.
Plus of course the forums are a great place for helpful information so you really know what you are getting yourself into.
Thank you again Knurpht. Nice name, btw, especially in the Dutch language.
It’s not after a kernel update, but at the time of a kernel update. In the past I’ve been biten by this a couple of times when the kernel was updated, the nvidia stuff wasn’t, ending up with no X. Waited a couple of hours ( I’ve got other machines ) updated again, nvidia packages updated, a reboot and all back to normal. Since I want control over my machines, I left the precompiled kmp packages and installed “the hard way, which isn’t hard at all” adding --dkms and let dkms take care of (re)building the nvidia kernel modules.
A much more (IMHO) important thing for you to consider is to have the Online Resources option in the installer checked. It will force checking networkconnection and add the update repos before actually starting the software install. This would have an up-to-date KDE desktop as a result, which has had a lot of fixes related to nvidia hardware since Leap was released. A recent Leap install on a machine with NVIDIA graphic card done this way still runs on nouveau because the user is completely satisfied with graphics and performance, so why add some proprietary stuff then.
I love VM’s, mostly use them to take a peak at other distros.
And, yes, “Knurpht” was picked from “knurft”. I was looking for some non-existing word/name as a universal username, call it online-alter-ego if you want, when in an outburst I called my son a “knurft”. I replaced the “f” by “ph”, then googled, consulted lots of online dictionaries and came to the conclusion that it did not exist in any language. I still keep a screenshot of google showing more hits on my nickname than on the origin :D.
Hi, maybe I don’t understand the DKMS process correctly, but my feeling is that the nvidia modules are built and installed some time (maybe minutes) AFTER the updated kernel is running, not at kernel install time.
This is no problem to hybrid systems (AKA Optimus) users like me, since we boot the updated kernel to integrated graphics, then the proprietary video modules are built and installed and everything (usually) is OK on the next boot of the updated kernel.
But if I understand correctly, the Nvidia modules for the updated kernel are NOT available on first boot after the update and are not (yet) in the initrd, so that the Nvidia GPU is not engaged on first boot: if that is the only GPU in the system, you are left with a “black screen”, you complain, you (generally) reinstall the driver, which forces module building and installing “on the fly”, then you reboot and everything seems OK.
Is that understanding correct, or has anybody a better explanation of what we generally witness (or complain about)?
I’ve been observing how the display driver (nVidia in this case) is actually compiled on demand and added to the kernel during boot.
To the OP,
The simplest procedure (unless you need to tweak) is to simply add the nVidia repository, run “zypper up” and reboot.
The three SDB articles which describe various approaches to installing the nVidia driver are linked form the following page https://en.opensuse.org/SDB:NVIDIA
Thank you tsu2, I have copied the link you provided to my favorites. I will study it so I know what to do (and to expect) when I will install Leap for real.
As I wrote I am a LinuxMint user and in Mint it is just so easy to perform a kernel update: the Nvidia modules are rebuilt automatically and all works at next boot when you use the updated kernel for the first time. One thing you can not do and that is update the kernel and in the same run update the Nvidia driver. Since updating the kernel means still using the old one, the Nvidia modules will be built into the old kernel instead of the new one, making the screen go black at reboot. But that is obvious.
But, how many times does Leap get a new kernel? What are we talking about here? Plus, if the old kernel runs fine why should I update it? To get support for newer hardware which I don’t have?
Again, thanks for your help, really appreciate it.
I would agree… to some extent. The following is taken from the system journal of my main notebook for the first boot after updating to the 4.1.20 kernel:
**apr 12 18:40:26 LT_B kernel: Linux version 4.1.20-11-default** (geeko@buildhost) (gcc version 4.8.5 (SUSE Linux) ) #1 SMP PREEMPT Fri Mar 18 14:42:07 UTC 2016 (0a392b2)
...
apr 12** 18:40:29 LT_B dkms.systemd[1151]: Kernel preparation unnecessary for this kernel. Skipping...**
apr 12 18:40:29 LT_B dkms.systemd[1151]: Building module:
apr 12 18:40:32 LT_B dkms.systemd[1151]: cleaning build area....
...
apr 12** 18:40:53 **LT_B gdm-password][5850]: pam_unix(gdm-password:session): **session opened for user bruno** by (unknown)(uid=0)
...
apr 12 18:40:53 LT_B dkms.systemd[1151]: make KERNELRELEASE=4.1.20-11-default -C /lib/modules/4.1.20-11-default/build M=/var/lib/dkms/vboxhost/5.0.16/build..........
apr 12 18:40:56 LT_B dkms.systemd[1151]: cleaning build area....
apr 12 18:40:56 LT_B dkms.systemd[1151]: DKMS: build completed.
apr 12 18:40:56 LT_B dkms.systemd[1151]: vboxdrv.ko:
apr 12 18:40:56 LT_B dkms.systemd[1151]: Running module version sanity check.
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Original module
apr 12 18:40:56 LT_B dkms.systemd[1151]: - No original module exists within this kernel
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installation
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installing to /lib/modules/4.1.20-11-default/updates/
apr 12 18:40:56 LT_B dkms.systemd[1151]: vboxnetflt.ko:
apr 12 18:40:56 LT_B dkms.systemd[1151]: Running module version sanity check.
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Original module
apr 12 18:40:56 LT_B dkms.systemd[1151]: - No original module exists within this kernel
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installation
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installing to /lib/modules/4.1.20-11-default/updates/
apr 12 18:40:56 LT_B dkms.systemd[1151]: vboxnetadp.ko:
apr 12 18:40:56 LT_B dkms.systemd[1151]: Running module version sanity check.
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Original module
apr 12 18:40:56 LT_B dkms.systemd[1151]: - No original module exists within this kernel
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installation
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installing to /lib/modules/4.1.20-11-default/updates/
apr 12 18:40:56 LT_B dkms.systemd[1151]: vboxpci.ko:
apr 12 18:40:56 LT_B dkms.systemd[1151]: Running module version sanity check.
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Original module
apr 12 18:40:56 LT_B dkms.systemd[1151]: - No original module exists within this kernel
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installation
apr 12 18:40:56 LT_B dkms.systemd[1151]: - Installing to /lib/modules/4.1.20-11-default/updates/
apr 12 18:40:56 LT_B dkms.systemd[1151]: Adding any weak-modules
apr 12 18:41:01 LT_B dkms.systemd[1151]: depmod....
apr 12 **18:41:01** LT_B dkms.systemd[1151]:** DKMS: install completed.**
apr 12 18:41:01 LT_B bumblebeed[7090]: 36.675981] [INFO]/usr/sbin/bumblebeed 3.2.1 started
apr 12 **18:41:41** LT_B bumblebeed[7090]: **modprobe: ERROR: could not find module by name='nvidia'**
apr 12 18:41:41 LT_B bumblebeed[7090]: modprobe: ERROR: could not insert 'nvidia': Function not implemented
...
apr 12 18:41:41 LT_B bumblebeed[7090]: modprobe: ERROR: Error running install command for nvidia
apr 12 18:41:41 LT_B bumblebeed[7090]: modprobe: ERROR: could not insert 'nvidia': Operation not permitted
apr 12 18:41:41 LT_B bumblebeed[7090]: 76.640497] [ERROR]Module nvidia could not be loaded (timeout?)
apr 12 **18:41:41** LT_B bumblebeed[7090]: 76.640504] [ERROR]**Could not load GPU driver**
We can notice the following:
dkms activity indeed started “on boot”, about 3s after kernel loading;
install of vbox modules completed 8s after user login, 35s after boot;
1m 15s after boot, 48s after login, the nvidia module was not found (dkms building had not even started…).
At that point, needing the Nvidia performance, I force-updated nvidia-bumblebee, which in itself didn’t change version, and rebooted.
BTW, the nvidia modules are not yet in the initrd (I didn’t force rebuild, since the system seems happy anyway).
On a previous kernel update I literally saw the modules “appearing” in the kernel tree while I was browsing there…
Nothing really to complain about on my side, but users should understand that such things happen and that a forced update of the driver and/or a forced rebuild of the initrd may occasionally be in order after a kernel update.
Although I may be corrected, I understand dkms only ensures that the associated module(s) are also re-compiled whenever the kernel is updated, strictly speaking the drivers may still be implemented in kernelspace without dkms but then you risk the module(s) not being re-compiled and updated automatically. The result is the module(s) become out of sync with the kernel and need to be re-compiled manually.
So, whether you apply dkms or not does not determine whether the drivers are running in kernelspace(standard graphics card architecture today) or userspace (the old architecture, pre- approx kernel 3.1)
openSUSE prides itself on implementing new proven technology when it becomes available, typically far ahead of most other distros.
Tumbleweed will generally make those features available before any other version, where integration and stability issues are discovered and addressed.
When LEAP and other “stable” versions of openSUSE adopt those features, they should be mostly bug free.
This benefits anyone who is either using or building leading edge applications or need best performance. Later kernels don’t just have new support for hardware, they also include improvements in performance and support for technologies that software uses.
The reason why proprietary nVidia drivers aren’t compiled for you is that openSUSE takes a very strict stance on adhering to licensing, and will refuse to re-distribute any code or software licensing attaches any restrictions. Not all distros take such a strict stance. This is why you will need to obtain your nVidia drivers from a repo set up and maintained by nVidia themselves, and there are other repos you may wish to add for their non-FOSS packages.
Updating the kernel should typically be an almost invisible experience to the User. Each kernel is pre-compiled (you simply download it) but if you have any optional kernel modules installed(like nVidia replacing nouveau), they will either need to be re-compiled manually or have it done automatically using dkms.
You can either rely on applications to keep your system updated, or manually update your system periodically with the following command running in a root console (Yes, that’s another diff between openSUSE and many others. You are permitted to run a real root console and not limited to sudo) Updating your system (advisable on a regular basis)
Yup, and Leap 42.1 , like the openSUSE 1#.# versions, will not see major kernel updates, i.e. stick to the 4.1 kernel. Leap 42.2 will probably have kernel 4.5 and keep that for it’s lifetime. Security fixes and so on will be backported to that kernel AFAIK.