When `nvme0n1` points at a different disk after every reboot on a dual-boot desktop

Environment: Kubuntu 26.04 LTS · dual-booting Windows 11 · two NVMe SSDs (Samsung PM9A1 + SK hynix P51)

TL;DR

A name like /dev/nvme0n1 isn't a stable identifier for a disk — it's just the order the kernel discovered the NVMe controllers in this boot. It can change between reboots, so before any disk operation, re-confirm the target by model, label, or mountpoint, not by name.

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,MODEL

The symptom

On a desktop dual-booting from two NVMe SSDs (one for Windows, one for Linux), after several reboots I asked the user to run lsblk before some disk work.

nvme0n1     931.5G  SHPP51-1000GM        ← wait, this was the Windows disk
├─nvme0n1p3 930.5G  ntfs
nvme1n1     953.9G  SAMSUNG MZVL21T0HCLR  ← and this is the Linux disk
└─nvme1n1p2 953.6G  ext4  kubuntu_2604   /

The notes from the install a few days earlier clearly said nvme0n1 = Samsung (Linux), nvme1n1 = SK hynix (Windows) — now it was completely reversed.

Root cause: an NVMe name is "this boot's detection order," not an identity

Names like /dev/nvme0n1 and /dev/nvme1n1 are numbered in the order the Linux kernel discovered the NVMe controllers at boot. There's no guarantee a given physical disk always comes up as nvme0 — depending on the motherboard firmware's PCIe enumeration order and NVMe controller init timing, disk A may be seen first this boot and disk B first the next. Plug both disks in under identical conditions (same M.2 slot generation, similar init speed) and this shows up more readily.

So nvme0n1 isn't a unique identifier for "that disk" — it's closer to a temporary label reassigned every boot.

Why it's dangerous

Commands that name a device directly — partitioning, bootloader install, a whole-disk dd copy — run on the wrong disk if you trust an old note and fire away. This is exactly how "I only meant to touch the Linux disk, but it turned out to be the Windows disk" accidents happen on dual-boot setups.

How to check: by model, label, or UUID

Identify by model or filesystem label/mountpoint instead of the device name.

lsblk -o NAME,SIZE,FSTYPE,LABEL,MOUNTPOINT,MODEL
# or
blkid

MODEL (e.g. SAMSUNG MZVL21T0HCLR, SHPP51-1000GM), LABEL (e.g. kubuntu_2604), and MOUNTPOINT (e.g. /) are stable as long as the disk doesn't physically change — confirm "yes, this really is that disk" with those first, then use the device name.

More fundamentally, in scripts and fstab use a UUID or PARTUUID (from blkid) rather than a name like /dev/nvme0n1p2 — a UUID doesn't change as long as the partition exists.

Takeaways / checklist

Don't trust nvme0n1/nvme1n1 as "this disk is always this name" — I watched it flip across reboots.
Before disk work (partitioning, bootloader, dd), always re-confirm the target by model/label with lsblk -o NAME,MODEL,LABEL,MOUNTPOINT. Don't trust an old note's "nvme0n1 = Linux disk."
If you must hardcode a disk in a script, use a UUID/PARTUUID, not the device name.

This principle was central during the Kubuntu dual-boot install too — pinning the disk to erase by model + capacity rather than device number was the safety pin against the worst accident, wiping the Windows disk.