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.
Fresh Quattro install: Limine UKI chainload panics with efi: LoadImage failure (EFI_INVALID_PARAMETER) on older UEFI
Reported by keylimesoda · filed Sep 16, 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
Lenovo ThinkPad Yoga 11e (20D9-0027US), Intel Celeron N2940 (Bay Trail), 4 GB RAM, Lenovo UEFI, Secure Boot disabled, standard Omarchy LUKS2 + Btrfs installation, current Quattro installer
What's wrong?
What’s wrong?
After successfully installing Omarchy, the fresh installation cannot boot on this machine. Limine starts, attempts to load the generated EFI/UKI image, and hard-panics:
PANIC: efi: LoadImage failure (0x8000000000000002)
Stacktrace: <panic+...> <chainload+...> <boot+...> <_menu+...>
End of trace. System halted.0x8000000000000002 corresponds to EFI_INVALID_PARAMETER. The Linux kernel never starts.
The installer itself also cannot boot through the normal Omarchy EFI path on this machine:
grub_arch_efi_linux_boot_image:227: cannot load image
However, the installer boots correctly via Ventoy GRUB2 mode. This suggests a firmware compatibility problem with the EFI LoadImage path being used both by the ISO and by the installed UKI configuration.
Diagnosis / workaround
Using the installer ISO as a rescue system, I opened the installed system and found:
/etc/limine-entry-tool.conf:ENABLE_UKI=no/etc/limine-entry-tool.d/omarchy-uki.conf:ENABLE_UKI=yes
The Omarchy drop-in therefore enables UKI generation. I added this local override:
/etc/default/limine:
ENABLE_UKI=no
Then I ran arch-chroot /mnt limine-mkinitcpio. The resulting Limine entry changed from EFI/UKI loading to native Linux loading:
protocol: linux
path: boot():/.../linux/vmlinuz...
module_path: boot():/.../linux/initramfs...The kernel and initramfs regenerated successfully. This bypasses the firmware EFI LoadImage/UKI path entirely. I have not yet confirmed a complete reboot into the installed system, so this report does not claim an end-to-end boot fix—only that the native-Linux entry was generated successfully.
Expected behavior
It would be useful if Omarchy retained a native-Linux Limine fallback entry even when UKI is enabled, for example:
- Omarchy (normal UKI entry)
- Omarchy (UEFI compatibility):
protocol: linux, using the vmlinuz and initramfs paths
Alternatively, the installer could expose an older-UEFI compatibility option to disable UKI.
Why this matters
The affected hardware is capable of running Omarchy: the installer completes normally, the kernel/initramfs builds normally, and the failure appears confined to the modern EFI/UKI boot path. This may affect a broader class of inexpensive retired education/business laptops with older UEFI implementations.
Related
The installer failure is reported separately in omacom/omarchy-iso. Related older-hardware reports include #1641 and UKI/Limine booting discussions such as #7989.
View raw text
### System details Lenovo ThinkPad Yoga 11e (20D9-0027US), Intel Celeron N2940 (Bay Trail), 4 GB RAM, Lenovo UEFI, Secure Boot disabled, standard Omarchy LUKS2 + Btrfs installation, current Quattro installer ### What's wrong? ### What’s wrong? After successfully installing Omarchy, the fresh installation cannot boot on this machine. Limine starts, attempts to load the generated EFI/UKI image, and hard-panics: ``` PANIC: efi: LoadImage failure (0x8000000000000002) Stacktrace: <panic+...> <chainload+...> <boot+...> <_menu+...> End of trace. System halted. ``` `0x8000000000000002` corresponds to `EFI_INVALID_PARAMETER`. The Linux kernel never starts. The installer itself also cannot boot through the normal Omarchy EFI path on this machine: `grub_arch_efi_linux_boot_image:227: cannot load image` However, the installer boots correctly via Ventoy GRUB2 mode. This suggests a firmware compatibility problem with the EFI LoadImage path being used both by the ISO and by the installed UKI configuration. ### Diagnosis / workaround Using the installer ISO as a rescue system, I opened the installed system and found: - `/etc/limine-entry-tool.conf`: `ENABLE_UKI=no` - `/etc/limine-entry-tool.d/omarchy-uki.conf`: `ENABLE_UKI=yes` The Omarchy drop-in therefore enables UKI generation. I added this local override: `/etc/default/limine`: `ENABLE_UKI=no` Then I ran `arch-chroot /mnt limine-mkinitcpio`. The resulting Limine entry changed from EFI/UKI loading to native Linux loading: ``` protocol: linux path: boot():/.../linux/vmlinuz... module_path: boot():/.../linux/initramfs... ``` The kernel and initramfs regenerated successfully. This bypasses the firmware EFI LoadImage/UKI path entirely. I have not yet confirmed a complete reboot into the installed system, so this report does not claim an end-to-end boot fix—only that the native-Linux entry was generated successfully. ### Expected behavior It would be useful if Omarchy retained a native-Linux Limine fallback entry even when UKI is enabled, for example: - Omarchy (normal UKI entry) - Omarchy (UEFI compatibility): `protocol: linux`, using the vmlinuz and initramfs paths Alternatively, the installer could expose an older-UEFI compatibility option to disable UKI. ### Why this matters The affected hardware is capable of running Omarchy: the installer completes normally, the kernel/initramfs builds normally, and the failure appears confined to the modern EFI/UKI boot path. This may affect a broader class of inexpensive retired education/business laptops with older UEFI implementations. ### Related The installer failure is reported separately in omacom/omarchy-iso. Related older-hardware reports include #1641 and UKI/Limine booting discussions such as #7989.
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 14:20 UTC