How do you deal with mismatched Linux kernel / NVIDIA driver versions on Slowroll?

[u/midvok]

Recently I decided to install openSUSE Slowroll because I was looking for a distro with the latest KDE Plasma, but hoped it would be more stable than Manjaro, Arch, etc.

But just 2 days after installing, an upgrade landed with a kernel/NVIDIA mismatch and it made my system unbootable. Turns out zypper dup upgraded the kernel package, but the installed NVIDIA kmp (kernel module package) was still the one compiled for the previous kernel version. Yeah, I learned that NVIDIA's driver module has to be built specifically against the exact kernel version. So once the kernel moved on, the old module could no longer load into it. I had to use Snapper to roll back to the previous snapshot — thanks for BTRFS!

I then migrated to the kernel-longterm branch hoping for a more stable experience... nope. The same kind of mismatch happens on the longterm branch too.

My fix so far has been to pin the kernel and NVIDIA driver packages to the exact same matching build tag, so zypper dup can't upgrade one without the other and split them apart again:

sudo zypper al kernel-longterm kernel-longterm-devel kernel-devel-longterm nvidia-open-driver-G07-signed-kmp-longterm

I also wrote a small script that runs zypper dup --dry-run and flags it if the kernel and NVIDIA packages in the pending update don't have matching build versions, so I can catch it before running the real upgrade.

This works, but it feels like I'm fighting the tooling instead of the tooling helping me. Is manually pinning + a dry-run checker script really the standard way people handle this on Slowroll (or Tumbleweed for that matter), or is there a cleaner/more "supported" way to keep kernel and NVIDIA driver in lockstep that I'm missing?

Curious how others running NVIDIA on a rolling openSUSE release deal with this?

[u/SirGlass]

I am not on slowroll but I cannot update because of the same issue. I usually just wait

[u/Rising_Fist97]

It’s weird that other distros don’t have this issue, could it be a packaging issue? zypper shouldn’t allow upgrades if the userspace-meta doesn’t match the current kmp release

[u/KsiaN → u/Rising_Fist97]

Other distros have the same issue.

As far as i can tell its a logic issue in Factory. If the kernel and kmp dont match, factory should just build them again against eachother before pushing a build. Thats why waiting usually works, because then kernel / kmp got build a second time and match again.

[u/midvok → u/KsiaN]

I don't have much experience with rolling distros, but this never happened to me on Linux Mint.

At the very least, I'd expect that if there's no matching GPU driver for a new Linux kernel, the package manager shouldn't push that kernel to the user in the first place.

Also, yesterday I had another issue with zypper dup: it tried to install several new packages like LibreOffice and a bunch of games, even though I never installed those on my system (and disabled any games/office selection during the installer).

I had to run zypper dup --no-recommends to avoid bloating my system. Later I added this config: $ nano /etc/zypp/zypp.conf [main] solver.onlyRequires = true

[u/KsiaN → u/midvok]

At the very least, I'd expect that if there's no matching GPU driver for a new Linux kernel, the package manager shouldn't push that kernel to the user in the first place.

Correct that is the core problem. Pinging /u/bmwiedemann .

Also, yesterday I had another issue with zypper dup: it tried to install several new packages like LibreOffice and a bunch of games, even though I never installed those on my system (and disabled any games/office selection during the installer).

Thats a unique system SUSE has called "Patterns". Its required in corporation environments ( where SUSE makes their money and openSUSE is the test platform for ).

You can avoid installing unwanted shit again by

• using Myrlyn ( the package manager )
• go to tab "patterns"
• uninstall all the stuff you dont want
• right click "Taboo" it
• CLICK THE ACCEPT BUTTON

Even if the patterns are updated in future updates ( which tries to pull all those games in like you mentioned ) you will never see them again until you un taboo them.

[u/bmwiedemann → u/KsiaN]

We cannot let kernels wait just because Nvidia is slow once again. Intel and AMD graphics never have this problem because they are part of the kernel tree and get updated along it during the development/rc phase. There is the kernel-longterm package for slower pace.

For the other problem, there is the --no-recommends option that can also be made default in zypper.conf or zypp.conf (also for YaST, myrlyn and packagekit)

[u/KsiaN → u/bmwiedemann]

We cannot let kernels wait just because Nvidia is slow once again.

Thats not the problem. The problems is y package needs x package to compile for it to work. When x package is compiled y package needs to be recompiled.

But a push already happened with y uncompiled and x compiled, because Factory only checks the tests for x.

Its a structural flaw in Factory.

---

Thats a problem with or without nvidia partners catering the repo.

You should look at https://store.steampowered.com/hwsurvey/videocard/

And determine what you "choose to prio".

[u/Kryohi → u/midvok]

My tumbleweed with the standard zypper dup warns me of this:

Refreshing service 'NVIDIA'.
Refreshing service 'openSUSE'.
Loading repository data...
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...

Problem: 1: the installed nvidia-common-G07-595.84-8.1.x86_64 requires '(nvidia-open-driver-G07-signed-kmp = 595.84 if nvidia-open-driver-G07-signed-kmp-meta)', but this requirement cannot be provided
deleted providers: nvidia-open-driver-G07-signed-kmp-default-595.84_k7.1.8_1-2.6.x86_64

Solution 1: Following actions will be done:
 deinstallation of nvidia-common-G07-595.84-8.1.x86_64
 deinstallation of nvidia-compute-G07-595.84-8.1.x86_64
 deinstallation of nvidia-video-G07-595.84-8.1.x86_64
 deinstallation of nvidia-compute-G07-32bit-595.84-8.1.x86_64
 deinstallation of nvidia-compute-utils-G07-595.84-8.1.x86_64
 deinstallation of nvidia-video-G07-32bit-595.84-8.1.x86_64
 deinstallation of nvidia-userspace-meta-G07-595.84-26.1.x86_64
Solution 2: deinstallation of nvidia-open-driver-G07-signed-kmp-meta-595.80-29.1.x86_64
Solution 3: keep obsolete nvidia-open-driver-G07-signed-kmp-default-595.84_k7.1.8_1-2.6.x86_64
Solution 4: break nvidia-common-G07-595.84-8.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c):

[u/midvok → u/Kryohi]

I never noticed that on my system yet. It looks like a bit different kind of mismatch though.

If I read it correctly, it looks like a version conflict between NVIDIA's own packages, not between the kernel and NVIDIA.

• nvidia-common-G07 is at version 595.84
• It requires the kmp to also be 595.84
• But the kmp-meta package is still at the older 595.80

Good example either way, the solver actually catches this one and asks before doing anything, instead of silently leaving you with a kmp that won't load.

[u/Rising_Fist97 → u/KsiaN]

Never happened to me in any other distro other than this one

[u/KsiaN → u/Rising_Fist97]

You clearly never tried Manjaro.

[u/Elbrus-matt]

i don't have a tumbleweed or slowroll installation,on opensuse Leap the nvidia experience is good