当kdump.service启动失败时，应首先检查crashkernel内核参数是否配置正确，因为该参数负责为捕获内核预留内存，若缺失、值过小或格式错误（如未指定偏移地址），会导致“Failed to start Crash recovery kernel arming”错误，进而使系统无法生成vmcore转储文件。
内核参数配置不当引发的系统崩溃，往往不会直接报错“参数错了”，而是表现为 Kernel Panic、随机重启、服务异常中断等现象。排查关键在于：不盯着错误本身，而是顺着崩溃日志反推哪些内核参数可能被误设或缺失。
先抓崩溃现场的原始日志片段
崩溃后第一件事不是重启，而是尽快提取未被覆盖的内核消息：
- 用 dmesg -T | grep -A 20 -B 5 -E "(Kernel panic|Oops|BUG:|Call Trace:)" ——-T 带时间戳，-A 20 拿到完整调用栈，-B 5 往上找前兆（比如 “memory allocation failure”、“kdump: no crashkernel memory reserved”）
- 若已重启，/var/log/kern.log 可能被轮转，优先查 zcat /var/log/kern.log.1.gz | grep -A 20 -B 5 "Kernel panic"
- 别依赖 journalctl -b -1 | grep panic —— 多数 panic 发生时 journal 还没来得及写入，尤其 rsyslog 未启用 imkmsg 模块时
重点盯这些与参数强相关的线索
日志里一旦出现以下关键词，基本可锁定是内核参数问题：
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- “Not enough memory reserved for crashkernel” 或 “crashkernel=auto failed” → crashkernel 参数缺失、值太小或格式错误（如写成 crashkernel=128M 而没指定偏移地址 @64M）
- “Kernel panic - not syncing: VFS: Unable to mount root fs” → root=、initrd= 或 ro/rw 参数指向错误设备或文件系统类型不匹配
- “ACPI: Failed to load table” 或 “acpi_osi=linux” 相关警告 → acpi=off、acpi_enforce_resources=lax 等 ACPI 相关参数与硬件不兼容
- “WARNING: CPU: 0 PID: 0 at kernel/time/timer.c” + 大量 watchdog 超时 → watchdog_thresh 设得太小，或 nmi_watchdog=0 被误禁用
验证参数是否生效且合法
光看日志不够，必须确认参数实际加载情况：
- 运行 cat /proc/cmdline，检查目标参数是否存在、拼写是否正确、值是否合理（例如 crashkernel=256M@64M 在 32G 内存机器上是常见有效值）
- 查 /proc/sys/kernel/panic：若为 0，panic 后系统会停机而非触发 kdump；建议设为非零值（如 10 表示 10 秒后重启并留给 kdump 时间）
- 检查 systemctl status kdump：状态为 active (running) 且无 “Failed to start” 才算 crashkernel 生效；若失败，90% 是 GRUB 配置未更新（改完 /etc/default/grub 必须执行 grub2-mkconfig -o /boot/grub2/grub.cfg）
确认 vmcore 是否真实可用
即使 kdump 启动成功，vmcore 也可能无效：
- 用 file /var/crash/*/vmcore 查类型：输出必须含 ELF 64-bit LSB core file x86-64；若显示 data 或 empty，说明 crashkernel 内存预留不足或写入被截断
- 运行 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore，进交互后立即输 bt：若堆栈全为 ?? 或报 “cannot determine vmcore type”，说明 vmlinux 符号文件版本不匹配或缺失 debuginfo 包
