Hibernation hangs and kills the keyboard on Apple T2 Macs #9237

What happened

Ran systemctl hibernate (via omarchy hibernation setup configured earlier) on an Apple T2 MacBook Air. The screen took a long time to turn off, then the machine hard-froze mid-hibernate — no shutdown, no resume, keyboard completely unresponsive. Had to hold the power button to force a reboot. The machine came up as a fresh cold boot rather than resuming the hibernation image (session state was lost).

What was expected

Either hibernation works and resumes cleanly, or it's not offered/blocked on hardware where it's known not to work, so the user isn't left with a hung, unresponsive machine.

Steps to reproduce

1. On an Apple T2 Mac, run omarchy hibernation setup and reboot.
2. Trigger hibernate (systemctl hibernate, or Hibernate from the System menu).
3. Wait — the screen stays on unusually long before turning off.
4. The machine never fully powers off/resumes; keyboard and screen are unresponsive. Only a hard power-off recovers it.

Diagnostics

journalctl -b -1 from the affected boot:

13:40:32 systemd-logind: hibernate requested from client PID ... ('systemctl') ...
13:40:32 systemd-logind: The system will hibernate now!
13:40:34 systemd[1]: Starting System Hibernate...
13:40:34 kernel: PM: hibernation: hibernation entry
13:41:27 kernel: Filesystems sync: 0.037 seconds     <- 53s later, and then...

...nothing else. The journal for that boot ends there — no shutdown target reached, no resume, no error. The next boot starts 7 seconds later as a completely fresh boot (not a resume), confirming the machine hung and was hard-power-cycled rather than cleanly hibernating.

System details (omarchy-debug --no-sudo --print):

• Machine: MacBookAir9,1 (2020, Apple T2 security chip)
• CPU: Intel Core i5-1030NG7 (Ice Lake)
• Kernel: 7.1.8-arch1-Watanare-T2-3-t2 (t2linux)
• Omarchy: 4.0.1-1
• lspci -nn shows the T2 chip at 106b:1801/106b:1802

Root cause

This is a known limitation of Linux on Apple T2 hardware, not a machine-specific fluke: the T2 chip's embedded controller (which also owns the internal keyboard/trackpad SPI bus, and the TouchBar's BCE controller on models that have one) doesn't reliably survive true hibernate (S4) — it drops power to those devices in a way the kernel can't recover from, and the machine hangs instead of cleanly powering off/resuming.

See the t2linux wiki: https://wiki.t2linux.org/state/ — hibernation is explicitly called out as not working; suspend-to-RAM (S3) is the only reliably supported sleep mode on this platform. omarchy hibernation setup currently has no awareness of this and will happily set up hibernation (swapfile + resume kernel params) on T2 hardware, and the Hibernate System-menu entry (default/omarchy/omarchy-menu.jsonc, guarded by omarchy-hibernation-available) then becomes available, so users can trigger this hang without any warning.

Proposed fix

I'm opening a PR from my fork that makes omarchy hibernation setup detect T2 hardware (new omarchy-hw-t2 helper) and refuse by default with an explanation and a link to the t2linux wiki, requiring --force to proceed anyway. This keeps the Hibernate menu entry hidden by default on T2 Macs (since it's gated on hibernation actually being configured) without touching suspend, which already works on T2 via the existing t2-wifi-suspend sleep hook.