### System details

Omarchy 4.x / Quattro - Kernel: 7.1.9-arch1-2 - Boot: Limine + UKI - Root filesystem: Btrfs subvolume @ on LUKS2 - Dual boot with Windows 10 on the same NVMe - Omarchy initramfs uses the classic mkinitcpio encrypt hook

### What's wrong?

I had an existing Omarchy installation with an encrypted Btrfs root.

After freeing ~54 GiB from the Windows partition, I added that space to the existing root Btrfs filesystem as a second encrypted device.

The resulting layout was effectively:

```text
/dev/nvme0n1p8
  -> LUKS
  -> /dev/mapper/omarchy_root
                                  \
                                   -> Btrfs root (/)

/dev/nvme0n1p5
  -> LUKS
  -> /dev/mapper/omarchy_extra
                                  /
```

The second device was configured in `/etc/crypttab` with a keyfile:

```text
omarchy_extra UUID=8b318f9f-1612-4d47-a34c-cb8bacc6ee88 /etc/cryptsetup-keys.d/omarchy_extra.key luks
```

The running system continued working normally.

However, after the next reboot, Omarchy dropped into the initramfs emergency shell:

```text
ERROR: Failed to mount '/dev/mapper/omarchy_root' on real root
You are now being dropped into an emergency shell.
```

The relevant Btrfs errors were:

```text
BTRFS error (device dm-0): devid 2 uuid 590b44eb-ecc8-47b5-a250-37fcadad952c is missing
BTRFS error (device dm-0): failed to read chunk tree: -2
BTRFS error (device dm-0): open_ctree failed: -2
```

`/dev/mapper/omarchy_root` existed and the primary LUKS container was successfully unlocked.

The problem was that the second LUKS container required by the same Btrfs filesystem was not unlocked during early boot.

Booting older Snapper snapshots did not help because all snapshots depend on the same underlying Btrfs devices.

### Diagnosis

Using the Omarchy/Arch live environment, I mounted the root filesystem in degraded/recovery mode and found:

```text
/etc/crypttab:

omarchy_extra UUID=8b318f9f-1612-4d47-a34c-cb8bacc6ee88 /etc/cryptsetup-keys.d/omarchy_extra.key luks
```

I then manually unlocked the second device:

```bash
cryptsetup open /dev/nvme0n1p5 omarchy_extra \
  --key-file /mnt/root/@/etc/cryptsetup-keys.d/omarchy_extra.key
```

`blkid` confirmed that this was exactly the missing Btrfs member:

```text
/dev/mapper/omarchy_extra:
LABEL="OMARCHY"
UUID="606eb6e0-b9f5-4888-ae2c-7aa1b0ac9818"
UUID_SUB="590b44eb-ecc8-47b5-a250-37fcadad952c"
TYPE="btrfs"
```

The `UUID_SUB` exactly matched the missing `devid 2` reported during boot.

Interestingly, the second Btrfs device had no allocated chunks:

```text
/dev/dm-1, ID: 2
  Device size: 54.03GiB
  Device slack: 0.00B
  Unallocated: 54.03GiB
```

I recovered the installation by removing that device from the Btrfs filesystem:

```bash
btrfs device remove /dev/mapper/omarchy_extra /mnt/root
```

Afterwards:

```text
Label: 'OMARCHY'
Total devices 1
devid 1 ... path /dev/mapper/omarchy_root
```

Omarchy booted normally again.

I then removed the stale `omarchy_extra` configuration, regenerated the UKI with:

```bash
sudo limine-mkinitcpio
sudo limine-update
```

and verified after reboot:

```text
Total devices 1
```

Finally, instead of using a second Btrfs device, I resized/moved the existing `OMARCHY_ROOT` LUKS partition and expanded it from ~228 GiB to ~282 GiB.

The final healthy layout is again:

```text
one partition
  -> one LUKS container
     -> one Btrfs device
        -> /
```

### Root cause

The second LUKS device was present in `/etc/crypttab`, but that is not sufficient for a device that is required to mount `/` itself.

Btrfs needed `omarchy_extra` before the real root filesystem could be mounted, while the normal `/etc/crypttab` configuration lives on that root filesystem.

This creates a circular early-boot dependency.

Omarchy's stock UKI uses the classic mkinitcpio `encrypt` flow and explicitly unlocks the configured root LUKS device. An additional independent LUKS container required by the same root Btrfs filesystem is not automatically available at that point.

The particularly dangerous part is that adding the second Btrfs device succeeds while the system is running, so everything appears healthy until the next reboot.

I do not believe the Omarchy update corrupted Btrfs. The reboot after the update most likely exposed an already-unbootable storage topology.

### Expected behavior

At minimum, Omarchy should detect or document this unsupported root layout before an update/reboot leaves the system unbootable.

For example, before regenerating the UKI or recommending a reboot, Omarchy could check whether:

```bash
btrfs filesystem show /
```

reports more than one device for `/`.

If multiple root Btrfs devices are present and more than one is behind independent LUKS containers, Omarchy could warn that the current initramfs may not unlock all required devices.

Example warning:

> Root Btrfs spans multiple devices, but the current encrypted-root initramfs configuration may not unlock every required device before mounting `/`. Do not reboot until the additional devices are available in initramfs.

### Suggested improvements

- Document the supported way to grow an encrypted Omarchy root:
  `resize partition -> resize LUKS mapping -> resize Btrfs`
- Warn against using `btrfs device add` with another independent LUKS container for the root filesystem.
- Add a preflight validation for multi-device Btrfs roots before UKI regeneration or reboot.
- Potentially support multiple early-boot encrypted root devices in the future.

### Related issues

This seems adjacent to other cases where Omarchy's generated initramfs does not match a non-standard root topology:

- #6876 — custom root layout requires initramfs hooks that Omarchy's fixed HOOKS configuration drops
- #7222 — encrypted root becomes unbootable due to a mismatch between the encryption kernel parameters and the effective initramfs hook

This issue is specifically about **a multi-device Btrfs root where an additional required Btrfs member lives behind a separate LUKS container**.