Hello,
There is a problem with my laptop with Fedora 42 KDE where, when shutting the system down, on some occasions the screen will freeze with the loading spinner always stuck in the same position (the only solution is to forcefully shut it down). When I have been able to bring up the output with ESC in Plymouth, nothing useful showed up:
[ OK ] Stopped user@1000.service - User Manager for UID 1000
Stopping systemd-oomd.service - Userspace Out-Of-Memory (OOM) Killer...
Stopping systemd-user-sessions.service - Permit User Sessions...
Stopping uresourced.service - User resource assignment daemon...
Stopping user-runtime-dir@1000.service - User Runtime Directory /run/user/1000...
[ OK ] Stopped systemd-oomd.service - Userspace Out-Of-Memory (O0M) Killer.
[ OK ] Started plymouth-poweroff.service - Show Plymouth Power Off Screen.
[ OK ] Unmounted run-user-1000.mount - /run/user/1000.
[ OK ] Stopped dnsconfd.service - Dns local cache services configuration daemon.
[ OK ] Stopped systemd-user-sessions.service - Permit User Sessions.
[ OK ] Stopped user-runtime-dir@1000.service - User Runtime Directory /run/user/1000.
[ OK ] Removed slice user-1000.slice - User Slice of UID 1000.
[ OK ] Stopped target remote-fs.target - Remote File Systems.
[ OK ] Stopped target remote-fs-pre.target - Preparation for Remote File Systems.
[ OK ] Stopped target nfs-client.target - NFS client services.
Stopping gssproxy.service - GSSAPI Proxy Daemon...
Stopping systemd-homed-activate.service - Home Area Activation...
Stopping systemd-logind.service - User Login Management...
When the problem does not take place, the spinner gets stuck in that same position for a second, then speeds up before the screen properly turns off.
I have not found a reliable way to reproduce it. It also happens when shutting down from SDDM before logging in. It never happens with either Plymouth disabled (by removing the rhgb quiet kernel command line arguments) or with acpi=strict.
I am using an Asus Zenbook 14 UM3406KA with an AMD Ryzen AI 7 350. My root partition is encrypted with LUKS.