Unable to shutdown

Which Linux distro are you using?

Unraid

Which release version?
7.1.4

Which kernel are you using?

Linux version 6.12.24-Unraid (root@Develop) (gcc (GCC) 14.2.0, GNU ld version 2.44-slack151) #1 SMP PREEMPT_DYNAMIC Sat May 3 00:12:52 PDT 2025

Which BIOS version are you using?

LFSP0.03.00 06/13/2025

Which Framework Desktop model are you using? (AMD Ryzen™ AI Max 300 Series)

AMD Ryzen AI MAX+ 395 w/Radeon 8060s with 128GB of memory motherboard in custom case.

Issue

I’m having a somewhat frustrating issue right now that I can’t seem to be able to figure out. Whenever I command the PC to shutdown (using poweroff command in Unraid or through the Web UI), the system goes through the shutdown process and actually turns off. I see the power button LED turn off and the keyboard LEDs turn off, then about 1 second later, the computer comes back on and starts the boot process again.

I’ve looked through /var/log/syslog for both startup and shutdown and nothing suspicious jumps out at me.

Has anyone else encountered similar issues and were able to resolve them?

Does anyone have any ideas on how to troubleshot this further?

Hope someone with actual Unraid experience on the Desktop will chime in soon.

In the meantime: have you tried looking through the USB / LAN / other IO Bios settings? Sounds like something might be waking up the Desktop. IIRC there was a setting to not provide power to USB ports when turned off. Maybe there is also a more obvious wake toggle or something in the settings for another port like LAN.

Where is the setting to not provide power to USB devices when shutdown? I would like to try that but I’m not seeing it. I’m also not seeing anything related to LAN. I do see wake on lan options but I have those disabled.

This might be a bug in the EC code.
At power off, when it switches off, remove the PSU for 60 seconds, and plug back in.
When you power off or reboot, the EC is not restarted. It is only restarted if you also unplug the PSU.

This might resolve the poweroff issues, as in after those steps, it should then poweroff without restarting in 1 second.

I attempted unplugging the power supply from the wall twice for 60 seconds each time. After each time I tried doing a graceful shutdown and the system still immediately rebooted. So that doesn’t appear to have fixed the issue.

It might be a hardware problem.

Can you boot from a Linux Live CD of another distro, like Debian or Ubuntu or Fedora.
Then do a “poweroff” and see if if works.
That way, one will know if the problem is hardware related (if it does the same in fedora) or is software related (only does the problem in unraid).

Ok, I will give that a shot. I’m out of time trying to debug this though, so I’ll have to respond later.

Ok, I was able to find some time. I created a Ubuntu 25.10 bootable USB drive. I booted it up, opened up a terminal, and typed poweroff. The system was successfully able to power off.

So I don’t think it’s a hardware issue, it seem to be related to the unraid OS.

I created a topic on the unraid forums as well: https://forums.unraid.net/bug-reports/stable-releases/714-unable-to-shutdown-on-framework-ai-max-395-motherboard-r4115/

Well, at least that is progress. We now know its a software problem and not a hardware problem.
Things like power off are low level stuff. So, this normally means Linux kernel related.

Your unraid one is:
Linux version 6.12.24

Ubuntu 25.10 is:
Linux version 6.17

So, if you can install a more recent kernel version than 6.12.24, you might make some progress towards fixing this.

I ran Unraid as my primary OS on Framework Desktop for a whole and did not have the problem you describe. Then again, I had upgraded to the 7.2 beta for usb4 support.

As a side note, I ended up ditching Unraid as my primary OS because I could not get Bazzite running in a VM with GPU passthrough on Unraid. Im currently doing the reverse, running Unraid in a VM with Bazzite OS as primary.

It is related the kernel version unraid is using and the the near cutting edge hardware you are trying to run it on. You will need near the latest kernel (6.16 / 6.17) for full hardware support. Remember all of the drivers, including the chipset and power management are backed into the kernel.

Linux kernels are portable. You could take the kernel files from Ubuntu and use them in unraid and it would boot.
Those files are the kernel file in /boot and all the files in /lib/modules.
Then do a mkinitrd in unraid, using them.

1 Like

Unraid 7.2 doesn’t seem to change the kernel version over 7.1, so interesting that the problem was not there.

I will try updating to 7.2 RC1 and see if it fixes it. And if it doesn’t, I’ll try manually changing the kernel.

You might be seeing

If you can build your own kernel you can confirm by reverting the identified commit or applying the series I wrote which is reported to help.

To follow up, I updated to unraid 7.2 RC2 and it did not fix the issue.

I decided to try cutting power off for an extended period of time again to see if it resolved the issue, but this time while monitoring the motherboard LEDs inside the case to make sure the motherboard was fully powered off.

After unplugging the power cable, I waited what seemed like 5 minutes, and at least 2 motherboard LEDs remained on. The SFF PSU I have doesn’t have a power switch, so that wasn’t an option. I eventually gave up waiting for the LEDs to turn off and I physically unplugged the motherboard from the power supply. The power supply must have some very large capacitors to provide power for that long to the motherboard while it has no A/C power coming in.

After the motherboard LEDs were off, I waited a couple of minutes, plugged the PSU back to the motherboard, connected the system to A/C power and turned on the system. I then tried the shut down again. I was then able to shutdown correctly using unraid without the system coming back on immediately.

This seems like a combination of OS and motherboard BIOS issue given full power cycle and Ubuntu 25.10 both allowed the system to shutdown correctly.

Did you look at the link I shared? There is a kernel commit identified that can cause a race condition at shutdown. Apply the patches linked in there. They’re reported to help.

I did look at it. But the issue is no longer there after I took the previous steps, so I would not be able to try it and see if it fixes the issue.

I have the same Framework Desktop running Fedora 42 and have the same issue. The desktop shuts down all the way and then turn on by itself about 10 seconds later.