Proof Portal

Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-1520GitHub issuePublicReceived

omarchy-upgrade-to-quattro leaves archinstall's /EFI/Linux/arch-linux.efi Limine entry in place, so the default boot entry panics

Reported by michaelsahlmann · filed Aug 24, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as not planned.

Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

omarchy-upgrade-to-quattro leaves archinstall's /EFI/Linux/arch-linux.efi Limine entry in place, so the default boot entry panicsrevision 1 · captured 2026-09-28 21:24 UTC via poll

What happened

After a routine omarchy update (which bumped linux 7.1.8.arch1-3 → 7.1.9.arch1-2 and omarchy-dev r1796 → r1816), the machine failed to boot into the default Limine entry:

PANIC: efi: Failed to open image with path 'boot():/EFI/Linux/arch-linux.efi'. Is the path correct?
Stacktrace:
  [0x7e83caef] <panic+0x15f>
  [0x7e85829e] <chainload+0x8e>
  [0x7e854e7b] <boot+0x16b>
  [0x7e853e89] <_menu+0x1fd9>
End of trace. Press a key to return to menu.

The system itself was fine — the working /+Omarchy entry booted normally. The panic came from a stale, hand-written entry that was still sitting at the top of /boot/limine.conf, i.e. the entry Limine selects when the timeout expires:

timeout: 5

/Arch Linux (linux)
    protocol: efi
    path: boot():/EFI/Linux/arch-linux.efi
    cmdline: cryptdevice=PARTUUID=...:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs
/+Omarchy
### This OS entry is auto-generated by limine-entry-tool
...
  path: boot():/EFI/Linux/omarchy_linux.efi#4c516ba8...

/boot/EFI/Linux/ contained only omarchy_linux.efi; arch-linux.efi no longer exists.

Where it comes from

/EFI/Linux/arch-linux.efi with a menu entry titled Arch Linux (linux) is what archinstall's Limine setup writes. It is not an Omarchy path — grep -rn 'arch-linux.efi' /usr/share/omarchy/ returns nothing.

Because the entry carries no ### auto-generated by limine-entry-tool marker, limine-entry-tool correctly leaves it alone on every regeneration, so it survives indefinitely.

What I expected

omarchy-upgrade-to-quattro already owns exactly this cleanup. normalize_limine_config() (around lines 497-515) migrates the other legacy UKI naming scheme:

# Pre-quattro custom-UKI installs used <machine-id>_linux.efi. Omarchy quattro uses the
# stable omarchy_linux.efi path generated by limine-entry-tool.
legacy_uki="/boot/EFI/Linux/${machine_id}_linux.efi"
if [[ -n $machine_id ]] && as_root test -f /boot/EFI/Linux/omarchy_linux.efi && as_root test -f "$legacy_uki"; then

I expected the same function to also drop (or at least de-prioritise) a manual entry whose path: points at a UKI that no longer exists on the ESP — especially when that entry is the default one.

The remove_legacy_limine_configs() / normalize_limine_config() pair guards against this class of problem, and there is even a validation step later (~line 615-623) that checks root= is present in limine.conf and enumerates omarchy_linux*.efi — but nothing notices a top-of-file entry pointing at a deleted image.

Steps to reproduce

  1. Install Arch with archinstall using Limine as the bootloader (writes /EFI/Linux/arch-linux.efi and the Arch Linux (linux) entry).
  2. Install Omarchy on top and run omarchy-upgrade-to-quattro, which sets CUSTOM_UKI_NAME="omarchy" so the UKI is generated as omarchy_linux.efi.
  3. Let any subsequent kernel update run. The old arch-linux.efi is gone; the manual entry remains first in the menu.
  4. Reboot and let the timeout expire instead of picking an entry.

Suggested fix

In normalize_limine_config(), after the omarchy_linux.efi UKI is confirmed present, strip any top-level entry whose path: resolves to a file that is absent from the ESP — or at minimum the known arch-linux.efi from archinstall. Failing hard with the existing fail/"do not reboot" messaging would also be an improvement over a silent panic at the next boot.

Workaround

Deleting the four stale lines from /boot/limine.conf fixes it; limine-entry-tool does not re-add them and no UKI regeneration is needed.

System details

  • omarchy version: 4.0.0.r1816.g43bfe9b-1 (edge channel, 4.0.0.alpha)
  • Kernel: 7.1.9-arch1-2
  • limine 12.6.0-1, limine-mkinitcpio-hook 1.37.1-1
  • Board: ASUSTeK PRIME B460M-A (BIOS 1806), Intel i5-10400F, NVIDIA RTX 5060 (GB206), nvidia-open-dkms 610.57.04
  • Root: btrfs on LUKS2 (encrypt hook), snapper + limine-snapper-sync
  • Secure Boot: disabled; no TPM exposed

Why this machine was installed with archinstall

This is worth spelling out, because it is the reason the "archinstall + Omarchy on top"
path is not as exotic as it sounds.

The CPU is an i5-10400F. The F suffix means no integrated graphics, so the
motherboard's own HDMI/DP outputs are dead — the only working video path on this box is
the discrete GPU. That GPU is an RTX 5060 (GB206, Blackwell), which is new enough
that the live environment's open-source nouveau driver cannot drive it. /sys/class/drm
shows exactly one card, the NVIDIA one.

The result is no usable display in a graphical installer. The working route was to install
Arch with archinstall in text mode (choosing Limine as the bootloader, which is what
writes /EFI/Linux/arch-linux.efi and the Arch Linux (linux) entry) and then layer
Omarchy on top.

Anyone with an F-series Intel CPU plus a current-generation NVIDIA card is pushed down
this same path, so the stale-entry cleanup is likely to matter to more than one user.

I could not attach omarchy debug output: omarchy debug is listed under "Common
commands" in omarchy --help, but running it (with or without --print / --help)
returns Unknown Omarchy command, and omarchy commands --all | grep -i debug is empty
on r1816.

Full system configuration

Hardware

CPU:    Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz  (no iGPU - 'F' SKU)
GPU:    NVIDIA Corporation GB206 [GeForce RTX 5060] [10de:2d05] (rev a1)
Board:  ASUSTeK COMPUTER INC. PRIME B460M-A, BIOS 1806
RAM:    31Gi
TPM:    none exposed (Intel PTT disabled in BIOS; /sys/class/tpm empty)
SecureBoot: disabled

Software

omarchy:  4.0.0.r1816.g43bfe9b-1
channel:  edge
kernel:   7.1.9-arch1-2
  linux 7.1.9.arch1-2
  linux-headers 7.1.9.arch1-2
  linux-firmware 20260810-2
  limine 12.6.0-1
  limine-mkinitcpio-hook 1.37.1-1
  nvidia-open-dkms 610.57.04-1
  nvidia-utils 610.57.04-1
  dkms 3.4.3-2
  mkinitcpio 41.1-1
  plymouth 26.134.222-2
  snapper 0.13.1-3
  btrfs-progs 7.1-1
  sddm 0.21.0-7
  hyprland 0.56.2-1

Storage / boot layout

NAME          SIZE FSTYPE      TYPE  MOUNTPOINTS
sda         111.8G             disk  
└─sda1      111.8G ext4        part  /mnt/datos
sdb         111.8G             disk  
└─sdb1      111.8G ext4        part  /run/media/michael/sandisk
zram0        31.3G swap        disk  [SWAP]
nvme0n1     465.8G             disk  
├─nvme0n1p1     1G vfat        part  /boot
└─nvme0n1p2 464.8G crypto_LUKS part  
  └─root    464.7G btrfs       crypt /var/log
                                     /var/cache/pacman/pkg
                                     /home
                                     /

root: btrfs subvol=@ on /dev/mapper/root (LUKS2), snapper snapshots + limine-snapper-sync
ESP:  vfat, mounted at /boot (holds EFI/Linux/omarchy_linux.efi, 144 MB UKI)

mkinitcpio HOOKS (effective)

HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
HOOKS+=(resume)
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)

mkinitcpio drop-ins

nvidia.conf
omarchy_hooks.conf
omarchy_hooks.conf.pacsave
omarchy_resume.conf
thunderbolt_module.conf

/etc/limine-entry-tool.conf (non-comment)

ENABLE_VERIFICATION=yes
BOOT_ORDER="*, *fallback, Snapshots"
ENABLE_SORT=no
FIND_BOOTLOADERS=yes
ENABLE_UKI=no

/etc/limine-entry-tool.d/

/etc/limine-entry-tool.d/omarchy-defaults.conf:

TARGET_OS_NAME="Omarchy"
KERNEL_CMDLINE[default]+=" quiet splash loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0"
# Kernel 7.1 unpacks the initramfs asynchronously, which races /init: the
# early /proc, /sys, /dev, and /run mounts fail while unpacking settles, so
# plymouthd exits when it can't read /proc/cmdline and encrypted boots fall
# back to an unthemed text LUKS prompt. Unpack synchronously until the race
# is fixed upstream.
KERNEL_CMDLINE[default]+=" initramfs_async=0"
CUSTOM_UKI_NAME="omarchy"
ENABLE_LIMINE_FALLBACK=yes
# Find and add other bootloaders
FIND_BOOTLOADERS=yes
BOOT_ORDER="*, *fallback, Snapshots"
# Snapper is configured with NUMBER_LIMIT="5" (see default/snapper/root), but
# limine-snapper-sync can see the newly created sixth snapshot before cleanup
# restores the retained snapshot count to 5. Allow for that creation window:
#   Snapshot limit mismatch: 6 Snapper snapshots exceed configured
#   MAX_SNAPSHOT_ENTRIES=5
MAX_SNAPSHOT_ENTRIES=6
SNAPSHOT_FORMAT_CHOICE=5

/etc/limine-entry-tool.d/omarchy-uki.conf:

ENABLE_UKI=yes

/etc/limine-entry-tool.d/resume.conf:

KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3791609"

/etc/default/limine

KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3791609"
# Written by omarchy-upgrade-to-quattro. The += drop-ins in
# /etc/limine-entry-tool.d/ stop limine-entry-tool from reading
# /etc/kernel/cmdline and /proc/cmdline, so the parameters identifying the
# root filesystem have to be stated explicitly.
KERNEL_CMDLINE[default]+=" cryptdevice=PARTUUID=<redacted>:root root=/dev/mapper/root rootflags=subvol=@ rw rootfstype=btrfs"

/etc/sddm.conf.d/

/etc/sddm.conf.d/10-theme.conf:

[Theme]
Current=omarchy

/etc/sddm.conf.d/10-wayland.conf:

[General]
DisplayServer=wayland

[Wayland]
CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua

/etc/sddm.conf.d/99-omarchy-login.conf:

[Users]
RememberLastUser=true
RememberLastSession=true

/etc/sddm.conf.d/autologin.conf:

[Autologin]
User=michael
Session=omarchy.desktop

Filed by Claude Opus 5 via Claude Code.

View raw text
### What happened

After a routine `omarchy update` (which bumped `linux` 7.1.8.arch1-3 → 7.1.9.arch1-2 and `omarchy-dev` r1796 → r1816), the machine failed to boot into the default Limine entry:

```
PANIC: efi: Failed to open image with path 'boot():/EFI/Linux/arch-linux.efi'. Is the path correct?
Stacktrace:
  [0x7e83caef] <panic+0x15f>
  [0x7e85829e] <chainload+0x8e>
  [0x7e854e7b] <boot+0x16b>
  [0x7e853e89] <_menu+0x1fd9>
End of trace. Press a key to return to menu.
```

The system itself was fine — the working `/+Omarchy` entry booted normally. The panic came from a stale, hand-written entry that was still sitting at the **top** of `/boot/limine.conf`, i.e. the entry Limine selects when the timeout expires:

```
timeout: 5

/Arch Linux (linux)
    protocol: efi
    path: boot():/EFI/Linux/arch-linux.efi
    cmdline: cryptdevice=PARTUUID=...:root root=/dev/mapper/root zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs
/+Omarchy
### This OS entry is auto-generated by limine-entry-tool
...
  path: boot():/EFI/Linux/omarchy_linux.efi#4c516ba8...
```

`/boot/EFI/Linux/` contained only `omarchy_linux.efi`; `arch-linux.efi` no longer exists.

### Where it comes from

`/EFI/Linux/arch-linux.efi` with a menu entry titled `Arch Linux (linux)` is what **archinstall**'s Limine setup writes. It is not an Omarchy path — `grep -rn 'arch-linux.efi' /usr/share/omarchy/` returns nothing.

Because the entry carries no `### auto-generated by limine-entry-tool` marker, `limine-entry-tool` correctly leaves it alone on every regeneration, so it survives indefinitely.

### What I expected

`omarchy-upgrade-to-quattro` already owns exactly this cleanup. `normalize_limine_config()` (around lines 497-515) migrates the *other* legacy UKI naming scheme:

```bash
# Pre-quattro custom-UKI installs used <machine-id>_linux.efi. Omarchy quattro uses the
# stable omarchy_linux.efi path generated by limine-entry-tool.
legacy_uki="/boot/EFI/Linux/${machine_id}_linux.efi"
if [[ -n $machine_id ]] && as_root test -f /boot/EFI/Linux/omarchy_linux.efi && as_root test -f "$legacy_uki"; then
```

I expected the same function to also drop (or at least de-prioritise) a manual entry whose `path:` points at a UKI that no longer exists on the ESP — especially when that entry is the default one.

The `remove_legacy_limine_configs()` / `normalize_limine_config()` pair guards against this class of problem, and there is even a validation step later (~line 615-623) that checks `root=` is present in `limine.conf` and enumerates `omarchy_linux*.efi` — but nothing notices a top-of-file entry pointing at a deleted image.

### Steps to reproduce

1. Install Arch with `archinstall` using Limine as the bootloader (writes `/EFI/Linux/arch-linux.efi` and the `Arch Linux (linux)` entry).
2. Install Omarchy on top and run `omarchy-upgrade-to-quattro`, which sets `CUSTOM_UKI_NAME="omarchy"` so the UKI is generated as `omarchy_linux.efi`.
3. Let any subsequent kernel update run. The old `arch-linux.efi` is gone; the manual entry remains first in the menu.
4. Reboot and let the timeout expire instead of picking an entry.

### Suggested fix

In `normalize_limine_config()`, after the `omarchy_linux.efi` UKI is confirmed present, strip any top-level entry whose `path:` resolves to a file that is absent from the ESP — or at minimum the known `arch-linux.efi` from archinstall. Failing hard with the existing `fail`/"do not reboot" messaging would also be an improvement over a silent panic at the next boot.

### Workaround

Deleting the four stale lines from `/boot/limine.conf` fixes it; `limine-entry-tool` does not re-add them and no UKI regeneration is needed.

### System details

- `omarchy version`: `4.0.0.r1816.g43bfe9b-1` (edge channel, 4.0.0.alpha)
- Kernel: `7.1.9-arch1-2`
- `limine` 12.6.0-1, `limine-mkinitcpio-hook` 1.37.1-1
- Board: ASUSTeK PRIME B460M-A (BIOS 1806), Intel i5-10400F, NVIDIA RTX 5060 (GB206), `nvidia-open-dkms` 610.57.04
- Root: btrfs on LUKS2 (`encrypt` hook), snapper + `limine-snapper-sync`
- Secure Boot: disabled; no TPM exposed

#### Why this machine was installed with archinstall

This is worth spelling out, because it is the reason the "archinstall + Omarchy on top"
path is not as exotic as it sounds.

The CPU is an **i5-10400F**. The `F` suffix means no integrated graphics, so the
motherboard's own HDMI/DP outputs are dead — the only working video path on this box is
the discrete GPU. That GPU is an **RTX 5060 (GB206, Blackwell)**, which is new enough
that the live environment's open-source `nouveau` driver cannot drive it. `/sys/class/drm`
shows exactly one card, the NVIDIA one.

The result is no usable display in a graphical installer. The working route was to install
Arch with **archinstall** in text mode (choosing Limine as the bootloader, which is what
writes `/EFI/Linux/arch-linux.efi` and the `Arch Linux (linux)` entry) and then layer
Omarchy on top.

Anyone with an F-series Intel CPU plus a current-generation NVIDIA card is pushed down
this same path, so the stale-entry cleanup is likely to matter to more than one user.

I could not attach `omarchy debug` output: `omarchy debug` is listed under "Common
commands" in `omarchy --help`, but running it (with or without `--print` / `--help`)
returns `Unknown Omarchy command`, and `omarchy commands --all | grep -i debug` is empty
on r1816.

<details>
<summary><b>Full system configuration</b></summary>

#### Hardware
```
CPU:    Intel(R) Core(TM) i5-10400F CPU @ 2.90GHz  (no iGPU - 'F' SKU)
GPU:    NVIDIA Corporation GB206 [GeForce RTX 5060] [10de:2d05] (rev a1)
Board:  ASUSTeK COMPUTER INC. PRIME B460M-A, BIOS 1806
RAM:    31Gi
TPM:    none exposed (Intel PTT disabled in BIOS; /sys/class/tpm empty)
SecureBoot: disabled
```

#### Software
```
omarchy:  4.0.0.r1816.g43bfe9b-1
channel:  edge
kernel:   7.1.9-arch1-2
  linux 7.1.9.arch1-2
  linux-headers 7.1.9.arch1-2
  linux-firmware 20260810-2
  limine 12.6.0-1
  limine-mkinitcpio-hook 1.37.1-1
  nvidia-open-dkms 610.57.04-1
  nvidia-utils 610.57.04-1
  dkms 3.4.3-2
  mkinitcpio 41.1-1
  plymouth 26.134.222-2
  snapper 0.13.1-3
  btrfs-progs 7.1-1
  sddm 0.21.0-7
  hyprland 0.56.2-1
```

#### Storage / boot layout
```
NAME          SIZE FSTYPE      TYPE  MOUNTPOINTS
sda         111.8G             disk  
└─sda1      111.8G ext4        part  /mnt/datos
sdb         111.8G             disk  
└─sdb1      111.8G ext4        part  /run/media/michael/sandisk
zram0        31.3G swap        disk  [SWAP]
nvme0n1     465.8G             disk  
├─nvme0n1p1     1G vfat        part  /boot
└─nvme0n1p2 464.8G crypto_LUKS part  
  └─root    464.7G btrfs       crypt /var/log
                                     /var/cache/pacman/pkg
                                     /home
                                     /

root: btrfs subvol=@ on /dev/mapper/root (LUKS2), snapper snapshots + limine-snapper-sync
ESP:  vfat, mounted at /boot (holds EFI/Linux/omarchy_linux.efi, 144 MB UKI)
```

#### mkinitcpio HOOKS (effective)
```
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
HOOKS+=(resume)
HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont block encrypt filesystems fsck)
```

#### mkinitcpio drop-ins
```
nvidia.conf
omarchy_hooks.conf
omarchy_hooks.conf.pacsave
omarchy_resume.conf
thunderbolt_module.conf
```

#### /etc/limine-entry-tool.conf (non-comment)
```
ENABLE_VERIFICATION=yes
BOOT_ORDER="*, *fallback, Snapshots"
ENABLE_SORT=no
FIND_BOOTLOADERS=yes
ENABLE_UKI=no
```

#### /etc/limine-entry-tool.d/

`/etc/limine-entry-tool.d/omarchy-defaults.conf`:
```
TARGET_OS_NAME="Omarchy"
KERNEL_CMDLINE[default]+=" quiet splash loglevel=0 systemd.show_status=false rd.udev.log_level=0 vt.global_cursor_default=0"
# Kernel 7.1 unpacks the initramfs asynchronously, which races /init: the
# early /proc, /sys, /dev, and /run mounts fail while unpacking settles, so
# plymouthd exits when it can't read /proc/cmdline and encrypted boots fall
# back to an unthemed text LUKS prompt. Unpack synchronously until the race
# is fixed upstream.
KERNEL_CMDLINE[default]+=" initramfs_async=0"
CUSTOM_UKI_NAME="omarchy"
ENABLE_LIMINE_FALLBACK=yes
# Find and add other bootloaders
FIND_BOOTLOADERS=yes
BOOT_ORDER="*, *fallback, Snapshots"
# Snapper is configured with NUMBER_LIMIT="5" (see default/snapper/root), but
# limine-snapper-sync can see the newly created sixth snapshot before cleanup
# restores the retained snapshot count to 5. Allow for that creation window:
#   Snapshot limit mismatch: 6 Snapper snapshots exceed configured
#   MAX_SNAPSHOT_ENTRIES=5
MAX_SNAPSHOT_ENTRIES=6
SNAPSHOT_FORMAT_CHOICE=5
```

`/etc/limine-entry-tool.d/omarchy-uki.conf`:
```
ENABLE_UKI=yes
```

`/etc/limine-entry-tool.d/resume.conf`:
```
KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3791609"
```

#### /etc/default/limine
```
KERNEL_CMDLINE[default]+=" resume=/dev/mapper/root resume_offset=3791609"
# Written by omarchy-upgrade-to-quattro. The += drop-ins in
# /etc/limine-entry-tool.d/ stop limine-entry-tool from reading
# /etc/kernel/cmdline and /proc/cmdline, so the parameters identifying the
# root filesystem have to be stated explicitly.
KERNEL_CMDLINE[default]+=" cryptdevice=PARTUUID=<redacted>:root root=/dev/mapper/root rootflags=subvol=@ rw rootfstype=btrfs"
```

#### /etc/sddm.conf.d/

`/etc/sddm.conf.d/10-theme.conf`:
```
[Theme]
Current=omarchy
```

`/etc/sddm.conf.d/10-wayland.conf`:
```
[General]
DisplayServer=wayland

[Wayland]
CompositorCommand=start-hyprland -- --config /usr/share/sddm/hyprland.lua
```

`/etc/sddm.conf.d/99-omarchy-login.conf`:
```
[Users]
RememberLastUser=true
RememberLastSession=true
```

`/etc/sddm.conf.d/autologin.conf`:
```
[Autologin]
User=michael
Session=omarchy.desktop
```

</details>

---

Filed by Claude Opus 5 via Claude Code.

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.

No decision has been recorded yet.