真正崩溃线索是含“Kernel panic”“Oops”“BUG:”或“Call Trace:”的日志段落，需用dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"定位源头；panic需kdump捕获，依赖crashkernel内存预留、非零/proc/sys/kernel/panic值及匹配的vmlinux符号文件。
怎么看 dmesg 里真正的崩溃线索，而不是被刷屏的驱动噪音
内核崩溃（panic）或严重异常（oops）发生后，dmesg 是第一手信息源，但默认输出混着大量无关的初始化日志和可恢复警告。真正关键的是带 Kernel panic、Oops、BUG: 或 Call Trace: 的段落。
实操建议：
- 用
dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)"定位时间戳对齐的上下文，-T避免靠uptime换算 - 别直接信
dmesg最后几行——有些 panic 会触发多次 log buffer 刷写，最早那条才是源头 - 如果系统已重启，
/var/log/kern.log可能被轮转覆盖，优先查/var/log/kern.log.1.gz或启用rsyslog的imkmsg模块持久化原始内核消息 -
Call Trace:后面的地址是符号化前的偏移，没加载对应vmlinux或debuginfo包时，无法还原函数名，这点常被忽略
如何让 kerneloops 和 abrt 真正捕获到 panic 而不是静默失败
很多发行版默认装了 kerneloops 或 abrt，但它们默认不处理 kernel panic——因为 panic 发生时内核已无法安全执行用户态进程，必须依赖硬件/固件级机制（如 kdump）或提前触发的守护进程。
实操建议：
-
kerneloops只捕获oops（可恢复错误），对panic无效；确认它是否在运行：systemctl status kerneloops，但别指望它报 panic -
abrt默认监听systemd-coredump，而内核 panic 不产生 core 文件；要让它介入，需配合kdump：配置好kdump后，abrt才能解析生成的vmlinux+vmcore - 检查
/proc/sys/kernel/panic值，若为0，panic 后内核会停机而非自动触发 kdump；应设为非零值（如10表示 10 秒后重启，并留给 kdump 时间） -
kdump服务启动失败很常见，典型原因是预留内存不足（crashkernel=参数太小）或 initramfs 未包含kdump工具链
kdump 生成的 vmcore 怎么快速确认是不是有效崩溃转储
vmcore 文件体积大（常数 GB），但可能只是空壳：比如 kdump 服务没起来、内存镜像写入失败、或 crashkernel 内存被其他模块占用导致截断。
实操建议：
- 先用
file /var/crash/*/vmcore看类型，正常应输出类似ELF 64-bit LSB core file x86-64；若显示data或empty，基本无效 - 用
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore进入交互模式，立刻输bt—— 如果报cannot determine vmcore type或卡住，说明符号或内存布局不匹配 - 检查
/var/crash/*/vmcore-dmesg.txt是否存在且含Kernel panic字样；没有这个文件，大概率 dump 过程本身失败了 - 注意
vmlinux必须和崩溃时运行的内核版本**完全一致**（包括 build id），用rpm -qf /usr/lib/debug/lib/modules/$(uname -r)/vmlinux核对是否安装了对应 debuginfo 包
为什么 sysctl.conf 里加了 kernel.sysrq = 1 还是没法手动触发 crash dump
sysrq 是调试利器，但 Alt+SysRq+c（触发 panic）或 Alt+SysRq+d（dump）能否生效，取决于多个开关是否同时打开，缺一不可。
实操建议：
-
kernel.sysrq必须设为1或位掩码（如438），但仅此不够；还需确认/proc/sys/kernel/sysrq运行时值确实为非零（有时 systemd 会覆盖 sysctl.conf） - 某些云环境（AWS EC2、Azure VM）或安全加固策略（如 SELinux enforcing + deny_sysrq）会彻底禁用 sysrq，
cat /proc/sys/kernel/sysrq返回0即使配置写了1 - 物理机上按
SysRq键前，必须先按住Alt+Print Screen（不是Ctrl！），再松开并按功能键（如c）；顺序错或按键时间太短都无效 - 触发
Alt+SysRq+c后，若机器没立即 panic，可能是内核编译时关了CONFIG_MAGIC_SYSRQ，或启用了CONFIG_KEXEC_CORE但没配kdump，此时 panic 仍会发生，但不会自动生成 vmcore
最麻烦的其实是符号匹配——同一内核版本，不同编译参数（CONFIG_DEBUG_INFO、CONFIG_DEBUG_INFO_DWARF4）产生的 vmlinux 无法互换。没这玩意儿，crash 工具连函数名都吐不出来，分析就只剩地址猜谜。
