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!)
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
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.
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.
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!
Anyone got an update on this problem? I’ve been suffering from this issue since it occurred, and I’ve been using the rpmfusion and nvidia-drm.modeset=1 for years. Did a clean install today to still no avail.
I suspect I may be suffering worse as I’m using the LUKS encryption and don’t even manage to load the password entry screen.
