## What happened

Fresh Omarchy 4.0.1 install (Btrfs + LUKS, Limine/UKI) on an Apple iMac17,1. The installer configured hibernation automatically (swapfile, `resume` hook, `resume=/dev/mapper/root resume_offset=…` on the cmdline), and the setup itself was **correct** — earlier boots logged `PM: Image not found (code -22)`, i.e. the kernel probed exactly the configured location and moved on.

First actual use of the Hibernate menu entry wrote a valid image and powered off. From then on the machine appeared dead: every boot showed a black screen immediately after the LUKS passphrase. No journal lines exist for any of these attempts. Adding `nomodeset` while keeping `resume=` changed nothing.

## Mechanism

Omarchy's initramfs is udev-based with the `resume` hook running right after `encrypt`. So directly after the passphrase, the kernel found the valid image and jumped into the restored pre-hibernate kernel. That kernel then hung re-initializing the GPU — a Radeon R9 M380 Mac Edition (Bonaire, GCN 2 "CIK", `amdgpu`), a generation whose S4 restore is long known to be unreliable, particularly in the Apple variants.

Two properties turn this hardware quirk into an apparent brick:

- The image persists until something rewrites the swap signature, so **every** boot retries the same doomed restore.
- `nomodeset` (the natural first rescue attempt) is powerless: it only configures the freshly booted kernel, but the hang happens inside the *restored* kernel, which already has `amdgpu` loaded. Together with `quiet splash loglevel=0`, the user sees nothing at all.

Recovery required knowing to edit the Limine entry and delete `resume=`/`resume_offset=`; the system then booted normally and re-activating the swapfile invalidated the stale image.

## Why file this against Omarchy

The amdgpu/CIK restore hang itself is a kernel problem, not Omarchy's. But two things in Omarchy's sphere decide whether this ends as "hibernate didn't work" or as "my machine is bricked":

1. Hibernation is enabled by default at install and exposed as a one-click menu entry, including on hardware classes where restore is known-shaky. This failure class is already represented here across drivers: #10039 (NVIDIA), #8352 (hybrid Intel+NVIDIA), #7848 (nouveau on MacBookPro11,3).
2. **There is no stock recovery path.** The default entry, the fallback entry, and every snapshot entry all carry `resume=`, so once a restore hangs there is no bootable choice left in the menu. (Related config asymmetry: #10037.)

## Suggested fix — make hibernation safe to keep, not remove it

This is deliberately **not** a request to gate or disable hibernation on Macs. Hibernation is a great default; what needs fixing is the *cost of a failed restore*, which today is an apparently bricked machine and should be one lost session.

1. **A generated rescue entry.** Emit one additional Limine entry, identical to the default but without `resume=`/`resume_offset=` — e.g. *"Omarchy (skip hibernation image)"*. One entry in the limine-entry-tool config makes the entire failure class — any GPU that cannot survive S4 restore, across #10039 / #8352 / #7848 and this report — self-recoverable from the boot menu with zero cmdline knowledge. Once booted, swap activation rewrites the swap signature, so the stale image clears itself and the *next* hibernate is a fresh attempt. With that entry in place, hibernation can safely stay enabled by default everywhere: worst case becomes "pick the second menu entry, lose the session", not "machine appears dead".

2. **A one-line manual note** closing the loop: "Black screen right after the LUKS passphrase, following a hibernate → choose the skip-hibernation-image entry; the stale image is cleared automatically once the system is up."

3. **(Optional, longer-term) a per-hardware quirk lane** so machines like this one can eventually hibernate successfully rather than merely recover. For Bonaire/CIK the candidate is booting with `radeon.cik_support=1 amdgpu.cik_support=0` — the older `radeon` driver's S4 path is far more exercised on this generation. I have **not** verified this on my machine (it stays flagged as an experiment, and I'm happy to test and report back if useful); the point is that `install/hardware/` already exists as the natural home for such known-hardware cmdline quirks, and the rescue entry from (1) is exactly what makes that kind of experimentation safe for users.

## Evidence

Last journal line of the pre-incident boot (Sep 3 20:47:13):

```
systemd-sleep[3154049]: Performing sleep operation 'hibernate'...
kernel: PM: hibernation: hibernation entry
```

`journalctl --list-boots` shows zero boots between the hibernate and the successful recovery boot 63 minutes later — the failed attempts died in the initramfs before logging starts. Earlier boot proving the resume config was read and valid:

```
kernel: Kernel command line: … resume=/dev/mapper/root resume_offset=1901397 …
kernel: PM: Image not found (code -22)
```

Side casualty worth knowing about for other Mac users: the failed restore + hard power-offs left the SMC wedged (`applesmc: #KEY: read data[0] fail` on every read), fans at failsafe full speed until an SMC reset (power cord out ~20 s).

## System

|  |  |
|---|---|
| Omarchy | 4.0.1-1 |
| Kernel | 7.1.9-arch1-2 |
| Hardware | Apple iMac17,1 (27" Retina 5K, Late 2015), firmware 170.0.0.0.0 |
| CPU / RAM | Intel Core i5-6500 / 32 GB |
| GPU | AMD Radeon R9 M380 Mac Edition — Bonaire/CIK `[1002:6640]`, subsystem `[106b:014b]`, driver `amdgpu` |
| Root | Btrfs on LUKS, Limine 12.6.0-1 + UKI, limine-mkinitcpio-hook 1.37.1-1, limine-snapper-sync 1.31.0-1 |
| Swap | 31.2 GB Btrfs swapfile (pri 0) + zram (pri 100), `zswap.enabled=0` |

Full `omarchy-debug` log available on request.

Filed by Claude Fable 5 via Claude Code.