查内核引导日志和服务启动轨迹需先验证日志持久化：运行sudo journalctl --disk-usage、journalctl --list-boots、journalctl -b -1 -k | head -n 5三步确认；再分层过滤——用journalctl -b -k查硬件驱动异常，journalctl -u service -b查服务依赖与执行链，并结合时间窗与设备名交叉比对内核与服务日志。
查内核引导日志和服务启动轨迹，关键不是“看多少”，而是“锁定哪一次启动”+“分层过滤”。journalctl -b 是起点，但直接跑它常漏掉早期硬件问题或服务跳过执行的真实原因。
先确认日志能回溯历史启动
很多报错查不到，不是命令用错，是日志根本没存下来。三步快速验证：
- 运行 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 可见
任意一步失败，journalctl -b -k 就不具备诊断价值——后续所有分析都建立在日志可回溯基础上。
分两层看：内核引导阶段 vs 用户空间服务启动
内核引导阶段（-k + -b）关注硬件识别、驱动加载、固件异常：
- 用 journalctl -b -k --no-pager | grep -i "fail\|oops\|panic\|taint" 快速抓异常
- 特别留意 Tainted: 行（如 kernel: Tainted: P OE 6.8.0-45-generic），P=专有模块，O=非主线驱动，是稳定性隐患信号
- ACPI Error、UEFI firmware bug 这类报错基本要升级 BIOS 或加 acpi=off 等内核参数
用户空间服务启动（-u + -b）看依赖是否就绪、脚本是否执行、权限是否拦截：
- 查具体服务：journalctl -u myapp.service -b，从 Starting... 到 Started/Failed 全链路可见
- 查前置依赖：journalctl -u network.target -b 或 journalctl -u local-fs.target -b，判断是否因网络未就绪导致服务跳过启动
- 查 SELinux 拦截痕迹：journalctl -b | grep avc
用时间线把内核和服务串起来
单纯分开看容易断层。真正卡点往往出现在“内核说设备就绪了，但服务却等不到它”：
- 先找关键设备名（如 nvme0n1、enp0s31f6），在 journalctl -b -k 中确认它何时被识别、是否有 probe fail
- 再查对应服务（如挂载单元 mnt-data.mount 或网卡管理服务 systemd-networkd）是否在设备出现后才启动
- 用 journalctl -b --since "2026-07-08 07:22:00" --until "2026-07-08 07:22:30" 锁定可疑时间窗，交叉比对内核和服务日志
对比 dmesg 和 journalctl -k 的差异
两者都读内核 ring buffer，但行为逻辑不同：
- dmesg 是快照式读取，只反映当前内存中残留的日志；重启后清空，适合查“现在还能看到什么”
- journalctl -k 默认也是快照，但加 -b 才关联到某次 boot session；它依赖 journald 持久化能力，适合查“那次启动到底发生了什么”
- 如果 dmesg 有报错而 journalctl -b -k 没有，大概率是日志未持久化或 ring buffer 被覆盖；反之说明该消息已被刷出 buffer，但 journald 提前捕获并存档了
