You are not logged in.
I've run Arch linux on my laptop for dev work for years, now I have a newly built desktop computer, components:
Asus b850i motherboard with latest BIOS (1028)
9800x3d cpu
5090 gpu
48GB G.Skill 6000 cl28 ram
2x NVME SSD (samsung 9100 pro, hynix p41)
Corsair SF1000 PSU
I have read every single thread I've been able to find related to random restarts/shutdowns, including the Ryzen issues article on the arch wiki.
The PC dual boots Windows 11. It's stable in Windows. I've run days of stability testing for RAM and CPU since I'm mildly OCing ram and undervolting CPU (red flag, I know, more on this later).
Originally, I installed Arch on my secondary SSD. I got through the install, but once booted into Arch it would randomly shutdown after a while. I made sure to install nvidia-open and amd-ucode to see if that fixed the issue, but shutdowns persisted.
I feared the secondary SSD was overheating (no heatsink), so I pulled it out of my system and went to install on the primary SSD instead. While going through the install I got the same shutdown problems from the install media. I installed lm_sensors on the install media to verify that temps look OK. I read that shutdowns from install media can indicate hardware issues, or that linux might be giving the CPU too little voltage.
I've tried to boot with Curve Optimizer at -20, 0, +10 (a way of adjusting Ryzen AM5 CPU voltage). The Ryzen issues guide suggest setting it to +4, but if +10 doesn't work I'm fairly sure it's not a voltage issue.
I've tried with 2 different RAM OC profiles that are both stable in Windows. I tried with the EXPO profile (6000cl28), and I tried running the RAM without EXPO on the JEDEC default. Same issue with shutdown. I've completely reset BIOS settings. Shutdowns persist.
The shutdown looks like a completely normal shutdown, I caught it on video since it's so predictable. This particular shutdown is from arch install media, since I haven't wanted to complete a full install again until I figure out why it's shutting down: https://streamable.com/ghocxo
Since I'm reproducing the shutdowns from the arch install media, I don't currently have any `journalctl -1` logs to access.
Last edited by atlimar (2025-06-07 09:29:37)
Offline
Assuming default BIOS settings, and a newly built PC. Maybe you got a faulty power button cable, disconnect it and turn on the system with a screwdriver shorting the power button contacts.
Maybe try disabling acpi with the kernel boot parameter ```acpi=off```, and/or disabling the C-States from bios.
Try a newer archlinux iso, maybe is a kernel bug. https://archlinux.org/download/
Offline
was this the first time you build a system yourself? noob check: have you removed the plastic cover from the heatsink?
Offline
was this the first time you build a system yourself? noob check: have you removed the plastic cover from the heatsink?
Overheating CPUs would cause a sudden shutdown, not a graceful shutdown like the video in the post suggests. I originally thought overheating too, but a graceful shutdown like that isn't it.
My personal question, is it a shutdown or a reboot? A Shutdown would power off the computer, while a reboot would boot the PC up again. This is important, since it may be a hardware fault in your PC case's wiring, that Windows might be ignoring, but Arch isn't.
Try running Linux Mint's Live CD and see if it reproduces there. We can diagnose if it is a Linux Kernel issue or specific with Arch. We know Windows is ignoring whatever's going on.
If you're not having fun, what's the point of being an Enthusiast? :3
Offline
The PC dual boots Windows 11.
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
However as Xylerfox pointed out this is a controlled shutdown, ie. it was initiated by the system.
Eg. spurious trigger of the power button (), "cltr+alt+del opens the taskmanager?" ebkac - or a scheduled reboot signal from the acpi (see above)
But this isn't a hardware defect/emergency shutdown/power starvation and if you can reproduce this on the installed system, the journals there might easily record the trigger (I'm pretty sure sysrq and power buttons get logged)
Sidebar: when you're using your computer, do you stand next to it and turn your head by 90°?
Offline
Background: I'm an experienced PC builder, and fairly experienced at overclocking as well. Medium experience with Arch (I'm a programmer), but total noob when it comes to this particular instability issue. All the parts in the system are brand new. I've tested 5 different CPUs for the silicon lottery, and have remounted/repasted CPU and AIO multiple times, always checking to make sure there is no damage or debris in the CPU socket. I kept the CPU I was most satisfied with (under Windows). I've run extensive stress test stability suites (karhu, p95, y-cruncher, corecycler).
It's a (graceful) shutdown, not a reboot. System turns off completely.
99.9% certain it's not overheating, I installed lm_sensor from the arch install media, tctl shows the same CPU temps I'm used to seeing in HWiNFO in Windows, and no other temps look out of place.
I'll try with a different/older arch iso and linux mint to try to see if the one I have just so happens to be unstable, thanks for the tip.
Since I think I can rule out the overheating (which AFAIK would not cause a graceful shutdown), I get a sinking feeling this is a CPU IMC/RAM instability issue, which I guess could cause the graceful shutdown. However, running memory tests for dozens of hours suggests it's rock solid. As for voltage, which has been an issue with Ryzen previously, I don't know... raising voltage pretty high did not have any perceivable effect.
Offline
Neither heat nor voltage issues will cause this and it is *NOT* "instability"
Some input is triggering a shutdown.
Common causes are the power button (short connect, maybe also circuit?), sysrq (needs to be explicitly enabled, though), ctr+alt+del bursts - or the ACPI, ie. windows does this.
Offline
The PC dual boots Windows 11.
3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.
Thanks, did that now. I have an old dual boot arch/w11 laptop that I never changed this setting for and it's been running solidly so far, but I pretty much never boot into Windows.
However, I don't have Arch installed yet (I pulled that disk out of the system, and formatted the primary disk before reinstalling Win11). The reboots are happening while idling in the arch install media without having installed anything, so there should be no shared EFI partition conflict happening.
I've freshly reinstalled Win11 3 times in the last day trying different setups to work around the linux shutdown issue...
I can wipe the entire disk and test if I still see the issue with Arch on its own.
However as Xylerfox pointed out this is a controlled shutdown, ie. it was initiated by the system.
Eg. spurious trigger of the power button (), "cltr+alt+del opens the taskmanager?" ebkac - or a scheduled reboot signal from the acpi (see above)
Not entirely sure I follow, but I'll look into the acpi thing. I guess the acpi thing wouldn't be an issue if I install only Arch?
But this isn't a hardware defect/emergency shutdown/power starvation and if you can reproduce this on the installed system, the journals there might easily record the trigger (I'm pretty sure sysrq and power buttons get logged)
I could do a quick test run with archinstall script to see what the journal says when the system inevitably shuts down, thanks for the tip.
Last edited by atlimar (2025-06-03 20:46:41)
Offline
Neither heat nor voltage issues will cause this and it is *NOT* "instability"
Some input is triggering a shutdown.Common causes are the power button (short connect, maybe also circuit?), sysrq (needs to be explicitly enabled, though), ctr+alt+del bursts - or the ACPI, ie. windows does this.
Thanks, knowing that'll let me sleep tonight. I'll look into all of these specifically. I'll disconnect the power button cables and boot by shorting (I did this plenty of times before my chassi arrived), or via the "direct bios boot" key that the motherboard has. If it's the direct bios boot key causing the short it's possible to reconfigure it in bios to not function as a boot key, so I'll try that as well (no cables to disconnect here unfortunately...)
not familiar with sysrq, so I'm fairly sure I've not enabled that (especially since reboot is triggering from the install media itself, not just on the installed os).
It's eerily consistent in that it seems to take 10-20min, never less, never more.
Last edited by atlimar (2025-06-03 20:35:50)
Offline
I guess the acpi thing wouldn't be an issue if I install only Arch?
Clearing the ACPI (what that voodoo part likely achieves, but we never figured why this is required - it's purely anecdotal) will be more relevant that what's on some disk.
The reboots are happening while idling in the arch install media
UEFI power saving?
Can you prevent it by un-idling the system (frenetic keyboard use)?
Offline
UEFI power saving?
Can you prevent it by un-idling the system (frenetic keyboard use)?
I've had the reboots happen while actively doing things on the system, e.g. typing or updating packages
I still get reboots after fully disabling hibernation and fast boot in Windows (I went for the "safe" option just to make sure).
Offline
And do you have a journal?
Offline
And do you have a journal?
I finally do (it was an experience to speed run an arch install to completion with a random shutdown timer), and you were right:
https://i.imgur.com/bDZukJC.jpeg
Does "short" here mean that it was pressed briefly, or is the OS actually detecting an electrical short?
Last edited by atlimar (2025-06-06 12:33:40)
Offline
Trying to work around it with:
https://i.imgur.com/e85DTRi.jpeg
but it's still shutting down with the same message, so I must be doing something wrong
Last edited by atlimar (2025-06-06 12:33:51)
Offline
Please replace the oversized images (the board has a 250x250 rule) w/ links and generally also do not post pictures of text, post the text.
Also because it is like top posting.
Why not?
Please don't "-r".
So, on topic:
"short" here mean that it was pressed briefly
This. The benign case for this is that you put your finger onto the power button and gently and briefly push it, instead of pressing it all the way down and holding it there to squeeze the life out of the computer.
Did you reload logind or reboot after editing logind.conf (and before the next involutary reboot)?
The message there is from logind, so if the system is still rebooting (after the initial reboot after altering that file)
tail /etc/systemd/logind.conf /run/systemd/logind.conf /usr/local/lib/systemd/logind.conf /usr/lib/systemd/logind.conf /etc/systemd/logind.conf.d/*.conf /run/systemd/logind.conf.d/*.conf /usr/local/lib/systemd/logind.conf.d/*.conf /usr/lib/systemd/logind.conf.d/*.confand then post the journal of that boot (or its tail) so after a reboot
sudo journalctl -b -1 | tail -n250 # I guess that's enoughOffline
generally also do not post pictures of text, post the text
agreed. due to having to speed run the install, and having a few minutes at a time for setup, I have no way of getting the text out of the system short of ripping the nvme drive out and putting it in a different system. Had to skip network setup to install in time.
Wiggling power button didn't do it, appears to be the case cable (Lian Li A3) that's causing it. I pulled it and booted by shorting the pins, system has stayed on for 30min so far.
Did you reload logind or reboot after editing logind.conf (and before the next involutary reboot)?
yeah, reloaded it and (involuntarily) cold shutdown several times after making the edit. Might have broken the file syntax by echoing straight to it since I have no other way of editing it lol
Last edited by atlimar (2025-06-06 12:43:12)
Offline
Oh, yeah - you posted the entire file ![]()
[Login]
HandlePowerKey=ignoreini syntax, it has to be in the "[Login]" group.
Offline
well - to come back to "works on windows": unless you sometime in the past have changed the setting there the default behaviour should be the same
to verify please boot windows and check the energy management settings
Offline
With the chassi io cable disconnected the system stayed on for about 3h then it shut down on its own, same reason.
After a couple of tries I managed to echo the correct lines into logind.conf, only for the system to suspend instead about a minute later.
Sorry for the massive image of text, but in it it's possible to see me appending the line to logind.conf and restart the service before the logs "power key pressed short" followed by "suspend key pressed long". It managed to ignore the power off and ended up suspending instead.
https://i.imgur.com/mUkwmlv.jpeg
Fwiw, I no longer have w11 installed to rule those issues out.
Is it the mobo that's shot? Interestingly never saw any issues in windows
Offline
well - to come back to "works on windows": unless you sometime in the past have changed the setting there the default behaviour should be the same
to verify please boot windows and check the energy management settings
wiped disk today when installing arch again, so no w11. The windows install was fresh, default "balanced" power settings. It possible that I disabled the default 5min sleep timer, but other than that nothing changed. I've had the system running windows for about 4 months, in the past week I reinstalled w11 and arch, swapping nvme drives in and out.
The shutdowns happen within a few minutes any time I am in arch (real install or on installmedia), w11 stayed on for hours, never saw an unexpected suspend or shutdown since I built the system
Last edited by atlimar (2025-06-06 16:20:01)
Offline
well, to my knowledge APM and ACPI are hardware interrupts causing the cpu to switch context and execute whereever the corresponding intrrupt handler vector points to
even the "long press to power off" is implemented in such a way and hence can also be caught
but - as it's software in the that gets executed triggered by a hardware event so can interrupted triggered by software itself
I don't suspect malicious software at play here but rather it could hint to some malfunction that for some reason not had happen on windows
overall quite strange behaviour
sorry to maybe re-ask if already answred: have you tried other distributions like debian/ubuntu or suse?
anotner idea: what bootloader do you use? how about disable the timeout and have it sit on the boot menu without selecting linux to boot?
point is I'd like to narrow down if this something caused by windows' bootmgfw vs grub/systemd or one level higher up ntoskrnl vs linux kernel
can also be tested with a winPE instead of a full install
Offline
I don't suspect malicious software either, I've tried two separate arch versions, disk is wiped every time when reinstalling.
Next step is probably to try a different distro, but most of my hardware is only a few months old (as in, released a few months ago), so I guess it might struggle with non-rolling distros.
I've reconnected the chassi io cable since I had the shutdowns with it disconnected anyway. I've wiggled and re-connected the power cable and removed a couple of USB devices.
Letting it sit in systemd-boot https://i.imgur.com/NdpOXF4.jpeg for now
Are you suggesting I reinstall W11 again to do some testing there as well? With the extremely limited time I have in the arch install before the shutdown happens I'm probably not able to set up dual booting properly, so I'd have to wipe arch to install windows again.
Offline
https://imgur.com/mUkwmlv shows you appending the "ignore" to logind.conf, the "suspend" config is likely still there and takes precedence.
The bogus power connector fires, the system suspends in response.
The power connector firing is unlikely a software problem, if you cannot fix t he hardware itr, you can only ignore it, but that should™ mitigate the problem (unless it's just symptom of a wider HW defect)
Sidebar: what are you actually installing there? The install iso comes with vim and nano, you cannot use either of them to edit the file?
well, to my knowledge APM and ACPI are hardware interrupts causing the cpu to switch context and execute whereever the corresponding intrrupt handler vector points to
even the "long press to power off" is implemented in such a way and hence can also be caught
but - as it's software in the that gets executed triggered by a hardware event so can interrupted triggered by software itself
I don't suspect malicious software at play here but rather it could hint to some malfunction that for some reason not had happen on windows
overall quite strange behaviour
The bogus trigger could be caused by the firmware
acpi_osi=! acpi_osi="Windows 2015"https://learn.microsoft.com/en-us/windo … inacpi-osi
I mean, that's still wild and I'd consider an actual spurious short on the board to be more likely, but hey *shrug*
@atlimar, pelase get us a complete system journal
"sudo journalctl -b > /path/to/some/file.txt" - you can redirect it into a file on a usb key and post it from some other system.
Offline
Sidebar: what are you actually installing there? The install iso comes with vim and nano, you cannot use either of them to edit the file?
Since there isn't enough time to get through a manual install I just trigger the default archinstall script, which does not install any text editor. The system stayed on longer during one install process, so now it has ethernet and nano. Finally.
I can get a full journal, but I think I'm on to something. Yesterday I mentioned I reconnected power cable and disconnected some USB devices. After that the system stayed on 12h+ over night.
I started suspecting one of the USB devices (2.4ghz wireless keyboard). I connected it and walked away from the computer. 5 minutes later the system had powered down.
Is there a way I can definitely figure out if the power off signal is coming from the connected USB keyboard? AFAIK the keyboard does not have a physical power off button, so I can't test by pressing buttons on it.
Last edited by atlimar (2025-06-07 08:34:41)
Offline
evtestOffline