直接运行sudo mount -a可立即暴露fstab配置错误，如设备不存在、文件系统类型不匹配、挂载点未创建、noauto或pass字段非法等，比重启查日志更快更准。
直接运行 mount -a 拿到最准的错误信息
系统启动时挂载失败，本质就是 systemd 执行了 mount -a。你完全可以在运行中手动触发它，立刻看到和开机一模一样的报错——比翻日志快得多，也比等重启更可控。
执行：sudo mount -a
终端会直接输出具体错误，比如：
-
mount: /mnt/data: wrong fs type, bad option, bad superblock→ 文件系统类型写错、选项非法，或 superblock 损坏 -
mount: /mnt/data: no such device→ UUID 或设备路径不对，或设备根本没识别到 -
mount: /mnt/data: mount point does not exist→ 第二列路径（如/mnt/data）还没mkdir -p创建 - 无声失败（无输出但没挂上）→ 可能该行含
noauto，或第六列pass字段不是数字（如误写成defaults），导致整行被 fstab 解析器跳过
查 /proc/mounts 确认当前真实挂载状态
/proc/mounts 是内核维护的原始挂载快照，比 mount 命令输出更权威，尤其当挂载被静默降级为只读时，mount 有时会漏掉 ro 标记。
快速提取某挂载点的选项字段：awk '$2 == "/mnt/data" {print $4}' /proc/mounts
如果输出含 ro（如 rw,relatime,ro），说明已被内核强制设为只读；若输出是 rw 或不含 ro，那问题不在挂载参数本身，得往硬件或文件系统损坏方向查。
用 dmesg 抓内核级错误线索
很多挂载失败的根本原因藏在内核日志里，比如 I/O 错误、ext4 journal abort、xfs write access disabled —— 这些不会出现在 mount -a 输出里，但会直接导致只读或挂载拒绝。
重点命令：dmesg -T | tail -30
搜索关键词：EXT4-fs error、XFS: write access disabled、sector、journal has been aborted
有这些就别急着重挂，先看 smartctl -a /dev/sdX 查坏道，或 tune2fs -l /dev/sdXN | grep "Filesystem state" 看是否已标记错误。
为什么 journalctl -xe 有时找不到挂载错误
journalctl -xe 默认只显示用户态服务日志，而挂载失败大多发生在内核或 systemd-fstab-generator 阶段，不一定被完整捕获。
更可靠的做法是加过滤：journalctl -b | grep -i "mount\|failed\|fstab"
但注意：如果 fstab 某行含 nofail，systemd 会把失败当作“预期行为”而不记 error 级日志，此时 mount -a 和 dmesg 才是唯一可信来源。
真正容易被忽略的是：错误代码本身不重要，关键看它是来自内核（dmesg）、解析器（mount -a 语法报错）、还是服务依赖（_netdev 未就绪）。三者排查路径完全不同，混着查只会绕远路。
