崩溃后第一时间应查/var/log/kern.log.1.gz，因/var/log/kern.log常被轮转而丢失panic线索；用zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic"优先检索。
崩溃后第一时间该看哪个文件
系统重启后，/var/log/kern.log 通常已被轮转，直接 cat /var/log/kern.log 很可能看不到 panic 线索。优先查压缩归档：zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic"。如果没找到，再试 .2.gz 或更早的；别依赖 journalctl -k -b -1——rsyslog 若未启用 imkmsg 模块，panic 那一瞬的日志根本不会进 journal。
dmesg 输出全是噪音，怎么揪出真正崩溃点
dmesg 默认混着启动日志、驱动 probe、热插拔事件，真正的崩溃线索往往只占几行。用这条命令过滤关键信号：dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"。-T 加时间戳，-A 20 向下取完整调用栈，-B 5 往上抓前兆（比如 end_request: I/O error 或 slab_out_of_memory）。注意：最早那条匹配行才是源头，后面可能是 panic 触发的连锁刷屏。
crash 命令报 “cannot determine vmcore type” 怎么办
这个错误说明 vmcore 文件本身无效，不是工具配错的问题。分三步验证：
- 检查文件类型：
file /var/crash/*/vmcore输出必须含ELF 64-bit LSB core file x86-64；若显示data或empty，说明捕获失败 - 确认 crashkernel 生效：
grep crashkernel /proc/cmdline必须有非空输出（如crashkernel=128M@64M） - 确保 kdump 服务真在跑：
systemctl status kdump状态要是active (running)，且日志里没有Failed to start Kdump Crash Kernel
crash 进去后 bt 命令全是 ??，vmlinux 路径对了还是不行
常见原因不是路径错，而是调试符号不匹配。重点检查：
-
uname -r输出的内核版本号，必须和/usr/lib/debug/lib/modules/下对应目录名**完全一致**（包括 .el8、-generic 等后缀） - RHEL/CentOS：装
kernel-debuginfo-$(uname -r)；Ubuntu/Debian：先配置ddebs.ubuntu.com源，再装linux-image-$(uname -r)-dbgsym - 用
file /usr/lib/debug/lib/modules/$(uname -r)/vmlinux确认它是带调试信息的 ELF，不是 stripped 版本
vmcore 和 vmlinux 的架构、位数、编译选项（如 CONFIG_DEBUG_INFO_DWARF4）必须严丝合缝，差一点，bt 就只能打印地址偏移。
