先用 journalctl --list-boots 列出所有历史启动批次，再用 -b 指定批次查日志；负数表示更早启动，0 是上次，1 是当前；支持按 Boot ID 精确查询，并可分层查看内核、服务等日志以定位问题。
直接用 journalctl --list-boots 列出所有历史启动批次，再用 -b 指定批次查日志。关键不是“翻日志”，而是先锁定哪一次启动，再分层看内核和服务行为。
先列出所有历史启动批次
运行命令：
journalctl --list-boots
输出类似：
-2 Tue 2026-07-25 08:12:33 CST — Tue 2026-07-25 14:20:11 CST -1 Wed 2026-07-26 09:05:42 CST — Wed 2026-07-26 18:33:07 CST 0 Thu 2026-07-27 07:11:22 CST — Thu 2026-07-27 12:45:30 CST 1 Fri 2026-07-28 06:22:15 CST — Fri 2026-07-28 15:19:44 CST
每行代表一次独立引导（boot），负数是更早的启动，0 是上次，1 是当前。
按批次号查完整日志
- 查当前启动：
journalctl -b或journalctl -b 1 - 查上一次启动：
journalctl -b 0 - 查上上次启动：
journalctl -b -1
加--no-pager避免卡在分页器里，加--since "HH:MM"缩小范围更高效，例如：journalctl -b -1 --since "09:00" --until "09:15"
按 Boot ID 精确查（推荐用于长期归档或频繁重启场景）
Boot ID 是每次启动的唯一标识，比序号更稳定：
- 先提取某次的 ID：
journalctl --list-boots | grep "2026-07-26" | awk '{print $NF}' - 再用它查日志：
journalctl -b abcdef1234567890...
分层看内容，避免漏掉关键断层
- 看内核早期硬件问题：
journalctl -b -1 -k | grep -i "fail\|oops\|taint" - 看某服务是否真正执行：
journalctl -b -1 -u nginx.service - 对比设备就绪与服务启动时间：先找
nvme0n1在-k日志中出现的时间，再查mnt-data.mount是否在其后启动
不复杂但容易忽略。
