Linux查主板IPMI日志需分层排查：先用ipmitool sel list查看SEL摘要日志（注意加-v参数、检查BMC连通性），再通过Web控制台导出debuglogs.zip获取温度曲线、电压采样等深度硬件日志，SEL仅记录关键事件，不包含调试细节。
Linux 查主板 IPMI 日志，不能只跑一个 ipmitool 命令就完事——SEL（System Event Log）只是 BMC 日志的一部分，且默认不包含硬件级调试细节。真实故障定位必须分层查：先看 SEL 是否有记录，再确认 BMC 是否启用了完整日志模式，最后导出压缩包供深度分析。
用 ipmitool sel list 查系统事件日志（SEL）
这是最常用、也最容易漏掉关键信息的操作。SEL 存在 BMC 芯片里，独立于 Linux 内核，只要 BMC 通电就能记录（比如过热关机、电源跌落、风扇停转）。但注意：
-
ipmitool sel list默认只显示最近若干条，可能截断早期错误；加-v参数可看到原始时间戳和事件类型码 - 部分厂商（如 Supermicro）需先执行
ipmitool mc reset cold才能刷新 SEL 缓存，否则新事件不出现 - 输出中
Event Reading字段为Upper Critical、Fan Fail、Power Supply Failure等才是真异常；Unknown或Transition to Critical需结合上下文判断 - 若提示
Unable to establish IPMI v2 / RMCP+ session，说明 BMC 网络未通或用户权限不足，先检查ipmitool lan print和ipmitool user list
导出完整 BMC 调试日志（非 SEL）
SEL 是摘要日志，真正含温度曲线、电压采样、固件状态、内存初始化失败详情的，是 BMC 的 debug log。Intel 服务器常用 syscfg /sbmcdl public debuglogs.zip，而多数厂商需走 Web 控制台：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 浏览器访问 BMC IP（如
https://192.168.1.100），登录后找System Diagnostics → Generate Logs或Maintenance → Export Logs - 导出的是
debuglogs.zip，解压后重点看bmc_log.txt、sensor_history.csv、bootlog.txt - 某些 BMC（如 AMI MegaRAC）支持命令行导出：
ipmitool raw 0x30 0x0a 0x01（需查对应 OEM 厂商文档），但成功率低，不推荐作为首选 - 若 BMC 固件版本老旧（如
验证 BMC 是否真正记录了硬件错误
很多用户跑完 ipmitool sel list 没看到报错，就以为“没硬件问题”，其实 BMC 可能根本没上报——常见于以下情况：
- CPU MCE 或内存 ECC 错误由内核直接捕获，BMC 不感知，必须查
dmesg -T | grep -i "mce\|ecc\|hardware" - RAID 卡自身错误（如 LSI MegaRAID 的
FW error）通常只写入卡 BIOS 日志，BMC SEL 里只有模糊的PCIe Device Error - BMC 日志等级设为
Warning或更低，会过滤掉Info级别事件（如 DIMM 插槽识别变化、风扇 PWM 调节日志），需进 Web 界面调成Debug - 某些 Dell 服务器需启用
iDRAC Lifecycle Controller Logging，否则 SEL 为空；HPE iLO 则要确认Integrated Management Log已开启
BMC 日志不是“有没有错”的开关，而是“错发生在哪里”的坐标系。SEL 提供时间锚点，debug log 提供硬件路径，dmesg 提供内核视角——三者对不上时，问题往往出在固件兼容性或日志采集配置上，而不是硬件本身。
