journalctl -b -1 看不到崩溃原因，首要原因是日志未持久化，/run/log/journal 为内存路径，断电或内核 panic 后日志丢失；需启用 /var/log/journal 持久存储并验证 disk-usage 非零，再结合 -k -r 查内核末尾日志，辅以 dmesg -T | tail -30 和 vmcore 分析。
journalctl -b -1 看不到崩溃原因？先确认日志是否持久化
默认 journalctl 不保存断电、内核 panic 后的日志，/run/log/journal/ 是内存路径，重启即丢。所以 journalctl -b -1 返回空或只有几行，大概率不是命令用错了，而是日志根本没存下来。
验证方式只有两个：journalctl --disk-usage 输出非 0B，且 ls /var/log/journal/ 能看到以机器 ID 命名的子目录。没看到？说明没启用持久化，立刻执行：
sudo mkdir -p /var/log/journalsudo systemctl restart systemd-journald
重启后，下次崩溃（或关机）才会被记录到磁盘。
内核级崩溃必须看 journalctl -b -1 -k -r
用户常误以为“系统崩溃”等于“服务挂了”，但真正导致自动重启的，90% 是内核层问题：panic、oops、MCE（machine check exception）、NVMe timeout。这些不会出现在普通 service 日志里，只在内核日志中。
journalctl -b -1 -k -r 是最有效的初筛命令——-k 限定内核消息，-r 倒序，让你一眼看到末尾最后几条记录。重点关注：
-
Kernel panic - not syncing（直接定性） -
Oops: 0000 [#1] SMP（驱动或模块异常） -
Hardware name:.*\nCall Trace:（后面跟着一串函数地址，说明已进入栈回溯） -
mce: CPU.*machine check或EDAC MC.*error（硬件报错）
如果这里什么都没出现，但系统确实无故重启，那更可能是电源掉电、主板复位或 BIOS 强制重启——这类事件 journalctl 根本不记录。
/var/crash/ 下有 vmcore 才能做深度分析
journalctl 只能告诉你“崩溃发生了”，但无法回答“为什么崩溃”。要定位到具体哪一行代码、哪个驱动函数触发 panic，必须依赖 kdump 生成的 vmcore 文件。
检查前提有三个，缺一不可：
-
grep crashkernel /proc/cmdline有输出（如crashkernel=256M@16M） -
systemctl status kdump显示active (running) -
ls /var/crash/有按时间戳命名的子目录，且里面含vmcore和dmesg.*
若有 vmcore，用 crash /var/crash/vmcore /usr/lib/debug/lib/modules/$(uname -r)/vmlinux 进入交互界面，再输入 bt 查看完整调用栈——这才是真正的“崩溃原因分析报告”源头。
别漏掉 dmesg -T | tail -30 的残留线索
即使启用了 journal 持久化，有些 panic 信息仍可能只留在内核环形缓冲区（ring buffer），没来得及刷进 journal。尤其在 panic 发生极快、系统瞬间重启时，journalctl 会漏掉关键几行。
此时运行 dmesg -T | tail -30（加 -T 显示可读时间戳），比翻 /var/log/kern.log 更可靠。常见有效线索包括：
-
[ 1.234567] ACPI Error:.*（固件兼容性问题） -
[ 45.678901] ata1.00: failed command: READ FPDMA QUEUED（硬盘故障前兆） -
[ 123.456789] nvme 0000:01:00.0: I/O 1234 timeout, aborting（NVMe 驱动或固件 bug）
这些行往往比 journalctl 里的更早、更原始，是硬件层问题的直接证据。
