kdump已启用需满足三条件：/proc/cmdline含crashkernel参数、/sys/kernel/kexec_crash_size非零、/proc/meminfo有CrashKernel行；再运行kdump-config show显示“ready to kdump”且systemctl status kdump-tools为active。
怎么确认kdump是否已启用
先别急着改配置，直接运行 kdump-config show。输出里如果看到 status: ready to kdump，说明服务已加载且内存预留成功；若显示 disabled 或 not ready，大概率是 crashkernel= 参数没生效，或 kdump-tools 服务没启动。
再补查一遍服务状态：systemctl status kdump-tools。常见问题包括：服务未 enable、启动失败（日志里常报 no crashkernel parameter）、或内核模块 crash_core 未加载（lsmod | grep crash 可验证）。
crashkernel参数怎么设才不翻车
你知道吗？crashkernel=这玩意儿，可不是越大越好，也不是越小越省内存哦。它得在boot阶段，就从物理内存里硬生生地划出一块来，而且还不能和其他内存管理机制起冲突。Ubuntu的默认值是crashkernel=512M-:192M，啥意思呢？就是当内存大于等于512MB的时候，预留192MB。不过呢，实际操作中，建议根据物理内存总量来调整哦，具体怎么调呢？接着往下看。
- ≤4GB 物理内存：设
crashkernel=256M - 4–16GB：设
crashkernel=512M - ≥16GB：设
crashkernel=1G（低于 768M 在某些驱动场景下会 dump 失败）
参数得写进 /etc/default/grub.d/kdump-tools.cfg 的 CRASHKERNEL 行，而非 /etc/default/grub 里的 GRUB_CMDLINE_LINUX_DEFAULT 哦。要知道，后者只对主内核启动参数起作用，而kdump工具读取的可是前者。
触发崩溃后vmcore没生成？检查这三处
手动触发 echo c > /proc/sysrq-trigger 后系统重启，但 /var/crash/ 下空空如也，常见原因有：
/var/crash所在分区空间不足（至少预留 2GB，vmcore 大小 ≈ 预留内存大小 × 0.8）kdump-tools配置里USE_KDUMP=1没开，或DEFAULT_KERNEL="auto"导致找不到匹配的 vmlinux 符号文件- 内核启动时没加载
crash_kexec模块（dmesg | grep -i crash查是否有crashkernel reservation成功提示）
注意：/var/crash 目录权限必须是 root:root 且 755，否则 kdump 进程无法写入。
分析vmcore前必须装什么
光有 crash 命令不够，缺三样东西没法解析 vmcore：
- 当前运行内核的调试符号包：
linux-image-$(uname -r)-dbgsym（不是linux-image-$(uname -r)） - 对应版本的
vmlinux文件，通常安装 dbgsym 后位于/usr/lib/debug/boot/vmlinux-$(uname -r) crash工具本身：sudo apt install crash（Ubuntu 20.04+ 自带，旧版需手动装）
验证符号是否到位：file /usr/lib/debug/boot/vmlinux-$(uname -r) 应输出 ELF 64-bit LSB pie executable；若报 “No such file”，说明 dbgsym 没装对或仓库源没配全（需加 ddebs.ubuntu.com 源）。
最易被忽略的是：kdump 生成的 vmcore 是压缩的（vmcore.gz），crash 默认不自动解压，得先 gunzip /var/crash/*/vmcore.gz 再传路径进去。直接拖 .gz 文件进去会报 invalid magic number。
