当 Linux 系统因内核 bug、硬件故障或驱动异常发生严重错误（Kernel Panic）时，若无有效诊断手段，运维人员将难以定位根本原因。Kdump 是 Linux 内核的崩溃转储机制，它利用 kexec 快速切换到一个预加载的“捕获内核”（capture kernel），在主系统崩溃后安全地保存内存快照（vmcore）供后续分析。openEuler 24.03 LTS 默认集成 Kdump，并优化了对 ARM64（鲲鹏）和 x86_64 架构的支持。本文将指导如何在 openEuler 24.03 LTS 上启用 Kdump，配置转储目标路径、内存预留策略，并使用 crash 工具解析 vmcore 文件，实现对内核级故障的精准回溯。

一、环境说明

• 操作系统：openEuler 24.03 LTS（x86_64 或 aarch64）
• 内存要求：建议 ≥ 4GB（Kdump 需预留专用内存）
• 转储目标：本地磁盘 /var/crash/（也可配置为 NFS、SSH 或 raw 设备）
• 分析工具：crash + kernel-debuginfo 包
• 测试方式：通过 sysrq 触发人工 panic（仅限测试环境）

二、确认 Kdump 支持并安装组件

1. 检查内核是否启用 Kdump 相关配置：

grep -i kdump /boot/config-$(uname -r)

应包含：

CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_FILE=y

1. 安装 Kdump 服务与分析工具：

sudo dnf install -y kexec-tools crash

openEuler 默认已安装 kexec-tools，但需显式启用服务。

三、配置 Kdump 内存预留

Kdump 需在系统启动时通过内核参数预留一块独立内存供捕获内核使用。

1. 查看当前内核命令行：

cat /proc/cmdline

1. 编辑 GRUB 配置以添加 crashkernel 参数：

sudo vi /etc/default/grub

在 GRUB_CMDLINE_LINUX 行追加（根据内存大小调整）：

GRUB_CMDLINE_LINUX="... crashkernel=512M"

推荐值：

• 内存 ≤ 8GB：crashkernel=512M
• 内存 > 8GB：crashkernel=1G
• ARM64（鲲鹏）建议 ≥ 1G

1. 更新 GRUB 配置并重启：

# x86_64
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# ARM64（如鲲鹏）
sudo grub2-mkconfig -o /boot/efi/EFI/openEuler/grub.cfg

sudo reboot

1. 验证预留内存是否生效：

cat /proc/iomem | grep -i crash
# 应显示类似 " Crash kernel: 0000000100000000 - 000000011fffffff "

四、配置 Kdump 服务与转储选项

1. 编辑 Kdump 配置文件：

sudo vi /etc/kdump.conf

关键配置项：

# 转储目标目录（默认）
path /var/crash

# 可选：压缩转储以节省空间
core_collector makedumpfile -l --message-level 1 -d 31

# 可选：设置最大保留转储数（防磁盘占满）
max_crash_dumps 3

# 若需远程转储（示例：NFS）
# nfs myserver:/export/crash

# 若需通过 SSH 转储
# ssh user@remote-server
# sshkey /root/.ssh/id_rsa

1. 启用并启动 Kdump 服务：

sudo systemctl enable kdump
sudo systemctl start kdump

1. 验证状态：

sudo systemctl status kdump
# 应显示 "Kdump is configured and ready to capture"

五、手动触发内核崩溃（仅限测试环境！）

此操作将导致系统立即重启，请勿在生产环境执行！

1. 启用 SysRq：

echo 1 | sudo tee /proc/sys/kernel/sysrq

1. 触发 panic：

echo c | sudo tee /proc/sysrq-trigger

系统将崩溃 → 自动重启 → 捕获内核保存 vmcore → 主系统恢复。

1. 检查转储结果：

ls -lh /var/crash/
# 应生成形如 127.0.0.1-2025-06-18-10:23:45 的目录，内含 vmcore

六、使用 crash 工具分析 vmcore

1. 安装对应内核的 debuginfo 包（关键！）：

# 查询当前内核版本
uname -r
# 示例输出：5.10.0-136.12.0.95.oe2203sp1.x86_64

# 安装 debuginfo（需启用 debuginfo 源）
sudo dnf install -y kernel-debuginfo-$(uname -r)

若未配置 debuginfo 源，可从 openEuler 官网下载 RPM 手动安装。

1. 启动 crash 分析器：

sudo crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore

1. 常用 crash 命令：

crash> bt          # 查看崩溃时的堆栈回溯
crash> log         # 显示内核日志（含 panic 原因）
crash> ps          # 列出所有进程状态
crash> files       # 查看打开的文件描述符
crash> mod         # 列出加载的内核模块
crash> quit        # 退出

典型输出片段：

KERNEL PANIC: "Fatal exception in interrupt"
PID: 0, CPU: 2, Command: swapper/2
Call Trace:
 [<ffffffffa1234567>] some_buggy_driver+0x45/0x80 [buggy_module]
 ...

据此可定位到具体驱动或内核函数。

七、高级配置建议

• 自动清理旧转储：结合 logrotate 或 systemd-tmpfiles；
• 邮件告警：在 /etc/kdump.conf 中添加 post_action 脚本发送通知；
• 最小化捕获内核：通过 dracut 自定义 initramfs，减少内存占用；
• ARM64 特别注意：确保 UEFI 支持 kexec，部分国产 BIOS 需开启相关选项。

八、安全与合规价值

• 故障可追溯：满足等保 2.0 对“安全事件分析”的要求；
• 驱动兼容性验证：在新硬件上线前通过 crash 分析验证稳定性；
• 根因分析（RCA）：避免“重启即恢复”掩盖深层问题。

九、常见问题排查

• Kdump 启动失败：检查 crashkernel 是否正确预留，磁盘空间是否充足；
• vmcore 为空或损坏：确认捕获内核能正常挂载根文件系统；
• crash 无法解析符号：必须安装 exact version 的 kernel-debuginfo；
• 系统未自动重启：检查 BIOS 是否禁用自动重启（需开启）。