4、日志分析方法：dmesg、journalctl、/var/log/messages 中的挂载相关日志
大家好，我是老李。做Linux系统运维这些年，我最大的体会就是：日志是系统留给我们的最后一张底牌。启动挂载失败，说白了就是系统在启动时没找到它想要的东西——要么设备没准备好，要么文件系统坏了，要么配置写错了。
那怎么查？三个工具：dmesg、journalctl、/var/log/messages。今天我就把这几个家伙怎么用、怎么看、怎么定位问题，掰开了讲清楚。
核心思路：挂载失败时，系统一定会报错。日志就是错误的第一现场。你只要知道去哪找、怎么过滤，问题就解决了一半。
4.1 dmesg：内核的“实时监控”
dmesg 是内核日志的环形缓冲区。说白了，它记录的是内核启动以来所有的“大事小情”——包括硬件检测、驱动加载、文件系统挂载。我个人习惯，遇到挂载问题，第一个命令就是 dmesg | grep -i mount。
为什么？因为挂载操作最终是由内核完成的。用户空间的 mount 命令只是发了个请求，真正干活的是内核。内核干没干成，都会在 dmesg 里留下痕迹。
常用过滤命令
# 查看所有挂载相关日志
dmesg | grep -i mount
# 查看文件系统错误
dmesg | grep -i "ext4\|xfs\|btrfs\|ntfs"
# 查看块设备状态
dmesg | grep -i "sda\|sdb\|nvme"
# 查看超时或I/O错误
dmesg | grep -i "timeout\|error\|fail"我在项目中遇到过一台服务器，重启后 /data 分区死活挂不上。用 dmesg | tail -50 一看，最后几行写着：
[ 3.456789] EXT4-fs (sdb1): INFO: recovery required on readonly filesystem
[ 3.456812] EXT4-fs (sdb1): write access unavailable, cannot proceed嗯，看到没？文件系统需要恢复，但因为是只读挂载，没法写日志。这就是典型的“非正常关机后，文件系统标记为 dirty，需要 fsck”。
小技巧： dmesg -T 可以把时间戳转成人类可读的时间格式。不过要注意，有些老版本内核不支持这个参数。
4.2 journalctl：systemd 时代的“全能日志”
现在大部分发行版都用 systemd 了。journalctl 就是 systemd 的日志管理工具。它比 dmesg 更全面——不仅包含内核日志，还包含用户空间的服务日志、应用日志。
我个人觉得，journalctl 最大的好处是：可以按时间、按服务、按优先级过滤。你想想看，启动挂载失败，肯定是发生在启动阶段。那我们就只看启动时的日志。
常用命令
# 查看本次启动的所有日志
journalctl -b
# 查看上一次启动的日志（如果这次起不来）
journalctl -b -1
# 只看挂载相关的服务
journalctl -u systemd-fsck@.service
journalctl -u local-fs.target
# 只看错误级别以上的日志
journalctl -p err -b
# 实时跟踪日志（类似 tail -f）
journalctl -f有一次，一个同事说服务器重启后 /home 分区没挂上。我让他跑 journalctl -u home.mount -b，结果输出是：
-- Unit home.mount has failed
-- Mount process exited with code 32
-- mount: /home: wrong fs type, bad option, bad superblock on /dev/sdc1看到“wrong fs type”了吗？这就是典型的 /etc/fstab 里文件系统类型写错了。比如实际是 ext4，你写成了 xfs。
注意： journalctl 默认只保留最近几次启动的日志。如果系统重启次数太多，旧日志会被覆盖。我建议你设置 SystemMaxUse=500M 来增大日志容量。
4.3 /var/log/messages：传统但可靠
虽然 journalctl 很强大，但 /var/log/messages 依然是我排查问题时必看的文件。为什么？因为它是一个纯文本文件，用 grep、awk、sed 随便处理，非常灵活。
而且，有些老系统（比如 CentOS 6）没有 systemd，只能用 /var/log/messages。你想想看，如果你接手一个跑了十年的老服务器，不会用这个文件怎么行？
常用命令
# 查看挂载相关日志
grep -i mount /var/log/messages
# 查看文件系统错误
grep -i "ext4\|xfs\|btrfs" /var/log/messages
# 查看磁盘错误
grep -i "sda\|sdb\|I/O error" /var/log/messages
# 查看最近10条日志
tail -10 /var/log/messages我曾经遇到一个案例：服务器启动时 /var 分区挂载失败，导致系统进入 emergency mode。用 grep -i "var" /var/log/messages 一看，发现日志里反复出现：
Feb 15 10:23:45 server kernel: EXT4-fs (sda3): VFS: Can't find ext4 filesystem
Feb 15 10:23:45 server kernel: EXT4-fs (sda3): VFS: Can't find ext4 filesystem嗯，这说明 /dev/sda3 上根本就不是 ext4 文件系统。后来查出来是磁盘分区表被误改了，分区类型变成了 0x83（Linux），但实际内容是 LVM 的 PV。
避坑指南： 我曾经因为 /var/log/messages 被日志轮转覆盖了，导致查不到历史记录。后来我养成了一个习惯：遇到问题先备份日志。命令很简单：cp /var/log/messages /var/log/messages.bak.$(date +%Y%m%d)
4.4 三种日志的对比与选择
| 工具 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| dmesg | 内核级问题（驱动、硬件、文件系统） | 实时、简洁、直接 | 只保留内核日志，不包含用户空间 |
| journalctl | systemd 服务、应用日志 | 功能全面、过滤强大 | 日志可能被轮转覆盖 |
| /var/log/messages | 传统系统、通用排查 | 纯文本、易处理、历史久 | 文件可能很大，搜索慢 |
我个人习惯是：先用 dmesg 看内核有没有报错，再用 journalctl 看服务状态，最后用 /var/log/messages 做交叉验证。三个工具配合使用，基本没有查不到的挂载问题。
4.5 实战：一个完整的排查流程
假设你遇到一个场景：服务器重启后，某个分区没挂上。你会怎么做？
- 第一步：确认现象
df -h看看哪个分区没挂上。比如 /data 不见了。 - 第二步：查 dmesg
dmesg | grep -i "data\|mount\|error"看看内核有没有报错。 - 第三步：查 journalctl
journalctl -u data.mount -b看看挂载服务的具体错误。 - 第四步：查 /var/log/messages
grep -i "data\|mount" /var/log/messages | tail -20看看有没有更多上下文。 - 第五步：检查 /etc/fstab
cat /etc/fstab看看配置有没有写错。 - 第六步：手动尝试挂载
mount /dev/sdb1 /data看看报什么错。
这个流程我用了十年，从来没失手过。你想想看，日志就是系统的“黑匣子”，只要你会读，问题就藏不住。
最后说一句： 别怕日志多。用 grep 过滤、用 tail 看最后几行、用 less 翻页。慢慢你就发现，日志其实很有规律。看多了，一眼就能看出问题在哪。
这张图就是我平时排查挂载问题的标准流程。从上到下，一步接一步。你只要照着做，90% 的问题都能在 5 分钟内定位到。
好了，关于日志分析的方法就讲到这里。记住：日志不会骗人，骗人的是你没看对地方。下次遇到挂载失败，别慌，先打开这三个日志文件看看。