I just installed F38 fresh on my i9-12900 desktop. This time I went with GNOME as most of the instructions for installing Nvidia drivers seem to address this configuration rather than KDE which I normally use.
I tried installing the rpmfusion Nvidia 530 drivers using the Software app after updating the OS.
I get a black screen on reboot (actually there were a couple of short, broken horizontal lines momentarily displayed and then it was black).
I reinstalled on the same M.2 drive a second time, updated, rebooted, installed the Nvidia drivers, rebooted and black screen again.
I’m making the most uncomplicated changes to get the Nvidia drivers working which the non-free option in the Software app gives the impression of allowing.
F38 was working fine with Nouveau, of course.
Why is getting Nvidia drivers working still this bad? The machine runs Windows 11 perfectly fine with any graphics card I stick in it.
FWIW, I upgraded my 7950X machine from F37 to F38 with no problems, but that machine currently has a Radeon 6800 in it.
How do I get an installation of F38 running with an Nvidia card?
I’m going to reinstall F38 for the third time, and try the rpmfusion installation instructions which have worked in the past, but I thought that installing via the Software app would basically do this for me and yield a working F38 installation with an Nvidia GPU. I don’t see why going the manual rpmfusion route should have any better chance of success than simply requesting the Nvidia drivers are installed using the app that comes with the system for that purpose.
Weird situation: I left the desktop to go and complain on the laptop. When I just came back to the desktop it’s logged into Fedora 38. Still no working Nvidia driver however. There was some interminable timeout in the nouveau driver which was backed into because the Nvidia wouldn’t load - the “normal” situation for me it appears:
Again, this is vanilla Fedora 38, with the OS updated with the latest bits, and then the Nvidia driver installed from Software. It looks to me that it’d do exactly the same as manually installing rpmfusion would.
Agh! False alarm. Screwed over by Secure Boot yet again. It was on in the BIOS (I updated it a few weeks ago but had mostly been using a new build). Turned it off and now I have an Nvidia driver via the Software app like normal people.
So, it was mea culpa: it’s not “still this bad” getting Nvidia drivers working on Fedora. However, it’d be really great if something would tell me/you that Nvidia drivers aren’t working because Secure Boot is on and the drivers aren’t signed. Obviously, they’re not signed by default or installing the Nvidia drivers would have worked without a hitch with Secure Boot enabled in the BIOS and I wouldn’t look like an idiot.
Lets do a little troubleshooting instead of repeatedly reinstalling.
As Einstein said → “The definition of insanity is doing the same thing repeatedly and expecting different results” (probably paraphrased there).
Please post the output of lsmod | grep nvidia (if anything) and dnf list installed '*nvidia*'
Note that this configures secure boot to sign the kernel modules when they are built but does not sign the modules already installed.
To get the modules already installed signed you would need to dnf remove kmod-nvidia-* followed by dnf reinstall akmod-nvidia then wait about 5 minutes before you reboot.
You should then be able to enable secure boot and the kernel modules will be automatically signed as they are built and can load with secure boot enabled from that point forward.
Thanks. I couldn’t produce any information from the system because I couldn’t log into it - I had a black screen and nothing else. Hence the re-installation.
Don’t you think there’s a larger issue of not knowing why the driver install fails? Does everyone make sure their BIOS has Secure Boot disabled first? Normally I do have it disabled but a BIOS update several weeks ago silently re-enabled it. There’s no indication when installing drivers that it should be, that I could see, and there’s nothing about driver signing in the Software utility, although there is verbiage about the proprietary nature of the drivers, the Unified Driver Architecture and what you can do with them, etc.
I installed GNOME this time because I expected that through Software there’d be a painless installation experience since it specifically includes Nvidia drivers. I suppose that would include signing the drivers if Secure Boot is enabled. I expected it to Just Work ™ but nope. I can’t be the only one running afoul of this? It’s especially egregious when you go through the install process, it doesn’t warn about Secure Boot or driver signing, you reboot, and you’re met with a black screen and can’t get access to your machine, which is why I re-installed: the first time there was no indication that it would eventually show a login screen because I didn’t wait 20 minutes (only about 5).
The second time I left the machine in the black screen state long enough that the BIOS put it into a low power state. When I restarted it by momentarily depressing the power button it now showed the usual login screen. So apparently the Nvidia driver was replaced by the blacklisted Nouveau driver after the machine had suspended and restarted. That was even more confusing: again, no indication of what was happening just that it wasn’t working then 20 minutes later it seemed that it was.
You may have stumbled onto the same (transient?) issue as I did when upgrading just now. The fedora-updates repo serves a more reent kernel than the base repo, but somehow it seems that the maintainers forgot to include the matching kernel-headers RPM in fedora-updates.
[nsmeds-x1(nsmeds):~] sudo dnf list --all kernel.x86_64 kernel-headers.x86_64
Last metadata expiration check: 0:44:16 ago on Tue 25 Apr 2023 15:33:40 CEST.
Installed Packages
kernel.x86_64 6.2.11-200.fc37 @updates
kernel.x86_64 6.2.12-200.fc37 @updates
kernel-headers.x86_64 6.2.6-300.fc38 @fedora
Available Packages
kernel.x86_64 6.2.12-300.fc38 updates
The kernel-headers package version number does not always match the most recent kernel version. If there are no updates to the headers the version number remains the same – sometimes for several upgrade releases.
It does not mean the kernel-core and kernel-headers do not match, merely that they have continued to match for all the kernel package upgrades since that header package was released.