生产环境需启用kdump实现崩溃现场捕获与根因分析：一、预留crashkernel内存并更新grub参数；二、安装启用kdump服务；三、配置转储路径、压缩过滤及失败策略；四、强化panic响应，启用sysrq、panic_on_oops、pstore等机制。
生产环境需要稳定、可靠、可回溯的崩溃处理机制。内核Panic发生时，不能只靠重启掩盖问题，而要确保内存现场被完整捕获，用于后续根因分析。核心方案是启用 kdump，并辅以关键加固配置，而非依赖简单重启或日志截断。
一、预留 crashkernel 内存并更新启动参数
这是 kdump 正常工作的前提——必须为捕获内核（second kernel）预留独立、隔离的物理内存空间，避免主内核崩溃后内存被破坏或覆盖。
- 根据系统总内存合理设置大小：128MB（≤4GB）、256MB（4–16GB）、512MB（16–64GB）、1GB（≥64GB）；嵌入式或内存受限环境可低至 64MB，但需验证稳定性
- 编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 行末追加：
crashkernel=auto（推荐，自动适配）或显式指定如crashkernel=512M - 执行
sudo update-grub（Ubuntu/Debian）或sudo grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL/CentOS）使配置生效 - 重启系统后，检查是否成功分配：
cat /proc/cmdline | grep crashkernel和grep -i crash /proc/iomem
二、安装并启用 kdump 服务
kdump 服务负责加载捕获内核、监听 panic 事件、执行转储流程。不同发行版安装方式略有差异，但启用逻辑一致。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- Ubuntu/Debian：
sudo apt install linux-crashdump，安装后服务自动启用 - RHEL/CentOS/Fedora：
sudo yum install kexec-tools或dnf install kexec-tools，再运行sudo systemctl enable --now kdump - 验证状态：
sudo systemctl status kdump应显示 active (exited)，且无报错；sudo kdumpctl status可查看更详细就绪信息
三、配置转储目标与过滤策略
默认本地保存易占满磁盘，生产环境建议指向专用存储路径或远程服务，并启用压缩过滤以缩短转储时间、减小体积。
- 编辑 /etc/kdump.conf，明确指定位置：
— 本地路径：path /var/crash（确保该分区有足够空间，建议 ≥2× 物理内存）
— 远程 NFS：nfs nfs-server.example.com:/export/kdump（需提前安装nfs-utils并测试挂载）
— 远程 SSH：ssh user@backup-server（需配置免密登录） - 启用智能过滤与压缩：
core_collector makedumpfile -l --message-level 1 -d 31
其中-l启用 LZO 压缩，-d 31排除零页、缓存页、用户页等非必要内容，显著提升效率 - 设置失败后行为（防止卡死）：
default reboot（转储失败则强制重启）或default halt（彻底停机，便于人工介入）
四、强化 panic 响应与可观测性
仅靠 kdump 不够，还需确保 panic 能被及时触发、记录和通知，避免“静默崩溃”。
- 启用 SysRq 键（调试与应急必需）：
echo 'kernel.sysrq = 1' | sudo tee -a /etc/sysctl.conf，再运行sudo sysctl -p - 让 oops 立即升级为 panic（避免悬挂）：
echo 'kernel.panic_on_oops = 1' | sudo tee -a /etc/sysctl.conf - 设置 panic 自动重启延迟（兼顾转储完成与业务恢复）：
echo 'kernel.panic = 30' | sudo tee -a /etc/sysctl.conf（单位秒，建议 ≥20） - 配合 pstore/ramoops 作为兜底：即使 kdump 失败，也能在重启后从 /sys/fs/pstore/ 读取 panic 控制台日志，尤其适合嵌入式或云实例
