# Apple Silicon: the Limine migration can never complete on a standard Asahi install (ESP is `/boot`, not `/boot/efi`)

## Summary

Migration `1790055026` ("Limine boot on Apple Silicon") calls
`install/hardware/apple/limine-boot.sh`, which looks for the EFI system partition at
**`/boot/efi`**. The Asahi installer mounts the ESP at **`/boot`**. On a stock Asahi
install the check therefore always fails, the leaf declines, and the migration is never
marked complete — so it re-runs and re-fails on **every** `omarchy-update`, forever.

The decline itself is safe and well written (it returns 0, restores state, and leaves GRUB
booting). The bug is that the default path is wrong for the only hardware this migration
targets, so the feature can never ship to it.

## Environment

- M1 MacBook, Omarchy on Asahi (Arch Linux ARM), LUKS2 root + btrfs, busybox mkinitcpio
- `omarchy-dev 4.0.4.r7069.g59ee15f-1`, `limine 12.9.0-1`,
  `limine-mkinitcpio-hook 1.36.0-3`, `limine-snapper-sync 1.30.1-1`,
  `uboot-asahi 2026.07.asahi2-1`
- Partition layout as created by the Asahi installer:

```
$ lsblk -o NAME,SIZE,FSTYPE,PARTTYPENAME,MOUNTPOINT
├─nvme0n1p4   500M vfat        EFI System             /boot

$ findmnt -no TARGET,SOURCE,FSTYPE /boot
/boot /dev/nvme0n1p4 vfat

$ findmnt /boot/efi
(nothing — the path does not exist)
```

## The check

`install/hardware/apple/limine-boot.sh`:

```bash
esp=${OMARCHY_ESP:-/boot/efi}                 # line 22
...
findmnt -no TARGET "$esp" >/dev/null 2>&1 || {
  echo "The ESP is not mounted at $esp; leaving GRUB in place" >&2
  return 0
}                                             # line 40
```

## Observed

```
Running migration (1790055026)
Limine boot on Apple Silicon
warning: limine-12.9.0-1 is up to date -- skipping
warning: limine-mkinitcpio-hook-1.36.0-3 is up to date -- skipping
warning: limine-snapper-sync-1.30.1-1 is up to date -- skipping
warning: uboot-asahi-2026.07.asahi2-1 is up to date -- skipping
 there is nothing to do
The ESP is not mounted at /boot/efi; leaving GRUB in place
Limine was not activated; the Limine migration will retry later.
```

The migration is not recorded in `~/.local/state/omarchy/migrations`, so it runs again next
update with the same result.

## Suggested fix

Derive the ESP rather than hardcoding a path that Asahi does not use. Something like:

```bash
esp=${OMARCHY_ESP:-$(findmnt -no TARGET --source "$(lsblk -no PATH,PARTTYPENAME \
  | awk '$2 == "EFI" { print $1; exit }')" 2>/dev/null || echo /boot/efi)}
```

or, more simply, accept `/boot` when it is a vfat ESP mount:

```bash
if [[ -z ${OMARCHY_ESP:-} ]]; then
  for candidate in /boot/efi /boot; do
    [[ $(findmnt -no FSTYPE "$candidate" 2>/dev/null) == vfat ]] && { esp=$candidate; break; }
  done
fi
```

`OMARCHY_ESP` already exists as an override, so the machinery is there — only the default is
wrong for Apple Silicon.

## Please also check before this ships

When the ESP path is fixed and this migration *does* activate Limine, the snapshot entries
matter. On this machine `/boot/limine.conf` contained sub-entries whose cmdline had **two**
`rootflags=`:

```
rootflags=subvol=/@/.snapshots/27/snapshot ... rootflags=x-systemd.device-timeout=0
```

The Apple Silicon image boots a busybox mkinitcpio initramfs whose parser keeps only the
**last** `rootflags=`, so `subvol=` is lost and the snapshot will not boot — the rescue path
fails exactly when it is needed. That duplicate token comes from
`install/hardware/apple/grub-console.sh`, the same root cause as the earlier GRUB report.
Pinning `KERNEL_CMDLINE[default]` in `/etc/limine-entry-tool.conf` fixes the main entry, but
entries generated from the running GRUB cmdline inherit the duplicate.

## Impact

Low severity, but permanent: Apple Silicon users never receive the Limine boot work, and
every update prints a failure they cannot act on. Two of the three migrations currently
pending on this machine are `x86_64`-only no-ops and the third is this one, so Apple Silicon
is effectively not being exercised by migration testing.