应使用dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"定位最早崩溃源头，-T加时间戳，-A 20取调用栈，-B 5抓前兆；系统重启后优先查/var/log/kern.log.1.gz，避免依赖不可靠的journalctl。
内核崩溃（Kernel Panic）发生后，日志不是“自动存好等你查”，而是极易丢失或混在海量输出里。关键不是找日志，而是找准那几行真正报错的原始线索，并确认它是否被完整捕获。
第一时间抓取 dmesg 中的有效崩溃段落
dmesg 默认输出包含大量启动和驱动日志，真正有用的只有 panic 或 oops 触发时的上下文片段。别翻最后几十行——最早出现的那条才是源头，后面可能是连锁刷屏。
- 运行 dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"：-T 加时间戳便于对齐，-A 20 向下提取完整调用栈（含函数地址），-B 5 向上抓前兆（如磁盘超时、内存分配失败）
- 若系统已重启，/var/log/kern.log 可能被轮转，优先查 /var/log/kern.log.1.gz：zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic"
- 慎用 journalctl -k -b -1：rsyslog 若未启用 imkmsg 模块，panic 瞬间日志根本不会进 journal，不可靠
确认串口或控制台是否留下临终快照
当服务器黑屏或无法 SSH 时，物理控制台、IPMI 或串口日志往往是唯一证据源。这些输出不依赖文件系统写入，可靠性更高。
- 检查是否配置了串口控制台：查看 /etc/default/grub 中是否有 console=ttyS0,115200n8；若有，用串口终端工具（如 minicom）回溯日志
- 云环境（如 Azure）直接通过门户打开「串行控制台」边栏，滚动到底部查找以 Kernel panic 或 Oops 开头的行
- 物理服务器可拍照记录控制台最后一屏——重点拍清 PC 地址、Call Trace 起始行和模块名（如 [nvidia]、[zfs]）
验证 kdump 是否成功捕获 vmcore 内存镜像
vmcore 不是“有文件就代表有效”。它是一块原始内存快照，类型错误、大小异常或符号缺失都会导致分析失败。
- 先用 file /var/crash/*/vmcore 查类型：正常应输出 ELF 64-bit LSB core file x86-64；若显示 data 或 empty，说明捕获失败
- 确认 crashkernel 预留生效：grep crashkernel /proc/cmdline 必须有非空输出（如 crashkernel=128M@64M）
- 检查服务状态：systemctl status kdump 应为 active (running)，且日志中无 Failed to start Kdump Crash Kernel
从 Call Trace 定位最可疑的模块或子系统
调用栈不是从上往下读，而是从最底端（panic 或 __warn）往上推，找到第一个非通用内核函数的位置。
- 看到 [nvidia]、[zfs]、[wireguard] 这类方括号模块名？90% 是第三方驱动问题，尤其内核升级后未重编译 ko 文件
- 连续出现 ext4_writepages、ext4_da_write_begin？重点查磁盘 SMART 状态：smartctl -a /dev/sda，并确认挂载选项是否含 data=journal
- 全是 mm_* 开头（如 mm_page_alloc、try_to_unmap）？结合 dmesg -T | grep -i "ecc\|correctable" 查硬件级内存故障
- 出现 unknown symbol 或 invalid opcode？内核模块版本不匹配，或 CPU 微码过旧，需查主板 BIOS 更新日志
