[SOLVED] F38: New Install, Familiar Nvidia Problem

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.

1 Like

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:

Apr 24 14:56:25 fedora kernel: ------------[ cut here ]------------
Apr 24 14:56:25 fedora kernel: nouveau 0000:01:00.0: timeout
Apr 24 14:56:25 fedora kernel: WARNING: CPU: 10 PID: 2301 at drivers/gpu/drm/nouveau/nvkm/engine/disp/gv100.c:724 gv100_disp_core_idle.isra.0+0xd0/0xe0 [nouveau]
Apr 24 14:56:25 fedora kernel: Modules linked in: rfcomm snd_seq_dummy snd_hrtimer nouveau drm_ttm_helper nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntra>
Apr 24 14:56:25 fedora kernel:  videobuf2_vmalloc iwlwifi kvm_intel videobuf2_memops btintel snd_seq iTCO_wdt videobuf2_v4l2 intel_pmc_bxt mei_hdcp mei_pxp snd_seq_device btmtk kvm pmt_telemetry videobuf2_common iTCO_vendor_support cfg80211 bluetooth irqbypass pmt_class snd_pcm videodev rapl sn>
Apr 24 14:56:25 fedora kernel: CPU: 10 PID: 2301 Comm: kworker/u48:34 Tainted: G        W          6.2.11-300.fc38.x86_64 #1
Apr 24 14:56:25 fedora kernel: Hardware name: Micro-Star International Co., Ltd. MS-7D30/MPG Z690 CARBON WIFI (MS-7D30), BIOS 1.A0 01/10/2023
Apr 24 14:56:25 fedora kernel: Workqueue: events_unbound async_run_entry_fn
Apr 24 14:56:25 fedora kernel: RIP: 0010:gv100_disp_core_idle.isra.0+0xd0/0xe0 [nouveau]
Apr 24 14:56:25 fedora kernel: Code: 8b 40 10 48 8b 78 10 48 8b 5f 50 48 85 db 75 03 48 8b 1f e8 82 59 27 e9 48 89 da 48 c7 c7 0a c9 95 c1 48 89 c6 e8 00 8b 8e e8 <0f> 0b b8 f0 ff ff ff eb ae e8 b2 f2 73 e9 66 90 90 90 90 90 90 90
Apr 24 14:56:25 fedora kernel: RSP: 0018:ffffa703416cbbb0 EFLAGS: 00010286
Apr 24 14:56:25 fedora kernel: RAX: 0000000000000000 RBX: ffff8e84c3254db0 RCX: 0000000000000000
Apr 24 14:56:25 fedora kernel: RDX: 0000000000000002 RSI: 0000000000000027 RDI: 00000000ffffffff
Apr 24 14:56:25 fedora kernel: RBP: ffff8e84c6719800 R08: ffffffffac064780 R09: 00000000ad97365f
Apr 24 14:56:25 fedora kernel: R10: ffffffffffffffff R11: ffffffffac119cd0 R12: 0000000000000001
Apr 24 14:56:25 fedora kernel: R13: ffffffffc195317f R14: ffff8e84d265ecf8 R15: ffff8e84d265ece8
Apr 24 14:56:25 fedora kernel: FS:  0000000000000000(0000) GS:ffff8e93ff480000(0000) knlGS:0000000000000000
Apr 24 14:56:25 fedora kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Apr 24 14:56:25 fedora kernel: CR2: 00007f85866dbfcc CR3: 00000009c6010004 CR4: 0000000000770ee0
Apr 24 14:56:25 fedora kernel: PKRU: 55555554
Apr 24 14:56:25 fedora kernel: Call Trace:
Apr 24 14:56:25 fedora kernel:  <TASK>
Apr 24 14:56:25 fedora kernel:  gv100_disp_core_fini+0x40/0x90 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_disp_chan_fini+0x1b/0x40 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_object_fini+0xb5/0x240 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_object_fini+0x71/0x240 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_object_fini+0x71/0x240 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_object_fini+0x71/0x240 [nouveau]
Apr 24 14:56:25 fedora kernel:  nvkm_object_fini+0x71/0x240 [nouveau]
Apr 24 14:56:25 fedora kernel:  nouveau_do_suspend+0xf5/0x280 [nouveau]
Apr 24 14:56:25 fedora kernel:  nouveau_pmops_suspend+0x2e/0x70 [nouveau]
Apr 24 14:56:25 fedora kernel:  pci_pm_suspend+0x78/0x170
Apr 24 14:56:25 fedora kernel:  ? __pfx_pci_pm_suspend+0x10/0x10
Apr 24 14:56:25 fedora kernel:  dpm_run_callback+0x89/0x1e0
Apr 24 14:56:25 fedora kernel:  __device_suspend+0x10a/0x560
Apr 24 14:56:25 fedora kernel:  async_suspend+0x1a/0x70
Apr 24 14:56:25 fedora kernel:  async_run_entry_fn+0x2d/0x130
Apr 24 14:56:25 fedora kernel:  process_one_work+0x1c4/0x3d0
Apr 24 14:56:25 fedora kernel:  worker_thread+0x4d/0x380
Apr 24 14:56:25 fedora kernel:  ? __pfx_worker_thread+0x10/0x10
Apr 24 14:56:25 fedora kernel:  kthread+0xe6/0x110
Apr 24 14:56:25 fedora kernel:  ? __pfx_kthread+0x10/0x10
Apr 24 14:56:25 fedora kernel:  ret_from_fork+0x29/0x50
Apr 24 14:56:25 fedora kernel:  </TASK>
Apr 24 14:56:25 fedora kernel: ---[ end trace 0000000000000000 ]---

There are several of these timeouts in journalctl. At least I can get into the system to access journalctl.

The repo list and grub file contents look OK to me:

$ sudo dnf repolist
repo id                                                                                                    repo name
copr:copr.fedorainfracloud.org:phracek:PyCharm                                                             Copr repo for PyCharm owned by phracek
fedora                                                                                                     Fedora 38 - x86_64
fedora-cisco-openh264                                                                                      Fedora 38 openh264 (From Cisco) - x86_64
fedora-modular                                                                                             Fedora Modular 38 - x86_64
google-chrome                                                                                              google-chrome
rpmfusion-nonfree-nvidia-driver                                                                            RPM Fusion for Fedora 38 - Nonfree - NVIDIA Driver
rpmfusion-nonfree-steam                                                                                    RPM Fusion for Fedora 38 - Nonfree - Steam
updates                                                                                                    Fedora 38 - x86_64 - Updates
updates-modular                                                                                            Fedora Modular 38 - x86_64 - Updates
$ cat /etc/default/grub 
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_CMDLINE_LINUX="rd.driver.blacklist=nouveau modprobe.blacklist=nouveau rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau"

Don’t know why the blacklist and modprobe entries are in there twice

inxi thinks I have an Nvidia card, but not an Nvidia driver:

$ inxi -G
  Device-1: Intel AlderLake-S GT1 driver: i915 v: kernel
  Device-2: NVIDIA GA106 [GeForce RTX 3060 Lite Hash Rate] driver: nouveau
    v: kernel
  Display: wayland server: X.Org v: 22.1.9 with: Xwayland v: 22.1.9
    compositor: gnome-shell v: 44.0 driver: dri: nouveau gpu: nouveau
    resolution: 1: 2560x1440~60Hz 2: 2560x1440~60Hz
  API: OpenGL v: 4.3 Mesa 23.0.2 renderer: NV176

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*'

1 Like

You can sign the nvidia drivers yourself by following the directions on rpmfusion
or the instructions in the file located at /usr/share/doc/akmods/README.secureboot

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.

The kernel headers have not changed between versions there is no need to rebuild the package. This is unrelated to whatever issue here.