ZimaOS 부팅 슬롯이 모두 실패하고 콘솔에 오버레이 마운트 오류, 슈퍼블록 읽기 실패 또는 NVMe I/O 오류가 표시되더라도 스토리지 풀 재구축부터 시작하지 마세요. 먼저 문제가 부팅 장치에 있는지, 별도의 데이터 디스크에 있는지 확인해야 합니다.
2026년 6월에 발생한 이 사례에서는 읽기 전용 진단 결과 부팅 NVMe에서 반복적인 미디어 오류가 확인되었고, 대용량 Btrfs 데이터 풀은 별도의 디스크에 구성되어 있었습니다. 사용자는 부팅 드라이브를 교체하고 ZimaOS를 재설치한 뒤 데이터 풀이 그대로 남아 있음을 확인했습니다.
먼저 부팅 장치와 데이터 풀을 분리해서 확인하세요
해당 스레드의 복구 셸 출력에는 ZimaOS 부팅 및 데이터 파티션이 포함된 약 119GB 용량의 NVMe와, 별도의 여러 디스크로 구성된 Btrfs 풀이 표시되었습니다. 이 구분에 따라 복구 계획이 달라집니다. 부팅 NVMe의 고장이 스토리지 풀의 고장을 자동으로 의미하지는 않습니다.
먼저 읽기 전용 명령을 실행하세요.
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
blkid
cat /proc/cmdline디스크나 파티션을 대상으로 하는 명령을 실행하기 전에 정확한 장치 이름을 기록해 두세요.
실제 I/O 오류가 있는지 커널 로그를 확인하세요
원본 사례에서는 부팅 장치에 대해 반복적인 critical medium error, Buffer I/O error, EXT4 마운트 실패 및 NVMe 오류가 나타났습니다. 이러한 메시지는 일반적인 부팅 화면 패닉보다 스토리지 고장을 훨씬 강하게 나타내는 증거입니다.
dmesg -T | grep -Ei 'nvme|I/O error|Buffer I/O|EXT4|superblock|reset|timeout|critical|media'오류가 부팅 NVMe를 지속적으로 가리키고 데이터 디스크에서는 문제가 보고되지 않는다면, 조사의 초점을 부팅 경로에 맞추세요.
SMART의 “PASSED” 결과만으로는 미디어 오류를 무시할 수 없습니다
해당 스레드에서 NVMe SMART 상태 요약은 여전히 PASSED였지만, 상세 카운터에는 76회의 미디어/데이터 무결성 오류가 표시되었고 커널에는 이미 읽기 실패가 기록되고 있었습니다. 읽기 전용 파일시스템 검사도 읽을 수 없는 블록에서 중단되었습니다.
올바른 장치 이름을 확인한 후 smartctl -x /dev/nvmeXn1 또는 nvme smart-log /dev/nvmeXn1와 같은 명령으로 상세 상태 정보를 확인하세요. 전체 상태를 나타내는 단일 단어만으로 진단을 끝내지 마세요.
먼저 읽기 전용 파일시스템 검사를 사용하세요
커뮤니티에서는 영향을 받은 EXT4 오버레이 파티션에 e2fsck -fn을 실행하여 복구 내용을 기록하지 않고 파일시스템을 검사했습니다. 이 읽기 전용 검사에서도 읽을 수 없는 블록이 발견되어 하드웨어 고장 진단을 뒷받침했습니다.
마운트된 파일시스템에서 쓰기 모드 fsck를 실행하지 말고, 파티션 이름을 추측하지도 마세요. 부팅 SSD가 물리적으로 고장 나는 중이라면 반복적인 쓰기 시도로 복구가 더 어려워질 수 있습니다.
슬롯 A와 슬롯 B가 모두 실패할 수 있는 이유
ZimaOS는 ZimaOS 시스템 복구 가이드에 설명된 A/B 시스템 슬롯을 사용합니다. 하지만 두 부팅 선택지 모두 부팅 장치에 있는 정상적인 공유 스토리지 구성 요소에 의존합니다. 따라서 오버레이 또는 부팅 NVMe에 문제가 발생하면 두 슬롯 모두 시작을 완료하지 못할 수 있습니다.
교체가 더 안전한 방법인 경우
원본 사례에서 부팅 NVMe에 커널 미디어 오류, 상세 SMART 미디어 오류 카운터 및 읽을 수 없는 파일시스템 블록이 확인된 후, 커뮤니티에서는 해당 SSD를 제자리에서 복구하려 하기보다 신뢰할 수 없는 장치로 간주할 것을 권장했습니다. 사용자는 SSD를 교체하고 ZimaOS를 성공적으로 재설치했습니다.
재설치 중에는 데이터 디스크를 명확히 식별하고 기존 풀을 초기화하거나 다시 생성하지 않도록 주의하세요. ZimaOS 설치 문제 해결 가이드에서는 부팅 설치 과정을 안내하며, 재설치 후 스토리지 복구 가이드에서는 핵심 원칙을 강조합니다. 이미 데이터가 들어 있는 풀을 다시 생성하지 마세요.
요점
이 사례에서 커널 패닉은 부팅 NVMe의 고장으로 발생했으며, 별도의 데이터 풀이 파괴되었다는 증거가 아니었습니다. 읽기 전용 방식으로 진단하고, 어느 장치에서 I/O 오류가 발생하는지 확인하며, 데이터 디스크는 건드리지 마세요. 원래 사용자는 고장 난 부팅 드라이브를 교체하고 ZimaOS를 재설치한 뒤 기존 데이터 풀이 그대로 유지되었음을 확인했습니다.
