### What happens

`omarchy update` fails at migration `1789325478` ("Install the Omarchy kernel and make it the first Limine boot entry") with:

```
The Omarchy kernel has no Limine boot entry; rerun omarchy-migrate after fixing the boot image build.
```

Because `omarchy-migrate` runs under `set -e`, the failure stops the migration loop, so **every migration after it never runs** (29 pending on my machine) and every subsequent `omarchy update` fails at the same place.

### Why it cannot succeed

The migration installs the kernel and then verifies its own work:

```bash
kernel="linux-omarchy"
omarchy-pkg-add "$kernel" "$kernel-headers"
...
if ! sudo limine-entry-tool --tree | grep -E "(^|[^[:alnum:]_-])$kernel([^[:alnum:]_-]|$)" >/dev/null; then
```

Two facts make that check unsatisfiable on a current system:

1. `linux-omarchy` is an **empty meta package** — it ships no kernel of its own:

   ```
   $ pacman -Ql linux-omarchy
   (no output)
   $ pacman -Qi linux-omarchy | head -3
   Name            : linux-omarchy
   Version         : 7.2.8-5
   Description     : ... (meta package for linux-omarchy-bore)
   ```

2. The kernel it pulls in is `linux-omarchy-bore`, and that is the name Limine gets. The regex's trailing `([^[:alnum:]_-]|$)` explicitly excludes `-`, so `linux-omarchy-bore` does **not** match `linux-omarchy`:

   ```
   $ sudo limine-entry-tool --tree
   Omarchy
   ├─ linux-omarchy-bore
   ├─ linux
   └─ Snapshots
      ├─ 9 │ 2026-10-10 11:23:21
      ...
   EFI fallback
   ```

So the migration installs `linux-omarchy-bore`, then rejects it. The kernel, its UKI and its boot entry are all fine — only the verification is wrong.

Note the migration is self-inflicting here: `omarchy-pkg-add linux-omarchy` is what installed the bore packages in the first place (`/var/log/pacman.log`, same run):

```
[2026-10-10T10:55:54-0400] [ALPM] installed linux-omarchy-bore (7.2.8-5)
[2026-10-10T10:55:54-0400] [ALPM] installed linux-omarchy (7.2.8-5)
```

### The migration's actual goal is already met

Everything the migration sets out to do is in place when the check rejects it:

- `linux-omarchy` + `linux-omarchy-headers` installed
- `/etc/default/limine` contains `BOOT_ORDER="linux-omarchy, linux-omarchy-*, *, *fallback, Snapshots"`
- `linux-omarchy-bore` is **first** in the Limine tree, ahead of `linux`
- `/boot/EFI/Linux/omarchy_linux-omarchy-bore.efi` exists (286 MB, built by the migration's own `limine-mkinitcpio` call)

The `BOOT_ORDER` line the migration writes itself already anticipates variants with `linux-omarchy-*`; only the verification regex does not.

### Suggested fix

Let the check accept the variant its own BOOT_ORDER lists — an optional `-<suffix>`:

```bash
if ! sudo limine-entry-tool --tree | grep -E "(^|[^[:alnum:]_-])$kernel(-[[:alnum:]_-]+)?([^[:alnum:]_-]|$)" >/dev/null; then
```

That still fails when no Omarchy kernel entry exists at all, which is the condition the check is there to catch.

### Who hits this

Anyone whose first run of this migration happens now, after `linux-omarchy` became a meta package — a fresh install, or a machine that skipped updates across the rename (mine sat untouched for two weeks). Machines that completed the migration before the rename have the marker and never re-run it, which is probably why this has stayed quiet.

### Workaround

After confirming the four effects above are in place, write the completion marker by hand so the remaining migrations can run:

```bash
sudo install -Dm644 /dev/null /var/lib/omarchy/migrations/1789325478
omarchy update
```

Patching `/usr/share/omarchy/migrations/1789325478.sh` locally is not a workaround: updates run `pacman -Syu --overwrite /usr/share/omarchy/*`, which reverts it.

### Environment

- `omarchy-dev` / `omarchy-settings-dev` `4.0.0.r6863.ga15636b-1` (quattro)
- `linux-omarchy` / `linux-omarchy-bore` `7.2.8-5`
- Limine with UKI + `limine-entry-tool`, encrypted root, Lenovo ThinkStation P920
- `migrations/1789325478.sh` is byte-identical to `quattro` tip (`14ba7d98`), so this is not a stale local copy