Creating a snapshot failed.

Omarchy takes a Btrfs snapshot before every update so you can roll back from the Limine boot menu. When that step fails you see a snapper error, and on older releases the whole update stopped there. This page covers Omarchy 3.x through 4.0.4.

The fix

1. Get the real error. The line you saw is snapper’s generic failure message (its source string is “Creating snapshot failed.”), and the specific cause is printed next to it. Run the snapshot by hand:

omarchy-snapshot create

If the update itself failed, the full session is logged at /tmp/omarchy-update.log. Background failures show up in journalctl -u snapper-cleanup.service -u limine-snapper-sync.service -b.

2. If a swapfile sits on the root subvolume. This is the most common cause. Btrfs refuses to snapshot a subvolume that holds an active swapfile. Check:

swapon --show

If you see a file such as /swapfile (as opposed to /dev/zram0 or /swap/swapfile), turn it off and retry:

sudo swapoff /swapfile
omarchy-snapshot create

That is the quick unblock. To keep swap and keep snapshots, move the swapfile onto its own top level subvolume. Omarchy’s own omarchy-hibernation-setup (present in 3.8.4 and 4.x) creates a /swap subvolume, marks it NOCOW, and puts a RAM sized swapfile there, but it also adds the resume hook and kernel parameters for hibernation. If you want swap without hibernation, jacksenechal posted the manual version in discussion #3168: swapoff, delete /swapfile, drop its /etc/fstab line, mount subvolid=5, btrfs subvolume create @swap, mount it at /swap, then sudo btrfs filesystem mkswapfile --size 16g /swap/swapfile and add the new fstab entry.

3. If the error says .snapshots is not a btrfs subvolume. This happens after restoring a system from rsync, tar, or a clone, where /.snapshots comes back as a plain directory. Reported as issue #11100 on 4.0.3, still open. Confirm first:

sudo btrfs subvolume show /.snapshots

If that fails and the directory is empty, replace it:

sudo rmdir /.snapshots
sudo btrfs subvolume create /.snapshots
sudo chmod 750 /.snapshots
omarchy-snapshot create

Do not rm -rf a /.snapshots that still holds real snapshots. Check sudo snapper -c root list first.

4. If you get No Snapper configs found, so no snapshot was created. This message is 4.x only. Before you act on it, check that sudo actually worked. Issue #10421 showed that a sudo failure inside the config lookup produces the same message, and the suggested repair then overwrites a config that was fine. Run sudo -v first, then:

sudo snapper list-configs

If that really is empty, create the config:

sudo snapper -c root create-config /
sudo bash -euo pipefail /usr/share/omarchy/install/config/snapper.sh

The second command installs Omarchy’s retention template (five snapshots, no timeline), enables snapper-cleanup.timer and limine-snapper-sync.service. Caution from issue #9619: it rewrites /etc/conf.d/snapper to SNAPPER_CONFIGS="root", which de-registers any extra config you added, such as home. Copy that file aside first and put your config names back afterwards.

5. If your root is not Btrfs. Issue #6683 covers this. install/config/snapper.sh writes a config with FSTYPE="btrfs" regardless of the real filesystem, so on ext4 you get a phantom root config, a daily failing snapper-cleanup.service, and a failing pre-update snapshot. Check with findmnt / -o TARGET,SOURCE,FSTYPE. If it is not btrfs, remove the config and stop the timers:

sudo snapper -c root delete-config 2>/dev/null || sudo rm -f /etc/snapper/configs/root
sudo systemctl disable --now snapper-cleanup.timer limine-snapper-sync.service

Snapshots are not available on a non-Btrfs root. Updates still work, and 4.x will say it continued without one.

Verify it worked

sudo snapper -c root create -c number -d "verify"
sudo snapper -c root list | tail -5
systemctl status snapper-cleanup.timer limine-snapper-sync.service

You should see your new snapshot numbered at the bottom of the list, both units healthy, and then omarchy-snapshot create finishing with “Snapshots can be selected during boot.” (4.x wording; 3.x prints nothing after the green header). Reboot once and confirm the dated entries appear under Snapshots in the Limine menu. Delete the test snapshot with sudo snapper -c root delete <number>.

Why it happens

omarchy-snapshot create asks snapper for its list of configs, then loops over them running snapper -c <config> create -c number followed by cleanup number. Anything that makes one of those calls fail takes the whole step down. That includes an active swapfile pinning the root subvolume, a /.snapshots path that is not a subvolume, a config that names a filesystem the machine does not have, and a sudo prompt that cannot be answered.

The version difference matters. On 3.x the updater ran omarchy-snapshot create || (($? == 127)) under set -e, so any failure other than “snapper is not installed” tripped the error trap and you got “Something went wrong during the update!” with nothing updated. Omarchy 4.0.0 changed this with PR #6580 by nille, merged 2026-08-07: a failed snapshot now prints “Continuing the update without a snapshot.” and the update proceeds, and a snapper with no configs fails loudly instead of printing a green header over nothing. That is friendlier but easy to miss in the scroll, so an install can keep updating with no working rollback.

Disk pressure is the other family of reports. Machines set up before the snapper config was normalized in June 2026 took hourly timeline snapshots. Later configs stopped creating new ones but never removed the old ones, and snapper’s number cleanup ignores anything tagged Cleanup=timeline, so the pile only grew. PR #6354 measured one machine at 592 leaked snapshots pinning 219 GB. Omarchy 4.x ships a migration that drains snapshots marked Cleanup=timeline in batches of 20, but only when your config has TIMELINE_CREATE="no". If the disk is full, snapper fails too. Note that 4.x refuses to start an update with less than 10 GiB free on /.

If that did not work

Check sudo btrfs filesystem du -s --human-readable /.snapshots for what the snapshots actually cost, and sudo snapper list -a for stragglers. Old @home/.snapshots/<n>/snapshot subvolumes can survive a snapper delete and need sudo btrfs subvolume delete by hand.

If limine-snapper-sync.service goes inactive right after boot, issue #6629, filed on 3.8.4, reports the watcher needs inotify-tools, which that release did not install. The 4.x base package list includes it, so this should only bite older installs: sudo pacman -S inotify-tools then restart the unit.

If this started at install time rather than at update time, you are probably looking at issue #3543 instead: on a hand built Arch install, the Omarchy limine-snapper install step bails with “Error: Limine config not found”, leaving snapper unconfigured. The original report had limine.conf in a path the script did not check; later commenters hit it because /boot was mounted with fmask=0077, so the config on the ESP was unreadable as a normal user. They worked around it by setting fmask=0022,dmask=0022 on the /boot line in /etc/fstab and remounting, or by adding sudo to the checks, then re-running install/login/limine-snapper.sh.

Evidence for the rest is thin. Several of these reports are still open against 4.0.x with no merged fix, so treat the steps above as workarounds rather than a repaired upstream. If the snapshot step keeps failing, you can still update: take your own backup, run the update, and read what migrations do so you know what changed.

Related

• omarchy update fails or hangs
• Rollback with snapper and Limine
• Before you update checklist
• Hibernate fails or hangs
• Kernel panic after update
• Omarchy manual: System snapshots