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.
Stale/orphaned PARTUUID in /etc/default/limine silently overrides /etc/kernel/cmdline, breaking LUKS auto-unlock after update — no validation against actual disk
Reported by pastorinj-pixel · filed Sep 15, 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
System details
- Omarchy 4.0.3, kernel 7.2.3-arch1-3 (regression appeared moving from 7.1.9)
- Filesystem: LUKS + Btrfs (subvolumes @, @home, @log, @pkg)
- Bootloader: Limine, UKI enabled
What happened
After yay -Syu upgraded limine 12.6.0→12.8.0, limine-mkinitcpio-hook
1.37.1→1.38.0, and limine-snapper-sync 1.31.0→1.31.0-1.1, the next boot
dropped to an emergency shell: the initramfs never attempted to unlock the
LUKS root (no passphrase prompt at all — /dev/mapper never populated).
Root cause
/etc/default/limine's KERNEL_CMDLINE[default]+=... line had a PARTUUID
(c4e66e2d-...) that doesn't match any partition on the disk — not the
ESP, not the LUKS partition. Because this file is loaded with highest
priority by limine-common-functions (see the "4. Load /etc/default/limine
(highest priority)" comment in that lib), it silently overrode the correct
PARTUUID that was present the whole time in /etc/kernel/cmdline. Two
Btrfs snapshot boot entries (older kernel, predating whenever this file was
last touched) still had the correct PARTUUID baked in, which is what made
this look kernel/regen-specific rather than a simple typo.
Repeatedly running limine-mkinitcpio reproduced the bad entry every time,
because it was faithfully reading the already-corrupt override file — the
tool isn't at fault for that part, but nothing in the chain validates the
override's PARTUUID/UUID against blkid/lsblk before baking it into a
boot entry that will hard-fail unlock if wrong.
What I could not pin down
I audited this system for anything that currently writes to/etc/default/limine (Hyprland plugins: none installed; every
Omarchy/limine-snapper script that references the file: none write a
PARTUUID into it — only omarchy-refresh-limine writes a limine config,
and only to /boot/limine.conf). omarchy-upgrade-to-quattro has apreserve_kernel_cmdline_root() function whose comments describe an
adjacent failure mode, but it only fills in a missing root=, never
overwrites an existing wrong value, and there's no trace it ran here. So I
can't identify the exact mechanism that wrote the stale PARTUUID — only
that it was already sitting in the file before this update'slimine-mkinitcpio regen baked it into the new boot entry. The oldlimine-mkinitcpio-hook 1.37.1 package is no longer in the pacman cache to
inspect its prior scriptlet.
Suggestion
Before limine-mkinitcpio/limine-entry-tool bakes a cryptdevice=/root=
PARTUUID from /etc/default/limine into a boot entry, validate it againstblkid/lsblk output and warn (or refuse) if it doesn't match any present
partition — this would have surfaced the problem at regen time instead of
at boot.
Fix used
Corrected the PARTUUID in /etc/default/limine to match the actual LUKS
partition (confirmed via blkid), matching what /etc/kernel/cmdline
already had, then reran limine-mkinitcpio and verified all boot entries
agree.
View raw text
## System details - Omarchy 4.0.3, kernel 7.2.3-arch1-3 (regression appeared moving from 7.1.9) - Filesystem: LUKS + Btrfs (subvolumes @, @home, @log, @pkg) - Bootloader: Limine, UKI enabled ## What happened After `yay -Syu` upgraded `limine` 12.6.0→12.8.0, `limine-mkinitcpio-hook` 1.37.1→1.38.0, and `limine-snapper-sync` 1.31.0→1.31.0-1.1, the next boot dropped to an emergency shell: the initramfs never attempted to unlock the LUKS root (no passphrase prompt at all — `/dev/mapper` never populated). ## Root cause `/etc/default/limine`'s `KERNEL_CMDLINE[default]+=...` line had a PARTUUID (`c4e66e2d-...`) that doesn't match *any* partition on the disk — not the ESP, not the LUKS partition. Because this file is loaded with highest priority by `limine-common-functions` (see the "4. Load /etc/default/limine (highest priority)" comment in that lib), it silently overrode the *correct* PARTUUID that was present the whole time in `/etc/kernel/cmdline`. Two Btrfs snapshot boot entries (older kernel, predating whenever this file was last touched) still had the correct PARTUUID baked in, which is what made this look kernel/regen-specific rather than a simple typo. Repeatedly running `limine-mkinitcpio` reproduced the bad entry every time, because it was faithfully reading the already-corrupt override file — the tool isn't at fault for that part, but nothing in the chain validates the override's PARTUUID/UUID against `blkid`/`lsblk` before baking it into a boot entry that will hard-fail unlock if wrong. ## What I could not pin down I audited this system for anything that currently *writes* to `/etc/default/limine` (Hyprland plugins: none installed; every Omarchy/limine-snapper script that references the file: none write a PARTUUID into it — only `omarchy-refresh-limine` writes a limine config, and only to `/boot/limine.conf`). `omarchy-upgrade-to-quattro` has a `preserve_kernel_cmdline_root()` function whose comments describe an adjacent failure mode, but it only fills in a *missing* `root=`, never overwrites an existing wrong value, and there's no trace it ran here. So I can't identify the exact mechanism that wrote the stale PARTUUID — only that it was already sitting in the file before this update's `limine-mkinitcpio` regen baked it into the new boot entry. The old `limine-mkinitcpio-hook` 1.37.1 package is no longer in the pacman cache to inspect its prior scriptlet. ## Suggestion Before `limine-mkinitcpio`/`limine-entry-tool` bakes a `cryptdevice=`/`root=` PARTUUID from `/etc/default/limine` into a boot entry, validate it against `blkid`/`lsblk` output and warn (or refuse) if it doesn't match any present partition — this would have surfaced the problem at regen time instead of at boot. ## Fix used Corrected the PARTUUID in `/etc/default/limine` to match the actual LUKS partition (confirmed via `blkid`), matching what `/etc/kernel/cmdline` already had, then reran `limine-mkinitcpio` and verified all boot entries agree.
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 13:33 UTC