This is how it normally sits. I did try it with a minimal set of kernel params, so it’s not all that fluff there Specifically, they were: quiet security=selinux selinux=1 amd_pstate=active psi=1 mitigations=auto
Strange about the monitors. Both of those are on, which is nice because I’m watching a game on one and typing to you on the other
Haha yeh, I admit I was tempted to just edit it, since I knew it had been tested without all that noise, but I wanted to shoot straight and give you what you asked for. I did reboot and test it one more time just to be certain that it works the same without, so you can safely pretend all those parms dont exist.
This installation has been riding the “are we nvidia yet” train for a couple of years, and half the kernel options are accumulated workarounds for various bugs that have been fixed meanwhile. It’s my intention to reinstall from scratch when this driver works, so I’ll clean everything then. The ‘nuke it from orbit’ approach to a stock install
Odd, OP’s logs are for X11 failing. Perhaps you have a different issue?
That seemed promising but permissive mode didn’t help. I wonder if maybe I need to set permissive and reinstall the driver, as in, maybe selinux interfered with the build or the installation. I’ll try that tomorrow.
Obviously this is common but not widespread, I really don’t feel the need to ring an alarm bell here now, but I don’t know where to log this against…kernel, driver, DE, selinux… other? I guess we’ll figure it out eventually
Link above, is not us. It describes black screen, with inability to render, where I see lots of distorted colourful imagery. I tried without that option regardless, to no avail. Thanks tho ernold!
fbdev and nvidia_drm.nomodeset are not existing parameters. nvidia_drm.fbdev is (see above link), and nvidia_drm.modeset, is, and is usually required for any GUI and USED to be packaged with the driver in a conf file which is why I removed it from my command line when I started testing 555/560 drivers - yes, I do actually clean up those params if the need presents itself You gave me the hint to try it and I’m happy to say it worked!
So, I don’t know what happened to 50-nvidia-default.conf but I’m going to go make my kernel command line longer again. This is what I get for cleaning up my mess on my PC. I’ never cleaning again!
THANK YOU ALL for helping!! @Maverick1024@ramdomPTM pinging you so you notice this has the fix in it
or:
It’s obvious that all of you have something specifying the modeset param for the nvidia_drm module. What is that something?
Do you all have the old config file still? Is there a new config file that didn’t roll out to a few of us? I know from your reports that you didn’t put it in your command lines, and obviously the files are not in the current package or I’d have them, so what unpackaged file do you have which provides this parameter?
Thanks for the tip, but actually I experimented carefully with only one of nvidia tumbleweed and cuda repo enabled and all driver package installed solely from that one repo. I do know the importance of not mixing repos here, and just want to test if newer display drivers from cuda repo would work. Still, thank you for your notification!
Me too. For now I’m switching to Plasma X11 session.
I do have options nvidia-drm modeset=1 fbdev=1 in /usr/lib/modprobe.d/50-nvidia-default.conf. If I read it right, the problem is that nvidia_drm.fbdev=1 is no longer valid. Please enlighten me what kernel parameters do I need to add to boot.
Aha, the file has moved, that’s why I could only find the .rpmsave… Thanks!
Strange though, I also have that file… and it’s obviously not working because I needed the param in my kernel command line.
Ahh, that would make sense, I guess the implication here is, that KDE was relying on fbdev functoning, which is why mine worked, because I had that on… Until it broke in 6.11, and then without being able to use fbdev, KDE relies on kms, and thus requires the nvidia_drm.modeset=1 to replace the now-missing fbdev.
This is what I have for the nvidia modules in my kernel command line, right now:
Pretty sure that last one is not relevant, the second one is not functional (6.11/550.107 bug), and the first one is redundant because it’s in that config file. So, I’ve zero clue how it became broken or how I’ve fixed it.
Hey this is my first post here and I just wanted to thank you/confirm a lot of things you’ve said here. I found this thread way too late as a relatively new user to linux/tumbleweed. In one of your original replies you mentioned how weird the behavior was with the semi-unresponsive plasma, and I suspect this is exactly what is happening on my machine because it sounded similar to my issue.
I don’t really tweak things or customize settings, I use “Stock” KDE tumbleweed as it were. I checked a lot of things people suggested here just from my own troubleshooting experiences; for example reinstalling drivers, checking different repos and even installing the 560 driver. Nothing was working for me, though I did notice x11 worked like others suggested. I rolled back to 6.10 and figured I would wait or see something on reddit but started to sweat when I didn’t, which brought me here.
Anyway, I can confirm that adding nvidia_drm.modeset=1 nvidia_drm.fbdev=1 to my kernel command line worked for me, so thanks!
Also as an additional piece of confirmation I too have nvidia-drm modeset=1 fbdev=1 in /usr/lib/modprobe.d/50-nvidia-default.conf
It depends on your definition of the “latest”. Technically driver is built for the target of /usr/src/linux-obj/x86_64/default symlink. This link is created by the kernel-default-devel package which has been installed last. That in your case this package also has the latest version is just a coincidence (although that is the most common case during normal update workflow).
You can do one of
Manually adjust symlinks /usr/src/linux and /usr/src/linux-obj/x86_64/default to point to the desired version and install the driver package.
Or - if you already installed the driver package - simply reinstall kernel-default-devel for the desired version. Assuming this package is still available of course (which probably is no more the case for Tumbleweed).
In both cases you will be left with symlinks pointing to some older kernel, which may result in driver update not building driver for the latest kernel version. Same problem in reverse direction.
It would be nice to have a script that builds driver for the specific kernel version and that could be used both by driver package and manually. Currently driver packages inline all necessary actions. Any takers?
Braves of heart could look at the output of rpm -q --trigggers nvidia-driver-G06-kmp-default and manually do the same.
Yes, adding “nvidia_drm.modeset=1” and “nvidia_drm.fbdev=1” to grub did the trick for me (with 6.11 & 550.107.02 & RTX4080 & plasma & wayland), too! So it seems that “50-nvidia-default.conf” (which contains those settings) is ignored!
Specifically, they were:
