### System details

X1 Carbon gen12

### What's wrong?

> **On authorship:** this report was written by Claude (Anthropic's Claude Code), working with the owner of the affected machine. They hit the symptom and aSnapper rollbacks silently un-apply Omarchy migrations (surfaced as: LUKS prompt still QWERTY after e891e5c)sked me to find out why an Omarchy update hadn't fixed it; the investigation, diagnosis and this write-up are mine, run against their system with their permission. They're posting it because it's their machine, and have asked me to be explicit that they can't independently vouch for the technical claims — so please direct follow-up questions at the evidence rather than assuming the reporter can reason about initramfs internals unaided. Everything below was observed directly on the machine except where marked as inference. I'm happy to run whatever further diagnostics would help.

## Summary

Migration markers are stored in `$HOME/.local/state/omarchy/migrations/`, on the `@home` subvolume. Migrations mutate `/`, on `@`.

Restoring a Snapper snapshot rewinds `@` but not `@home`. Everything the migrations did is undone; every marker survives. `omarchy-migrate` is one-shot, so those migrations never run again — silently, with no way to detect or recover.

This affects any machine that has used the snapshot-restore feature Omarchy ships and promotes.

## How this surfaced

The Plymouth LUKS prompt was still US QWERTY despite `XKBLAYOUT` being set to a non-US layout — the bug e891e5c fixed. On this machine that migration **ran and succeeded**: the journal shows both the `tee` into `omarchy_hooks.conf` and an 11-second `limine-mkinitcpio` rebuild, with the marker written immediately after. About 90 minutes later the owner booted a snapshot predating it and restored it.

Observed now:

- `/etc/mkinitcpio.conf.d/omarchy_hooks.conf` holds its install-day content, **with its original mtime intact**. Btrfs preserves mtime across a snapshot restore; an overwrite would not. So nothing about the file looks disturbed.
- The corresponding marker under `~/.local/state/omarchy/migrations/` still says applied.
- `findmnt` shows `@` with a high `subvolid` while `@home`, `@log` and `@pkg` retain their original low ones — i.e. `@` was replaced.
- The UKI has since been rebuilt from the reverted config, so it still lacks `/etc/vconsole.conf`.

*(Inference, not a log line: no journal entry says "rollback". The conclusion that the restore is what reverted the file rests on the four observations above — preserved mtime, replaced subvolume, a boot with `rootflags=subvol=…/.snapshots/<n>/snapshot`, and a reboot immediately after. I consider it solid but it is reconstructed, not directly logged.)*

The keymap fix is just the instance that got noticed. Every migration applied between the snapshot and the restore is in the same state.

## Two things that close off the recovery paths

**1. `omarchy_hooks.conf` is permanently a `.pacnew` on pre-packaging installs.**

The current fix lives in the packaged `omarchy_hooks.conf` (the `case` / `FILES+=(/etc/vconsole.conf)` block — a good refinement on e891e5c, since it skips non-Latin layouts). But `install/login/limine-snapper.sh` creates that file with `sudo tee`. On any install predating `omarchy-settings` owning the path, pacman sees a locally-modified file and writes `.pacnew` forever. The live file stays stale, and `omarchy update` never mentions it.

#6876 already notes that this file "is a pacman backup file… produces a `.pacnew` to merge on every update". The consequence worth adding: it also means **upstream fixes shipped inside that file never reach these installs at all**.

`install/post-install/pacman.sh` already handles this exact pattern for `cups-files.conf` — claim the file the way `omarchy-settings` would, then delete the `.pacnew`. The same treatment would work here.

**2. The migration has been pruned from the package.** It is absent from the 4.0.0 / 4.0.1 / 4.0.2 tarballs; the shipped set skips the window it belonged to. So: effect reverted, marker permanent, migration deleted, replacement behind a `.pacnew`. No path back.

## Suggested fixes

- Track markers for system-scoped migrations on `@` rather than `$HOME` — `/var/lib/omarchy/migrations/` already exists for root-scoped migrations. Purely user-scoped migrations can stay where they are.
- Or have `omarchy update` reconcile desired system state rather than relying only on one-shot markers.
- Have `omarchy update` report pending `.pacnew` files for Omarchy-owned paths, and add a migration that replaces a known-unmodified `tee`-written `omarchy_hooks.conf` with the packaged version.
- Consider a warning from `limine-snapper-restore` that a restore can desynchronize Omarchy migration state.

## Note on the underlying keymap mechanism

Confirming e891e5c's diagnosis independently, for the record. The `keymap` hook bakes the correct `keymap.bin` into the initramfs — extracted from this machine's UKI, it is byte-identical to `loadkeys -b <layout>`. But the `encrypt` hook delegates the prompt to `plymouth ask-for-password`, and Plymouth 26 reads evdev directly and translates via libxkbcommon, ignoring the console keymap entirely.

`libply-splash-core.so.5` links `libxkbcommon` and `libevdev`, and contains `parse_vconsole_conf`, `/etc/vconsole.conf`, `XKBLAYOUT`, and the log string *"Not creating devices for subsystem input because there is no configure XKB layout"*. Arch's `initcpio/install/plymouth` copies the entire XKB database into the initramfs but never the file that selects a layout, so plymouthd falls back to its built-in US default. `/etc/vconsole.conf` is confirmed absent from the UKI on this machine.

`FILES+=(/etc/vconsole.conf)` is the right fix. This report is only about it not reaching existing installs.

## Workaround

**Not yet applied on the affected machine** — the owner preferred to report this before changing anything, so the following is reasoned from the config rather than confirmed by a boot:

```bash
sudo cp /etc/mkinitcpio.conf.d/omarchy_hooks.conf.pacnew /etc/mkinitcpio.conf.d/omarchy_hooks.conf
sudo rm /etc/mkinitcpio.conf.d/omarchy_hooks.conf.pacnew
sudo limine-mkinitcpio
```

`diff` the two first — here the change is a pure addition, so the merge is trivial, but that won't hold for anyone who has edited their `HOOKS` line. Use `limine-mkinitcpio`, not `mkinitcpio -P`: on a Limine + UKI setup `/etc/mkinitcpio.d/` is empty, the image is built via `kernel-install`, and `limine.conf` embeds its hash.

## Versions

Omarchy 4.0.2, plymouth 26.134.222, mkinitcpio 41.1, limine 12.6.0 with `limine-mkinitcpio-hook` and `limine-snapper-sync`, LUKS root on btrfs, UKI boot.

Related: #6876 (same file, `.pacnew` churn), #5916 (restore vs. `@home` split, different mechanism), #6183 / #6151 / #6072 (the keymap fix itself).