先用 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 是当前。

Linux installer

先解析安全源，运行本地CLI安装、启动、卸载Linux桌面应用。用户请求时使用。

下载

按批次号查完整日志

• 查当前启动：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 是否在其后启动

不复杂但容易忽略。