기술 · 실용 가이드
Linux “wrong fs type, bad option, bad superblock”: 먼저 실패 경계를 증명하세요
이 mount 메시지는 진단이 아니라 요약입니다. 정확한 시도를 고정하고 source와 filesystem signature를 증명한 뒤 첫 kernel error를 읽고 helper, option 또는 filesystem 전용 분기를 선택하세요.
이 mount 메시지는 진단이 아니라 요약입니다. 정확한 시도를 고정하고 source와 filesystem signature를 증명한 뒤 첫 kernel error를 읽고 helper, option 또는 filesystem 전용 분기를 선택하세요.
같은 일반 mount 메시지는 생성되지 않은 filesystem, 잘못된 device/partition, 지원되지 않는 option, 누락 helper, 지원되지 않는 feature, on-disk damage를 뜻할 수 있습니다. lsblk와 findmnt는 device topology와 mount/config identity를 보여 주고 blkid는 on-disk TYPE과 UUID metadata를 probe합니다.
1. 다른 명령 전에 정확한 실패 시도를 고정하세요
전체 command, source, target, option, shell, namespace, 시간을 저장합니다. mount 출력과 그 시도 후 새로 생긴 첫 kernel/journal 줄을 기록하고 후속 retry를 같은 evidence window에 섞지 않습니다.
mkfs, force flag, generic fsck부터 실행하지 마세요. 이 메시지는 여러 가능성을 포함하며 destructive command는 잘못된 device/type을 선택했다는 증거를 지울 수 있습니다.
2. source, partition, 기존 mount identity를 증명하세요
lsblk에 NAME,MAJ:MIN,SIZE,FSTYPE,UUID,MOUNTPOINTS column을 명시하고 findmnt를 --source와 --target으로 각각 조회합니다. /dev/mapper, loop, RAID, LVM, cloud alias를 실패 process가 본 정확한 major:minor로 확인합니다.
/etc/fstab 또는 mount unit의 UUID, type, target, option과 비교합니다. /dev/sdX 이름은 reboot 후 바뀔 수 있으므로 현재 mapping을 증명해 잘못된 partition 복구를 막습니다.
3. on-disk signature를 쓰기 없이 probe하세요
정확한 device에서 lsblk --fs와 권한 있는 blkid probe를 실행해 TYPE, UUID, ambiguous/colliding signature를 기록합니다. signature가 없으면 blank, encrypted, RAID/LVM member 또는 wrong layer인지 먼저 판단합니다.
GPT type label이나 bad superblock 문구로 ext를 추정하지 마세요. partition metadata와 filesystem metadata는 별개이며 signature가 충돌하면 지우지 말고 stack을 조사합니다.
4. helper/option failure와 filesystem failure를 나누세요
userspace helper가 필요하면 mount.<type> 존재와 option을 검증합니다. fstab syntax는 mount -a가 아니라 findmnt --verify로 검사하고 첫 kernel error를 unsupported feature, dirty state, permission, namespace 또는 I/O로 분류합니다.
NFS, CIFS, overlay, FUSE, container volume도 같은 summary를 낼 수 있습니다. 해당 helper/kernel path를 조사하고 local block-filesystem repair를 실행하지 마세요.
5. 일치하는 한 분기만 실행하고 같은 mount를 반복하세요
type과 unmounted state를 증명한 뒤 해당 checker를 사용합니다. ext는 적절한 documented no-write path부터, XFS는 xfs_repair -n no-modify scan부터 시작합니다. 메시지만 없애려고 -L을 쓰면 metadata change를 잃을 수 있습니다.
근거 있는 한 변경 뒤 같은 source, target, 의도한 option으로 다시 mount하고 findmnt, 예상 file, 깨끗한 kernel-log window를 확인합니다. 실패가 바뀌면 추측을 더하지 말고 ledger를 다시 봅니다.
