Summary
When installing LMDE using manual partitioning, already-unlocked dm-crypt mappings (e.g. cryptsetup open … cryptroot → /dev/mapper/cryptroot) are not shown in the partition list. As a result, the installer cannot select the mapper as /.
This makes the manual-partitioning path unsafe: users are pushed toward selecting the underlying raw partition (e.g. /dev/nvme0n1p6) and formatting it, which destroys the LUKS header and breaks the intended full-disk encryption flow.
Impact
- User-facing risk: easy to brick the intended encryption setup by formatting the raw block device.
- UX issue: manual partitioning is effectively non-functional for dm-crypt/FDE workflows.
- Support burden: leads to install loops and recovery attempts.
Environment
- Distro: LMDE 7 “Gigi” live ISO
- Installer: LMDE installer (manual partitioning screen)
- Firmware: UEFI (Secure Boot enabled)
- Disk layout goal:
- ESP (FAT32) mounted at
/boot/efi (existing)
- ext4
/boot
- root intended inside LUKS2 (btrfs)
- Goal: dual boot (Windows preserved), LUKS2 for root, btrfs snapshots later
Reproduction steps (minimal)
- Boot LMDE live ISO.
- Prepare partitions (or use an existing target partition):
- keep existing ESP (FAT32)
- create ext4
/boot
- create a large partition to be encrypted (example:
/dev/nvme0n1p6)
- In the live session, create and unlock the dm-crypt mapping:
sudo cryptsetup luksFormat /dev/nvme0n1p6
sudo cryptsetup open /dev/nvme0n1p6 cryptroot
- Verify the mapper exists (before launching the installer):
ls -la /dev/mapper/
lsblk -f
- Start the installer and go to Manual partitioning.
Expected behavior
- Manual partitioning lists
/dev/mapper/cryptroot (or equivalent unlocked mapper) and allows selecting it as / (and formatting it as btrfs/ext4).
Actual behavior
- Manual partitioning does not list any
/dev/mapper/* entries.
- Only the underlying raw partition (e.g.
/dev/nvme0n1p6) appears as a selectable target for / and formatting.
Evidence to attach (non-sensitive)
- Screenshot: manual partitioning screen showing the absence of
/dev/mapper/* entries.
- Terminal output:
ls -la /dev/mapper/ (shows mapping exists)
lsblk -f (shows crypto_LUKS + the mapping)
Workaround used (works, but non-obvious)
Install first onto plain btrfs on the raw partition, do not reboot, then encrypt in-place using cryptsetup reencrypt, followed by initramfs/GRUB updates from a chroot.
Reference used: https://gist.github.com/Leniwcowaty/4b2c239ca74629cad60d4718f79ff600
Related
- TPM2+PIN /
systemd-cryptenroll availability (separate issue): https://github.com/linuxmint/live-installer/issues/177
Suggested fix direction
- In manual partitioning, refresh and include
/dev/mapper/* devices once dm-crypt has been unlocked.
- Alternatively, provide an explicit UI action to “unlock encrypted volume”, and after unlock, surface the mapper device as a selectable target.
Summary
When installing LMDE using manual partitioning, already-unlocked dm-crypt mappings (e.g.
cryptsetup open … cryptroot→/dev/mapper/cryptroot) are not shown in the partition list. As a result, the installer cannot select the mapper as/.This makes the manual-partitioning path unsafe: users are pushed toward selecting the underlying raw partition (e.g.
/dev/nvme0n1p6) and formatting it, which destroys the LUKS header and breaks the intended full-disk encryption flow.Impact
Environment
/boot/efi(existing)/bootReproduction steps (minimal)
/boot/dev/nvme0n1p6)Expected behavior
/dev/mapper/cryptroot(or equivalent unlocked mapper) and allows selecting it as/(and formatting it as btrfs/ext4).Actual behavior
/dev/mapper/*entries./dev/nvme0n1p6) appears as a selectable target for/and formatting.Evidence to attach (non-sensitive)
/dev/mapper/*entries.ls -la /dev/mapper/(shows mapping exists)lsblk -f(showscrypto_LUKS+ the mapping)Workaround used (works, but non-obvious)
Install first onto plain btrfs on the raw partition, do not reboot, then encrypt in-place using
cryptsetup reencrypt, followed by initramfs/GRUB updates from a chroot.Reference used:
https://gist.github.com/Leniwcowaty/4b2c239ca74629cad60d4718f79ff600Related
systemd-cryptenrollavailability (separate issue):https://github.com/linuxmint/live-installer/issues/177Suggested fix direction
/dev/mapper/*devices once dm-crypt has been unlocked.