2512版本固件回退问题

Feedback 建议与反馈
1

当前BMC版本：2509

待刷固件版本：2512

当前使用2512,高可用组件出包，固件更新后能ssh，web查看版本，都是2512的固件版本

过几分钟BMC就开始重启，重启2～3次后固件版本回退到上一个版本2509

这个问题如何定位

2

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

BMC固件从2512版本回退至2509版本的问题分析与定位

根据您描述的现象：BMC成功升级至2512版本，SSH和Web可访问且显示为新版本，但几分钟后开始频繁重启，最终自动回退到2509版本，这是一种典型的 “升级后回滚”（Rollback after upgrade）问题。以下是基于现有知识库内容的系统性分析与定位指导。

:magnifying_glass_tilted_left: 问题本质

该问题属于 Upgrade Failure 的一种表现形式，具体体现为：

  • 固件写入成功，重启后能短暂运行新版本。
  • 系统在运行一段时间后异常重启。
  • 最终触发 BMC自动回滚至旧版本固件（2509），说明升级过程未被系统认定为“稳定生效”。

这表明：虽然固件包被正确刷写，但新版本在运行阶段出现了致命错误，导致系统无法维持正常运行状态，进而触发了回滚机制。

:puzzle_piece: 可能原因分析

1. 新固件存在运行时缺陷（如组件崩溃、内核异常等）

  • 证据支持：

    • 文档 reference_id: 5 描述了类似现象：“更新到25.12后bmc一直重启的问题”，并伴随 Call trace 错误日志。
    • 日志中重复出现的 [ 264.923029] Call trace: 表明 RTOS 内核级崩溃（Crash），常见于驱动或底层服务异常。
    • 此类崩溃会导致 BMC 持续重启，并可能因 health check 超时或启动失败次数过多 而触发自动回滚。

  • 结论：2512版本固件可能存在代码缺陷，特别是在高可用组件集成后引入了不兼容或资源竞争问题。

2. 高可用组件集成引发冲突或资源耗尽

  • 背景：您提到“当前使用2512, 高可用组件出包”，说明此版本是定制化构建。

  • 潜在风险：

    • 新增组件可能导致内存泄漏、CPU占用过高或系统服务初始化失败。
    • 如知识库中 Document Chunk 1 所示，BMC在升级过程中已有 Memory warning 记录（如 Memory warning 77.11 M），若2512版本占用更多资源，可能超过系统阈值。
    • 高可用模块若依赖特定硬件或配置缺失，也可能导致服务无法完成启动流程。

  • 相关日志线索：

    • 查看 framework.log、app.log 中是否有关于高可用组件（如 ha_service、cluster_mgr 等）的 启动失败、心跳超时、初始化错误 记录。
    • 特别注意 iam、maca、security 等核心服务是否因新组件影响而延迟或失败启动（参考 reference_id: 3 中 iam 启动检查失败案例）。

3. 签名或安全验证失败导致运行中被拒绝

  • 尽管能短暂运行，但如果固件未正确签名或证书链不完整，某些安全子系统（如 Trust Zone、Secure Boot）可能在运行一段时间后执行二次校验并失败。

  • 触发回滚机制防止不受信代码长期运行。

  • 建议排查项：

    • 确认2512固件是否使用 远端签名服务器 签名（推荐做法），避免本地私钥泄露或签名格式不一致。
    • 检查 validate_sign.lua 日志中是否有后续运行时验证失败记录。
    • 参考 [搜索结果1 - 签名包制作指导] 中的安全配置要求。

4. 双分区策略下的自动回滚机制被触发

  • BMC 通常采用 A/B双分区 设计，升级时先将新版本写入备用分区，重启后运行。

  • 如果系统检测到：

    • 多次启动失败（如健康检查超时）
    • 关键服务无法就绪（如 iam、soctrl）
    • 用户未在规定时间确认升级成功（如未调用 /redfish/v1/UpdateService/update/confirm）

    则会 自动切换回原分区（2509） 以保证系统可用性。

  • 关键判断依据：

    • 查看日志中是否存在 rollback、switch to backup partition、confirm upgrade timeout 等关键词。
    • 检查是否有 GracefulResetLocked 超时释放记录（见 reference_id: 1），这可能标志着升级窗口关闭而未确认成功。

:hammer_and_wrench: 定位步骤与建议操作

:white_check_mark: 步骤一：收集串口日志（最关键）

# 使用串口线连接 BMC 控制台，在系统重启时捕获完整日志
# 重点关注：
- 内核 Call trace
- 启动阶段的服务初始化失败信息
- 是否有 “Rolling back to previous version” 类似提示
- 分区切换记录（如 uboot 阶段的日志）

:warning: 注意：Web 和 SSH 在重启后可能无法登录，串口日志是唯一可靠的信息源。

:white_check_mark: 步骤二：检查关键日志文件

登录 SSH 后（在重启前短暂窗口），执行以下命令收集日志：

# 查看框架日志
cat /var/log/framework.log | grep -i "error\|fail\|crash\|call trace"

# 查看应用日志（重点关注 maca、iam、bmc_core）
cat /var/log/app.log | grep -i "startup\|failed\|timeout"

# 查看安全相关日志
cat /var/log/security.log | grep -i "verify\|signature\|security"

# 查看升级管理器日志
cat /var/log/firmware_mgmt.log | grep -A5 -B5 "rollback\|upgrade"

:white_check_mark: 步骤三：确认是否触发自动回滚机制

  • 检查是否存在以下行为：

    • 升级完成后未调用 升级确认接口。
    • 系统设置了 GracefulResetLocked 时间（如 300 秒），期间未完成健康检查或确认操作。
    • 最终因超时触发回滚（参考 reference_id: 1 日志中 unlock GracefulResetLocked 记录）。

  • 建议动作：

    • 在2512版本启动成功后，立即通过 Redfish 接口发送确认命令：
      POST /redfish/v1/UpdateService/update/confirm
{}
      表明升级已成功，阻止自动回滚。

:white_check_mark: 步骤四：验证固件包完整性与构建环境

项目 建议
BMC SDK 版本 确保使用 2512版本官方配套 SDK，避免混用不同版本 RTOS 或工具链（参考 search result 8）
Conan 版本兼容性 若使用 Conan 2.0+，需确保所有组件适配（参考 search result 8）
签名方式 推荐使用远程签名服务器，避免本地签名证书问题
构建一致性 确保 manifest 切换到 2512 正确分支，无本地修改污染

:white_check_mark: 步骤五：尝试降级路径验证

如果无法解决2512问题，建议采取 过渡方案：

  1. 构建一个中间版本（如 2510），先从 2509 → 2510 → 2512。
  2. 或者：在 2512 包中暂时移除高可用组件进行测试，确认是否为其引起问题。

:toolbox: 应急恢复方法（如已无法正常运行）

若 BMC 已完全陷入重启循环，可尝试以下方式恢复：

方法一：串口进入 U-Boot 切换分区

# 1. AC 断电后重新上电
# 2. 在启动初期按提示进入 uboot 命令行
# 3. 执行命令切换回 2509 所在分区（命令因平台而异）
#    例如：
#      setenv bootcmd 'run bootcmd_b'
#      saveenv
#      reset

:light_bulb: 参考：document 7 和 topic 2059 中关于串口恢复的讨论。

方法二：带内通道（In-band）恢复

如果主机 OS 正常运行，可通过虚拟网口（veth）向 BMC 传包并升级：

# 加载 host_veth_drv.ko 驱动
insmod host_veth_drv.ko

# 使用 send_file 脚本发送 2509 正常固件到 BMC 的 /tmp/
./send_file "[a:b:c:d:e%veth]" good_bmc.hpm /tmp/

# 通过 IPMI raw 命令触发升级
ipmitool -H <veth-ipv6> -I lanplus -U Administrator -P password raw 0x30 0x91 ...

:books: 详见 document 7 和 topic 2059 中的带内升级指导。

:white_check_mark: 总结与建议

项目 建议
根本原因 2512 固件运行时出现严重错误（如内核崩溃、服务启动失败），触发自动回滚机制
首要任务 获取完整 串口日志，查找 Call trace 或服务失败记录
重点排查 高可用组件是否导致资源泄漏或服务冲突
构建验证 确保使用标准 SDK 和签名流程构建固件
操作建议 升级成功后立即调用 Redfish 接口确认，防止超时回滚
恢复手段 优先尝试串口进 uboot 切回旧分区，或通过带内通道重新刷写

:link: 参考链接：

请尽快采集串口日志以便进一步精准定位问题根源。

相关链接：

  1. UBMC网页更新BMC固件后，重启时BMC回滚到之前版本导致升级失效
  2. 伙伴过渡包刷到华为bmc后，bmc起不来
  3. BMC固件升级失败，重启后自动回退到升级前的版本。
  4. bmc是否支持无感升级
  5. 签名包制作指导 | 文档中心 | openUBMC
3

看一下framework.log日志，里面可能某些组件启动异常，maca检测到异常就会重启

4

出现回滚的原因一般情况下是这样导致的：
1）组件拉不起来，导致了框架检测到异常，触发了重启
2）多次重启之后，会触发回滚，导致了回滚到了上一个版本
请从下面的顺序进行排查：
1）添加的新的组件或者代码是否存在bug
2）查看框架日志，framework.log，这里会记录每一次重启的原因
3）根据framework.log记录的重启的时间和重启原因，查看app.log之中对应时间附近的app日志，具体判断是什么组件具体情况导致了出错