## Summary

On a dual-NVMe system with one ESP per drive, the installer omitted the direct
Omarchy UKI firmware entry. The first boot therefore went through Limine and
halted, while manually creating the missing UKI entry made Omarchy boot normally.

## System details

- Omarchy installer media: `OMARCHY_202608`
- Installed system version: `4.0.1-1`
- Laptop: ASUS ProArt, UEFI firmware
- CPU: AMD Ryzen 9 5900HX with Radeon Graphics
- GPUs: NVIDIA GeForce RTX 3060 Mobile / Max-Q and AMD Cezanne Radeon Vega
- Linux SSD: Samsung 990 PRO 2 TB (`/dev/nvme0n1`)
  - Previously contained CachyOS; Omarchy was installed over that Linux installation
  - `/dev/nvme0n1p1`: 2 GiB VFAT EFI System Partition, filesystem UUID `1066-6D86`
  - `/dev/nvme0n1p2`: approximately 1.8 TiB LUKS-encrypted system partition
- Windows SSD: separate 1 TB Samsung NVMe (`/dev/nvme1n1`), with its own 200 MiB ESP and Windows partitions

## Bug description

After installing Omarchy to the dedicated Linux SSD, the first boot failed in
Limine. Windows, installed on a separate SSD with a separate ESP, continued to
boot normally.

The firmware contained Limine and fallback `UEFI OS` entries for the Linux ESP,
but the installer did not create a direct Omarchy entry for the generated UKI
at `\EFI\Linux\omarchy_linux.efi`.

## Error shown at boot

```text
WARNING: Could not meaningfully match the boot device handle with a volume.
Using the first volume containing a Limine configuration!
THIS IS A BUG! Please report this issue upstream.
Press any key to continue...
PANIC: No volume contained a Limine configuration file
Stacktrace:
[0xb6134aef] <panic+0x15f>
[0xb6128675] <uefi_entry+0x3e5>
End of trace. System halted.
```

## Steps to reproduce

1. Use an ASUS ProArt UEFI laptop with two NVMe drives, each containing its own ESP.
2. Keep Windows on one NVMe drive.
3. Install Omarchy from `OMARCHY_202608` over the existing CachyOS installation on the other NVMe drive, using a 2 GiB ESP and a LUKS-encrypted system partition.
4. Allow the installer to finish successfully and reboot.
5. Boot the installer-created `Limine` entry.

## Expected behavior

The installer creates a direct `Omarchy` UEFI entry for
`\EFI\Linux\omarchy_linux.efi`, places it in the boot order, and the first boot
succeeds. Limine remains available as a recovery/snapshot boot path.

## Actual behavior

Only the following entries were created or available after installation:

```text
Boot0001 Limine  -> Linux ESP, \EFI\LIMINE\LIMINE_X64.EFI
Boot0002 UEFI OS -> Linux ESP, \EFI\BOOT\BOOTX64.EFI
Boot0000 Windows Boot Manager -> Windows ESP
```

There was no direct Omarchy entry pointing to
`\EFI\Linux\omarchy_linux.efi`. Booting through Limine produced the panic above.

## ESP contents verified from the live environment

I booted the installation USB and mounted the Linux ESP read-only. The expected
files were present:

```text
/limine.conf
/limine.conf.old
/EFI/limine/limine_x64.efi
/EFI/limine/limine_x64.bak
/EFI/BOOT/BOOTX64.EFI
/EFI/Linux/omarchy_linux.efi
/amd-ucode.img
```

Therefore, the message that no volume contained a Limine configuration does not
match the on-disk state: `/limine.conf` existed at the root of the same ESP as
the Limine EFI executable.

## Workaround

From the live environment, I manually created the missing direct UKI entry:

```bash
efibootmgr -c -d /dev/nvme0n1 -p 1 -L Omarchy -l '\EFI\Linux\omarchy_linux.efi'
```

This created `Boot0005 Omarchy` and placed it first in the boot order. The
system then booted successfully. The running system currently confirms:

```text
BootCurrent: 0005
BootOrder: 0005,0001,0000,0002
Boot0005 Omarchy -> Linux ESP, \EFI\LINUX\OMARCHY_LINUX.EFI
```

## Partition identifiers

```text
Linux ESP GPT partition GUID:   f7e9faa8-b6b1-472f-af89-ae3ef239eb8d
Windows ESP GPT partition GUID: 71e81db6-d762-4676-b503-f82d75c08bf2
```

## Possible causes / suggested installer checks

These are hypotheses based on the observed behavior:

1. Limine may be unable to associate its UEFI boot-device handle with the Linux
   ESP when two NVMe drives each contain an ESP.
2. The installation path may have failed to create or verify the intended
   direct Omarchy/UKI firmware entry.
3. Before reporting success, the installer could verify that the direct UKI
   entry exists and targets the correct ESP. If Limine is also expected to boot,
   it could verify that Limine can locate `/limine.conf` on that ESP.

I can provide the Omarchy diagnostic output, additional firmware information,
or Limine debug output if useful.