듀얼부팅 데스크탑에서 `nvme0n1`이 재부팅마다 다른 디스크를 가리킬 때

환경: Kubuntu 26.04 LTS · Windows 11 듀얼부팅 · NVMe SSD 2개(삼성 PM9A1 + SK하이닉스 P51)

TL;DR / 빠른 해결

/dev/nvme0n1 같은 이름은 디스크의 고유 식별자가 아니라 이번 부팅에서 커널이 NVMe 컨트롤러를 발견한 순서일 뿐이다. 재부팅마다 바뀔 수 있으니, 디스크 작업 전엔 이름 말고 모델명·라벨·마운트포인트로 대상을 재확인한다.

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

증상

NVMe SSD 두 개(윈도우용·리눅스용)로 듀얼부팅 중인 데스크탑에서, 여러 번 재부팅한 뒤 디스크 작업을 하려고 사용자에게 lsblk를 찍어보도록 요청했다.

nvme0n1     931.5G  SHPP51-1000GM        ← 어? 이게 윈도우 디스크였는데
├─nvme0n1p3 930.5G  ntfs
nvme1n1     953.9G  SAMSUNG MZVL21T0HCLR  ← 이게 리눅스 디스크
└─nvme1n1p2 953.6G  ext4  kubuntu_2604   /

며칠 전 설치 때 기록해둔 걸 보면 분명 nvme0n1 = 삼성(리눅스), nvme1n1 = SK하이닉스(윈도우)였는데, 지금은 완전히 반대로 나왔다.

근본 원인: NVMe 이름은 "정체성"이 아니라 "이번 부팅의 인식 순서"

/dev/nvme0n1, /dev/nvme1n1 같은 이름은 리눅스 커널이 부팅 때 NVMe 컨트롤러를 발견한 순서대로 번호를 매긴 것뿐이다. 어떤 물리 디스크가 항상 nvme0으로 잡힌다는 보장이 전혀 없다 — 메인보드 펌웨어의 PCIe 열거 순서, NVMe 컨트롤러 초기화 타이밍 같은 것에 따라 이번 부팅엔 A 디스크가 먼저, 다음 부팅엔 B 디스크가 먼저 잡힐 수 있다. 두 디스크를 완전히 같은 조건(같은 M.2 슬롯 세대, 비슷한 초기화 속도)으로 꽂으면 이 현상이 더 잘 드러난다.

즉 nvme0n1이라는 이름 자체가 "그 디스크"를 가리키는 고유 식별자가 아니라, 매 부팅마다 새로 배정되는 임시 라벨에 가깝다.

왜 위험한가

파티셔닝, 부트로더 설치, dd로 디스크 통째 복사처럼 디바이스 이름을 직접 지정하는 명령을 예전 기록만 믿고 실행하면, 엉뚱한 디스크에 명령이 나갈 수 있다. 특히 듀얼부팅에서 "리눅스 디스크에만 손대려 했는데 알고 보니 윈도우 디스크였다"는 사고가 이래서 생긴다.

확인 방법: 모델명·라벨·UUID로

디바이스 이름 대신 모델명이나 파일시스템 라벨/마운트포인트로 식별한다.

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

MODEL(예: SAMSUNG MZVL21T0HCLR, SHPP51-1000GM)·LABEL(예: kubuntu_2604)·MOUNTPOINT(예: /)는 디스크가 물리적으로 바뀌지 않는 한 안정적이다 — 이걸로 먼저 "이게 진짜 그 디스크 맞다"를 확인한 다음 디바이스 이름을 써야 안전하다.

더 근본적으로는 스크립트·fstab에서 /dev/nvme0n1p2 같은 이름 대신 UUID나 PARTUUID(blkid로 확인)를 쓰는 게 정석이다 — UUID는 파티션이 존재하는 한 안 바뀐다.

교훈 / 체크리스트

nvme0n1/nvme1n1 같은 이름을 "이 디스크는 항상 이 이름"이라 믿지 말 것 — 재부팅마다 바뀔 수 있는 걸 실제로 겪었다.
디스크 작업(파티셔닝·부트로더·dd 등) 전엔 항상 lsblk -o NAME,MODEL,LABEL,MOUNTPOINT로 모델명·라벨 기준 재확인. 예전 메모의 "nvme0n1 = 리눅스 디스크" 기록을 그대로 믿지 말 것.
스크립트에 디스크를 하드코딩해야 하면 디바이스 이름이 아니라 UUID/PARTUUID를 쓸 것.

이 원칙은 Kubuntu 듀얼부팅 설치 때도 핵심이었다 — 설치 마법사에서 지울 디스크를 장치 번호가 아니라 모델명+용량으로 확정하는 게 최악의 사고(윈도우 디스크 밀어버리기)를 막는 안전핀이었다.