必须匹配当前内核版本，crash依赖完全一致的vmlinux（带调试符号）才能启动和解析vmcore；否则报“no debug info”或“version mismatch”，且vmlinux不可用/boot/vmlinuz替代。
crash 工具安装必须匹配当前内核版本
不装对版本的 crash 和调试符号，连启动都报错，更别说解析 vmcore。常见错误是 crash: /usr/lib/debug/lib/modules/$(uname -r)/vmlinux: no debug info 或 version mismatch。
-
crash本身是通用二进制，但依赖与运行内核**完全一致**的vmlinux文件（带调试符号） - Debian/Ubuntu：运行
apt install linux-image-$(uname -r)-dbg；若提示包不存在，先查apt search "linux-image-$(uname -r)-dbg"确认准确包名 - RHEL/CentOS：执行
yum install kernel-debuginfo-$(uname -r)；注意该包通常不在 base repo，需启用debuginfo或crb源 - 验证关键文件是否存在：
ls -l /usr/lib/debug/lib/modules/$(uname -r)/vmlinux—— 必须存在且非空
启动 crash 时路径和参数不能写错
命令行输错一个斜杠或漏掉 vmlinux，crash 就会默认读取实时内存（需要 root），而不是你辛苦生成的 vmcore。
Python Linux版
下载
Python Linux版 为 Python.org 官方提供的 Python 3.14.6 Linux/Unix 源码包，适合在Linux/Unix环境中安装、运行 Python 代码并学习函数、模块和脚本开发。
- 标准命令格式是：
crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore -
vmlinux路径必须指向带调试信息的未压缩内核镜像，不是/boot/vmlinuz-xxx（那是压缩过的，无符号） -
vmcore路径要确认真实位置：可能在/var/crash/$(date +%Y-%m-%d-%H:%M:%S)/vmcore，而非固定/var/crash/vmcore - 如果提示
cannot access memory，先用file /var/crash/vmcore确认文件是否为 valid ELF core dump；损坏或截断的vmcore无法加载
分析时常用命令别依赖自动补全
crash 的交互式命令没有 tab 补全，拼错就报 unknown command，但实际只需几个核心命令就能定位多数 panic 原因。
-
sys：看系统基本信息、CPU 数量、崩溃时间戳，确认是否真进了 crash 上下文 -
log：等价于dmesg，直接显示崩溃前最后几屏内核日志，常含Kernel panic或Oops前缀行 -
bt -a：显示所有 CPU 的回溯栈，重点看标有PANIC或CRASH的线程 -
ps：列出崩溃时刻所有进程状态，配合bt <pid></pid>可查特定进程栈 - 不要一上来就跑
runq或mount——这些在 vmcore 中未必能完整重建，优先看log和bt -a
符号缺失或架构不匹配时别硬试
某些情况 crash 启动成功但输出全是 ???，说明符号表没对上，继续分析只是浪费时间。
- 检查
crash输出首行是否含WARNING: kernel version—— 若版本号与uname -r不一致，说明vmlinux版本错了 - ARM64 或 RISC-V 机器上，确保
crash二进制支持该架构（file $(which crash)查看 target） -
vmcore是从不同内核（如升级后未重建 kdump initramfs）捕获的，vmlinux必须与捕获时的内核一致，不是当前uname -r - 临时办法：用
makedumpfile --dump-dmesg /var/crash/vmcore提取原始 dmesg，至少能看到 panic 字符串
crash 命令，而是 vmlinux 和 vmcore 这两个文件根本没对上版本或架构——它们得是同一台机器、同一内核、同一时刻的产物。
