BMC热复位失败

WH11003 · 2026 年4 月 13 日 08:29

问题描述

带内执行ipmitool mc reset warm，framework日志显示热复位失败

2026-04-13 16:22:29.386881 maca NOTICE: init.lua(413): WarmReset begin
2026-04-13 16:22:29.416383 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/file_transfer/MicroComponent
2026-04-13 16:22:29.455285 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/ssdp/MicroComponent
2026-04-13 16:22:29.488235 maca NOTICE: init.lua(287): bmc_upgrade warm reseting ... prepare successfully, takes 80 ms
2026-04-13 16:22:29.489411 maca NOTICE: init.lua(287): firmware_mgmt warm reseting ... prepare successfully, takes 80 ms
2026-04-13 16:22:29.497704 maca NOTICE: init.lua(287): remote_console warm reseting ... prepare successfully, takes 80 ms
2026-04-13 16:22:29.498777 maca NOTICE: init.lua(287): event warm reseting ... prepare successfully, takes 80 ms
2026-04-13 16:22:39.392099 maca NOTICE: init.lua(191): prepare warm reset timeout, components: file_transfer,ssdp
2026-04-13 16:22:42.443153 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/file_transfer/MicroComponent
2026-04-13 16:22:42.484648 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/ssdp/MicroComponent
2026-04-13 16:22:42.568701 maca NOTICE: init.lua(316): ums warm reseting ... closed successfully, takes 110 ms
2026-04-13 16:22:42.574827 maca NOTICE: init.lua(316): bmc_soc warm reseting ... closed successfully, takes 110 ms
2026-04-13 16:22:42.575607 maca NOTICE: init.lua(316): chassis warm reseting ... closed successfully, takes 110 ms
2026-04-13 16:23:42.434130 maca NOTICE: init.lua(191): action warm reset timeout, components: file_transfer,license,capability_proxy,certificate,thermal_mgmt,ums,usb_entry,vnc_proxy,web_backend,ai_engine,bmc_health,bmc_soc,chassis,trust,compute,cooling,dcmid,ddns,event_policy,fault_diagnosis,general_hardware,storage,host_agent,ipmi_core,lsw,ssdp,spdm,pcie_device,sensor,rmcpd,observability,power_mgmt,power_strategy,redfish,hwdiscovery,key_mgmt,manufacture,persistence,hwproxy,soctrl,mctpd

环境信息

软件版本：OpenUBMC2512 + 高可用

ubmc_assistant · 2026 年4 月 13 日 08:32

答案内容由AI生成，仅供参考：

总结

本次BMC热复位失败的根本原因是：在执行WarmReset过程中，关键微组件（如file_transfer、ssdp）未能被成功获取并进入Prepare阶段，导致后续大量组件在Action阶段超时，最终复位失败。

建议优先采取冷重启BMC作为恢复手段，并结合组件状态检查与固件版本确认，彻底排除系统异常。长期来看，应关注OpenUBMC对热复位流程的稳定性改进与超时机制优化。

点击此处查看详细分析解答

BMC热复位失败问题分析与解决方案

问题概述

在使用ipmitool mc reset warm命令进行BMC热复位操作时，系统执行失败。根据提供的日志信息，该问题发生在OpenUBMC2512版本环境中，带内执行热复位后，系统显示组件准备超时和执行超时，最终导致热复位失败。

故障关键日志分析

根据framework日志显示：

2026-04-13 16:22:29.386881 maca NOTICE: init.lua(413): WarmReset begin
2026-04-13 16:22:29.416383 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/file_transfer/MicroComponent
2026-04-13 16:22:29.455285 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/ssdp/MicroComponent
...
2026-04-13 16:22:42.443153 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/file_transfer/MicroComponent
2026-04-13 16:22:42.484648 maca NOTICE: init.lua(333): WarmReset get object fail, path:/bmc/kepler/ssdp/MicroComponent
...
2026-04-13 16:22:39.392099 maca NOTICE: init.lua(191): prepare warm reset timeout, components: file_transfer,ssdp
2026-04-13 16:23:42.434130 maca NOTICE: init.lua(191): action warm reset timeout, components: file_transfer,license,capability_proxy,...

日志关键点解析：

对象获取失败：系统在尝试获取/bmc/kepler/file_transfer/MicroComponent和/bmc/kepler/ssdp/MicroComponent等微组件对象时失败，提示"get object fail"。
Prepare阶段超时：file_transfer和ssdp组件未能在规定时间内完成准备操作（Prepare），导致进入Prepare超时状态。
Action阶段全面超时：随后，多达数十个核心组件（包括license, certificate, redfish, ipmi_core, web_backend等）在Action阶段也未能在规定时间内完成关闭或重启准备，触发Action阶段超时。

这表明系统中存在多个微组件无法正常响应热复位指令，可能是组件无响应、服务卡死或组件管理器（MACA）通信异常所致。

根本原因分析

结合知识库信息和当前日志，可能的根本原因如下：

1. 微组件管理系统（MACA）异常或组件无响应

根据知识库中《微组件管理介绍》（[id: 9]），MACA负责管理所有微组件的启动、健康检查和复位流程。
热复位过程分为Prepare（准备）和Action（执行）两个阶段，各自有超时限制（Prepare阶段默认超时时间为10秒，Action阶段为60秒）。
当组件在Prepare阶段因初始化卡顿、死锁或资源占用等原因无法及时响应时，将导致整个热复位流程中断。

2. 特定组件服务异常

file_transfer和ssdp服务是最早报错的组件。这两个服务通常与固件传输、网络发现相关，若其对应的微组件未正常注册或已崩溃，则会导致get object fail。
若这些基础服务异常，可能引发连锁反应，影响其他依赖组件的正常响应。

3. OpenUBMC版本兼容性或Bug

尽管当前使用的是较新的OpenUBMC2512版本（支持BMC热复位），但某些特定构建可能存在组件生命周期管理缺陷。
知识库中提到OpenUBMC曾存在升级失败由软件缺陷引起的情况（如OpenUBMC2509中日志格式化函数处理空值不当），说明不同版本间可能存在稳定性差异。

解决方案建议

方案一：尝试强制冷重启BMC

由于热复位失败，可尝试通过冷重启恢复系统状态：

# 使用ipmitool执行冷复位
ipmitool mc reset cold

# 或通过Redfish API触发
curl -k -X POST https://<BMC_IP>/redfish/v1/Managers/1/Actions/Manager.Reset \
     -H "Content-Type: application/json" \
     -d '{"ResetType": "ForceRestart"}'

冷重启将完全重置BMC系统，有望解决组件卡死等问题。

方案二：检查并重启异常组件

登录BMC系统，检查相关组件运行状态：

# 查看file_transfer和ssdp服务状态
ps | grep file_transfer
ps | grep ssdp

# 尝试手动重启组件（如有管理命令）
systemctl restart file_transfer
# 或进入组件容器/进程手动启动

同时检查系统资源使用情况：

df -h           # 检查磁盘空间
free -m         # 检查内存
top             # 检查CPU占用

方案三：更新或修复BMC固件

确认当前固件是否为官方推荐稳定版本。
若非最新版，建议升级至更稳定的OpenUBMC版本，特别是针对热复位流程优化过的版本。

方案四：增加热复位超时时间（可选配置项）

根据知识库《【已评审】支持BMC复位流程添加复位前处理操作》（[id:8]）和《微组件管理介绍》（[id:9]），可考虑适当延长Prepare和Action阶段的超时时间：

{
  "WarmReset": {
    "PrepareTimeout": 30,     // 原默认10s，可调至30s
    "ActionTimeout": 120      // 原默认60s，可调至120s
  }
}

注意：此配置需平台支持且需评估潜在风险（如延长等待时间可能导致故障诊断延迟）。

方案五：收集完整日志提交技术支持

若以上方法无效，请执行一键日志收集：

ipmcget -d log -v all -f full_log.tar.gz

并将日志发送至相关技术支持团队（如华为或社区支持邮箱），以进一步排查深层问题。

总结