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:
Shutdown
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)
Reboot
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)
Additional Info
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
What’s next
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.
So far I can say that doing manual offline updates with gnome software (packagekit) doesn’t prevent it. The options for automatic updates in gnome software are disabled for all users.
So wouldn’t that involve the same components under the hood + Gnome Software on top ?
And that’s the output from the last unsuccessfull shutdown on my screen:
[33940.586199] systemd-shutdown[1]: Failed to finalize DM devices, ignoring.
[33943.286015] reboot: Power down
I would like to paste the journalctl log in here too, but it seems to be too long. What would be the proper way to do that in here?
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.
After an entire week of no issues, it happened again. Now I do sudo dnf upgrade before every system shutdown for some time now and will continue to monitor the situation.
Quite frustrating to deal with this.
Here are some more people experiencing pretty much the same thing:
Well, doing a system update by sudo dnf upgrade before shutting down doesn’t work either.
I will try the UEFI setup trick next, as mentioned in my first post.
By the way, it seems even my printer hangs during shutdowns while connected to my Fedora 37 PC via USB.
This is what happens:
Press the power button (Starting the printer)
Print something
Press the power button (Power off)
Printer doesn’t turn off and gets stuck on the “shutdown screen”, like the PC on Fedora 37 with Kernel 6.1.X and 6.2.X. Reminder: Kernel 6.0.X works flawlessly.
This happened before, but I shrugged it of as a coincidence up until now.
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:
Why should they acknowledging an issue they not have ?
I also made a topic but not using Nvidia. Mine was simply rebooting even if I just was shutdown. I had to cklick the power button again to switch it off.
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.
No, not with running sudo dnf upgrade before shutting the system down.
Under these circumstances there never is anything unusual to be seen there, not even in the journalctl logs. And that’s what other affected people noticed as well.
I will just disable the disable the splash screen later, so I don’t have to press ESC manually.
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.