journalctl -k 默认只显示当前内核环缓冲区快照，非完整启动日志；查启动错误须用 journalctl -b -k，并确保持久化日志启用、ring buffer 足够大、early console 可用。

journalctl -k 显示的是内核环缓冲区，不是完整启动日志

journalctl -k 输出等价于 dmesg，它读取的是内核 ring buffer（环形缓冲区）当前内存中的快照。这个缓冲区大小有限（通常几 MB），且只保留最近的内核消息 —— 也就是说，系统刚启动时的早期报错如果被后续日志覆盖，journalctl -k 就看不到了。真正要查“启动那一刻”的内核错误，得结合启动会话和持久化日志。

查启动阶段内核报错，必须加 -b 参数

每次系统启动都会被 systemd-journald 记录为一个独立的 boot session。-b 是关键开关：

• journalctl -b -k：查看本次启动的内核日志（含 early boot 阶段，只要没被刷掉）
• journalctl -b -1 -k：查看上一次启动的内核日志（排查重启后消失的报错）
• journalctl -b 0 -k 和 journalctl -b -k 效果一样，0 表示当前 boot

注意：-b 必须和 -k 同时用才有意义；单独 journalctl -k 不带 -b，就只是当前内存里还剩的那点内核消息，跟启动过程无关。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

为什么有些启动报错始终看不到？三个常见原因

即使用了 journalctl -b -k，仍可能漏掉早期错误，主要卡在以下环节：

• 日志未持久化：默认 /run/log/journal/ 是内存文件系统，重启即丢；必须启用 /var/log/journal/ 持久存储，否则 -b -1、-b -2 全是空的
• ring buffer 太小：内核启动初期大量驱动 probe 日志会快速填满缓冲区，早期 panic 或 oops 可能被覆盖；可通过内核参数 log_buf_len=4M 加大（需改 grub 配置）
• early console 未启用：某些硬件初始化失败发生在 console 初始化之前，连 ring buffer 都没机会记 —— 这类问题只能靠串口日志或 BIOS/UEFI 日志定位

快速验证是否能查到历史启动内核错误

执行这三步，立刻判断环境是否就绪：

• 运行 sudo journalctl --disk-usage：输出非零值（如 Archived and active journals take up 124.0M），说明持久化已生效
• 运行 journalctl --list-boots：能看到多行输出（如 -1 23a7e8f... Wed 2026-04-19 09:22:11 CST），说明 boot session 被记录了
• 运行 journalctl -b -1 -k | head -n 5：有输出且时间戳早于系统启动时间（比如 Apr 19 09:22:05 出现在 systemd[1]: Starting... 之前），说明 early kernel log 可见

这三个检查中任意一个失败，journalctl -k 就不具备诊断启动错误的能力 —— 别花时间翻日志，先修配置。