Hibernate fails or hangs on Omarchy

Hibernate on Omarchy has two common failure shapes. Either the image is written and the machine powers down, but the next boot is a cold boot with your session gone, or the image is written and the machine never powers off at all. The steps below cover both. Everything here was checked against the v4.0.4 source tree and the v3.8.4 tree for comparison.

The fix

Work through these in order. Steps 1 to 3 apply to every machine. Step 4 is NVIDIA only.

1. Confirm the kernel will accept hibernation at all.

cat /sys/power/state   # must contain "disk"
cat /sys/power/disk    # must not be "[disabled]"
swapon --show

omarchy hibernation available does not check /sys/power/state. It only looks for /sys/power/image_size, non-zram swap larger than the image size, and /etc/mkinitcpio.conf.d/omarchy_resume.conf. mnemonicspace showed in issue #7730 that all three can pass while /sys/power/disk reads [disabled], which is why the Hibernate menu item can appear and then do nothing. In that thread the cause turned out to be Bitwarden Desktop holding a memfd_secret file, which the kernel treats as a hibernation blocker. Closing it, or launching it with SECURE_KEY_CONTAINER_BACKEND=mlock, brought disk back.

2. Set hibernation up if it is not already there.

omarchy hibernation setup

This needs Limine and Btrfs. It creates a /swap subvolume with a swapfile the size of your RAM, adds it to /etc/fstab, writes HOOKS+=(resume) to /etc/mkinitcpio.conf.d/omarchy_resume.conf, and writes resume= plus resume_offset= to /etc/limine-entry-tool.d/resume.conf. On 3.x the same values were also appended to /etc/default/limine. Omarchy 4 writes only the drop-in. If it prints Hibernation is already set up, it changed nothing, which matters for the next step.

3. Check the resume offset actually matches the swapfile.

sudo btrfs inspect-internal map-swapfile -r /swap/swapfile
cat /etc/limine-entry-tool.d/resume.conf

If the numbers differ, edit the drop-in. omarchy hibernation setup will not repair this for you. As adevwithpurpose showed in issue #11437, the script only writes the drop-in when the file is absent, and its repair branch matches an empty value, never a stale one. On 3.x, fix /etc/default/limine too.

Then rebuild:

sudo limine-mkinitcpio
sudo reboot

4. On NVIDIA, take the driver out of the initramfs.

sudo mv /etc/mkinitcpio.conf.d/nvidia.conf /etc/mkinitcpio.conf.d/nvidia.conf.disabled
sudo limine-mkinitcpio
sudo reboot

This is the change reported working on single-GPU desktops across Ampere, Ada and Blackwell in issues #5554 and #10039. NVIDIA still loads once the root filesystem is up and nvidia-smi still works. The cost is a plainer LUKS prompt on a single-GPU box, since Plymouth falls back to the firmware framebuffer. The installer writes this file from install/hardware/nvidia.sh, so re-check it after a reinstall or a major upgrade.

On a hybrid laptop there is a lighter option. The -5 failure needs NVreg_PreserveVideoMemoryAllocations=1, and on Omarchy that value comes from /usr/lib/modprobe.d/gsr-nvidia.conf, installed by Arch’s gpu-screen-recorder package. Appending options nvidia NVreg_PreserveVideoMemoryAllocations=0 to /etc/modprobe.d/nvidia.conf sorts after it and wins. diegomendi and jorgenfoss both confirmed resume working with only that change, on a Radeon 680M plus RTX 4050 laptop in #5554 and an ASUS ProArt P16 in #10375.

Verify it worked

Check the live cmdline first:

tr ' ' '\n' < /proc/cmdline | grep resume

Now hibernate with systemctl hibernate, power back on, and look at the boot list:

journalctl --list-boots | tail -3

A real resume keeps the same boot ID before and after, because the restored image is the old kernel instance. A failed resume shows up as a new boot. jorgenfoss pointed this out in #10375 as a cleaner test than grepping for strings. If you want the strings anyway:

journalctl -b -k | grep -E 'PM: |resume'

A good run shows Image signature found, Image successfully loaded, and hibernation exit. PM: Image not found (code -22) means the hook ran and found nothing at the offset, so go back to step 3. Failed to load image, recovering after a full load is the NVIDIA case. If the machine hung instead, the evidence is in the next boot’s journal, not the failed one. Once userspace is frozen, journald has stopped writing.

Why it happens

Hibernation on Omarchy stacks four fragile things. The swap is a file on Btrfs, so the kernel needs a physical block offset rather than a device, and that offset changes if the file is ever recreated. The root is LUKS, so the resume hook has to run after encrypt. The boot is a Limine UKI, so every cmdline change needs a rebuild. And zram sits at priority 100 above the disk swapfile at priority 0, sized to all of RAM since 4.0.0, which is correct but makes swapon --show confusing to read.

One thing that looks broken is not. omarchy_hooks.conf reassigns the whole array with HOOKS=(...) and omarchy_resume.conf only appends, so resume always lands last, after filesystems. manuelbecker123 documented the sort-order clash in issue #8471 and jorgenfoss reported it in #10375. But filesystems and fsck have no runtime hook, and mkinitcpio’s init runs every run_hook before it mounts anything, so resume at the end is still the next hook after encrypt. TechLuddite showed this from a kernel log in #8471, and jorgenfoss’s own failed boot in #10375 had the image fully loaded before NVIDIA aborted it. Reordering the hook is not the fix.

The NVIDIA case is separate and worse. Omarchy early-loads nvidia, nvidia_modeset, nvidia_uvm and nvidia_drm from the initramfs for early KMS at the LUKS prompt. The resume hook runs in that same initramfs, after the driver has bound to the card. With NVreg_PreserveVideoMemoryAllocations set to 1, the driver refuses a freeze that did not come through its own suspend path, so nv_pmops_freeze returns -EIO and the kernel discards the restore. unconnect laid this out in issue #10039. Issue #5554 is the tracking issue and it is still open.

If that did not work

Image written, machine never powers off. wjax found in issue #8589 that the kernel can abort silently during image creation on an s2idle-only machine. Create /etc/systemd/sleep.conf.d/hibernate-mode.conf containing a [Sleep] section with HibernateMode=shutdown.

Hybrid ASUS ROG. Omarchy ships a force-igpu sleep hook that detaches the dGPU through supergfxctl before hibernate, but rdelpiano showed in issue #9696 that neither the hook nor supergfxctl is installed unless you have run omarchy toggle hybrid gpu. Run it. On 4.0.0 to 4.0.2 the toggle copied the hook without the executable bit, per PR #8588, so also check that stat -c %A /usr/lib/systemd/system-sleep/force-igpu starts with -rwx.

NVIDIA desktop still cold-boots after step 4. hanshs got a Blackwell 5070 Ti desktop resuming in #5554 with the drop-in disabled plus nvidia-suspend.service, nvidia-hibernate.service and nvidia-resume.service enabled. A different symptom, the image written and restored but the machine never powering off, is the NVIDIA .shutdown hang that tzalkind and asmyshlyaev177 reported in the same thread. No module parameter avoids it.

AMD crashes after resume. sspaeti reported in issue #4259 that adding amdgpu.gpu_recovery=1 and amdgpu.noretry=0 to the kernel cmdline, later with amdgpu.ip_block_mask=0xfffff7ff and amdgpu.cwsr_enable=0, ended the post-hibernate crashes on a TUXEDO InfinityBook Pro 14. That was on 3.x, where the cmdline lived in /etc/default/limine. On 4.x put it in a /etc/limine-entry-tool.d/ drop-in instead.

You removed hibernation and boot got worse. omarchy hibernation remove deletes the swapfile and the mkinitcpio hook but leaves /etc/limine-entry-tool.d/resume.conf in place, so the rebuilt UKI still carries resume= pointing at blocks that no longer hold a swapfile. brenodyego reported this in issue #10037. Delete the drop-in yourself, then run sudo limine-mkinitcpio.

Nothing changed on 4.0.0 to 4.0.2. The keyboard backlight sleep hook was installed non-executable on those releases, so it never ran. janne reported it in issue #7618 and 4.0.3 replaced the cp -p with a mode 0755 install. The visible impact is limited to ASUS keyboards blocking S4.

Related

• The System sleep chapter of the Omarchy manual
• Suspend will not resume from s2idle
• NVIDIA drivers on Omarchy 4
• Hybrid GPU laptop black screen
• Suspend and sleep hardware notes
• omarchy-hibernation-setup