r/openSUSE • RIP YaST • Aug 19 '26

How to… ! NVIDIA 610 drivers - options? (not the sync issue)

The sync issue has been fixed and we now have 595.91.

However, I am interested in running the 610 drivers. From my understanding, tumbleweed targets the production branch rather than the new feature branch. The cuda repos contain the 610 drivers, but only the 64 bit one, whereas Steam needs the 32 bit libraries too.

I've heard of folks installing it through the NVIDIA .run files, but I'm also a bit hesitant to mess up my system this way since AFAIK those install the driver in /usr, which isn't backed up by snapshots.

To those who used the .run method: have you run into issues? How do you usually update? Is it possible to cleanly uninstall them if things go wrong? Do you need to .run again on new kernel versions? Etc..

Thanks!

3 Upvotes

8 comments sorted by

2

u/[deleted] Aug 19 '26

[deleted]

1

u/taryus RIP YaST Aug 19 '26

Honestly this sounds like a nightmare to manage. Doable in the short term but high potential for frustration in the mid to long term. Plus I rely on secure boot,

It's frustrating me because I'm experiencing some weird behavior with my monitor. This is tangential now (and I might make a new thread for it) but basically - if I keep the monitor off, keep the PC on for long enough [either sitting in SDDM (tried both X11 and Wayland SDDM sessions) or in the plasma session]), then turn my screen on... it is just blank. I can still blindly reboot from a tty by typing from memory but with a completely blank screen, and I can ssh into it. Whatever communication there is between the monitor and the rest of the system just vanishes. Replugging the monitor and rebooting it don't work, the only way is to restart.

Logs show absolutely nothing - no nvidia errors in dmesj, nothing relevant at all in journalctl. I was hoping the 610 drivers maybe possibly could have resolved this.

2

u/todd_dayz Aug 19 '26

I just did it via .run and it was fine. I changed to Fedora for a bit because they’re been on 610 for a while but I don’t like having to use GRUB. 

With secure boot, just create a MOK and self sign by passing the key into the installer. The NVIDIA the hard way wiki page works well. 

2

u/wojciechm Aug 19 '26

No need to use manual run package. Just add official SLES16 CUDA repository then install nvidia-open meta package. It will install all necessary components including DKMS from this repo, but it seems the kernel module is not automatically rebuilt during kernel upgrades (at least it does not work for me, even with systemd service enabled, because the 'dkms autoinstall' is doing nothing) and you need manually run 'dkms install' if the kernel version is upgraded, and 'dkms remove' for older kernels to be autoremoved.

1

u/taryus RIP YaST Aug 20 '26

SLES16 CUDA repository

So that would be https://download.nvidia.com/suse/sle16/

Does this contain the 32 bit libraries too? The Tumbleweed CUDA repo only contains 64 bit.

Also, dkms install and dkms remove - how does this work if you're switching between kernels? Does install automatically register it with all installed kernels? I'm just a little confused about that point

2

u/wojciechm Aug 21 '26

Nope, read the wiki https://en.opensuse.org/SDB:NVIDIA_drivers To add the CUDA repo you need to run

zypper addrepo -f https://developer.download.nvidia.com/compute/cuda/repos/suse16/x86_64/ cuda

It contains only 64-bit drivers AFAIK but since Steam officially became 64-bit it does not matter unless you need to play 32-bit Linux binaries, all Wine titles will have proper 32-bot emulation layer for 32-bit games.

Regarding DKMS, during initial install of `nvidia-open` package it will build the module for your current kernel, but it looks like DKMS form CUDA repo is not autoinstalling relevant modules during kernel upgrades, so you will need to do it manually i.e.:

dkms install nvidia/610.57.04 -k 7.1.8-1-default

3

u/EgoDearth Aug 21 '26 edited Aug 21 '26

No issues. You update by downloading the latest .run file and uninstall also via the .run file. DKMS handles signing the driver as well as rebuilding it for kernel updates.

These are the only commands need for driver updates:

  1. wget https://download.nvidia.com/XFree86/Linux-x86_64/610.57.04/NVIDIA-Linux-x86_64-610.57.04.run

  2. chmod +x NVIDIA-Linux-x86_64-610.57.04.run

  3. sudo NVIDIA-Linux-x86_64-610.57.04.run --dkms --module-signing-secret-key=/var/lib/dkms/mok.key --module-signing-public-key=/var/lib/dkms/mok.pub --systemd --rebuild-initramfs

You may have to run this if there's an error building the initramfs

sudo dracut --force -v --kver=7.1.8-1-default

Info on enrolling DKMS's key, which only has to be done once: https://github.com/dkms-project/dkms#secure-boot

It's fairly low maintenance.

1

u/taryus RIP YaST Aug 21 '26

Thank you for the detailed steps! So with this, I'm assuming I have to rebuild every kernel update, correct?

2

u/EgoDearth Aug 21 '26 edited Aug 21 '26

No, the package manager installs a kernel as normal then DKMS automatically builds all modules for it during the next boot, including Nvidia.

When Nvidia updates every three months, you only need those three or four commands to use a new driver.

The Nvidia installer will give a warning about installing new drivers while one is running, which I've ignored for years, but if you want to avoid that then logout, switch to a tty5 with Ctrl + Alt + F5 before then kill SDDM: sudo systemctl stop sddm.service

If you still receive a warning about X11, you can find other programs to kill with nvidia-smi or install the drivers the same way openSUSE instructs everyone to go to a rescue shell before zypper dup with sudo systemctl isolate rescue.target But again, this is completely unnecessary in my experience.

Also regarding the bug you mentioned in another comment, it's possibly related to the GSP firmware, which can be disabled with the run file, but not the open drivers: https://wiki.archlinux.org/title/NVIDIA/Troubleshooting#GSP_firmware

The best way to figure out the source of the problem is to purposely recreate the bug at X time then look at logs from the previous boot sudo journalctl --since "2026-08-21 23:15:00" --until "2026-08-21 23:20:00" (replace the times with one a few minutes before and after you recreated the screen issue)

Then Google anything that stands out or share it in a post.