Talk: Proprietary Nvidia driver shows a black screen instead of a virtual terminal or a graphical session

Sorry, missed your comment before. Yes, it does look good to me.

Fedora + CSM + nvidia proprietary drivers

In Fedora34 I have options video=vesa:off and vga=0x034d.
Fullhd bootlog and consoles without artifacts and freezes.
And, of course working X.

In Fedora36:

nvidia-drm.modeset=1 or 0 — does not matter.
video=vesa:off and vga=0x034d gives fullhd boot log and VTs (boot log draws an artfact: colored line during a few seconds while boot), X shows black screen

initcall_blacklist=simpledrm_platform_driver_init gives not text while booti process and in VTs (colored line only) but working X (well, no frame buffer in this case)

removing video=vesa:off and vga=0x034d gives low-resolution boot log and console, which freezes after exiting from mc and some other commands (old clean/clear console bug?), and working X.

Somehow I’ve got 1280x1024 console at secondary display (HDMI-1-1, not primary DP-4), but not sure how to reproduce it. No VTs at primary display in this case, but X always starts at primary one. UP: this works if both nvidia-drm.modeset and i915.modeset=1, i915 needed for secondary monitor which pluged-in to motherboard, intel card works like a proxy for nvidia.

The question is: is it possible to get in Fedora 36 behavior of Fedora 34 which works fine? Atm VTs of Fedora 36 are unusable and looks ugly, if you want to use X.

Do you keep in mind that system can use both, nvidia and intel card drivers at the same time?

Yes, but that shouldn’t be relevant for this particular issue. Basically what the workaround does is just to revert to the old behaviour when nvidia-drm.modeset=1 is set.

Ok, In the situation where nvidia-drm and i915 have modesetes set to 1 and display connected to nvidia card shows _ (lowline «cursor») in VT while display connected to motherboard (intel card as a proxy to nvidia one) shows normal VT (maximal resolution, no freezes)… Is there any solution for this situation to get working VT at nvidia display in maximal resolution without freezes as it was in Fedora 34 with fbdev? Or the only option is to wait while nvidia add support for simpledrm/whatever to drivers?

It can’t matter yet, because the patched kernel build is not yet available. Please follow the linked bugzilla tickets to learn when they are and provide feedback there, thanks.

Since I wanted to promote the topic to the main #common-issues category, I transferred the whole discussion here into the “Talk” page. When the new workaround is available, feel free to ping me and I’ll update the issue description.

1 Like

I’ve noticed something similar, but I don’t know, if it is related.

Hardware and software:

  • OS: Fedora 36 Silverblue
  • AMD Ryzen 5 2600
  • nVidia Geforce GTX 1060 6gb
  • 16gb 3200mHz DDR4 RAM

When I switch to a virtual terminal, not exactly a black screen but weird graphical glitches are shown. The login screen and the Gnome session are working just fine (although the latter freezes from time to time under heavier load). These glitches are happening both with the nouveau and the proprietary nVidia driver (I did a rollback to an earlier deployment from before I installed the driver from RPMFusion).


These are the mentioned glitches

I couldn’t even get the sudo dnf system-upgrade process to run (in the post-reboot stage), the update attempts kept bailing out as soon as they started with dependency errors in the journal:

May 28 15:13:51 dnf[910]:   Cannot find rpm nevra "kmod-nvidia-470xx-5.17.7-200.fc35.x86_64-3:470.103.01-1.fc35.x86_64".

May 28 15:36:16 dnf[912]:  Problem: package kmod-nvidia-470xx-5.17.7-200.fc35.x86_64-3:470.129.06-1.fc35.x86_64 requires kernel-uname-r = 5.17.7-200.fc>
May 28 15:36:16 dnf[912]:   - problem with installed package kmod-nvidia-470xx-5.17.7-200.fc35.x86_64-3:470.129.06-1.fc35.x86_64

…Dunno why, it’s never been a problem before. So I ripped out all of the proprietary bits, rebooted into Wayland, and did the upgrade again with no problems.

I was going to reinstall the proprietary drivers after I was up and running in F36, but honestly now that I’m playing video in VLC (using the OpenGL surface output)… I might just stick with Nouveau.

(As the driver version implies, my card is an out-of-date — and underpowered — GeForce GT 710, so it barely has hardware decoding (MPEG and x264, but no x265 or vp9), doesn’t need a firmware download to function, and it’s been locked out of CUDA completely since the 10.x series. So, there isn’t really much I gain from the proprietary drivers, as long as Nouveau is able to render video without tearing or dropped frames. Which, seemingly, it might be!)

The solution is simple folks.

1/ Remove all nvidia drivers with sudo dnf remove "*nvidia*"

2/ Install the rpm-nonfree repo for Fedora 36, and remove negative17 (if installed) with sudo rm /etc/yum.repos.d/fedora-nvidia.repo.

3/ And then install the rawhide latest/beta rpm-nonfree, and follow the setups listed here, this will install the latest 515 drivers that have all the patches that takes care of the above issue! Source: Howto/NVIDIA - RPM Fusion

The steps are:

sudo dnf install "kernel-devel-uname-r >= $(uname -r)"
sudo dnf update -y
sudo dnf copr enable kwizart/nvidia-driver-rawhide -y
sudo dnf install rpmfusion-nonfree-release-rawhide -y
sudo dnf --enablerepo=rpmfusion-nonfree-rawhide install akmod-nvidia xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda --nogpgcheck

Anyone who installs Rawhide packages into Fedora 36 (or any release version) is asking for trouble, IMHO. Most of the reports here specifically mentioned the rpmfusion drivers, not negativo17’s, so the differentiator is likely the driver version.

If this really is a problem with the 510 drivers, and the 515 drivers contain the fix, then those need to get packaged up for F36 proper. I don’t even see them in rpmfusion-nonfree-updates-testing for F36, so they don’t seem to be on the horizon.

Is there an RPMFusion bug report open regarding the 510 drivers in F36, and is Kwizart aware that the 515 drivers fix the issue?

I am experiencing the described behaviour on f35 after performing the most recent update to kernel 5.17.11-200.fc35.x86_64 (and several other packages) in combination with the proprietary nvidia-driver (version 510.68.02-1.fc35) installed through negativo17’s repo.
The GPU inside my mobile workstation is a Quadro P1000 (GP107GL-A).

By choosing an older kernel (5.17.7-200.fc35.x86_64) through grub, luckily I still can start my system.

Then, when comparing the systemd-journals of the recent boots i get through the still working kernel, I can see that

  • for kernel 5.17.7 there are fb-related entries of :

kernel: efifb: probing for efifb
kernel: efifb: No BGRT, not showing boot graphics
kernel: efifb: framebuffer at 0x71000000, using 8100k, total 8100k
kernel: efifb: mode is 1920x1080x32, linelength=7680, pages=1
kernel: efifb: scrolling: redraw
kernel: efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
kernel: Console: switching to colour frame buffer device 240x67
kernel: fb0: EFI VGA frame buffer device

  • while with 5.17.11 this section reads:

kernel: [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
kernel: Console: switching to colour frame buffer device 240x67
kernel: simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device

Then later, at about thei height where the journal-entries stop for kernel 5.17.11, one of the first lines that are only present on the still working kernel read

systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:nvidia_0.

which might be an indication that this is indeed related to the proprietary nvidia driver as described in one of the earlier posts.

For me, it is not an option to go back to nouveau because I too often need cuda and rawhide… well… not on my productive system please.

So in essence: the issue described seems not only limited to Fedora 36 but also seems to be affecting Fedora 35 systems. And fingers crossed that there will be a fixed driver soon.

@javierm maybe you want to consider updating the workaround mentioning staying on f35?

I don’t know if it’s due to the same underlying issue, but I too have the same symptom of a blank screen in Fedora 35 (not 36) starting with kernel 5.17.11: Blank screen when booting kernel 5.17.11

Nope, not the driver version, negativo has 515 and it does not work! What did work was the rawhide version because it is patched!

1 Like

Mmm, looks like Leigh has been working on it to disable simpleDRM when running with the Nvidia driver. I guess that integration isn’t as ready for prime time as everyone thought.

The good news is, I see the same patches being applied to the F36 packages, so once they make it out of testing the issue should be solved with the unofficially-official drivers too.

Hi, this should be fixed (the simpledrm change reverted) in kernel 5.17.12, currently in updates-testing.

I have updated the Workarounds section in Proprietary Nvidia driver shows a black screen instead of a virtual terminal or a graphical session to talk about the new nvidia-drm.modeset=1 workaround.

Fedora 36 does not work nvidia 515.48.07 driver (from cuda).

Workaround: Old kernel 5.16.20-200 (from fedora 35) does work with nvidia 515.48.07

I reported the problem at Bug report for fedora 36 (with x11, RTX 2060 Rev. 1) - Linux - NVIDIA Developer Forums for kernels 5.17.13-300 and 5.18.5-200.

I just tested the nvidia-drm.modeset=1 solution and it works for me!

All works fine; please see my solution above! And here’s a screenshot.

FYI, Wakeland also works well, but for things like zoom, I just chose to continue using xorg for now. You can choose either from the login screen (settings wheel at the bottom right of the screen).

Also, I do not use any kernel flags like nvidia-drm.modeset, I removed them all!