## What happens

On Apple hardware the installed system ends up with no `\EFI\BOOT\BOOTX64.EFI` on its ESP, because `/etc/default/limine` carries:

```
ENABLE_LIMINE_FALLBACK=no
```

Apple's firmware boot picker (hold ⌥ at power-on) only lists volumes that have that path. With it absent, Omarchy is invisible there — macOS and Windows show up, Omarchy does not. Booting still works day to day, because the installer also registers an NVRAM entry and puts it first:

```
BootCurrent: 0000
BootOrder: 0000,0080,0002
Boot0000* Limine  HD(4,GPT,...)/\EFI\limine\limine_x64.efi
Boot0002* Windows Boot Manager
Boot0080* Mac OS X
```

## Why it matters on Macs specifically

That NVRAM entry is the only way in, and Mac NVRAM is routinely cleared: a PRAM reset wipes it, macOS updates re-bless themselves as the default, and a fully drained battery can lose it. After any of those there is no Omarchy entry in NVRAM *and* no icon in the boot picker — recovery needs a live USB or blessing the loader from macOS.

This is a recovery hazard rather than a day-one failure, which is probably why it has not come up.

## Before / after on a MacBookPro14,3

Omarchy 4.0.3-1, limine 12.8.0-1, kernel 7.2.3-arch1-3, Apple EFI 529.140.2.0.0, dual-booting macOS and Boot Camp Windows:

```
nvme0n1p1  300M  vfat  EFI          <- Apple ESP (EFI/APPLE, EFI/Microsoft/Boot)
nvme0n1p2  93G   apfs               <- macOS
nvme0n1p3  94G   ntfs  BOOTCAMP     <- Windows
nvme0n1p4  2G    vfat  OMARCHY_EFI  <- Omarchy's own ESP, mounted /boot
nvme0n1p5  276G  LUKS               <- Omarchy root
```

Before — `ls /boot/EFI/BOOT/` → `No such file or directory`; holding ⌥ shows macOS and Windows only.

After setting `ENABLE_LIMINE_FALLBACK=yes` and running `limine-install --no-efi-register`:

```
/boot/EFI/BOOT/BOOTX64.EFI   372736 bytes
md5 BOOTX64.EFI       18c7ec40ea1a5c0f070a537d6b40a0df
md5 limine_x64.efi    18c7ec40ea1a5c0f070a537d6b40a0df
```

Holding ⌥ now shows a third volume, and selecting it boots into the Limine menu. `limine.conf`, the UKI and the NVRAM entries were all byte-identical before and after — `limine-update` passes `--no-efi-register`, so nothing touches the firmware variables.

## Why the current default is right elsewhere

I am not suggesting flipping it globally. On a PC sharing one ESP between systems, writing `\EFI\BOOT\BOOTX64.EFI` can overwrite another OS's fallback loader — close to the complaint in #7867. The default is defensible there.

Macs are the case where it is both safe and needed: the installer gives Omarchy its own ESP, so the fallback path on that partition belongs to nobody else, and Apple's picker is the only boot UI most users will ever see.

A gate on Apple DMI would cover it, in the same place the other `install/hardware/apple/` fixes live.

## Notes

`/etc/default/limine` is owned by no package, and it carries the machine-specific `cryptdevice=UUID=…` line, so it is written at install time rather than shipped. I have not traced which part of the installer writes the `no`.

For what it is worth, `limine-install` already installs the fallback when the variable is *unset* and no fallback exists (`limine-install:391`) — so the explicit `no` is what suppresses it.