4 ms·
Interesting experience, not one I can corroborate myself. So a few weeks ago I updated to Fedora 41. (Updating from N-2 -> N is supposed to be fully supported)
by mroche 2y ago
Interesting experience, not one I can corroborate myself.
So a few weeks ago I updated to Fedora 41. (Updating from N-2 -> N is supposed to be fully supported)
Correct, and I do believe F39 -> F41 was tested, but every system will be a little bit different.
I wasn't surprised that it broke my nvidia driver's dkms integration - I don't expect any distro to test their integration of the market leader GPU manufacturer.
Fedora actually does test this. What driver installation method are you using? Unless you are using NVIDIA GRID for vGPU or need to use a very specific version of the generic Linux driver, use RPM Fusion's akmod-nvidia package[0]. Normal DKMS via NVIDIA's modularity CUDA repositories or the binary installer can be fraught with issues that users don't deserve. Rather than just installing the kmods directly, an akmod package will build an RPM for the modules and install that. You'll know well in advance if there's a problem before you reboot, nor have to twiddle your thumbs during the upgrade transactions. Just give the system an extra minute after running a kernel update before rebooting (watching "ps aux" for "dnf", "kmod", and "rpm" helps). Several system configurations regarding module parameters and initramfs boot options are included as well.
I finally did this today (I have a GTX 1070), but configuring my kernel parameters[1] to disable NVIDIA's fbdev allows me to once again have alternate console TTYs. Despite being an experimental option, it is enabled by default in newer drivers and it conflicts with another framebuffer. For the past few Fedora releases since it was flipped on I've had to use a second device to SSH to my system after the version upgrade to gracefully reboot once the driver module package rebuilt. The akmod rebuild trigger doesn't stall the offline upgrade reboot, so the driver isn't prepared in time for first boot. My standard practice is configuring my system to the multi-user target before issuing an offline version upgrade, then switching back after.
the system was suspended. When I wake it up, the screen is also locked. That was weird, as I have disabled all power mgment features, and I have also passwordless autologin on this machine. Then looking at some of the logs, it turned out that xdg-desktop-portal segfaulted in the middle of the night, which in turn killed all user sessions and processes and logged me out. And then it ignored my powermgmt settings, and sent the machine to sleep.
That is definitely a new one to me. In addition to your searching, did you happen to follow through with Fedora's problem reporting checklist[3]? It's not a mandatory step, but it can be incredibly helpful having these issues documented and brought to engineering's attention.
[0]: https://rpmfusion.org/Howto/NVIDIA https://rpmfusion.org/Howto/NVIDIA (alternatively just enable the NVIDIA driver specific repository pre-provided by Fedora: dnf config-manager --enable rpmfusion-nonfree-nvidia-driver)
[1]: grubby --update-kernel=ALL --args="nvidia-drm.fbdev=0" && dracut -f
[2]: https://docs.fedoraproject.org/en-US/quick-docs/bugzilla-file-a-bug/ https://docs.fedoraproject.org/en-US/quick-docs/bugzilla-fil...