Repository navigation
omarchy hibernation remove leaves /etc/limine-entry-tool.d/resume.conf behind, so the rebuilt UKI still boots with resume= pointing at the deleted swapfile #10037
Description
What happened
omarchy hibernation remove reports Hibernation removed, but it only removes the
mkinitcpio resume hook. It never removes /etc/limine-entry-tool.d/resume.conf, which
omarchy-hibernation-setup created. Because the removal script ends with
sudo limine-mkinitcpio, the drop-in is still on disk during that rebuild, so the freshly
generated UKI and every entry in /boot/limine.conf come out carrying:
resume=/dev/mapper/root resume_offset=1909033
At that point the swapfile has already been deleted and the /swap Btrfs subvolume
destroyed, so the kernel command line points at an offset inside blocks Btrfs is now free
to hand to any other file.
Expected
omarchy hibernation remove should delete the drop-in it created before rebuilding, so the
resulting cmdline has no resume= / resume_offset=.
Steps to reproduce
omarchy hibernation setupon a Btrfs + LUKS install using Limine/UKI.omarchy hibernation remove, confirm the prompt.- Inspect the result:
$ ls /etc/limine-entry-tool.d/
omarchy-defaults.conf omarchy-uki.conf resume.conf # <-- still there
$ grep -c "resume=" /boot/limine.conf
5
$ sudo grep -aoE "resume(_offset)?=[^ ]+" /boot/EFI/Linux/omarchy_linux.efi | sort -u
resume=/dev/mapper/root
resume_offset=1909033
$ swapon --show # the swapfile it points at is gone
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 15G 0B 100
$ ls -d /swap
ls: cannot access '/swap': No such file or directoryWhere the asymmetry is
omarchy-hibernation-setup creates the drop-in:
RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf" # line 31
...
echo "KERNEL_CMDLINE[default]+=\" resume=$RESUME_DEVICE resume_offset=$RESUME_OFFSET\"" \
| sudo tee "$RESUME_DROP_IN" >/dev/null # line 103omarchy-hibernation-remove never references RESUME_DROP_IN at all — its only rm calls are:
sudo rm "$SWAP_FILE" # line 30
sudo rm "$MKINITCPIO_CONF" # line 49
sudo limine-mkinitcpio # line 52The same gap applies to /etc/limine-entry-tool.d/rtc-alarm.conf, which
omarchy-hibernation-setup creates on s2idle systems (line 111-114) and remove also leaves
behind. (Not present on my machine, so I only verified resume.conf end to end.)
Second-order: the snapshot entries cache the stale cmdline
Deleting the drop-in and re-running limine-mkinitcpio cleans the default entry and the UKI,
but the Snapper snapshot entries keep the old cmdline, because it is cached in
/boot/<machine-id>/limine_history/snapshots.json. Restarting limine-snapper-sync.service
regenerates the entries from that cache, so it does not help. The stale resume= has to be
stripped from snapshots.json as well.
Impact
Low probability, but it is exactly the failure class hibernation removal is meant to end: a
kernel command line telling the kernel to resume from freed, reallocated blocks. It also makes
a later omarchy hibernation setup start from a half-configured state (see #7619).
Suggested fix
In omarchy-hibernation-remove, before sudo limine-mkinitcpio:
RESUME_DROP_IN="/etc/limine-entry-tool.d/resume.conf"
RTC_DROP_IN="/etc/limine-entry-tool.d/rtc-alarm.conf"
[[ -f $RESUME_DROP_IN ]] && { echo "Removing resume kernel parameters"; sudo rm "$RESUME_DROP_IN"; }
[[ -f $RTC_DROP_IN ]] && sudo rm "$RTC_DROP_IN"and additionally strip resume=/resume_offset= from
/boot/<machine-id>/limine_history/snapshots.json so the snapshot entries stop resurrecting it.
System
| Omarchy | 4.0.2-1 |
| Kernel | 7.1.9-arch1-2 |
| CPU | AMD Ryzen 5 5600G |
| GPU | NVIDIA GeForce GTX 1660 SUPER (nvidia-open-dkms 610.57.04) |
| RAM | 15 GiB |
| Root | Btrfs on LUKS, Limine + UKI |
| limine | 12.6.0-1, limine-mkinitcpio-hook 1.37.1-1, limine-snapper-sync 1.31.0-1 |
PARTUUIDs redacted from the pasted cmdline above; full omarchy debug output available on request.
Activity
madakas commentedon Sep 3, 2026
Confirmed on a second machine and version: iMac17,1 (Btrfs + LUKS, Limine/UKI), Omarchy 4.0.1-1 — the
omarchy-hibernation-removeshipped in 4.0.1 has the same gap: it never references/etc/limine-entry-tool.d/resume.conf, so the drop-in survives the removal and the closinglimine-mkinitcpiobakesresume=/resume_offset=back into every regenerated entry.One addition that the suggested fix does not cover yet: current master's
omarchy-hibernation-setupwrites the resume parameters to a second location. Right after creating the drop-in, it also appends it to/etc/default/limine:Consequences on a master-based install:
$RESUME_DROP_IN(the fix proposed above) still leavesresume=/resume_offset=on the generated cmdline, via/etc/default/limine.[[ ! -f $RESUME_DROP_IN ]], so after a remove-then-setup cycle a second copy of the line is appended to/etc/default/limine— the recreated swapfile gets a fresh offset while the stale line stays in the file.So a symmetric remove needs, in addition to the two drop-ins:
sudo sed -i '/resume=.*resume_offset=/d' /etc/default/limine(The
/etc/default/limineappend does not exist in 4.0.1 — verified absent on my machine — so this part is master-only.)Filed by Claude Fable 5 via Claude Code.
exergonic commentedon Sep 9, 2026
Confirming on Omarchy 4.0.3-1 (btrfs on LUKS desktop, 7.2.3-arch1-3): after a successful
omarchy hibernation remove,/etc/limine-entry-tool.d/resume.confsurvived and all limine.conf cmdlines kept staleresume=/resume_offset=pointing at the deleted swapfile./etc/default/limineon this release build has no resume line, consistent with the master-only note above.omarchybot commentedon Oct 11, 2026
Confirmed in source on current
quattro(a3d4bea). Nothing was run: the mechanism can be read directly from the two scripts.bin/omarchy-hibernation-removedeletes the swapfile, the/swapsubvolume, the fstab entry andomarchy_resume.conf, then runslimine-mkinitcpiowith/etc/limine-entry-tool.d/resume.confstill in place, so the rebuilt entries keepresume=/resume_offset=for a swapfile that no longer exists.rtc-alarm.confis left behind the same way. There is a second consequence:omarchy-hibernation-setuponly writesresume.confwhen it is absent, so after a remove-then-setup cycle the new swapfile is paired with the old offset.omarchy-system-factory-resetalready works around exactly this.The fix for the core defect is already open as #13584. It deletes
resume.confbefore the rebuild, and it makes setup always recompute the offset and drop a stale drop-in when it can't. #13768 makes the same change to remove, but on a failed offset lookup it keeps the old drop-in, so #13584, the older of the two, is the one to prefer. This issue isn't yet linked to #13584 as one it closes: #13584 has been pushed to since it was last classified, and it is being reviewed again on its own. #10374, #12096 and #13583 report this same bug and are newer than this one.What neither pull request covers, for the maintainer to decide:
rtc-alarm.confis not removed. Revert "Use ACPI alarm for RTC wakeup on s2idle systems for hibernation" #14113 drops that drop-in from setup and removes it with a migration.resume.conf. Running remove again won't clean it up, because it exits as soon asomarchy_resume.confis gone. A migration would be needed./etc/default/limineappend mentioned above exists only ondev(3.x), not onquattro.Reviewed by Claude Opus 5.5, with a second opinion from Codex Medium. Codex agreed on the mechanism and independently found the #13768 stale-offset case and the gap for machines already affected. Its independence from this review is not guaranteed. This now waits on the maintainer's decision on #13584 and the follow-ups above.
zkellsworth commentedon Oct 13, 2026
Confirming on Omarchy 4.0.4-1 (fresh install, btrfs on LUKS, Limine, i9-13900K / RTX 4090). After omarchy hibernation remove, /etc/limine-entry-tool.d/resume.conf survived with resume=/dev/mapper/root resume_offset=1889153. Removing it by hand and running sudo limine-mkinitcpio cleaned it up.