dmesg 日志需聚焦设备初始化失败、内存异常、驱动报错三类信号，用 -t 加时间戳、-l err,warn 限级别、–since 限时间、按子系统（ata/nvme/usb等）过滤，并区分 dmesg 与 journalctl -k 的数据源差异。
怎么看 dmesg 输出里真正有用的那几行
内核日志动辄几千行，dmesg 默认输出全是噪音。关键不是“全看”，而是过滤出设备初始化失败、内存分配异常、驱动报错这几类信号。用 dmesg -T 加时间戳能快速定位问题发生时段；配合 dmesg | grep -i "Error|fail|warn" 是基础操作，但要注意：很多真实错误不带 error 字样，比如 nvme 0000:01:00.0: PCIe Bus Error 这种就只写 “Bus Error”。
更可靠的做法是按子系统过滤：dmesg | grep -E "(ata|nvme|usb|pci|iommu)"，再结合 dmesg -l err,warn 只看错误和警告级别。别忘了加 --since "2024-05-20 14:30:00"（需 systemd）限定时间范围——重启后日志会被清空，但 dmesg 缓存里只保留最近一次启动的内容。
journalctl -k 和 dmesg 输出为啥不一样
因为 journalctl -k 读的是 journald 持久化后的内核日志，而 dmesg 直接读内核环形缓冲区（/dev/kmsg）。两者内容可能差几百行：journald 默认只保存部分日志，且受 Storage=volatile 或磁盘空间限制影响；dmesg 则只保留内核缓冲区当前容量（通常 64KB 左右），旧日志会被覆盖。
- 要查历史重启前的日志，必须用
journalctl -k --all --no-pager，并确认/var/log/journal/存在且未被systemd-journald清理 - 如果
journalctl -k空但dmesg有内容，说明 journald 没启用持久存储，改/etc/systemd/journald.conf中的Storage=persistent并重启systemd-journald -
dmesg -C会清空缓冲区——别在排查中误用，它不会影响 journal 日志
遇到 Kernel panic - not syncing: VFS: Unable to mount root fs 怎么快速定位
这错误意味着内核找不到或无法挂载根文件系统，不是驱动没加载就是 initramfs 里缺模块。先别急着重启，用 dmesg | tail -n 50 看 panic 前最后几十行，重点找三类线索：
- 是否有
dracut或initrd相关报错，比如modprobe: FATAL: Module xxx not found in Directory /lib/modules/... - 是否识别到了正确磁盘：搜
sd[a-z]或nvm[ae]，确认scsi/nvme驱动已加载，且设备路径（如/dev/nvme0n1p2）和root=内核参数一致 - 是否提示
Failed to find suitable root device—— 很可能是 initramfs 没包含lvm2或mdraid工具，得重做 initramfs（dracut -f或update-initramfs -u）
为什么 printk 日志级别调高了还是看不到驱动输出
内核日志有两级控制：一是 printk 的调用级别（KERN_ERR, KERN_INFO 等），二是当前控制台日志级别（/proc/sys/kernel/printk 第一个数字）。即使驱动用了 pr_info()，如果控制台级别设为 4（即只显示 KERN_ERR 及以上），那 info 就不会输出到终端或 dmesg 缓冲区。
- 临时提高：运行
sudo dmesg -n 8（8 = 最高，显示所有） - 永久生效需改
/etc/sysctl.conf加kernel.printk = 8 4 1 7，然后sysctl -p - 注意：某些驱动（如
vfio-pci）默认关闭详细日志，需加内核参数vfio-pci.enable_sriov=1 vfio-pci.disable_idle_d3=1或通过 debugfs 控制 - 别依赖
printk查高频事件——它本身有锁开销，大量调用会拖慢系统甚至掩盖真问题
内核日志不是文本搜索游戏，关键是把设备链路（PCIe → 总线驱动 → 设备驱动 → 文件系统）和日志级别、存储路径、时间窗口这四者对齐。漏掉任意一环，看到的都可能是断章取义的“证据”。