nvme-migration-notes.md

Migrating Boot to nvme0n1 — Duplicate LUKS UUID Fix

The Problem

Both LUKS partitions share the same UUID:

nvme0n1p3: 3724c71a-d873-4991-9534-05669f6de28e  (target — want to boot this)
nvme1n1p5: 3724c71a-d873-4991-9534-05669f6de28e  (current running system)

GRUB's cryptdevice=UUID=... is ambiguous — the kernel grabs whichever it finds first, so you end up booting the old drive.

Fix

1. Change the UUID on nvme0n1p3

# Close nvme0n1p3 if it's open
sudo cryptsetup close /dev/mapper/<name-if-open>

# Assign new UUID
sudo cryptsetup luksUUID /dev/nvme0n1p3 --uuid "$(uuidgen)"

# Verify
sudo blkid /dev/nvme0n1p3

2. Update GRUB config

Edit /etc/default/grub on the nvme0 boot partition:

GRUB_CMDLINE_LINUX="cryptdevice=UUID=<new-uuid>:cryptlvm root=/dev/mapper/vg-root"

3. Regenerate grub.cfg

From a chroot into the nvme0 root (or live USB):

grub-mkconfig -o /boot/grub/grub.cfg

4. Check for LVM VG name collision

If the LUKS volume was cloned, both containers will have a VG named vg. With both drives present, opening the second causes a name collision. Fix with:

vgrename <old-vg-uuid> vg-old

Quick Test (no permanent changes)

Use device path instead of UUID in the GRUB editor (e at boot):

cryptdevice=/dev/nvme0n1p3:cryptlvm

This sidesteps the UUID collision for a one-shot boot to verify nvme0's root works.