## What happened

On a fresh Omarchy 4.0.4-1 install, `omarchy-hibernation-setup` wrote this drop-in to
`/etc/limine-entry-tool.d/resume.conf`:

```
KERNEL_CMDLINE[default]+=" resume= resume_offset=9338098"
```

The offset is correct; the **device is empty**. The resulting kernel cmdline carries
`resume=` with no value, so `/sys/power/resume` reads `0:0` while
`/sys/power/resume_offset` reads `9338098`.

Hibernating writes the image to swap, and the next boot ignores it and cold-boots.
There is no error at any point — the session is simply gone.

## Expected

Either a correct `resume=UUID=…`/device value, or a hard failure telling the user
hibernation could not be configured. Not a well-formed-looking drop-in with a silently
empty parameter.

## Root cause

In `/usr/share/omarchy/bin/omarchy-hibernation-setup`:

```bash
134:  RESUME_DEVICE=$(findmnt -no SOURCE -T "$SWAP_FILE" | sed 's/\[.*\]//')
135:  RESUME_OFFSET=$(sudo btrfs inspect-internal map-swapfile -r "$SWAP_FILE")
136:  if [[ -n $RESUME_OFFSET ]]; then
138:    echo "KERNEL_CMDLINE[default]+=\" resume=$RESUME_DEVICE resume_offset=$RESUME_OFFSET\"" | ...
```

`$RESUME_OFFSET` is validated at line 136. **`$RESUME_DEVICE` never is.** If the
`findmnt` at line 134 comes back empty, the drop-in is still written, with `resume=`
blank.

(Re-running `findmnt -no SOURCE -T /swap/swapfile` on this machine now returns
`/dev/mapper/root[/@]` correctly, so the emptiness was specific to the conditions during
initial provisioning — the swapfile is created moments earlier, at 07:49:48, and the
drop-in written at 07:49:49. Root is LUKS + btrfs subvol `@`.)

## Why it is not self-healing

Three things each independently hide it:

1. The repair block at line 65 matches only `grep -q 'resume_offset="$'` — an empty
   **offset**. An empty **device** does not match, so the repair never runs.
2. Line 131 writes the drop-in only `if [[ ! -f $RESUME_DROP_IN ]]`. The file exists, so
   re-running never rewrites it. Setup reports "Hibernation is already set up" and exits 0.
3. `omarchy-hibernation-available` checks only total swap size against
   `/sys/power/image_size` plus the presence of `/etc/mkinitcpio.conf.d/omarchy_resume.conf`.
   It never inspects the drop-in, so it returns 0 and the menu keeps offering **Hibernate**
   on a system that cannot resume.

## Reproduce

1. Install Omarchy on LUKS + btrfs and enable hibernation during setup.
2. `cat /etc/limine-entry-tool.d/resume.conf` — check whether `resume=` has a value.
3. `cat /sys/power/resume` — `0:0` means broken.
4. `sudo omarchy-hibernation-setup` — reports already set up, changes nothing.

## Suggested fix

Validate `$RESUME_DEVICE` alongside `$RESUME_OFFSET` at line 136, and fail loudly if it is
empty. Widen the line 65 repair to reconcile an empty or wrong `resume=` as well as the
offset. Having `omarchy-hibernation-available` verify the drop-in actually contains a
non-empty `resume=` would stop the menu offering an action that cannot work.

## Related — this is a third, distinct variant

Three existing issues describe the neighbouring failures in this same script. None of
them covers an unvalidated `$RESUME_DEVICE`:

| Issue | Drop-in | `resume_offset` | `resume=` |
|---|---|---|---|
| #7619 | never created | detection failed | absent |
| #11437 | present | stale, non-empty | correct |
| **this** | **present** | **correct** | **empty** |

The distinction matters for the repair path: in #7619 the self-heal is skipped because
`[[ -f $RESUME_DROP_IN ]]` is false. Here the file *does* exist, so that guard passes —
and the repair is still skipped, because the `grep -q 'resume_offset="$'` on the same line
only ever looks at the offset. Widening the self-heal to cover a missing drop-in (#7619's
suggestion) would still not fix this case.

- #10374, #10375, #10037, #12096 — other `resume.conf` / hook-ordering failures nearby.

## System

- `omarchy version`: 4.0.4-1
- kernel: 7.2.5-3-omarchy (linux-omarchy), `linux` 7.2.3 also installed
- root: `/dev/mapper/root` (LUKS) btrfs subvol `@`; swapfile `/swap/swapfile`, 7.6 GB
- bootloader: Limine with UKI (`ENABLE_UKI=yes`), `limine-mkinitcpio-hook 1.38.0-1.1`

Worked around locally by writing `resume=UUID=<root-fs-uuid>` by hand and running
`limine-mkinitcpio`; `/sys/power/resume` now reads `253:0` and the cmdline is correct.

---
Filed by Claude Opus 5 via Claude Code.