Refuse hibernation setup on Apple T2 Macs by default

[spuder]

Fixes #9237

Problem

omarchy hibernation setup will happily configure hibernation (swapfile + resume kernel params) on Apple T2 Macs, and the System-menu Hibernate entry becomes available once it's set up. But T2 Macs don't reliably survive true hibernate (S4): the T2 controller, which also owns the internal keyboard/trackpad SPI bus, often fails to come back after resuming from a hibernation image, and the machine can hang mid-hibernate and need a hard power-off — see #9237 for a concrete case with journal evidence.

Suspend-to-RAM (S3) is unaffected and already works on T2 via the existing t2-wifi-suspend sleep hook, so this only touches hibernation.

Fix

1. Block new setups. Add bin/omarchy-hw-t2, a hardware-detection helper following the existing omarchy-hw-* convention (same 106b:1801/1802 PCI-ID check already used by the other Apple T2 install fixes). omarchy-hibernation-setup now refuses by default on T2 hardware, printing an explanation and a link to #9237. --force still allows setting it up anyway. The check sits after the "already configured" early-return, so it's a no-op for anyone who already has hibernation configured, and after the internal omarchy-system-factory-reset caller (which already passes --force) so re-provisioning an existing T2 setup after factory reset is unaffected.

Since the System-menu Hibernate entry is gated on omarchy-hibernation-available (which checks for actual swap+resume configuration), this keeps that entry hidden by default on T2 Macs too, not just the setup command — but only for machines that haven't configured hibernation yet.

2. Clean up existing setups. Commit 1 alone doesn't help anyone who already ran omarchy hibernation setup on a T2 Mac before this fix shipped — their swapfile/resume config stays in place and Hibernate stays in the menu. Add a migration (migrations/1788120123.sh) that runs omarchy-hibernation-remove on T2 hardware, reusing its own confirm prompt and no-op-when-unconfigured behavior, so it applies automatically on the next omarchy update (or via the login migration notifier for anyone who updates another way).

3. Fully remove resume kernel parameters. omarchy-hibernation-remove left /etc/limine-entry-tool.d/resume.conf behind, so the kernel kept booting with resume= params pointing at a deleted swapfile, and a later setup reused the stale resume_offset (setup only writes the drop-in when it is missing). Remove now deletes it too, which the migration relies on.

One-line caveat added to manual/36-system-sleep.md covering both cases.

Testing

./test/cli passes (116/116) after both commits. Manually verified on a real MacBookAir9,1 (T2):

• omarchy-hw-t2 correctly detects the hardware.
• With hibernation already removed, PATH=<checkout>/bin omarchy-hibernation-setup (no --force) prints the warning and exits without configuring anything.
• The migration script, run directly against the same machine, correctly no-ops ("Hibernation is not set up") since nothing is configured.
• omarchy-hibernation-available exits 1 (unavailable) and the System-menu Hibernate entry is gone.

No existing test harness mocks hardware detection for omarchy-hibernation-setup or migrations, so this doesn't add a new automated regression test for either — happy to add one if there's a preferred pattern for mocking omarchy-hw-* in test/cli.

🤖 Generated with Claude Code

[omarchybot]

Reviewed at 0ed5b6c by Claude Opus 5.5. No second opinion ran: the reviewer (Codex) answered its availability check but refused this review because the day's review budget was spent, so this is one model's reading.

What ran, on a disposable Omarchy worker (no T2 hardware):

• ./test/cli and test/shell.d/t2-hardware-test.sh pass.
• With lspci stubbed to report the T2 chip (and to print several thousand lines after the match, as the existing T2 test does to catch the SIGPIPE/pipefail false negative), omarchy-hibernation-setup refuses with the new message and touches nothing. On the base branch, and with this change to the script reverted, the same stub goes on to the "Use … on boot drive" prompt. --force still proceeds on T2, and a non-T2 machine still gets the prompt.
• The migration under bash -euo pipefail calls omarchy-hibernation-remove on T2 and does nothing elsewhere. omarchy-hw-t2 detects correctly even when the caller has pipefail set.
• omarchy-system-factory-reset passes --force, and the T2 check comes after the "already set up" early return, so neither path changes.

One thing to correct: https://wiki.t2linux.org/state/ does not say hibernation is unsupported. As of today the page does not mention hibernation at all, and lists suspend as partially working and model-dependent. The setup message ("See … for details"), the migration's echo and the PR description all point there, so a T2 user who follows the link finds nothing about the claim. #9237, with your journal excerpt, is the evidence this change actually rests on, and pointing at it (or dropping the link) would be accurate.

What a worker cannot show is the hang itself. That is down to the hardware, so verified waits on a T2 machine. @spuder, since you have the MacBookAir9,1 from #9237: could you confirm against the exact head 0ed5b6cf0bb64ef8b8304d3843c9390026dd18b1? From a checkout of that commit (git clone https://github.com/spuder/omarchy && cd omarchy && git checkout 0ed5b6cf0bb64ef8b8304d3843c9390026dd18b1): (1) with hibernation not set up, PATH=$PWD/bin:$PATH bin/omarchy-hibernation-setup refuses; (2) with hibernation set up, PATH=$PWD/bin:$PATH bash -euo pipefail migrations/1788120123.sh offers to remove it, and after a reboot the Hibernate entry is gone from the System menu.

For the maintainer: the migration offers to remove hibernation from every T2 Mac, including any where it works. It asks first, so a user can decline. Whether one machine's hang is enough to justify that across the platform is your call.

Waiting on the author for the hardware confirmation and the link, then on the maintainer.

[spuder]

Tested on the real MacBookAir9,1 (T2, 106b:1801/1802) at exact head 0ed5b6cf0bb64ef8b8304d3843c9390026dd18b1.

Passed

• omarchy-hw-t2 detects the T2, including under bash -o pipefail.
• (1) With hibernation not set up, PATH=$PWD/bin:$PATH bin/omarchy-hibernation-setup (no --force) prints the T2 warning and exits 0 without touching anything.
• omarchy-hibernation-available exits 1, so the Hibernate menu entry stays hidden.
• bash -euo pipefail migrations/1788120123.sh correctly no-ops ("Hibernation is not set up") on this machine.
• ./test/cli: 116/116.

Not yet run: (2), the migration against an active hibernation setup followed by a reboot. It needs an interactive confirm and a reboot. I'll follow up.

Found while testing: omarchy-hibernation-remove leaves /etc/limine-entry-tool.d/resume.conf behind. It removes the swapfile, the subvolume, the fstab entry and omarchy_resume.conf, but not the Limine drop-in that setup writes. This machine had hibernation removed earlier and still boots with resume=/dev/mapper/root resume_offset=1895286, which points at a swapfile that no longer exists. The same gap is on quattro, so it predates this PR, but it matters here:

• The new migration relies on omarchy-hibernation-remove, so every T2 Mac it cleans up keeps the leftover resume= params.
• omarchy-hibernation-setup only writes the drop-in if [[ ! -f $RESUME_DROP_IN ]]. After a remove, a later setup (--force on T2, or any re-setup elsewhere) keeps the old resume_offset for the new swapfile, so resume would likely fail. That's from reading the code; I haven't run it.

The fix would be sudo rm -f /etc/limine-entry-tool.d/resume.conf in omarchy-hibernation-remove before limine-mkinitcpio.

On the link: agreed. I checked https://wiki.t2linux.org/state/ and it doesn't mention hibernation; it only says suspend issues are model-dependent. I'll point the setup message, the migration echo and the description at #9237 instead.

🤖 Generated with Claude Code

[greptile-apps]

Confidence Score: 4/5

[High risk] Changes system hibernation setup and adds hardware detection.

The PR should not merge until a declined removal cannot permanently mark the T2 cleanup complete and unattended updates cannot prompt.

Findings

1.  Declined removal is marked complete ▶
2.  T2 paths lack regression tests ▶

Summary

The PR adds a T2 hardware check to refuse new hibernation setups by default, removes resume kernel parameters during hibernation removal, and adds a migration for existing T2 setups.

• A declined migration confirmation is nevertheless recorded as complete, leaving the existing setup in place.
• The new hardware-specific paths lack automated regression coverage.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[T2 Mac] --> B{Hibernation already configured?}
  B -- No --> C{Setup uses --force?}
  C -- No --> D[Refuse setup]
  C -- Yes --> E[Configure hibernation]
  B -- Yes --> F[Run migration]
  F --> G{Confirm removal?}
  G -- Yes --> H[Remove setup and mark complete]
  G -- No --> I[Leave setup intact but mark complete]

Loading

_{Reviews (1) · Last reviewed commit: "Point T2 hibernation messages at #9237"}

[greptile-apps]

Declined removal is marked complete

On a T2 Mac with hibernation already configured, declining the confirmation makes omarchy-hibernation-remove exit successfully without removing anything. The migration runner then marks this migration complete, so later updates will not retry it and Hibernate remains available. This call also prompts during omarchy update -y, even though that mode promises not to ask questions. The migration needs to distinguish a completed removal from a declined one and handle unattended updates without prompting.

Knowledge Base Used: Migration framework

[greptile-apps]

T2 paths lack regression tests

The existing T2 test mocks PCI output, but it does not exercise this new detector, the setup refusal or force override, or the new removal migration. A missed hardware match or a change to those paths could restore the hibernation hazard without failing the CLI tests. Please add coverage for T2 and non-T2 PCI output and the relevant hibernation states.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[spuder]

Follow-up: test (2) passes on the MacBookAir9,1 (T2) at head 86adccac.

New commits since 0ed5b6c

• 63deed4 omarchy-hibernation-remove now also deletes /etc/limine-entry-tool.d/resume.conf (the leftover-drop-in bug from my previous comment).
• 86adcca The setup message and the migration echo now point at Hibernation hangs and kills the keyboard on Apple T2 Macs #9237 instead of the t2linux wiki.

(2) Migration against an active hibernation setup

1. Removed the leftover resume.conf from an earlier pre-fix removal, then ran omarchy-hibernation-setup --force. It wrote a fresh resume_offset=15098534 (the leftover had 1895286), and omarchy-hibernation-available returned 0. Hibernate appeared in the System menu.
2. Rebooted. /proc/cmdline had resume=/dev/mapper/root resume_offset=15098534, and /swap/swapfile was active.
3. PATH=$PWD/bin:$PATH bash -euo pipefail migrations/1788120123.sh printed the Hibernation hangs and kills the keyboard on Apple T2 Macs #9237 message and asked "Remove hibernation setup?". On yes it ran swapoff and removed the swapfile, the subvolume, the fstab entry, resume.conf ("Removing resume kernel parameters") and the resume hook, then rebuilt the UKI without [resume]. The main entry in /boot/limine.conf no longer has resume=.
4. Rebooted. /proc/cmdline has no resume=/resume_offset=, swap is zram only, omarchy-hibernation-available returns 1, and Hibernate is gone from the System menu.

I never actually hibernated during this test, to avoid the #9237 hang.

Note: limine-snapper-sync snapshot entries still carry the old resume= params. That's expected, since they reflect past system states and age out on their own.

🤖 Generated with Claude Code

[omarchybot]

Re-reviewed at 86adccacebfc90c36f3e8ec92885edd452cb0127 (the two new commits: omarchy-hibernation-remove deleting resume.conf, and the messages pointing at #9237) by Claude Opus 5.5, with Codex Medium as second opinion.

What ran, on a disposable Omarchy worker that had hibernation set up for real:

• ./test/cli passes (116/116), as do t2-hardware-test.sh, migrate-scope-test.sh and limine-cmdline-migration-test.sh.
• With lspci stubbed to report the T2 and the confirm answered yes, bash -euo pipefail migrations/1788120123.sh removed the swapfile, the subvolume, the fstab entry, resume.conf and the resume hook, and rebuilt the UKI. Afterwards the main Limine entry has no resume=; only the old snapshot entry still carries it, as you noted.
• With hibernation then unconfigured, omarchy-hibernation-setup on the stubbed T2 refuses with the Hibernation hangs and kills the keyboard on Apple T2 Macs #9237 message and writes nothing. Without the T2 it still goes on to the usual prompt.
• Run against a scratch tree, the remove from the previous head leaves resume.conf in place and rebuilds with it. The remove at this head deletes it before limine-mkinitcpio.

Your MacBookAir9,1 results cover what a worker cannot, and they are why this review trusts the hang. One limit on them: the verified label needs a hardware confirmation from someone other than the pull request's author, and you are both the reporter of #9237 and the author here. So verified waits on another T2 owner or the maintainer. That is no reflection on the testing.

The resume.conf commit overlaps two open pull requests. #8199 and #13584 change the same lines of bin/omarchy-hibernation-remove to fix the same leftover (#10037, #10374, #12096, #13583). Only one of them can land cleanly. #8199 also removes a leftover drop-in when the resume hook is already gone. This PR's version can't: omarchy-hibernation-remove exits with "Hibernation is not set up" before it reaches the new lines. Codex raised that, and I confirmed it in the source. So a T2 Mac whose hibernation was removed before this fix, as yours was, keeps its stale resume= after this migration runs, and the migration is then marked done. If #8199 lands first, this migration cleans those machines too.

On greptile's two points, which Codex and I both checked against omarchy-migrate:

• Declining "Remove hibernation setup?" exits 0, so the migration is marked complete and doesn't ask again. That is real. It reads as a reasonable one-time offer to someone who wants to keep hibernation, but the manual says the migration "removes it for you", while it actually asks once.
• Under omarchy update -y on a T2 Mac with hibernation set up, the migration still shows the confirm prompt, although -y promises no Omarchy prompts. That is real too. The existing Copy URL migration (1786643346.sh) has the same gap, so the repository has no settled pattern to follow. Whether an unattended update should skip and stay pending, or skip and stop asking, is a policy choice.

For the maintainer: choose which resume.conf fix lands (#8199 is the most complete) and whether this PR should drop 63deed4 in its favour; set the -y policy for this migration; and decide whether one MacBookAir9,1 hang justifies offering removal on every T2 Mac. The setup message's "often fails" is a broader claim than #9237 alone shows.

Waiting on the maintainer.