## Summary

The AVX2 requirement in `limine-entry-tool` is already fixed: `limine-mkinitcpio-hook` 1.38.0-1.1 is built at `x86-64-baseline` and runs fine on an old CPU.

The problem is that a user on a **pre-fix version cannot safely reach that fix**. The update that delivers it is the same pacman transaction that needs the broken binary to rebuild the UKI. The machine can be left unbootable on the way.

## Hardware

Intel Celeron N4000 (Goldmont Plus). Maximum ISA level `x86-64-v2`, no AVX2.

## What happens

Starting from `limine-mkinitcpio-hook 1.29.0-1` (Feb 2026):

1. `pacman -Syu` installs a new kernel. New modules land in `/usr/lib/modules/<new>`.
2. The `90-mkinitcpio-install.hook` runs `limine-mkinitcpio`, which calls `/usr/lib/limine/limine-entry-tool`.
3. That binary refuses to start:

```
The current machine does not support all of the following CPU features that are
required by the image: [CX8, CMOV, FXSR, MMX, SSE, SSE2, SSE3, SSSE3, SSE4_1,
SSE4_2, POPCNT, LZCNT, AVX, AVX2, BMI1, BMI2, FMA, F16C].
Please rebuild the executable with an appropriate setting of the -march option.
ERROR: failed to get kernel cmdline for 'linux'.
```

4. **The UKI is never rebuilt.** A `PostTransaction` hook failing does not abort pacman.
5. Pacman removes the old kernel's modules.
6. On reboot the old UKI starts a kernel whose modules no longer exist.

The user has no warning. The hook error scrolls past among hundreds of other lines.

## Why the fix is hard to reach

To update you need a working UKI rebuild. To get a working UKI rebuild you need the updated package. To get the updated package you have to run the update.

## Evidence

Before (1.29.0-1): the error above.

After (1.38.0-1.1):

```
$ readelf -n /usr/lib/limine/limine-entry-tool | grep ISA
    x86 ISA needed: x86-64-baseline

$ /usr/lib/limine/limine-entry-tool --version
1.38.0
```

Same for `limine-snapper-sync` 1.31.0-1.1. Both work correctly now, including `snapper-cleanup.service`, which had been failing daily.

## Suggested fix

Any one of these would be enough:

1. **A pre-update check.** Before `omarchy-update-system-pkgs`, if `limine-entry-tool` cannot execute, stop and tell the user, rather than updating into an unbootable state.
2. **A migration that rebuilds the UKI with plain `mkinitcpio`** when the Java tooling cannot run.
3. **A release note** for users on older CPUs, telling them to update `limine-mkinitcpio-hook` and `limine-snapper-sync` on their own first, then run the full update.

Option 1 seems smallest. Something like:

```bash
if ! /usr/lib/limine/limine-entry-tool --version >/dev/null 2>&1; then
  echo "limine-entry-tool cannot run on this CPU."
  echo "Update limine-mkinitcpio-hook and limine-snapper-sync first:"
  echo "  sudo pacman -S limine-mkinitcpio-hook limine-snapper-sync"
  exit 1
fi
```

## Also worth considering

`kernel-modules-hook` is added by migration `1768236764.sh`, but only for users who reach that migration. Users updating from before it are exposed to exactly this failure. Installing it earlier, or as a hard dependency, would make any UKI rebuild failure recoverable instead of fatal, because the old kernel's modules would still be on disk.

## Environment

- Omarchy 3.8.5 (was on a Feb 2026 build when this happened)
- `limine-mkinitcpio-hook` 1.29.0-1 -> 1.38.0-1.1
- `limine-snapper-sync` 1.22.0-1 -> 1.31.0-1.1
- Kernel 6.18.7 -> 7.2.3
- Btrfs root with LUKS, subvolumes `@`, `@home`, `@pkg`, `@log`