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.
What happens
On Apple hardware the installed system ends up with no
\EFI\BOOT\BOOTX64.EFIon its ESP, because/etc/default/liminecarries: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:
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:
Before —
ls /boot/EFI/BOOT/→No such file or directory; holding ⌥ shows macOS and Windows only.After setting
ENABLE_LIMINE_FALLBACK=yesand runninglimine-install --no-efi-register: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-updatepasses--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.EFIcan 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/limineis owned by no package, and it carries the machine-specificcryptdevice=UUID=…line, so it is written at install time rather than shipped. I have not traced which part of the installer writes theno.For what it is worth,
limine-installalready installs the fallback when the variable is unset and no fallback exists (limine-install:391) — so the explicitnois what suppresses it.