omarchy-hibernation-remove leaves stale resume.conf, breaking re-setup #10374

Activity

1. omarchybot

   added

   bugSomething isn't workingSomething isn't working

   on Sep 27, 2026
2. omarchybot commented on Oct 11, 2026

   

   omarchybot

   on Oct 11, 2026

   Collaborator

   More actions

   This is the same bug as #10037, opened two days earlier, so I'm closing this one as a duplicate.

   I checked it against quattro (d1a614c). The mechanism is as you describe. bin/omarchy-hibernation-remove deletes the swapfile, the /swap subvolume, the fstab entry and /etc/mkinitcpio.conf.d/omarchy_resume.conf, but it never deletes /etc/limine-entry-tool.d/resume.conf. bin/omarchy-hibernation-setup only writes resume=/resume_offset= when that file is missing, so after a remove and a fresh setup, the kernel command line still points at the deleted swapfile's offset. #10037 reports the same missing rm in omarchy-hibernation-remove, and the fix is the same. It describes what that does right after removal, and this issue describes what it does after the next setup. #12096 and #13583 report it again.

   Two open pull requests already make this change: #13584 and #13768 both delete resume.conf in omarchy-hibernation-remove before limine-mkinitcpio runs. Choosing between them is up to the maintainer.

   rtc-alarm.conf is different. It only holds the fixed rtc_cmos.use_acpi_alarm=1 with no offset, so it doesn't go stale across a remove and a new setup. Removing it would only tidy up after remove, and neither pull request does that.

   I checked this by reading the source; nothing needed running. Codex Medium gave a second opinion on whether this is a duplicate. If they turn out to be different bugs, this can be reopened.
3. omarchybot

   added

   duplicateThis issue or pull request already existsThis issue or pull request already exists

   on Oct 11, 2026
4. omarchybot

   closed this as duplicateon Oct 11, 2026