Post written by me and polished using AI
Hi everyone,
I’m dealing with a very strange issue on my Framework Laptop 16 running Manjaro, and after several days of troubleshooting I’m running out of ideas.
The issue
Since August 3rd, my laptop has started powering off after approximately one hour of use.
The problem originally appeared while I was troubleshooting a separate issue with the USB-C ports on the left side of the laptop. That USB issue is still present, but it’s much less impactful, so for now I’m focusing on the shutdown problem.
The shutdown looks like a hard power-off, rather than a normal systemd shutdown. I haven’t found evidence in the journal of a normal shutdown sequence immediately before it happens.
Why I don’t think it’s simply a hardware problem
I’ve tested several different boot environments, with some very interesting results:
| Environment | Result |
|---|---|
| BIOS/UEFI | Stable for >1 hour |
| Installed Manjaro, normal boot | Powers off after ~1 hour |
Installed Manjaro, multi-user.target |
Powers off after ~1 hour |
Installed Manjaro, rescue.target |
Powers off after ~1 hour |
Installed Manjaro, emergency.target |
Stable for >1 hour |
| Older Manjaro Live USB | Stable for >1 hour |
| Newly created Manjaro Live USB | Powers off after ~1 hour |
The last result is what confused me the most.
Today, as a last resort, I was planning to reinstall the entire OS. Unfortunately, I overwrote the old Live USB that had previously remained stable.
Before reinstalling, I booted the newly created Manjaro Live USB and deliberately left it running for over an hour.
It powered off too.
So now the problem is reproducible both on my installed system and on the new Manjaro Live environment, while it was not reproducible on the older Live USB.
Things I’ve already tested
I’ve tried quite a few things while narrowing this down:
-
Tested different kernels on the installed Manjaro system, including 6.18 and 6.12: the issue remained.
-
Booting with
systemd.unit=multi-user.target: still powers off. -
Booting into
rescue.target: still powers off. -
Booting into
emergency.target: stays powered on beyond the usual shutdown point. -
Running with
systemd-inhibit: did not prevent the shutdown. -
Disabled/masked several non-essential and recently added services, including VPN/cloud/container/cron/power-related services: still powers off.
-
Checked the hardware watchdog:
sp5100_tco/ SP5100 TCO is present.- Its timeout is 60 seconds, but the watchdog is inactive.
- systemd runtime watchdog is disabled.
- I haven’t found any obvious one-hour systemd timer responsible for the shutdown.
-
The journal does not appear to show a normal shutdown sequence before the machine dies.
-
BIOS can remain open well beyond one hour without shutting down.
The fact that emergency.target works but rescue.target does not seems particularly interesting to me, since presumably something initialized between those two environments could be triggering the problem.
The old vs new Live USB behavior also makes me wonder whether this could be related to a kernel, kernel module, firmware interaction, or something included in newer Manjaro images, rather than my installed userspace configuration.
Possibly related USB-C issue
Around the same time, I started having problems with the USB-C ports on the left side of the Framework.
I have seen errors such as:
ucsi_acpi USBC000:00 failed to reset PPM
error -ETIMEDOUT: PPM init failed
I don’t know whether this is related to the shutdown problem or just coincidental.
The USB-C problem was actually what I was troubleshooting when the shutdown behavior first started.
Where I’m stuck
At this point I’m very confused about what could produce this combination:
- BIOS → works
- emergency.target → works
- rescue.target → fails
- normal Manjaro → fails
- older Live USB → worked
- new Manjaro Live USB → fails
- different installed kernels → fail
This makes a straightforward hardware failure seem unlikely, but the fact that a completely separate Live environment now reproduces it also makes an installed-system configuration problem seem unlikely.
My main question is:
What gets initialized in rescue.target / a normal Live environment that is not initialized in emergency.target, and how can I systematically narrow that down?
I’d be extremely grateful for any ideas about where to look next.
I’m happy to run commands, collect logs, compare loaded kernel modules/services between emergency.target and rescue.target, test kernel parameters, or provide any other output that could help diagnose this.
Thanks!