Same here…again…when will this mess end? How to prevent it happening, why there is no solution to prevent it at least no one I’m aware of and could not find one? Why it’s so hard for this OS to not ■■■■ up every 2 or so months?
You may want to read the wiki. Tumbleweed is not for everyone. Something like this is to be expected. If you are not sure if you can keep the pace of a rolling release, better use a stable release like Leap.
1 Like
There’s “may release a newer package that’s got new bugs in” and “may release an update that’s incompatible with your old config (which wouldn’t have been around for so long if it was regularly reinstalled)” and then there’s “doesn’t keep vital packages in sync and doesn’t keep more than one version of the package”.
I’ve been using Tumbleweed for nearly 9 years now. Snapper is great and useful in some of these situations. But it’s still not fun when your graphics drivers suddenly stop working again because it updated one part and not the other.
If you are a TW user for 9 years, you know how to prevent a missmatch. Zypper didn‘t force it on you. Read the zypper output and choose a solution.
1 Like
Or, just make it work with auto testing. If it doesn’t pass, throw an error to prevent the update. Then it is up to the user to force it or wait for compatibility changes. It’s shortsighted is quite ridiculous to suggest that a rolling distro that is known for stability and just working should allow things to break.
If you read the zypper output you would have noticed that zypper has thrown an error when updating the drivers. You have unfortunately choosen the wrong solution or ignored the error.
The meta packages are there to prevent an update without noticing the user. By keeping the meta package and not blindly updating (ignoring the error), the missmatch is prevented.
As the Nvidia drivers cannot be provided/distributed by openSUSE it is always possible that a small missmatch between independend repos (Nvidia and openSUSE) occur. But it is also not that hard to prevent the update by using the right zypper solution. But for that, the user must use the meta packages provided by openSUSE and as described in the wiki.
Or use the run file and have full control over the packages and be responsible for patching/installation/fixing…
1 Like
I have not unfortunately chosen the wrong solution. I decided to install an NVIDIA GPU yesterday, and it was immediately non-functional. How about you stop making excuses that ruin user experience, eh?
I’ve been using Nvidia GPU’s for some 20 years now, y’all have it pretty easy now with the repository and rpm’s…
Anyway, I have no issues with the rpm’s, from the cuda repository (no 32bit required)… the open driver from there rebuilds automatically via dkms, and it’s in the 610 series as well…
There is always distrobox to fill those gaps or a flatpak as this will pull in anything 32bit required.
As pointed out by @hui there isn’t an ability to do any testing from a hardware perspective, likewise there is some expectation that Tumbleweed users can sort out a glitch or two…
2 Likes
Yes, I’ve learned how to resolve these issues.
And yes, the meta package can protect you… except the meta package doesn’t stop a newer kernel being installed without the drivers.
And sure, the DKMS repo has been recommended by users here BUT the wiki explicitly calls it out as unsupported.
So our choice is “rebuild around kernel updates, but zero support” or “officially supported and supposed to be kept compatible by meta package but still has a failure mode”.
Absolutely unclear what you are talking about…
The latest kernel is
~> uname -r
7.1.8-1-default
And the properly working set of drivers (due to the use of the meta package) is:
:~> LANG=C zypper se -si nvidia
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
---+-------------------------------------------+---------+----------------------+--------+------------------
i+ | kernel-firmware-nvidia | package | 20260610-2.1 | noarch | repo-oss
i | libnvidia-cfg | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | libnvidia-egl-gbm1 | package | 1.1.3-11.6 | x86_64 | repo-non-free
i+ | libnvidia-egl-gbm1-32bit | package | 1.1.3-11.3 | x86_64 | repo-non-free
i+ | libnvidia-egl-wayland1 | package | 1.1.22-57.8 | x86_64 | repo-non-free
i+ | libnvidia-egl-wayland1-32bit | package | 1.1.22-57.4 | x86_64 | repo-non-free
i+ | libnvidia-egl-x111 | package | 1.0.5-26.6 | x86_64 | repo-non-free
i+ | libnvidia-egl-x111-32bit | package | 1.0.5-26.3 | x86_64 | repo-non-free
i+ | libnvidia-gpucomp | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | libnvidia-gpucomp-32bit | package | 595.84-8.1 | x86_64 | repo-non-free
i | libnvidia-ml | package | 595.84-8.1 | x86_64 | repo-non-free
i | libnvidia-ml-32bit | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-common-G07 | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-compute-G07 | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-compute-G07-32bit | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-compute-utils-G07 | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-gl-G07 | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-gl-G07-32bit | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-libXNVCtrl | package | 595.84-2.1 | x86_64 | repo-non-free
i+ | nvidia-modprobe | package | 595.84-2.1 | x86_64 | repo-non-free
i+ | nvidia-open-driver-G07-signed-kmp-default | package | 595.84_k7.1.8_1-2.6 | x86_64 | (System Packages)
i+ | nvidia-open-driver-G07-signed-kmp-meta | package | 595.80-29.1 | x86_64 | repo-non-free
i+ | nvidia-persistenced | package | 595.84-2.1 | x86_64 | repo-non-free
i+ | nvidia-settings | package | 595.84-2.1 | x86_64 | repo-non-free
i+ | nvidia-userspace-meta-G07 | package | 595.84-26.1 | x86_64 | repo-non-free
i+ | nvidia-video-G07 | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | nvidia-video-G07-32bit | package | 595.84-8.1 | x86_64 | repo-non-free
i+ | openSUSE-repos-Tumbleweed-NVIDIA | package | 20260423.1a6a0f3-2.2 | x86_64 | repo-oss
As already explained: zypper and Myrlyn tell you clearly that there is an issue when you try to update the kmp package. What else do you expect from the maintainer or the zypp solver? If you choose to ignore it…
And as pointed out by Malcolm, you can be really lucky that the openSUSE maintainer created the meta packages which prevent a missmatch. They didn’t always exist. But yeah, some users still complain…you can’t please everybody.
If you have constructive ideas how to make the process better, the openSUSE maintainer is fur sure happy to incorporate your brilliant ideas.
Before the update, my kernel was 7.1.6.
After the update, I also had the 7.1.8 kernel BUT the meta package held back the Nvidia packages so that I didn’t have modules for the new kernel, because the only package for 7.1.8 conflicted with the meta package (which I kept).
I remember not having the meta package. And it’s better than it was. But my situation would have been avoided if it could also prevent a new kernel being installed until the matching kernel modules are available (rather than just keeping the two parts in sync).
Unless we’re expected to check whether there’s a kernel update every single time, and whether there’s matching modules when there is. Because I’d always assumed that once the conflicts are resolved (and I’m not uninstalling modules) then the system should have the same features and drivers as before.
Hey, look at this guy telling users that they should be developers and maintainers. What a brilliant response.
1 Like
That’s what Tumbleweed is designed for openSUSE development…
Perhaps Slowroll or Leap may be a btter fit for your use? I have Nvidia running on there with the rpms, it’s been fine.
Dafaq are even spouting?
" The openSUSE distributions are stable, easy to use and complete multi-purpose distributions.
They are aimed towards users and developers working on the desktop or server. They are great for beginners, experienced users and ultra geeks alike, in short, they are perfect for everybody! The latest release, openSUSE Leap 16.0, based on SUSE Linux Enterprise, features updated software packages useful for server and desktop applications and has extended maintenance and security. It comes with more than 1,000 open source applications. openSUSE Tumbleweed is the rolling release, providing the latest upstream software releases, yet only those packages that pass testing."
Guess you better change the website. Get on it so you can be right about this.
OK, enough! The Documentation is fine (You can change it if you like?)
If you follow the Tumbleweed link it says;
https://en.opensuse.org/Portal:Tumbleweed
Who should try Tumbleweed?
Any user who wishes to have newer packages than are available in the openSUSE Leap repositories. This includes, but is not limited to, an updated Linux kernel, SAMBA, git, desktops, office applications, and many other packages.
Also, Tumbleweed should appeal most to Power Users, Software Developers (who require the latest software stacks and IDEs), and openSUSE Contributors (who need a reliable platform that is as close to openSUSE Factory as possible while remaining usable).
Due to the Linux kernel being updated very frequently, users who rely on 3rd party kernel driver modules including graphic drivers should not use the Tumbleweed distribution unless they are familiar with updating these drivers from source on their own or they have supported hardware. For more details please refer to the “Third Party Drivers” section below.
To All Keep it constructive and technical.
@sunscape suggest you reign in the attitude.
Sure.
Linux is replacing Windows in a meaningful way for the first time ever. Do you think new users are going to stick to opensuse, having tied it because it’s the one that has the most relevant updates for gamers without the instability of Arch, if the damn thing doesn’t work the day they install it?
Nope. Few excuses, and more solutions.
What has this got to do with Windows, people use the tools that work for them, I use Windows (10 and 11), MacOS and openSUSE depending on my needs.
Leap or Slowroll may be the better option?
I don’t use 32bit, so I use the cuda repository which works fine here on Tumbleweed with a Turning based GPU and dkms.
I have no issues on Leap 16.0 with Nvidia either (Both Turing and Pascal based cards).
If you go to download an opensuse desktop os, Tumbleweed comes recommended for gamers, so here we are 
I came straight from Windows and it’s mostly a smooth ride, except when it comes to these drivers. For newly released games, you usually want the newest drivers and since it’s mostly proton, you likely need 32bit as well. This breaks often and I admit the proper way to install them is still not very clear to me. G06, G07, meta packages, several others and why do I always seem to end up subscribed to the microos repo? These are not actual questions, just things I feel could be better explained to nvidia equipped newcomers to linux, there’s probably dozens of us, dozens!
3 Likes
The driver maintainer worked hard to prevent missmatch of driver versions by providing the meta packages. He is also really fast and responsive when issues are reported.
Additionally we straightened up the installation instructions in the wiki heavily. They are now quite straight forward compared to some time ago. It was a bloody mess before it got overhauled.
Unfortunately user often do not read documentation or prefer to use some arbitrary AI instead of reading few sentences.
The Nvidia TW and MicroOS repo is exactly the same URL and content wise. Thus the zypper solver picks the first available. No harm when you have the Nvidia MicroOS repo on TW as there isn‘t any difference.
1 Like
Just you wait, I decided to try and .run the drivers to see how that goes!
I have faith in snapper, if not in myself.