kdump捕获vmcore需满足三前提：crashkernel内存预留成功、捕获内核正常加载、转储路径可写且空间充足；现代系统推荐分段式crashkernel参数（如crashkernel=0m-2g:0m,2g-8g:192m,8g-:256m），避免auto或固定值引发的兼容性与启动失败问题。
能用 kdump 捕获 vmcore，前提是 crashkernel 内存预留成功、捕获内核能正常加载、转储路径可写且空间充足——三者缺一不可。生产环境里多数失败不是因为配置漏项，而是内存预留冲突或 initramfs 未重建。
crashkernel= 参数怎么设才不踩坑
别直接写 crashkernel=256M。现代系统（尤其是 >8G 内存）建议用分段式表达，比如 crashkernel=0M-2G:0M,2G-8G:192M,8G-:256M。原因有二：
-
crashkernel=auto在某些 ARM64 或 Alibaba Cloud Linux 3 环境中可能触发小页映射，导致捕获内核访问内存变慢，影响转储成功率 - 硬写固定值（如
crashkernel=256M）在低内存机器上会直接失败：内核启动时发现物理内存不足， silently 忽略该参数，/sys/kernel/kexec_crash_size返回 0 - 修改后必须更新 GRUB 并重启，仅
grubby修改不生效；Alibaba Cloud Linux 3 还需检查/usr/share/alinux-base-setup/cmdline
验证是否生效，运行：
cat /proc/cmdline | grep crashkernel
再确认预留大小：
cat /sys/kernel/kexec_crash_size
返回非零值（如
268435456）才表示 256MB 确实被预留。
/etc/kdump.conf 修改后为什么没反应
/etc/kdump.conf 不是热加载配置。任何涉及存储路径、压缩方式、网络挂载的变更，都必须重建 initramfs 才能让捕获内核识别新设置。
- Debian/Ubuntu：运行
update-initramfs -u -k $(uname -r) - RHEL/CentOS/Alibaba Cloud Linux：运行
dracut -f - 改完不重建，
kdumpctl restart看似成功，但崩溃时仍按旧 initramfs 行为执行——比如写到/var/crash而你已改成 NFS，结果就是 vmcore 丢在本地磁盘根目录下找不着 - 注意：若只修改
KDUMP_COMMANDLINE_APPEND这类纯命令行参数（在/etc/sysconfig/kdump），则无需重建 initramfs
手动触发崩溃后没生成 vmcore 怎么排查
执行 echo c > /proc/sysrq-trigger 后系统重启，但 /var/crash（或你配置的路径）为空，常见断点如下：
- 捕获内核根本没起来：检查
dmesg | grep -i "kdump\|kexec"，若看到"Failed to load kdump kernel"或"No memory for crash kernel"，说明crashkernel预留失败或地址冲突 - initramfs 缺少必要模块：NFS 路径需
add_driver nfs和add_drivers ext4；LVM 路径需add_lvmmodules，否则捕获内核无法挂载目标文件系统 - 权限或磁盘满：捕获内核以 root 运行，但目标路径父目录若为
noexec或nosuid挂载，makedumpfile可能静默失败；df -h查看目标分区剩余空间，vmcore原始大小 ≈ 当前物理内存容量 - SELinux 限制：RHEL/CentOS 上若启用 enforcing 模式，需确保
sestatus输出为 permissive，或临时setenforce 0测试
分析 vmcore 时 crash 工具报错的典型场景
crash vmlinux vmcore 启动失败，90% 是符号文件不匹配或缺失：
-
"vmlinux: no debugging data available"：说明vmlinux是 stripped 版本。必须用带调试信息的内核镜像，通常位于/usr/lib/debug/lib/modules/$(uname -r)/vmlinux（RHEL/CentOS）或/usr/lib/debug/boot/vmlinux-$(uname -r)（Ubuntu） -
"vmcore: cannot determine dump level"：vmcore文件损坏或被截断，检查生成时磁盘是否满、是否用了core_collector makedumpfile -c但makedumpfile版本太老不兼容当前内核 -
"page table is not available"：常见于 ARM64 系统，需确认vmlinux是否包含vmcoreinfo数据，可用readelf -n vmlinux | grep VMCOREINFO验证 - 别用
crash自带的bt直接看栈——先输log看最后一段 panic 日志，它比栈更早暴露触发点（如"BUG: unable to handle kernel NULL pointer dereference"）
最易被忽略的是：vmcore 和 vmlinux 必须来自同一内核构建批次。哪怕只是 make modules_install 覆盖了部分模块，vmlinux 符号偏移也可能错位，导致 crash 解析出完全错误的栈帧。
