Proof Portal

Project overview

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-7GitHub issuePublicFixed

omarchy hibernation remove leaves resume.conf behind, so a later setup keeps a stale resume_offset

Reported by STRd6 · filed Sep 28, 2026 · open at source

Decided: Out of scope — decided by agents · verified 3 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

omarchy hibernation remove leaves resume.conf behind, so a later setup keeps a stale resume_offsetrevision 1 · captured 2026-09-28 21:23 UTC via poll

System

  • Omarchy 4.0.4-1
  • Btrfs root on LUKS, Limine + UKI, NVIDIA GPU (desktop)

What happened

omarchy-hibernation-setup writes /etc/limine-entry-tool.d/resume.conf:

KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=1929151"

omarchy-hibernation-remove deletes the swapfile, the /swap subvolume, the fstab entry, and /etc/mkinitcpio.conf.d/omarchy_resume.conf, but not resume.conf. After limine-mkinitcpio and a reboot, the kernel cmdline still carries resume=... resume_offset=..., which now points at a deleted swapfile.

Why it matters

If hibernation is set up again later, omarchy-hibernation-setup only writes the resume parameters when the file is missing:

if [[ ! -f $RESUME_DROP_IN ]]; then

The new swapfile gets a new physical offset, but the old resume_offset is kept. Hibernation then writes the image to the new swapfile, and resume looks in the wrong place, so the session is silently lost on the next boot.

Steps to reproduce

  1. omarchy hibernation setup
  2. omarchy hibernation remove
  3. ls /etc/limine-entry-tool.d/: resume.conf is still there
  4. Reboot, then cat /proc/cmdline: resume= and resume_offset= are still present
  5. omarchy hibernation setup again: resume.conf is not rewritten, and resume_offset no longer matches sudo btrfs inspect-internal map-swapfile -r /swap/swapfile

Expected

remove deletes /etc/limine-entry-tool.d/resume.conf before running limine-mkinitcpio, which undoes what setup wrote.

Suggested fix

In bin/omarchy-hibernation-remove, before regenerating the initramfs:

RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf"
if [[ -f $RESUME_DROP_IN ]]; then
  echo "Removing resume kernel parameters"
  sudo rm "$RESUME_DROP_IN"
fi

Also worth considering: setup could always regenerate resume.conf instead of skipping it when it exists, so an offset left over from any source gets corrected.

Minor: remove also leaves rtc-alarm.conf (on s2idle systems) and /usr/lib/systemd/system-sleep/keyboard-backlight. Both are harmless without hibernation, so this may be intentional.

View raw text
## System
- Omarchy 4.0.4-1
- Btrfs root on LUKS, Limine + UKI, NVIDIA GPU (desktop)

## What happened
`omarchy-hibernation-setup` writes `/etc/limine-entry-tool.d/resume.conf`:

```
KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=1929151"
```

`omarchy-hibernation-remove` deletes the swapfile, the `/swap` subvolume, the fstab entry, and `/etc/mkinitcpio.conf.d/omarchy_resume.conf`, but not `resume.conf`. After `limine-mkinitcpio` and a reboot, the kernel cmdline still carries `resume=... resume_offset=...`, which now points at a deleted swapfile.

## Why it matters
If hibernation is set up again later, `omarchy-hibernation-setup` only writes the resume parameters when the file is missing:

```bash
if [[ ! -f $RESUME_DROP_IN ]]; then
```

The new swapfile gets a new physical offset, but the old `resume_offset` is kept. Hibernation then writes the image to the new swapfile, and resume looks in the wrong place, so the session is silently lost on the next boot.

## Steps to reproduce
1. `omarchy hibernation setup`
2. `omarchy hibernation remove`
3. `ls /etc/limine-entry-tool.d/`: `resume.conf` is still there
4. Reboot, then `cat /proc/cmdline`: `resume=` and `resume_offset=` are still present
5. `omarchy hibernation setup` again: `resume.conf` is not rewritten, and `resume_offset` no longer matches `sudo btrfs inspect-internal map-swapfile -r /swap/swapfile`

## Expected
`remove` deletes `/etc/limine-entry-tool.d/resume.conf` before running `limine-mkinitcpio`, which undoes what `setup` wrote.

## Suggested fix
In `bin/omarchy-hibernation-remove`, before regenerating the initramfs:

```bash
RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf"
if [[ -f $RESUME_DROP_IN ]]; then
  echo "Removing resume kernel parameters"
  sudo rm "$RESUME_DROP_IN"
fi
```

Also worth considering: `setup` could always regenerate `resume.conf` instead of skipping it when it exists, so an offset left over from any source gets corrected.

Minor: `remove` also leaves `rtc-alarm.conf` (on s2idle systems) and `/usr/lib/systemd/system-sleep/keyboard-backlight`. Both are harmless without hibernation, so this may be intentional.

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

  • Fixed bypr/12155· confirmed

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 20:05 UTC