Installer crashes with DiskError when mounting LUKS partition as Btrfs during device scan (NVMe + LUKS + Btrfs)

[OmarGonD]

Description

During a fresh Omarchy installation (using the official ISO), the installer successfully creates the Btrfs filesystem on the LUKS mapper device (/dev/mapper/omarchy_root) and creates the expected subvolumes (@, @home, @log, @pkg).

Shortly after, the process fails when archinstall's DeviceHandler attempts to re-scan devices and mount the underlying LUKS partition (/dev/nvme0n1p2) as if it were a Btrfs filesystem.

This appears to be a device detection / Btrfs info gathering issue inside archinstall when handling encrypted layouts.

Error

archinstall.lib.exceptions.SysCallError: ['/usr/bin/mount', '/dev/nvme0n1p2', '/mnt/arch_btrfs'] exited with abnormal exit code [32]
During handling of the above exception, another exception occurred:
archinstall.lib.exceptions.DiskError: Could not mount /dev/nvme0n1p2:
['/usr/bin/mount', '/dev/nvme0n1p2', '/mnt/arch_btrfs'] exited with abnormal exit code [32]:
mount: /mnt/arch_btrfs: wrong fs type, bad option, bad superblock on /dev/nvme0n1p2, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

The failure happens in:

• DeviceHandler.load_devices()
• → get_btrfs_info()
• → mount() of /dev/nvme0n1p2 to /mnt/arch_btrfs

Steps to reproduce

1. Boot official Omarchy ISO
2. Start the installer (Omarchy configurator → archinstall path)
3. Select full disk or appropriate layout with disk encryption enabled (LUKS)
4. Choose Btrfs with default subvolumes
5. Proceed with installation
6. After Btrfs creation on the mapper device and subvolume creation, the installer crashes with the error above

Expected behavior

The installer should correctly identify that /dev/nvme0n1p2 is a crypto_LUKS container and only attempt Btrfs operations on the opened mapper device (/dev/mapper/omarchy_root or equivalent).

Actual behavior

After successfully creating the encrypted Btrfs volume, a later device re-scan tries to mount the raw LUKS partition as Btrfs and fails.

System information

Hardware:

• Model: HP ProDesk 600 G5 Desktop Mini
• Manufacturer: HP
• BIOS: R22 Ver. 02.26.00 (Release date: 2026-05-05)
• CPU: Intel Core i5-9500T @ 2.20 GHz (6 cores / 6 threads)
• RAM: 32 GB (2 × 16 GB Hynix DDR4-3200, running at 2667 MHz)
• GPU: Intel UHD Graphics 630 (Driver 31.0.101.2140)
• OS (current): Windows 11 Pro (Build 26200) — 64-bit
• Firmware: UEFI

Installation details:

• Omarchy ISO version: [versión exacta del ISO que usaste]
• Encryption: Yes (LUKS)
• Filesystem: Btrfs with default subvolumes (@, @home, @log, @pkg)
• Previous state of the disk: [¿había dual-boot Windows / instalación previa fallida / disco limpio?]

Additional context:

• This does not appear to be a common issue (most successful installs with LUKS + Btrfs work).
• The Btrfs creation itself succeeds (label OMARCHY, correct size, subvolumes created).
• The crash occurs during a subsequent device scan / Btrfs info collection phase.
• Similar patterns have been seen in archinstall issues involving encrypted partitions + Btrfs detection.

Suggested investigation

• DeviceHandler.get_btrfs_info() should skip or properly handle partitions with fstype=crypto_LUKS.
• Consider checking lsblk / blkid more carefully before attempting a temporary mount to /mnt/arch_btrfs.

### System information

**Hardware:**
- **Model**: HP ProDesk 600 G5 Desktop Mini
- **Manufacturer**: HP
- **BIOS**: R22 Ver. 02.26.00 (Release date: 2026-05-05)
- **CPU**: Intel Core i5-9500T @ 2.20 GHz (6 cores / 6 threads)
- **RAM**: 32 GB (2 × 16 GB Hynix DDR4-3200, running at 2667 MHz)
- **GPU**: Intel UHD Graphics 630 (Driver 31.0.101.2140)
- **OS (current)**: Windows 11 Pro (Build 26200) — 64-bit

**Storage:**
- **Drive**: WD Green SN350 2TB NVMe SSD — 1863.02 GB — Healthy
- **Serial**: E823_8FA6_BF53_0001_001B_448B_473C_597E
- **Current partition layout** (Disk 0):

| Partition | Size      | Type      | Notes                          |
|-----------|-----------|-----------|--------------------------------|
| 1         | 2 GB      | System    |                                |
| 2         | 0.02 GB   | Reserved  |                                |
| 3 (C:)    | 975.71 GB | Basic     | Windows (NTFS)                 |
| 4         | 0.85 GB   | Recovery  |                                |
| 5         | 2 GB      | System    |                                |
| 6         | 882.44 GB | Unknown   | Target partition for Omarchy   |

**Security / Dual-boot:**
- Secure Boot: Could not be determined (likely disabled or insufficient privileges)
- TPM: Status could not be retrieved
- BitLocker: Access denied / no BitLocker volumes detected with current privileges

**Installation context:**
- Installing Omarchy with **LUKS encryption + Btrfs** (default subvolumes)
- Target is the NVMe drive (`/dev/nvme0n1`)
- Btrfs is successfully created on the LUKS mapper (`/dev/mapper/omarchy_root`, ~882 GiB, label `OMARCHY`)
- Crash happens afterwards when `archinstall` tries to mount the raw LUKS partition (`/dev/nvme0n1p2`) as Btrfs → `DiskError: wrong fs type, bad superblock`

Happy to provide full dmesg, lsblk -f, install.log or more details if needed.