Update 4: Kernel 6.0.18 works!
Update 3: According to users on Reddit, 6.0.17 still exhibit the problem. One user said that 6.0.18 has the fix.
Update 2: Decided to remove the back kernel package using the dnf remove command in the previous update rather then dnf history since I only wanted to remove the kernel. That removed the .16 kernel from the boot loader and had the .15 as the default.
sudo dnf remove $(rpm -qa | grep ^kernel | grep 16-300)
Update: Seems like others are also affected by the same issue with a suggestion on how to remove and block the 6.0.16 kernel.
sudo dnf remove $(rpm -qa | grep ^kernel | grep 16)
# Bad packages excludepkgs=kernel*-6.0.16-300.fc37.x86_64
Tracking bugs on Fedora:
- https://bugzilla.kernel.org/show_bug.cgi?id=216895 (what the developers are commenting on)
- https://bugzilla.redhat.com/show_bug.cgi?id=2158496 (says that 6.1 kernel works)
- https://bugzilla.redhat.com/show_bug.cgi?id=2158977 (likely duplicate of first)
- https://bugzilla.redhat.com/show_bug.cgi?id=2158932 (likely duplicate of first)
- https://bugzilla.redhat.com/show_bug.cgi?id=2158615 (likely duplicate of first)
Today I did a typical update of my Fedora system which included a new kernel (kernel-6.0.16-300.fc37.x86_64), but when I rebooted and logged in the system will freeze. This might be the first time (or at least it's been a long time) that I've had a Fedora upgrade not be seamless.
Fortunately, when Fedora upgrades the kernel, it keeps copies of the previous two versions so switching back simply requires watching for the GRUB boot loading screen and picking the previous kernel. Just make sure you do this before the system automatically boots to the latest version.
I was able to determine the freeze is caused by the kernel since booting the previous kernel showed no problems after logging in. Knowing that I have at least one working kernel, I had two choices. Uninstall the latest kernel or keep using the old one and wait to see if any future updates fixes the problem.
I've not uninstalled a kernel on Fedora before and was unsure what would happen. I could also simply try to revert the entire update, but that still leaves the same question. Using dnf, you can review what was done by:
sudo dnf history
To see the details of a specific transaction, use the ID that the history command gives and use:
sudo dnf history info <id>
With dnf, you can chose to undo or rollback a transaction. Undo will do the opposite of what was done (e.g. uninstall or reinstall the packages) of the specific reaction while rollback will undo everything between the between the transaction and the current system.
Since I didn't want to do either since this involved the kernel, I decided to just keep rebooting to the previous kernel even though it is inconvenient and hope that it gets a fix for whatever is causing the problem.
Protecting the Previous Kernel
What if it took a few more kernel updates before the problem gets fixed and the working kernel gets removed during the update?
The versionlock plugin will lock and keep the kernel on the system.
sudo dnf install python3-dnf-plugins-extras-versionlock sudo dnf versionlock add kernel-6.0.15-300.fc37.x86_64
sudo dnf versionlock delete kernel-6.0.15-300.fc37.x86_64