要查看最近一次系统崩溃日志，需先确认journal持久化已启用（检查/var/log/journal/或Storage=persistent），再用journalctl --list-boots定位倒数第二次启动（-b -2），结合grep筛选panic、oops、watchdog等关键词及error级别日志分析。
要查看最近一次系统崩溃的日志，关键是用 journalctl 定位到崩溃前后的日志时间段，并筛选出内核、systemd 或 panic 相关的关键信息。Linux 的 systemd journal 会记录从启动到关机（或崩溃）的完整日志，只要崩溃后能正常重启并保留日志（默认启用持久化），就可以回溯分析。
确认 journal 持久化已启用
默认情况下，journal 日志只保存在内存中（/run/log/journal），重启后丢失。要查“最近一次崩溃”，必须确保日志持久化开启：
- 检查目录是否存在：
ls /var/log/journal/，若存在且有子目录，说明已启用持久存储 - 若不存在，启用它：
sudo mkdir -p /var/log/journal，然后重启 journald：sudo systemctl restart systemd-journald - 也可检查配置：
cat /etc/systemd/journald.conf | grep Storage，确认Storage=persistent
定位崩溃发生的时间点
崩溃通常伴随 abrupt shutdown（如无正常关机日志）、内核 panic、oops 或 watchdog timeout。先找最近两次启动的边界：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 列出所有 boot 记录：
journalctl --list-boots，输出类似：
-2 8a1f... Wed 2024-04-10 14:22:03 CST — Wed 2024-04-10 14:27:15 CST
-1 9b2e... Wed 2024-04-10 14:27:30 CST — Thu 2024-04-11 09:15:02 CST
其中倒数第二行（-2）很可能是崩溃前的那次启动 - 用 boot ID 查看该次启动的末尾日志：
journalctl -b -2 --no-pager | tail -n 50，重点观察最后几条是否含kernel: Kernel panic、watchdog: BUG、Oops或突然中断的 systemd 单元状态
筛选崩溃相关的关键日志
直接搜索典型崩溃线索，提高排查效率：
- 查内核 panic/oops：
journalctl -b -2 | grep -i "panic\|oops\|BUG\|watchdog\|die\|unable to handle" - 查硬件或驱动异常：
journalctl -b -2 -p 3 --no-pager（只显示 error 及以上级别日志） - 查 systemd 在崩溃前的最后动作：
journalctl -b -2 | grep -E "(Stopping|Stopped|Starting|Started).*\.service" | tail -n 20，看是否有服务卡住或失败 - 结合时间范围缩小：如果知道大致崩溃时间，可用
--since "2024-04-10 14:25:00"和--until "2024-04-10 14:27:00"
导出和进一步分析
把可疑日志保存下来，方便离线查看或提交给支持团队：
- 导出完整崩溃前启动日志：
journalctl -b -2 --no-pager > crash-boot.log - 提取内核环缓冲区（dmesg）快照：
journalctl -b -2 -k > kernel-crash.log（-k仅限 kernel messages） - 若系统启用了 kdump 或 crash kernel，还可检查
/var/crash/下的 vmcore 文件（需额外配置）
