修改kdump转储路径必须修改/etc/kdump.conf中的path项，该配置指定vmcore保存的绝对路径，且目标目录须预先存在、属主为root、权限755；修改后需重启kdump.service并验证生效。
修改kdump转储路径必须改/etc/kdump.conf中的path项
kdump生成的coredump默认存放在/var/crash，但这个目录常位于根分区，空间容易不足。真正起作用的是/etc/kdump.conf里的path配置行，不是GRUB参数或服务名。改错地方（比如只动crashkernel）会导致路径不变，但系统仍能启动kdump——只是文件全堆在默认位置。
-
path值必须是绝对路径，且目标目录需已存在、属主为root、权限为755 - 如果指定路径在非根分区（如
/mnt/data/crash），要确保该挂载点开机自动挂载（检查/etc/fstab） - 不要用符号链接路径；kdump不解析软链，会写入链接本身所在目录
core_collector参数影响转储文件大小和可读性
默认core_collector用makedumpfile -c -l -message-level 1 -d 31，其中-c启用压缩，-d 31过滤掉大量无用内存页。若你后续要用crash工具分析，建议保留-d 31；若想保留完整内存镜像（比如调试硬件问题），可删掉-d 31，但文件体积可能达数GB。
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 删掉
-c后，转储文件不压缩，/var/crash下会生成vmlinux和vmcore两个大文件 - 修改后必须重启
kdump.service才生效：sudo systemctl restart kdump.service - 验证是否加载新配置：
sudo kdumpctl status会显示当前path和core_collector
测试前务必确认crashkernel内存预留成功
即使path改对了，如果内核没预留内存，kdump根本不会触发——echo c > /proc/sysrq-trigger只会硬重启，不生成任何转储。关键看dmesg | grep -i crashkernel输出是否含crashkernel=128M及Reserving <x>M</x>字样。
-
GRUB_CMDLINE_LINUX里crashkernel=auto在CentOS 7上不可靠，必须显式写成crashkernel=128M或crashkernel=256M - 改完
/etc/default/grub后，一定要运行sudo grub2-mkconfig -o /boot/grub2/grub.cfg并重启 -
systemctl status kdump显示Active: active (exited)不代表就绪，要看journalctl -u kdump | tail -20里有没有Loaded kdump kernel
转储路径变更后常见失败现象和定位方式
最典型的错误是：手动触发crash后，/var/crash或你指定的路径下空空如也，但系统确实重启了。这说明kdump启动了捕获内核，但写入失败。
- 检查
/var/log/messages里是否有kdump: failed to copy vmcore或Permission denied——多半是目录权限不对或磁盘满 - 用
sudo kdumpctl debug可模拟一次完整流程，输出详细日志到控制台，比等真崩溃快得多 - 如果路径在LVM或NFS上，kdump默认不支持；必须在
/etc/kdump.conf里加ext4 /dev/mapper/vg-lv这类显式文件系统声明
grub.cfg没重生成，或者新路径没提前mkdir -p并chown root:root。
