### System details

Hostname: omarchy | OS: Arch Linux x86_64 (Omarchy 3.8.4) | Kernel (running): 7.1.3-arch1-2 | CPU: AMD Ryzen 5 1600 | GPU: NVIDIA GeForce GT 1030 | Memory: 7.7 GiB total | DE/WM: Hyprland 0.55.4 + waybar, SDDM, Wayland | btrfs-progs: v7.0 | Filesystem: btrfs on LUKS2 (/dev/mapper/root), @ subvolid 287 | Disk: 221.6 GiB root | limine-snapper-sync: 1.30.1-1 | Snapshot tool: snapper (-c root) | Bios/UEFI: UEFI boot via Limine

### What's wrong?

### Why this matters

Omarchy documents `Limine ▸ Omarchy snapper ▸` as the recovery path when normal boot breaks after a pacman install. It is the only escape route for users who hit installer-template regressions — no USB-chroot or ISO reinstall required.

On a default Omarchy install, this bug breaks both paths: live boot hits the same `systemd-remount-fs` failure, and snapper-menu boot hits the same failure compounded by Issue B's hook. Every fresh Omarchy install ships with a non-functional recovery path until manually configured around.

**Observed (single-machine, ~7 months of uptime):**
- Default Omarchy 3.8.4 on btrfs + LUKS2, fresh install on **2026-01-10**.
- `/etc/mkinitcpio.conf.d/omarchy_hooks.conf` injects `btrfs-overlayfs` into `HOOKS=(…)` — unchanged since install date.
- `/etc/fstab` and `/etc/default/limine` were unmodified Omarchy defaults until **2026-08-08 14:59 / 15:02** — **the broken combo shipped with the installer and has not changed in 7 months.**
- `journalctl --list-boots` reports **271 distinct boots** since 2026-05-03; nearly all snapper-menu boots hit the red splash banner.
- mkinitcpio rebuilds at **2026-06-02 / 2026-07-14 / 2026-07-25** all re-installed `btrfs-overlayfs` into the initramfs on each kernel upgrade — the bug re-asserts itself on every update. This is not a regression; it is the deterministic outcome of Omarchy's default config.
- today is the first time a manual fix was applied.

### Summary

Boots of a snapper snapshot from the Limine menu (`Omarchy snapper ▸ #N`) — and in some installs the live `Omarchy` entry itself — reach `systemd-remount-fs.service` early in userspace and fail with exit status 32:

```
mount: /: fsconfig() failed: overlay: No changes allowed in reconfigure.
systemd-remount-fs[NN]: /usr/bin/mount for / exited with exit status 32.
systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'.
```

The boot splash shows a red **"Remount Root and Kernel File Systems"** banner. The kernel hands off cleanly — **systemd is the layer that dies, not the kernel**.

### Steps to reproduce

1. Default Omarchy install on btrfs + LUKS2 with the default snapper config.
2. Wait for ≥ 2 snapper snapshots so Limine has a `Omarchy snapper ▸ #N` submenu (`omarchy-snapshot create` twice).
3. Reboot. From Limine, pick **`Omarchy snapper ▸` then any one** of the snapshot entries (not the top-level live `Omarchy` entry).
4. Within ~2 s of userspace, observe the `systemd-remount-fs` failure above.

### Root cause

`subvol=` cannot be reconfigured post-mount. The default Omarchy installer template disagrees on what subvolume `/` should be:

| File | What it says about `/` |
|---|---|
| `/etc/fstab` (Omarchy installer template) | `subvol=/@` (path-based) |
| `/etc/default/limine`'s `KERNEL_CMDLINE` (live entry) | `rootflags=subvol=@ rw …` (no `compress=zstd:3`, `ssd`, `space_cache=v2`, `relatime`) |
| Limine snapper boot entries (regenerated by `limine-snapper-sync`) | `rootflags=subvol=/@/.snapshots/N/snapshot rw …` |

Path-based `subvol=` is unstable across snapper churn; numeric `subvolid=` is the stable form. The "overlay" label in the kernel error is libmount's class label for "VFS reconfigure"; the *actual* cause is that `subvol=` reconfiguration is never allowed.

### Suggested fix

Two installer-template changes, both small:

1. **In the Omarchy installer fstab template**, change `subvol=/@` → `subvolid=<N>` (numeric, from `btrfs subvolume get-default /` at install time) **and** append `,x-systemd.remount=false` to the `/` line. `x-systemd.remount=false` tells `systemd-fstab-generator` to skip the post-mount reconfigure step for `/`, sidestepping the kernel's `subvol=` prohibition.
2. **In `/etc/default/limine`'s `KERNEL_CMDLINE`**, append `,compress=zstd:3,ssd,space_cache=v2,relatime` to `rootflags` so the kernel applies the btrfs options at mount time (defense-in-depth; if someone disabled `x-systemd.remount=false` later, the mount options still hold).

### Workaround applied locally (survives reboots)

**`/etc/fstab` — `/` line** (substitute your actual btrfs UUID and `@` subvolid):

```
UUID=<your-btrfs-uuid>  /  btrfs  rw,relatime,compress=zstd:3,ssd,space_cache=v2,subvolid=<N>,x-systemd.remount=false  0  0
```

**`/etc/default/limine` — `KERNEL_CMDLINE`**:

```
rootflags=subvol=@,compress=zstd:3,ssd,space_cache=v2,relatime rw rootfstype=btrfs
```

**`/etc/boot/hooks/post.d/95-reapply-btrfs-cmdline-options`** — a hook that re-applies the cmdline `rootflags` after `limine-snapper-sync` regenerates `/boot/limine.conf`:

```bash
#!/bin/bash
set -e
LIMO=/boot/limine.conf
sed -i 's|rootflags=subvol=@ rw rootfstype=btrfs|rootflags=subvol=@,compress=zstd:3,ssd,space_cache=v2,relatime rw rootfstype=btrfs|' "$LIMO"
```

After applying all three edits + reinstalling the durability hook, every `limine-snapper-sync` run regenerates `/boot/limine.conf` and the hook re-asserts the missing options.

### Severity

**High.** On a default install, this bug (combined with Issue B #6634) removes the documented recovery path for normal-boot failures. Until upstream fixes ship, every fresh Omarchy install ships with a non-functional snapshot menu and a sit-in-able but splash-broken live boot. The system still reaches `multi-user.target` so it isn't "won't boot at all", but new users who hit this will assume their install is broken — and they will be substantially correct.

This has been latent on a default install for ~7 months with no `omarchy update` ever addressing it. 
### Labels

`bug` `btrfs` `boot` `limine` `installer`

### Related

A companion issue (#6634: `initcpio: btrfs-overlayfs hook unconditionally overlays / for snapper boots, defeating fstab-level fixes`) covers the **second layer** of this failure — the hook's `/snapshot` detection creates an overlayfs that defeats the fstab-level workaround here. This issue (#6633) and #6634 are filed together; **both fixes are required** for snapper-menu boots to come up clean on a default install. Apply #6633 first (it's the prerequisite for the symptom to even *appear*), then #6634 on top.