kdump默认不保存全量内存镜像，因体积大、i/o慢、存储难且调试通常只需活动页；全量需禁用压缩与过滤，改用raw设备或copy_kernel，并验证crashkernel预留生效。
为什么 kdump 默认不保存全量内存镜像
kdump 的核心机制是用预留的备用内核（crash kernel）接管系统崩溃后的内存快照捕获。但默认配置下，它只保存活动内存页（vmcore 是压缩的、去除非活动页后的镜像），并非物理内存的完整逐字节拷贝。这是因为全量镜像体积巨大（比如 256GB 内存 → ~256GB vmcore），I/O 延迟高、存储难、分析慢，且多数调试只需可访问的内核/进程上下文。
若你明确需要全量（例如硬件级内存篡改分析、固件 bug 复现、或某些安全取证场景），必须显式禁用内存压缩和页过滤：
- 在
/etc/default/grub的crashkernel=参数后追加rd.neednet=1（仅当网络转储时需要）和关键选项：crash_kexec_post_notifiers=1 nokaslr（后者非必需但有助于符号定位） - 更重要的是，在
/etc/kdump.conf中注释掉或删除所有ext4/xfs等文件系统过滤行，并确保没有core_collector makedumpfile -c --message-level 1 -d 31这类启用压缩/过滤的配置 - 改用裸写入：将
path /var/crash改为raw /dev/sdb1（指向一块独立、足够大的裸块设备），或保留path但设置core_collector copy_kernel—— 它会跳过makedumpfile，直接dd物理内存到文件（风险高，需确认磁盘空间 & I/O 稳定性）
如何验证 crashkernel 预留内存是否生效
很多“kdump 启动失败”或“崩溃后无 vmcore”问题，根源是 crashkernel 没被内核识别。不要只看 dmesg | grep -i crash，它可能显示成功但实际未预留。
正确验证步骤：
- 检查启动参数：
cat /proc/cmdline | grep crashkernel—— 必须看到类似crashkernel=512M或crashkernel=auto - 确认预留内存大小：
cat /sys/kernel/kexec_crash_size—— 输出应为非零字节数（如536870912表示 512MB）；若为0，说明预留失败 - 常见失败原因：
crashkernel=auto在大内存机器上可能计算不足；手动指定时单位写错（512M正确，512MB错误）；UEFI Secure Boot 启用时部分发行版会禁用 kdump - BIOS/UEFI 设置中需关闭 CSM（Compatibility Support Module），否则
crashkernel可能无法在 64 位模式下正确映射高位内存
makedumpfile 的 -d 参数到底过滤了什么
即使你没主动调用 makedumpfile，只要 /etc/kdump.conf 里有 core_collector makedumpfile ...（这是 RHEL/CentOS/Fedora 默认），它就在后台运行。其中 -d 后跟的数字是位掩码，控制丢弃哪些内存页：
-
-d 1：丢弃未使用的零页（ZERO_PAGE） -
-d 2：丢弃缓存页（CACHE） -
-d 4：丢弃用户进程页（USER）→ 这会导致vmcore里没有用户态内存，GDB 调试core时看不到应用变量 -
-d 31=1|2|4|8|16：默认值，几乎清空所有非内核关键页，结果远小于物理内存大小 - 要接近全量，至少设为
-d 1（只去零页），并配合-c（禁用压缩）和--message-level 7（避免日志干扰）
注意：makedumpfile -d 0 并非“不过滤”，而是使用内置默认策略（仍去零页+缓存），真正最小过滤需显式 -d 1。
崩溃后 vmcore 写入失败的典型现象与定位
最常遇到的是：系统卡死几秒后自动重启，/var/crash 下空空如也，或只有 2024-04-01-12:34/vmcore-dmesg.txt 而无 vmcore 文件。这不是 kdump 没触发，而是写入阶段失败。
- 先查
/var/log/messages或journalctl -u kdump --since "1 hour ago"，搜索Failed to write vmcore、Cannot open /dev/sda2、No space left on device - 磁盘配额（
quota）或 XFS 的projid限制可能导致kdump进程无法写入，即使df -h显示有空间 - 如果使用 NFS 或 SSH 转储，检查
ssh-keyscan是否被防火墙拦截，或 NFS server 是否启用了no_root_squash（否则kdump以 root 身份挂载失败） - 最关键的静默失败点：
/var/crash所在文件系统必须支持ext4或xfs，且不能是 Btrfs 或 ZFS —— 它们不被kdumpinitramfs 中的工具链支持
全量内存镜像对存储 I/O 压力极大，SSD 寿命、RAID 卡缓存策略、甚至 ext4 的 barrier=1 设置都可能让写入超时中断。真要全量，优先用直连 SATA/NVMe 块设备 + raw 模式，别碰网络或复杂文件系统。
