Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
Snapshot boot entry cmdline has typo 'zswaap.enabled=0' after fresh 4.0.4 install
Reported by MyriadColors · filed Sep 24, 2026 · open at source
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
Summary
Fresh Omarchy 4.0.4 install generates a snapshot boot entry in /boot/limine.conf whose kernel cmdline contains zswaap.enabled=0 (typo for zswap.enabled=0), while every actual configuration source on the installed system is correct.
Environment
- Omarchy 4.0.4-1 (ISO build 2026-09-15), kernel
7.2.5-3-omarchy,limine 12.8.0,limine-mkinitcpio-hook 1.38.0,limine-snapper-sync 1.31.0 - x86_64 / UEFI / LUKS on
nvme0n1p2booted via UKI entries (ENABLE_UKI=yes,CUSTOM_UKI_NAME=omarchy), btrfs@/@.snapshotssubvol layout - Hardware: Samsung 850XBD
Symptom
The first Snapper snapshot entry created during install (2026-09-24 11:08) has:
cmdline: cryptdevice=PARTUUID=... root=/dev/mapper/root zswaap.enabled=0 rootflags=subvol=/@/.snapshots/1/snapshot rw rootfstype=btrfs resume=... initramfs_async=0 quiet splash ...The main /Omarchy entry in the same file and all cmdline sources are correct (zswap.enabled=0):
/etc/kernel/cmdline/etc/default/limine→KERNEL_CMDLINE[default]+="cryptdevice=... zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs"- booted
/proc/cmdline
Impact
zswaap.enabled=0 is an unknown kernel parameter and is silently ignored, so zswap.enabled=0 does not apply when booting a snapshot. Arch kernels enable zswap by default; Omarchy additionally disables it at runtime via tmpfiles.d/omarchy-zswap.conf, so both mechanisms are bypassed/affected on snapshot boots.
Root cause unclear / not reproducible post-install
rg zswaap over /etc, /usr/share/omarchy, /usr/lib/limine — and the ISO's airootfs.sfs /etc — finds nothing after the fact. The bad string existed only in the generated /boot/limine.conf. Likely the install-time tool run transiently sourced the cmdline from somewhere other than the final /etc/kernel/cmdline + /etc/default/limine, and the value was baked into the snapshot entry; later entry-tool runs refresh the main entry but the snapshot section only rewrites on the next limine-snapper-sync.
Verified fix
Running limine-snapper-sync rewrites snapshot entries from the live /proc/cmdline; it produced an exact one-line diff zswaap → zswap and /boot/limine.conf is now correct.
Suggested hardening
Have the installer run limine-entry-tool and limine-snapper-sync as a final post-install step (or validate the generated snapshot cmdline against /etc/kernel/cmdline), so snapshot entries cannot retain stale/transient cmdline values from install time.
View raw text
## Summary Fresh Omarchy 4.0.4 install generates a snapshot boot entry in `/boot/limine.conf` whose kernel cmdline contains `zswaap.enabled=0` (typo for `zswap.enabled=0`), while every actual configuration source on the installed system is correct. ## Environment - Omarchy 4.0.4-1 (ISO build 2026-09-15), kernel `7.2.5-3-omarchy`, `limine 12.8.0`, `limine-mkinitcpio-hook 1.38.0`, `limine-snapper-sync 1.31.0` - x86_64 / UEFI / LUKS on `nvme0n1p2` booted via UKI entries (`ENABLE_UKI=yes`, `CUSTOM_UKI_NAME=omarchy`), btrfs `@`/`@.snapshots` subvol layout - Hardware: Samsung 850XBD ## Symptom The first Snapper snapshot entry created during install (2026-09-24 11:08) has: ``` cmdline: cryptdevice=PARTUUID=... root=/dev/mapper/root zswaap.enabled=0 rootflags=subvol=/@/.snapshots/1/snapshot rw rootfstype=btrfs resume=... initramfs_async=0 quiet splash ... ``` The main `/Omarchy` entry in the same file and all cmdline sources are correct (`zswap.enabled=0`): - `/etc/kernel/cmdline` - `/etc/default/limine` → `KERNEL_CMDLINE[default]+="cryptdevice=... zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs"` - booted `/proc/cmdline` ## Impact `zswaap.enabled=0` is an unknown kernel parameter and is silently ignored, so `zswap.enabled=0` does not apply when booting a snapshot. Arch kernels enable zswap by default; Omarchy additionally disables it at runtime via `tmpfiles.d/omarchy-zswap.conf`, so both mechanisms are bypassed/affected on snapshot boots. ## Root cause unclear / not reproducible post-install `rg zswaap` over `/etc`, `/usr/share/omarchy`, `/usr/lib/limine` — and the ISO's `airootfs.sfs` `/etc` — finds nothing after the fact. The bad string existed only in the generated `/boot/limine.conf`. Likely the install-time tool run transiently sourced the cmdline from somewhere other than the final `/etc/kernel/cmdline` + `/etc/default/limine`, and the value was baked into the snapshot entry; later entry-tool runs refresh the main entry but the snapshot section only rewrites on the next `limine-snapper-sync`. ## Verified fix Running `limine-snapper-sync` rewrites snapshot entries from the live `/proc/cmdline`; it produced an exact one-line diff `zswaap` → `zswap` and `/boot/limine.conf` is now correct. ## Suggested hardening Have the installer run `limine-entry-tool` and `limine-snapper-sync` as a final post-install step (or validate the generated snapshot cmdline against `/etc/kernel/cmdline`), so snapshot entries cannot retain stale/transient cmdline values from install time.
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
Not linked to any known issue, other report or change yet.
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 18:19 UTC