Ever since Kernel 6.1 got introduced, my system running Fedora 37 is unable to shut down or reboot properly. What’s curious about this, is the fact that it doesn’t necessarily happens on every single occasion. It’s most likely to happen if the system was running for a while.
The exact symptoms are the following:
The mouse and keyboard get turned off like expected
The display stays on, stuck at the Fedora logo/splash screen, pressing ESC during the shutdown process doesn’t reveal any (obvious) error messages (No picture yet)
The system stays powered on with all the LEDs, Fans spinning etc.
It doesn’t matter how long I wait for the system to finally power off, it just doesn’t happen (The longest I waited were over 2 hours so far until I long pressed the power button)
Mostly the same as above, except it still kind of works.
Instead of getting stuck forever, the system shuts down und turns itself on again (similar to changing specific settings in the UEFI. Example: turning virtualization on/off)
I noticed that entering the UEFI setup before booting Fedora 37 seems to prevent the issue so far
My USB DAC stays on after shutting down my system, regardless of the Kernel Version. Never happened on Windows and not with openSUSE Tumbleweed last time I checked
As hinted before, any 6.0 Kernel works just fine without any issues
The first Kernel Version that displayed this behaviour was 6.1.7, because I had to skip 6.1.5 and 6.1.6 because of Nvidia related issues back then
Nothing has changed with Kernel 6.2.7
Fast Boot is disabled in the UEFI settings
About my system
Nvidia Graphics, using latest akmod-nvidia from RPMFusion
Using an external VPN App (Wireguard) that offers official support for Fedora 37
After searching around, it looks like there are more people affected by this as well:
Common denominators: All of them on Fedora 37, often Nvidia Graphics, occuring since Kernel 6.1.X
Trying to replicate the issue with Tumbleweed on a spare Disk
Posting journalctl logs the next time it happens
Trying without the VPN App, just in case
Trying to replicate the issue without my USB DAC
Checking if the Nvidia 530.XX Driver helps, as soon as RPMFusion releases them
As you can probably tell, this is a VERY frustrating issue and staying on EOL Kernels is absolutely NOT an long term solution. I would greatly appreciate help with troubleshooting this, because I simply can’t continue using Fedora if this persists any longer.
If the system is doing the automatic update when it boots it will (for me) seem to boot, then shutdown and reboot at least once before it reaches the login screen. This happens unexpectedly if I fail to note the checkbox in the restart or power off popup before I click to confirm.
I am unsure what may be causing the delay in shutdown, but it could be the same. It may be trying to download the updates, cannot, so hangs while trying to do so and never completes the shutdown.
Please note the final confirmation popup when shutting down or rebooting and if that checkbox is in the popup then uncheck it so you may be able to confirm if it is the update causing the delays and apparent reboots.
If it is the updates causing the delays one simple workaround could be to manually do a dnf upgrade from the command line before shutting down so the offline upgrade has nothing to do.
Seems like I found the culprit. After updating the VPN App, the issues went away. It has been multiple days already and I have not encountered a single problem so far. That was unthinkable before.
If it wasn’t for that, I would have updated my packages before shutting down like you suggested, but for troubleshooting purposes I did only one change at a time in order to catch the root of the issue.
I feel silly for not doing that sooner, but what’s (not) done, is (not) done.
Well, if you turn it around, buggy/incompatible/broken USB devices can absolutely prevent a system from successfully booting altogether.
Considering how flaky mainline Linux Kernels can be sometimes with the rapid development behind them (no critique btw) it does make me wonder. Same goes for Fedora, it’s not a rolling release but quite close in terms of updates. Plus each Distro has it’s own patchsets etc.
But yeah, I’m just making assumptions here. Not denying that.
Here is a bugreport on the Redhat Bugzilla regarding the issues since Kernel 6.1:
What I meant was taking the bug that a few different people (including myself) encounter more serious. And we’re talking about quite different hardware setups here, as described in the reddit posts.
Troubleshooting tips would be greatly appreciated but so far no one from the Fedora Team commented on this.
So if it’s not buggy firmware on our end that gets triggered by upstream changes on the kernel site for example, it will probably not get fixed.
I see you can shut your system down with the 6.2 series, congrats. Even thought that wasn’t the fix for your system, I will check out the mentioned settings in the UEFI, those are available on my machine as well.
BTW, earlier today I encountered the issue even at the end of an offline system update. That was a first one. I assume during offline updates only a very minimal set of of the OS gets loaded so that might help narrowing the cause down?
That was the one time I didn’t enter the UEFI setup before booting Fedora, so I will keep watching this.
That makes it a real puzzle — a lot of similar but not identical reports across a wide array of hardware suggests that there isn’t just one simple issue. And there is a lot of diverse hardware. On top of that, with the closed-source Nvidia driver being a possibile common factor, there’s often not much we could even do.
I’m not quite sure what you mean by this. Or rather, I have a guess, but if that guess is right, you have a misconception. We don’t have anything in the project we call “the Fedora Team”. Instead, we have many different teams (largely of volunteers) that work together to make this all work. Ask Fedora and the people you have been interacting with are all part of that. And by helping us figure it out, you are too.
Good point and that’s why I mentioned all the external things that I added to my system. Be it the proprietary Nvidia Drivers or a VPN App.
I mean someone responsible for kernel related issues, development etc. that might give me and other affected people troubleshooting tips. And maybe if that person can even reproduce it, since it got mentioned before.
I will definitely keep an eye one this, because there are quirks on my system that could indicate that something is up with the firmware, yet again everything is fine with kernel 6.0.X and any other operating system that I’ve used before. So as of now it’s pretty inconclusive and could be either way.
In the time you replied, I had to edit my previous post a lot. Does the aforementioned part
This is the dilemma, we do have to report on bugzilla.redhat.com that someone is looking in to it.
But just reporting is not enough, we do have to deliver enough information that they can try to reproduce it. And in my case I use older Hardware 2013. Quite a challenge not just for us as requester, to find a conses what causes the issue also for them on Bugzilla to give us some advice’s what we can do.
I know and I will join the discussion for Bug 2179634 on the redhat bugzilla after I’ve done some additional testing and get more time on my hand.
It helps IMO not just asking for help in bugtrackers but on official community forums as well. Linking relevant posts from other platforms like reddit too. It’s about making this issue and discussions about it as easily discoverable as possible.
I’m sure you have already tried it but after you have ran dnf upgrade when you reboot have you hit the esc key to go to the shutdown screen and watched what seems to be hanging up or causing the issue.
It’s interesting, but hard to know what to do with. To me, it suggests that there’s some underlying problem which is more likely to happen with the full system — not that the full system has something that causes it, but that for some reason the minimal environment is less likely to trigger the issue.