## Summary

`omarchy-settings` ships `/etc/mkinitcpio.conf.d/omarchy_hooks.conf`, whose first statement is a **plain reassignment** of the whole array:

```bash
HOOKS=(base udev plymouth keyboard autodetect microcode modconf kms keymap consolefont block encrypt filesystems fsck btrfs-overlayfs)
```

Because mkinitcpio concatenates `/etc/mkinitcpio.conf` with `conf.d/*.conf` and sources the result, the drop-in does not extend the user's HOOKS — it **replaces** them. Any hook the machine needs that is not in Omarchy's list is silently discarded.

On this machine that dropped `lvm2` and `resume`. Root is LVM-on-LUKS (`/dev/mapper/ArchinstallVg-root`, an LV inside the `cryptlvm` container), so the resulting UKI unlocks LUKS and then never activates the volume group. The root device never appears and the boot dies — invisibly, behind the Plymouth splash, with no reachable TTY.

`lvm2` had been in `/etc/mkinitcpio.conf` since the machine was installed:

```
2025-09-13  HOOKS=(base udev autodetect microcode modconf kms keyboard keymap consolefont encrypt lvm2 block filesystems fsck)
2026-07-20  HOOKS=(base udev plymouth autodetect microcode modconf kms keyboard keymap consolefont encrypt lvm2 btrfs block filesystems fsck)
current     HOOKS=(base udev plymouth autodetect microcode modconf kms keyboard keymap consolefont encrypt lvm2 resume btrfs block filesystems fsck)
```

## Impact

Any root layout that needs a hook outside Omarchy's fixed list becomes unbootable after the update — LVM (`lvm2`), mdraid (`mdadm_udev`), and hibernation (`resume`) are the obvious ones. The failure is silent: `quiet splash loglevel=0 systemd.show_status=false` hides it, so the user sees a hang with no way into a console.

This is the initramfs half of a problem the cmdline half of which is already handled. #6579 goes to real trouble to preserve `cryptdevice=`, `rd.lvm.*`, `dm-mod.create` and friends, and detects the crypt layer with `lsblk -nso TYPE` across parents. So the kernel command line arrives correct and complete — and then the initramfs has no `lvm2` hook to act on it.

## Evidence

The generated UKI is missing every LVM component:

```console
$ objcopy -O binary --only-section=.initrd /boot/EFI/Linux/omarchy_linux.efi /tmp/uki-initrd.img
$ lsinitcpio -l /tmp/uki-initrd.img | grep -E "^hooks/"
hooks/
hooks/btrfs-overlayfs
hooks/encrypt
hooks/keymap
hooks/plymouth
hooks/udev

$ lsinitcpio -l /tmp/uki-initrd.img | grep -iE "bin/lvm|dm-lvm"
(nothing)
```

Against the pre-update image still sitting in `/boot`, built from the unoverridden config:

```console
$ lsinitcpio -l /boot/initramfs-linux.img | grep -iE "bin/lvm|dm-lvm"
usr/bin/lvm
usr/lib/udev/rules.d/11-dm-lvm.rules
usr/lib/udev/rules.d/69-dm-lvm.rules
```

## Why this is easy to miss

GRUB kept booting the machine, which masked the breakage. `/etc/pacman.d/hooks/90-mkinitcpio-install.hook` (from `limine-mkinitcpio-hook`) overrides the stock pacman hook and, with `ENABLE_UKI=yes`, runs `limine-mkinitcpio-install`, which builds **only UKIs**. `/boot/initramfs-linux*.img` are therefore no longer regenerated by anything. GRUB was booting a stale image built before the update — with the correct hooks still in it.

That may well be intended for a UKI-only setup, but the side effect is worth noting on its own: the standalone images and their bootloader entries stay in `/boot` looking bootable while quietly going stale, and they will break on the next kernel bump. (Adjacent to #6188, though a different cause.)

## Steps to reproduce

1. Install on a root that needs a hook outside Omarchy's list — LVM-on-LUKS is the easy case.
2. Confirm `/etc/mkinitcpio.conf` carries `lvm2` (archinstall puts it there).
3. Update to Omarchy 4 so `omarchy_hooks.conf` is deployed.
4. `sudo limine-mkinitcpio`
5. Boot via Limine → hangs; the volume group is never activated.

## Suggested fix

Make the drop-in **augment** rather than replace. The detection logic already exists from #6579 — walking the root device's parents with `lsblk -nso TYPE` — so it can drive the hooks too:

- `lvm` in the chain → ensure `lvm2` (after `encrypt`)
- `raid*` in the chain → ensure `mdadm_udev`
- `resume=` present in the cmdline → ensure `resume`

Alternatively, preserve any hook already present in `/etc/mkinitcpio.conf` that Omarchy does not itself manage, instead of starting from a fixed list.

A guard would also help: refuse to install a UKI whose HOOKS cannot reach the configured root, in the same spirit as #6758 refusing to call a cmdline bootable without a volume selector.

Note that `omarchy_hooks.conf` is a pacman backup file, so editing it in place is possible but produces a `.pacnew` to merge on every update — and doing so freezes the user out of Omarchy's own improvements to that file (the NVIDIA `kms` conditional from #6791, the vconsole guard from #6229). A local drop-in sorting after it is the better workaround, but it should not be necessary:

```bash
# /etc/mkinitcpio.conf.d/zz-lvm2-resume.conf
_local_hooks=()
for _local_hook in "${HOOKS[@]}"; do
	[[ $_local_hook == lvm2 || $_local_hook == resume ]] && continue
	_local_hooks+=("$_local_hook")
	[[ $_local_hook == encrypt ]] && _local_hooks+=(lvm2 resume)
done
HOOKS=("${_local_hooks[@]}")
unset _local_hooks _local_hook
```

## System

- Omarchy `omarchy-dev 4.0.0.r1744.gf002044-1` (dev channel)
- ThinkPad T14 Gen 6 (21QH000NBO), Core Ultra 5 238V (Lunar Lake), Intel integrated graphics
- Kernel 7.1.8-arch1-3 (also reproduced against 6.18.44-1-lts)
- Root: btrfs subvol `@` on LVM on LUKS — `/dev/mapper/ArchinstallVg-root` inside container `cryptlvm`
- Boot: Limine 12.5.2 + UKI (`ENABLE_UKI=yes`), GRUB still present from the pre-Limine install