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.
limine template hardcodes default_entry: 2, so the linux-omarchy migration silently keeps booting the stock kernel
Reported by dragosol · filed Sep 20, 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
Description
Migration 1789325478.sh — "Install the Omarchy kernel and make it the first Limine boot entry" — correctly installs linux-omarchy and makes it entry 1. But omarchy-settings ships a Limine template with the default pointing at entry 2:
/usr/share/omarchy/default/limine/limine.conf:3:default_entry: 2Since the migration deliberately leaves the old kernel installed ("so it remains available if the new one cannot boot"), the generated entry list is:
/+Omarchy
1. //linux-omarchy → 7.2.5-3-omarchy
2. //linux → 7.2.3-arch1-3 ← default_entry: 2
//SnapshotsThe migration promotes the Omarchy kernel to the top of the list, and the shipped default selects the one immediately below it. The machine keeps booting the stock Arch kernel indefinitely.
Why it is easy to miss
Nothing looks wrong. /etc/default/limine has the right BOOT_ORDER, the migration is marked complete, linux-omarchy is installed, and the boot menu lists it first. The only symptom is uname -r, which most people never check after an update that never claimed to need a reboot.
On this machine the migration ran 2026-09-16 07:05 and the stock kernel was still what was running four days later:
$ uname -r
7.2.3-arch1-3
$ pacman -Q linux linux-omarchy
linux 7.2.3.arch1-3
linux-omarchy 7.2.5-3
$ grep '^default_entry' /boot/limine.conf
default_entry: 2/boot/limine.conf was regenerated 2026-09-19 15:53 — after the migration — and still carried default_entry: 2, so nothing self-corrects on a later update.
Steps to reproduce
- Machine installed before the
linux-omarchymigration, so stocklinuxis present. - Update to 4.0.4; migration
1789325478.shinstallslinux-omarchyand setsBOOT_ORDER. - Reboot and accept the default entry.
uname -rreports the stock kernel.
Suggested fix
default_entry: 2 is a hardcoded index into a list whose contents depend on how many kernels are installed, which is fragile by construction. Either:
- ship
default_entry: 1so the default followsBOOT_ORDER's first entry, or - have
1789325478.shsetdefault_entryexplicitly after it rewritesBOOT_ORDER, rather than relying on the template, or - drop
default_entryfrom the template and let Limine default to the first entry.
The second is probably safest for existing installs, since the template alone will not repair machines that already have the wrong value.
Environment
omarchy 4.0.4-1 · omarchy-settings 4.0.4-1 · limine-mkinitcpio-hook 1.38.0-1.1 · Arch x86_64 · Dell XPS 13 9350 (Lunar Lake)
View raw text
### Description
Migration `1789325478.sh` — *"Install the Omarchy kernel and make it the first Limine boot entry"* — correctly installs `linux-omarchy` and makes it **entry 1**. But `omarchy-settings` ships a Limine template with the default pointing at **entry 2**:
```
/usr/share/omarchy/default/limine/limine.conf:3:default_entry: 2
```
Since the migration deliberately leaves the old kernel installed ("so it remains available if the new one cannot boot"), the generated entry list is:
```
/+Omarchy
1. //linux-omarchy → 7.2.5-3-omarchy
2. //linux → 7.2.3-arch1-3 ← default_entry: 2
//Snapshots
```
**The migration promotes the Omarchy kernel to the top of the list, and the shipped default selects the one immediately below it.** The machine keeps booting the stock Arch kernel indefinitely.
### Why it is easy to miss
Nothing looks wrong. `/etc/default/limine` has the right `BOOT_ORDER`, the migration is marked complete, `linux-omarchy` is installed, and the boot menu lists it first. The only symptom is `uname -r`, which most people never check after an update that never claimed to need a reboot.
On this machine the migration ran 2026-09-16 07:05 and the stock kernel was still what was running four days later:
```
$ uname -r
7.2.3-arch1-3
$ pacman -Q linux linux-omarchy
linux 7.2.3.arch1-3
linux-omarchy 7.2.5-3
$ grep '^default_entry' /boot/limine.conf
default_entry: 2
```
`/boot/limine.conf` was regenerated 2026-09-19 15:53 — after the migration — and still carried `default_entry: 2`, so nothing self-corrects on a later update.
### Steps to reproduce
1. Machine installed before the `linux-omarchy` migration, so stock `linux` is present.
2. Update to 4.0.4; migration `1789325478.sh` installs `linux-omarchy` and sets `BOOT_ORDER`.
3. Reboot and accept the default entry.
4. `uname -r` reports the stock kernel.
### Suggested fix
`default_entry: 2` is a hardcoded index into a list whose contents depend on how many kernels are installed, which is fragile by construction. Either:
- ship `default_entry: 1` so the default follows `BOOT_ORDER`'s first entry, or
- have `1789325478.sh` set `default_entry` explicitly after it rewrites `BOOT_ORDER`, rather than relying on the template, or
- drop `default_entry` from the template and let Limine default to the first entry.
The second is probably safest for existing installs, since the template alone will not repair machines that already have the wrong value.
### Environment
omarchy 4.0.4-1 · omarchy-settings 4.0.4-1 · limine-mkinitcpio-hook 1.38.0-1.1 · Arch x86_64 · Dell XPS 13 9350 (Lunar Lake)
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 16:50 UTC