直接运行 sudo mount -a 可立即暴露 fstab 配置错误，如设备不存在、文件系统类型不匹配、挂载点未创建等；需结合 blkid 核对 UUID 和 TYPE，检查 noauto、_netdev、nofail 等选项及第六列 pass 字段是否为合法数字。
直接运行 sudo mount -a 暴露 fstab 错误
系统开机挂载失败，本质就是 systemd 启动时执行了类似 mount -a 的操作。你完全可以在运行中的系统里手动触发它，立刻拿到具体报错——比等重启、翻日志快得多。
执行后终端会直接输出错误，比如：
-
mount: /mnt/data: wrong fs type, bad option, bad superblock→ 文件系统类型不匹配或 superblock 损坏 -
mount: /mnt/data: no such device→ UUID 写错、设备已拔出、或 LVM/LUKS 未激活 -
mount: /mnt/data: mount point does not exist→ 第二列路径（如/mnt/data）还没创建 - 无输出但实际没挂上 → 该行含
noauto，或第六列pass字段不是数字（如误写成defaults）导致整行被跳过
用 blkid 和 lsblk -f 核对设备真实状态
fstab 第一列（设备标识）和第三列（TYPE）必须与当前设备实际输出严格一致，大小写、引号、空格都不能差。
运行 sudo blkid，看目标设备输出，例如：
/dev/sdb1: UUID="a1b2-c3d4" TYPE="ext4"
那么 fstab 中必须写 UUID=a1b2-c3d4 和 ext4，不能写 Ext4 或 EXT4，也不能漏掉 UUID= 前缀。
- NVMe 盘注意后缀：
/dev/nvme0n1p1是分区，/dev/nvme0n1是整盘，后者不能挂载 - LVM 逻辑卷要先
vgscan && vgchange -ay，再确认lvscan有输出，fstab 才能写/dev/mapper/vg0-lv_data - LUKS 加密卷 fstab 必须用解密后的映射名（如
/dev/mapper/crypt-data），且/etc/crypttab已正确定义 - NFS/CIFS 必须在第四列选项中包含
_netdev，否则mount -a会因网络未就绪超时失败
查 dmesg 和 journalctl 获取内核级线索
当 mount -a 报错模糊（比如只说 wrong fs type），或挂载后 df -h 看不见，就得看内核和 systemd 日志。
-
dmesg | tail -20：重点看是否有EXT4-fs error、NTFS: failed to load $MFT、device-mapper: reload ioctl failed这类底层报错 -
journalctl -xe | grep -i "mount\|failed"：过滤 systemd 挂载单元的启动日志，常暴露mnt-data.mount: Mount process exited, code=exited status=32这类具体退出码 - 若怀疑文件系统损坏，先
umount /dev/sdb1（确保未挂载），再运行e2fsck -f /dev/sdb1（ext4）或xfs_repair /dev/sdb1（xfs）
检查挂载点目录和 SELinux 上下文
挂载点本身的问题常被忽略：目录不存在只是表象，权限、嵌套挂载、SELinux 策略才是深层原因。
- 挂载点目录必须存在且非只读：
ls -ld /mnt/data确认权限是drwxr-xr-x类型；若父目录（如/mnt）是只读，子目录也无法挂载 - 挂载后
ls /mnt/data为空？先运行findmnt /mnt/data，它比df更准，能发现是否被其他挂载遮蔽（比如 NFS 已挂到/mnt，新挂载被覆盖） - SELinux 可能静默拒绝：
setenforce 0临时关闭，若此时挂载成功，说明是上下文问题；用restorecon -Rv /mnt/data重置上下文，或加context="system_u:object_r:default_t:s0"到 fstab 选项中
真正卡住的地方往往不在设备本身，而在挂载点路径的层级依赖、fstab 第六列 pass 字段的数值合法性，或者网络存储缺 _netdev 导致 systemd 启动时直接跳过整行——这些细节不报错，但会让配置形同虚设。
