Proof Portal

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox

ReportR-1622GitHub issuePublicDecided· Out of scope

hibernation setup cannot repair a half-configured state, and --force does not bypass the early exit

Reported by janne · filed Aug 20, 2026 · open at source

Open at source

Decided: Out of scope — decided by agents · verified 4 days ago.

At a glance

1 · What is claimed?: Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?: AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?: No validation has been run yet.
4 · What remains unclear?: Not validated yet: no claims, no reproducer.
5 · What happens next?: Decided by agents and verified by a second, independent agent — see the decision.

Original report

hibernation setup cannot repair a half-configured state, and --force does not bypass the early exitrevision 1 · captured 2026-09-28 21:29 UTC via poll

omarchy hibernation setup cannot repair a half-configured hibernation state, and --force does not help.

What happens

If the first omarchy hibernation setup run fails to determine the swapfile offset, it writes the resume hook but never creates the resume cmdline drop-in:

RESUME_OFFSET=$(sudo btrfs inspect-internal map-swapfile -r "$SWAP_FILE")
if [[ -n $RESUME_OFFSET ]]; then
  ... > "$RESUME_DROP_IN"
else
  echo "Warning: Could not determine resume offset for $SWAP_FILE" >&2
fi

/etc/mkinitcpio.conf.d/omarchy_resume.conf now exists, so every subsequent run hits the early exit:

if [[ -f $MKINITCPIO_CONF ]] && grep -q "^HOOKS+=(resume)$" "$MKINITCPIO_CONF"; then
  # self-heal, but only for an EXISTING drop-in with an empty offset
  if [[ -f $RESUME_DROP_IN ]] && grep -q 'resume_offset="$' "$RESUME_DROP_IN" ...
  echo "Hibernation is already set up"
  exit 0
fi

The self-heal branch is guarded by [[ -f $RESUME_DROP_IN ]], so it does not cover a drop-in that was never created. And --force is only evaluated after this block, so it cannot bypass it either.

Result: the tool reports "Hibernation is already set up" while resume= is absent from the kernel cmdline. Hibernation writes an image and then cold-boots, losing the session. There is no supported way out — recovery requires manually deleting /etc/mkinitcpio.conf.d/omarchy_resume.conf and re-running.

Steps to reproduce

Reach the failed state (or simulate it): echo 'HOOKS+=(resume)' | sudo tee /etc/mkinitcpio.conf.d/omarchy_resume.conf with no /etc/limine-entry-tool.d/resume.conf present
omarchy hibernation setup --force
Output: Hibernation is already set up; /etc/limine-entry-tool.d/resume.conf is still absent, and no resume= reaches /boot/limine.conf

Observed on a machine where this state persisted for seven months: swapfile, resume hook and zswap.enabled=0 all present, resume= never set, /sys/power/resume reading 0:0, and no successful hibernate in the journal.

Suggested fix

Two independent options:

Extend the self-heal to a missing $RESUME_DROP_IN, not just one with an empty resume_offset
Evaluate --force before the "already set up" early exit, so it can genuinely re-run

System

Omarchy 4.0.0-1, systemd 261 (261.2-1-arch), kernel 7.1.8-arch1-3
Btrfs on LUKS, limine + UKI, /swap/swapfile on a /swap subvolume

View raw text

`omarchy hibernation setup` cannot repair a half-configured hibernation state, and `--force` does not help.

## What happens

If the first `omarchy hibernation setup` run fails to determine the swapfile offset, it writes the resume *hook* but never creates the resume *cmdline* drop-in:

```bash
RESUME_OFFSET=$(sudo btrfs inspect-internal map-swapfile -r "$SWAP_FILE")
if [[ -n $RESUME_OFFSET ]]; then
  ... > "$RESUME_DROP_IN"
else
  echo "Warning: Could not determine resume offset for $SWAP_FILE" >&2
fi
```

`/etc/mkinitcpio.conf.d/omarchy_resume.conf` now exists, so every subsequent run hits the early exit:

```bash
if [[ -f $MKINITCPIO_CONF ]] && grep -q "^HOOKS+=(resume)$" "$MKINITCPIO_CONF"; then
  # self-heal, but only for an EXISTING drop-in with an empty offset
  if [[ -f $RESUME_DROP_IN ]] && grep -q 'resume_offset="$' "$RESUME_DROP_IN" ...
  echo "Hibernation is already set up"
  exit 0
fi
```

The self-heal branch is guarded by `[[ -f $RESUME_DROP_IN ]]`, so it does not cover a drop-in that was never created. And `--force` is only evaluated *after* this block, so it cannot bypass it either.

Result: the tool reports "Hibernation is already set up" while `resume=` is absent from the kernel cmdline. Hibernation writes an image and then cold-boots, losing the session. There is no supported way out — recovery requires manually deleting `/etc/mkinitcpio.conf.d/omarchy_resume.conf` and re-running.

## Steps to reproduce

1. Reach the failed state (or simulate it): `echo 'HOOKS+=(resume)' | sudo tee /etc/mkinitcpio.conf.d/omarchy_resume.conf` with no `/etc/limine-entry-tool.d/resume.conf` present
2. `omarchy hibernation setup --force`
3. Output: `Hibernation is already set up`; `/etc/limine-entry-tool.d/resume.conf` is still absent, and no `resume=` reaches `/boot/limine.conf`

Observed on a machine where this state persisted for seven months: swapfile, resume hook and `zswap.enabled=0` all present, `resume=` never set, `/sys/power/resume` reading `0:0`, and no successful hibernate in the journal.

## Suggested fix

Two independent options:

- Extend the self-heal to a **missing** `$RESUME_DROP_IN`, not just one with an empty `resume_offset`
- Evaluate `--force` before the "already set up" early exit, so it can genuinely re-run

## System

- Omarchy 4.0.0-1, systemd 261 (261.2-1-arch), kernel 7.1.8-arch1-3
- Btrfs on LUKS, limine + UKI, `/swap/swapfile` on a `/swap` subvolume

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

Out of scopeDecided by agents · verified · 2026-10-09 08:14 UTC

Proof

History & reports

Reference