Framework 13 suspends mid-boot

Framework Laptop 13 Linux
1

I use my laptop with an external monitor, mouse and keyboard. The lid is usually closed, and I start it by connecting power. Roughly 1 in 3 boot attempts result in the laptop going to sleep mid boot. When I open the lid, I see how the internal screen turns back on after a few seconds and then the boot log starts scrolling again. This issue has bothered me since this laptop came out. I don’t know how many Fedora versions, BIOS updates and kernels I had, but here my current setup:

Fedora 42
AMD Ryzen 7840U
External Dock: CalDigit TS4 with a 4k monitor attached

2

Can you try to install amd-debug-tools and the s2idle hook? Once you have reproduced it with the hook in place run:

amd-s2idle report --report-debug --format=txt

Share that report somewhere.

Here is the details:

3

I did not run the tool yet. But the problem is actually that my external monitor only turns on after GNOME has fully started. And since logind starts before GNOME, it thinks there is no monitor and suspends.

Creating this file works around my issue: /etc/systemd/logind.conf.d/dont-suspend-with-lid-closed.conf:

[Login]
HandleLidSwitchExternalPower=ignore

The underlying problem here is that by default Grub and Linux only post to the same display to which the BIOS posts. So the real solution would be to implement BIOS on External Monitor

4

Good job root causing this. You can probably avoid it by loading amdgpu earlier then too.

You should report this bug to fedora and to upstream.

5

Amdgpu is one of the earliest things my kernel loads. GNOME happens 10+ seconds later. This isn’t a Fedora issue either, but rather UEFI related. My Thinkpad T430i has the same problem. But there I can solve it by enabling “show BIOS on external monitors”. Then grub and Linux will pick it up by default and everything just works. Unfortunately Framework’s BIOS has no such option.

6

I would still argue it’s a logind bug. Logind should wait until boot is complete to make this decision.

When I said earlier - you can potentially compile it in instead of initramfs, but distros don’t usually have appetite for that decision.