有个细节很容易踩坑：crashkernel 参数必须写进 GRUB_CMDLINE_LINUX，不能放到 _GRUB_CMDLINE_LINUX_DEFAULT 里，不然内核根本不会解析。配置完之后，别只看“像是生效了”，最好做三步确认：先用 cat /sys/kernel/kexec_crash_size 看返回值是否非零；再检查 dmesg 里有没有 “Reserving...for crashkernel”；最后确认 /proc/iomem 中是否出现 “Crash kernel” 条目。这三项都对上，才算真正生效。
crashkernel= 参数必须写在 GRUB_CMDLINE_LINUX 中
Linux 中为 kdump 预留内存，crashkernel= 必须出现在 GRUB_CMDLINE_LINUX（而非 GRUB_CMDLINE_LINUX_DEFAULT）里，否则内核根本不会解析它。很多用户改错位置后发现 dmesg | grep -i crash 没输出、/sys/kernel/kexec_crash_size 为 0，就是这个原因。
实操建议：
- 编辑
/etc/default/grub，找到GRUB_CMDLINE_LINUX=行（不是_DEFAULT），在其引号内添加crashkernel=128M或更复杂的表达式 - 若该行为空或不存在，直接添加：
GRUB_CMDLINE_LINUX="crashkernel=128M" - 运行
sudo update-grub再sudo reboot，否则修改不生效
crashkernel=128M 和 crashkernel=auto 的行为差异
crashkernel=auto 这项配置，别把它理解成“系统会自动挑一个最优值”。它本质上还是按硬编码规则去查表执行：在 x86_64 平台上，只有物理内存 ≥ 1GB 时才会生效；而 ARM64 和 Power 平台，则要求物理内存 ≥ 2GB。达不到这个门槛，系统就不会预留任何内存——这时在 /proc/meminfo 里也看不到 CmaTotal，同时 kdump 服务启动会直接失败，并报出 “No memory reserved for crash kernel”。
手动指定更可靠：
crashkernel=128M：固定预留 128MB，适用于内存 ≥ 2GB 的常见服务器crashkernel=512M-2G:64M,2G-:128M：按物理内存分段预留，避免小内存机器浪费过多- 注意单位大小写：
M（兆字节）合法，m或MB在多数内核版本中会被忽略或报错
mem= 参数会覆盖物理内存总量，不是“预留”而是“截断”
mem= 是限制内核可管理的内存上限，比如 mem=32G 在 64G 机器上，会导致后 32G 物理内存完全不可见 —— /proc/meminfo 的 MemTotal 就是 32G，dmesg 里 e820 显示那段区域标记为 reserved，但这段内存连 DMA、PCIe 设备都用不了，和 kdump 的 crashkernel 机制完全无关。
典型误用场景：
- 想“给硬件留点内存”，却用了
mem=，结果网卡驱动报dma_alloc_coherent failed - 和
crashkernel=同时使用，导致实际可用内存远低于预期（两者叠加裁剪） mem=值设得过大（如mem=128G在 64G 机器上）会被内核静默忽略，但日志里会有 warning
验证是否生效不能只看 /proc/meminfo
/proc/meminfo 的 MemTotal 是扣除 crashkernel 后的可用内存，但它不体现预留区本身。真正确认方式是：
cat /sys/kernel/kexec_crash_size—— 输出非 0 即已分配（单位字节）dmesg | grep -i "crash kernel"—— 应出现类似Reserving131072Kof memory at0x37b00000for crashkernelcat /proc/iomem | grep "Crash kernel"—— 显示该段物理地址范围，且状态为reserved
如果 kexec_crash_size 为 0，但 iomem 里有 Crash kernel 条目，说明 kdump 服务没起来或未加载模块；如果两者都无，则 GRUB 配置或内核参数根本没生效。
