Help with Nvidia drivers, Fedora 42

Hello, everyone!
I recently built a gaming PC and decided to go with fedora as it worked very well on my thinkpad.

I followed the RPM fusion guide and before following any steps made sure my system was up-to date and I had met any prerequisites.

I first followed the secure boot steps and then the how to/nvidia steps.
Everything went according to the guide and I thought it would work but after a reboot, I get a black screen after choosing fedora from the boot menu. I tried the guide multiple times with the same steps but nothing seems to work.

Does anyone have a solution? Is anyone facing the same issue?

Hi,

Here is how I install NVIDIA drivers, and I’m a noob, and it worked so far for me:

But I disabled Secure Boot, it’s just too much PITA with Linux. I never got NVIDIA drivers to work reliably with Secure Boot on any distro I tried.

I have a 3080 and a 4080 though. I saw some people having difficulties with the 5000 series.

Also, NVIDIA drivers will break often with kernel updates.

I’ll try this first thing tomorrow. I am incredibly tired from this. I also dread the kernel updates now… I was thinking of getting an amd GPU and I just might in the near future.

Yeah, I was gonna say, but didn’t want to talk down your newly purchased hardware: if you’re building or buying a PC with intentions to put Linux on it, it still makes more sense to get an AMD GPU.

The ā€œNVIDIA situationā€ is improving, but very slowly. Though, even AMD GPUs aren’t entirely issues-free either: VRR/Freesync/GSYNC is still not working well for many users under Wayland on both AMD and NVIDIA.

So, I’m on the fence, sell my GPUs or wait and see what develops in a year or so. But yeah, I feel burnt out and tired too. My NVIDIA drivers died three times since December or so, and I’m not even using Linux full time yet :frowning:

First I changed from Windows to Linux and the second step was to get rid of Nvidia. Since then my live with Linux is a pleasure. Then there was the issue with Realtek network adapters and its drivers. Till I realized my second network-adapter is Intel, since then I avoid the RTL one :slight_smile:

While planing to buy new hardware it makes sens to have a look at https://linux-hardware.org/ to get an idea if there are troubles with it.

2 Likes

Woah, I didn’t know something like this existed! Thanks for sharing.
Yeah, I really am thinking about getting an amd gpu and just be done with it. I’ll try nobara and maybe cachy once but if they don’t work, I’ll use windows till I get an amd gpu.

Lots of Windows switchers are in this situation as NVIDIA is far more popular than AMD on the Windows side, though that may be changing because of the way NVIDIA has been behaving recently.

So most of us have NVIDIA GPUs and we’re trying to make it work with what we have. And I’m not too fond of the idea of selling my RTX4080 that is not even two years old, it works great on Windows. On top of this, it is really a bad time now to buy a GPU, even AMD GPUs are badly overpriced right now.

And I second the Realtek issues: I have problems with both Realtek on-board NIC and Realtek onboard audio on my main (newer) PC that are as bad as my NVIDIA issues.

So, I’d need a new network card, a new audio interface and a new GPU. So Linux may be free but there may be significant monetary costs associated with a Windows->Linux switch.

Besides, many AMD GPU owners still have VRR/Freesync issues under Wayland, so getting an AMD GPU may not even solve all of my Linux issues.

I don’t even know if I want to do it any more. I’m running into too many issues and I don’t hate Windows that much and I have it under control (I build custom ISO installers). I may need to wait couple of years when I build a new PC then I might consider Linux again and do a more targeted build for Linux.

I understand your struggles, I really do. I too have suffered because of realtek.
I still have linux but on this system, I just want to play games, watch movies and shows in peace. I can’t do that unless I get over this nvidia issue and it doesn’t look like thats going to be happening anytime soon. At least definitely not with fedora, might try nobara and if that doesn’t work, I’ll try cachy.

If that fails, I can only conclude that linux isn’t ready for a full on switch.

There is zero useful info posted here to even give a hint at the issue.

See. Howto/NVIDIA - RPM Fusion

I can barely remember my last nvidia issue as it was so long ago, 5 or 6 years, it was minor, a display port sound issue.

Do you have a high refresh rate GSYNC monitor?

How do your NVDIA drivers not break with every kernel update? What is the secret?

Are you on Wayland or X11?

I generally like Linux. I have three Debian servers: Nextcloud, web server and NAS/File server and they’re great.

But desktop Linux is an uphill battle.

I’m waiting to see what Debian 13 KDE brings. I tried the preview but it was too unstable.

I used the rpm fusion guide to install it on my RTX3090, and it has been working fine for ages — several years and many upgrades of both OS, kernel, and drivers. It even works with secure boot.

The if not true, then false guide could be useful as well, so I am leaving a link here.

However, I have not moved to Wayland yet… I am guessing that will be a pain.

No high res or gsync, my monitor is quite old.

$ inxi -GSCm
System:
  Host: leigh-pc Kernel: 6.14.3-300.fc42.x86_64 arch: x86_64 bits: 64
  Desktop: Cinnamon v: 6.4.8 Distro: Fedora Linux 42 (Cinnamon)
Memory:
  System RAM: total: 64 GiB available: 62.65 GiB used: 3.75 GiB (6.0%)
  Array-1: capacity: 128 GiB slots: 4 modules: 4 EC: None
  Device-1: DIMM_A1 type: DDR4 size: 16 GiB speed: 2133 MT/s
  Device-2: DIMM_A2 type: DDR4 size: 16 GiB speed: 2133 MT/s
  Device-3: DIMM_B1 type: DDR4 size: 16 GiB speed: 2133 MT/s
  Device-4: DIMM_B2 type: DDR4 size: 16 GiB speed: 2133 MT/s
CPU:
  Info: 8-core model: AMD Ryzen 7 5700 bits: 64 type: MT MCP cache: L2: 4 MiB
  Speed (MHz): avg: 2383 min/max: 400/4654 cores: 1: 2383 2: 2383 3: 2383
    4: 2383 5: 2383 6: 2383 7: 2383 8: 2383 9: 2383 10: 2383 11: 2383 12: 2383
    13: 2383 14: 2383 15: 2383 16: 2383
Graphics:
  Device-1: NVIDIA TU117 [GeForce GTX 1650] driver: nvidia v: 570.144
  Display: x11 server: X.Org v: 21.1.16 with: Xwayland v: 24.1.6 driver: X:
    loaded: nvidia unloaded: modesetting,nouveau gpu: nvidia,nvidia-nvswitch
    resolution: 3840x2160~60Hz
  API: EGL v: 1.5 drivers: nvidia platforms: gbm,x11,surfaceless,device
  API: OpenGL v: 4.6.0 vendor: nvidia v: 570.144 renderer: NVIDIA GeForce
    GTX 1650/PCIe/SSE2
  API: Vulkan v: 1.4.309 drivers: N/A surfaces: xcb,xlib
  Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
    gpu: nvidia-settings,nvidia-smi wl: wayland-info x11: xdriinfo, xdpyinfo,
    xprop, xrandr

It rarely breaks on kernel updates, I still need to address kernel-6.16rc support for the rpmfusion driver.
I alway use dnf cli to update.

I use both Wayland and X11 on Cinnamon

It’s much better under X11. Wayland is the problem. It needs like another 20 years to mature and get the basics right.

OK, so… I do, and it does not work properly under Wayland. There is heavy flickering and screen turns often black when alt-tabbing out of a game. BTW, AMD owners have this problem too.

I have been told at least twice on this forum alone that NVIDIA drivers must be reinstalled/rebuilt with every major kernel update and yeah, it broke three times since December, on two different PCs, one with 3080 (twice) and one with 4080 (once, but I only used it for few days).

All I did was run a system update in Discovery and reboot and the driver reverted to Nouveau and had to reinstall. There were frequent posts from people who had this problem too. Do you sacrifice a goat or spit over your right shoulder before running system updates? Because I have no clue what I’m doing wrong and I’m close to giving up because it’s way too frustrating.

I use dnf to update and wait long enough after the transaction completes to allow enough time for the nvidia driver to rebuild for the new kernel.

I sacrifice a dozen users each time I update the driver, they are cheaper and easier to find than virgins.

My experience is similar to Leigh’s. I have been using Fedora and with rpmfusion’s nvidia packages for many years. Current configuration:

āÆ inxi -GSCm
System:
  Host: pico Kernel: 6.14.2-300.fc42.x86_64 arch: x86_64 bits: 64
  Desktop: GNOME v: 48.1 Distro: Fedora Linux 42 (Workstation Edition)
Memory:
  System RAM: total: 32 GiB available: 31.24 GiB used: 4.16 GiB (13.3%)
  Array-1: capacity: 128 GiB slots: 4 modules: 4 EC: None
  Device-1: DIMM_A1 type: DDR4 size: 8 GiB speed: 3000 MT/s
  Device-2: DIMM_A2 type: DDR4 size: 8 GiB speed: 3000 MT/s
  Device-3: DIMM_B1 type: DDR4 size: 8 GiB speed: 3000 MT/s
  Device-4: DIMM_B2 type: DDR4 size: 8 GiB speed: 3000 MT/s
CPU:
  Info: 12-core model: AMD Ryzen 9 5900X bits: 64 type: MT MCP cache:
    L2: 6 MiB
  Speed (MHz): avg: 1964 min/max: 550/5622 cores: 1: 1964 2: 1964 3: 1964
    4: 1964 5: 1964 6: 1964 7: 1964 8: 1964 9: 1964 10: 1964 11: 1964 12: 1964
    13: 1964 14: 1964 15: 1964 16: 1964 17: 1964 18: 1964 19: 1964 20: 1964
    21: 1964 22: 1964 23: 1964 24: 1964
Graphics:
  Device-1: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] driver: nvidia
    v: 570.133.07
  Device-2: Logitech Logitech Webcam C920-C driver: snd-usb-audio,uvcvideo
    type: USB
  Display: wayland server: X.Org v: 24.1.6 with: Xwayland v: 24.1.6
    compositor: gnome-shell driver: X: loaded: nouveau
    unloaded: fbdev,modesetting,vesa gpu: nvidia,nvidia-nvswitch resolution:
    1: 2560x1440~60Hz 2: 2560x1440~60Hz
  API: EGL v: 1.5 drivers: nvidia
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6.0 vendor: nvidia v: 570.133.07 renderer: NVIDIA
    GeForce RTX 3060/PCIe/SSE2
  Info: Tools: api: eglinfo,glxinfo gpu: nvidia-settings,nvidia-smi
    x11: xdriinfo, xdpyinfo, xprop, xrandr

There are occasional problems with a new kernel but rare and mostly due to timing of release from rpmfusion and the kernel team. As Leigh notes, always wait after an update from rpmfusion is installed before a reboot. I typically open the system monitor (gnome) and check the CPU trace.

I use Wayland exclusively, and no issues here. VRR is a different matter though. But this is mostly an issue with the EDID table reported by the monitor. I had to create and install a custom EDID table for my monitor on Windows as well to prevent this.

Each kernel version requires a rebuilt of the nvidia kernel modules, and akmods does take care of this. You ONLY need to wait a few minutes before reboot.
dnf info last will show a new transaction with the status OK.
You will also find a new kmod-nvidia package installed with rpm -qa kmod-nvidia\*

See, this is what I’m talking about: how the heck is an average user supposed to know this? How much time is ā€œenoughā€? Five minutes? Ten minutes? Why isn’t Discovery doing this properly? Is there a warning anywhere? Stuff like is frustrating and discouraging for new users.

I reboot when Discovery (KDE software manager/store) tells me to reboot. If this is the wrong way of doing updates then it’s a major UI/UX design flaw. And I have no idea what ā€œCPU traceā€ is and I shouldn’t need to know.

The entire Linux graphics subsystem is just too fragile. I’m not a software engineer but this entire ā€œdrivers are built into the kernelā€ Linux thing just seems bizzare and the biggest reason for Linux driver issues and failures. On Windows I can just install a driver without ever worrying about the kernel or ā€œrebuildingā€ the drivers and there isn’t even a need to reboot.

It works fine in Windows without any tinkering. The only times it flickers slightly is during some static content inside the game, like loading screens or menus and even that is rare. Under Wayland the flickering is nauseating, unusable.

There is no flickering under X11 though.

it does not matter, if you reboot to early, then the next boot will take much longer, because akmods will compile and install the needed kernel modules.
But it’s best to wait for a few minutes and give the system time to finish the job. Check with rpm / dnf or look at /var/log/akmods/akmods.log

We probably mean different types of ā€˜flickering’.
Monitor would go dark for 1-2 seconds, like a mode switch.
I had to increase the lower VRR limit frequency from 24Hz to 48Hz.

If you mean some textures are corrupted / flickering then this is something else. I leave VRR disabled. because importing a custom EDID table deactivates VRR on current stable 570.* drivers anyway. This was implemented in the new BETA 575* driver, but I had no time yet to test.

Fedora 42 with 575.51.02 beta NVIDIA drivers