### System details

Omarchy 4.0.3-1 (kernel 7.2.3-arch1-3), MSI MAG X870E TOMAHAWK WIFI, AMD Ryzen 9 9900X3D, RTX 2080 Ti, AMI Aptio firmware (tested on BIOS 7E59v2AC0-era and current 7E59v2AC4, same result on both)

### What's wrong?

**Context**

Omarchy's own docs recommend disabling Secure Boot, and that's the default I installed with. I only enabled it afterward because I dual-boot Windows on this machine and some games (e.g. those using Riot/Ricochet-style anti-cheat) refuse to launch without it — so Secure Boot has to stay on for Windows regardless of what Omarchy itself needs. I'd guess this isn't a rare setup among dual-booters, so it seemed worth documenting rather than just working around quietly.

**Summary**

On this board's firmware, Omarchy's default UKI-based boot entry (`protocol: efi`, chainloading `/EFI/Linux/<machine-id>_linux.efi`) causes a hard boot panic when Secure Boot is enabled — even after correctly signing the UKI and Limine binary with `sbctl`. Switching the kernel entry from UKI to Limine's native `protocol: linux` (plain `vmlinuz` + `initramfs`, no `LoadImage()` chainload) resolves it completely, no other changes required.

**Steps to reproduce**

1. Fresh Omarchy install with Secure Boot enrolled via `sbctl` (custom keys + `--microsoft`, following the community dual-boot guide).
2. Reboot with Secure Boot enabled in firmware.
3. From Omarchy's own Limine menu (not a cross-disk chainload — just the normal `linux` entry), select the kernel to boot.

**Expected behavior**

Kernel boots normally, same as it does with Secure Boot disabled.

**Actual behavior**

Immediate panic:
```
PANIC: efi: LoadImage failure (0x800000000000000f)
Stacktrace:
    [0x6a2b8c2f] <panic+0x15f>
    [0x6a2d534c] <chainload+0x38c>
    [0x6a2d160b] <boot+0x16b>
    [0x6a2cf028] <_menu+0xe18>
End of trace. System halted.
```
`0x800000000000000f` is `EFI_ACCESS_DENIED`.

**What I found causes it**

This board apparently can't reliably `LoadImage()` any non-factory-signed `.efi` binary — separately from that, its `db`/`KEK` Secure Boot variable writes also silently no-op even in Setup Mode (confirmed with both `sbctl` and `efi-updatevar` independently, across two BIOS versions). Limine's `protocol: efi` path (used for Omarchy's UKI kernel entries) goes through `LoadImage()` and hits this. Limine's `protocol: linux` path doesn't — Limine parses and loads the kernel/initramfs itself, bypassing the broken firmware call entirely.

I confirmed this is UKI-specific, not a general "this board can't do Secure Boot" problem: I have a second CachyOS install on the same physical firmware, using `protocol: linux` (standard mkinitcpio preset, not UKI), and it boots completely cleanly under Secure Boot on this same board — no panic.

**Scope**

This likely isn't limited to my specific board. The underlying firmware bug is already tracked by sbctl as [FQ0001](https://github.com/Foxboron/sbctl/wiki/FQ0001) ("defaults to executing on Secure Boot policy violation"), which lists every MSI 600-series motherboard and newer as affected, plus a long list of earlier boards that picked it up via a firmware update — so this is a whole board family, not a one-off. Anyone on affected MSI hardware enabling Secure Boot on Omarchy would likely hit this same panic.

I followed [this community dual-boot/Secure Boot guide](https://github.com/omacom/omarchy/discussions/2296), which is the most discoverable reference for this setup and is referenced/linked from multiple other threads — it doesn't mention `ENABLE_UKI` or this failure mode at all, so it'd be a good place for a note alongside (or instead of) the official docs.

**Workaround**

Omarchy ships a drop-in forcing UKI mode at `/etc/limine-entry-tool.d/omarchy-uki.conf` (`ENABLE_UKI=yes`), overriding upstream `limine-entry-tool`'s own default of `ENABLE_UKI=no`. Setting it back to `no` and rebuilding fixes it:
```bash
sudo sed -i 's/ENABLE_UKI=yes/ENABLE_UKI=no/' /etc/limine-entry-tool.d/omarchy-uki.conf
echo "linux" | sudo /usr/share/libalpm/scripts/limine-mkinitcpio-install
```
This regenerates the kernel entry as `protocol: linux` and it boots cleanly under Secure Boot from then on.

One gap: `limine-snapper-sync` only picks up the new format for snapshots taken *after* the config change — snapshots from before still point at the old UKI in `limine_history` and would panic the same way if selected from the Snapshots submenu.

**Suggestion**

Even a short mention in the Secure Boot / dual-boot docs that `ENABLE_UKI` exists and is overridable would save others a lot of debugging if they hit this same `LoadImage` panic on similar firmware. Happy to provide full `sbctl status` / `efi-readvar` logs across both BIOS versions if useful.