查内核启动报错需分清早期硬件/驱动问题与systemd启动后异常；先验证日志持久化，再用dmesg查原始内核环缓冲区，辅以journalctl -k分析systemd接管后的内核日志，并交叉比对时间线与设备行为。
查内核启动报错，核心是分清两个层次：一是 内核早期硬件/驱动问题（journald 还没启动时就发生了），二是 systemd 启动后加载内核模块或设备时的异常。两者日志来源不同，命令组合也不同。
先确认日志是否可回溯
很多“查不到报错”其实是日志根本没存下来。三步快速验证：
- 运行
sudo journalctl --disk-usage：输出非零（如89.2M）说明/var/log/journal/持久化已启用 - 运行
journalctl --list-boots：能看到多行记录（如-2、-1、0），代表每次重启都被独立标记 - 运行
journalctl -b -1 -k | head -n 5：输出里有早于systemd[1]: Starting的时间戳（如Jun 28 07:11:02），说明 early kernel log 可见
用 dmesg 抓最原始的内核错误
这是第一动作，因为 dmesg 直接读取内核环缓冲区，覆盖从 GRUB 交权开始的全部早期信息，journalctl -k 会丢失部分早期日志。
-
dmesg -T -l err,warn：加人类时间戳 + 精准过滤错误和警告，比grep -i error更可靠（有些 err 级日志正文不含 “error” 字样） -
dmesg -l err,warn --since "5 minutes ago"：查最近 5 分钟的内核级异常，适合刚重启完的排查 - 若
dmesg输出极短或为空，说明内核可能根本没跑起来（如 initramfs 解包失败、根文件系统找不到），需回头检查 GRUB 或 initrd
用 journalctl -k 查 systemd 管理下的内核日志
当 journald 已启动后，journalctl -k 是它的快捷方式，等价于 journalctl _TRANSPORT=kernel，适合看驱动 probe、ACPI、firmware 类报错。
-
journalctl -b -k --no-pager | grep -i "fail\|oops\|panic\|taint"：快速抓关键异常 - 特别注意
Tainted:行（如kernel: Tainted: P OE 6.8.0-45-generic），P=专有模块、O=非主线驱动，是稳定性隐患信号 -
journalctl -k -p err..warn -b：只看当前启动的内核错误与警告，不混入服务日志
交叉比对时间线与设备行为
真正卡点常出现在“内核说设备就绪了，但服务却等不到它”。需要把内核日志和服务日志串起来看：
- 先在
journalctl -b -k中搜索关键设备名（如nvme0n1、enp0s31f6），确认它何时被识别、是否有probe fail - 再查对应服务（如
mnt-data.mount或systemd-networkd）是否在设备出现后才启动 - 用
journalctl -b --since "2026-10-12 08:22:00" --until "2026-10-12 08:22:30"锁定可疑时间窗，同时翻内核和服务日志
