升级330版本，上机验证版本回退出现 iam和rmcp組件报错

CICD SIG
1

问题描述

构建社区26年330+高可用版本，构建成功，上机验证会回退

f7533d38bf9523a9f860fa316d45bf5618a34157

1
11917×466 99.8 KB

framework.txt (2.0 MB)

已经按照 社区26年330_Q1构建的包会回退 - 交流互助区 - openUBMC 论坛 这个帖子进行修改，但仍然有上机升级就回退问题，请教下如何解决？

2

答案内容由AI生成，仅供参考：
:white_check_mark: 总结与建议

项目 建议
根本原因 关键服务 iam/rmcpd 未启动 → 触发强制重启 → 多次失败 → 自动回退
首要解决措施 清理 manifest 中的白牌配置
次要排查项 确保关键服务被打包、依赖完整、可启动
版本控制 检查 RevisionNumber，避免防回退策略误触发
升级方式 使用冷升级（AC 断电重启）
推荐流程 构建 → 清理配置 → 冷升级 → 手动验证服务状态 → 持续监控
点击此处查看详细分析解答

升级社区330版本后上机验证出现回退问题的分析与解决方案

根据您的描述，您在构建并部署社区 330+高可用版本 时，尽管构建成功，但在上机验证过程中系统多次重启并发生版本回退。该问题表现为升级看似成功，但最终系统自动切换回旧版本。结合您提供的日志信息、问题场景以及知识库中的相关信息，本文将从问题现象、根本原因、排查思路和解决方案四个方面进行系统性分析。

:magnifying_glass_tilted_left: 一、问题现象

  1. 构建成功：使用社区最新 manifest 构建 openUBMC 2603（即26年330_Q1）版本成功。
  2. 上机验证失败：部署到硬件环境（如1711机型）后，设备反复重启并最终回退至旧版本。
  3. 日志关键线索：
    • 多次出现以下错误：
      [iam]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.iam was not provided by any .ser
[rmcpd]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.rmcpd was not provided by any .ser
    • 最终触发：
      Force Reset begin
force reset bmc successfully
    • 时间戳异常：重启后时间变为 1970-01-01，表明系统未正常启动或 RTC 初始化失败。
  4. 结果：尽管升级过程完成，但系统未能稳定运行新版本，触发自动回退机制。

:warning: 二、可能的根本原因分析

1. 关键服务启动失败导致系统判定为异常（主因）

从日志中可见，iam 和 rmcpd 两个核心服务无法启动，报错为 DBus 服务未注册（ServiceUnknown）。这两个服务分别为：

  • iam（Identity and Access Manager）：负责用户认证、权限管理。
  • rmcpd（RMCP Daemon）：处理 IPMI RMCP 协议通信，是带外管理的基础。

:white_check_mark: 结论：
上述关键服务未能在系统启动时正常加载，导致 BMC 健康检查失败，触发 init.lua 中的 Force Reset BMC 机制，并最终因连续启动失败而激活分区回退逻辑。

2. 版本回退机制被触发

参考知识库文档《升级常见问题指南》中的说明：

“升级实际上是成功的，升级成功后复位iBMC，iBMC系统启动失败，三次未启动成功之后触发分区切换，切回了原版本。”

该场景与您当前现象完全一致：

  • 升级成功 → 启动新版本 → 核心服务启动失败 → BMC 强制重启 → 再次失败 → 达到重试上限 → 回退到旧分区。

3. 构建配置问题：白牌配置干扰系统行为

根据已有文档（参考 Document Chunk 3）指出：

“请在 manifest 中删除白牌配置。”

如果构建包中存在未清理的白牌自定义配置（如 web_custom.xml 中的 CustomManufacturer 等），可能导致部分服务无法正确加载或路由异常，尤其影响 iam、dbus 服务的注册。

此外，社区版本通常要求使用纯净配置，残留的品牌化配置可能造成兼容性问题。

4. 防回退机制未关闭或版本控制冲突

根据 CSR 配置字典（FirmwareComponentInfo 类）定义，BMC 存在防回退控制策略：

参数 说明
RevisionNumber 控制是否允许降级
RevisionNumber > 0 只能升级不能降级
RevisionNumber = 0 无限制，可自由切换

若新旧版本之间 RevisionNumber 设置不当，或未设置为 0，也可能导致升级后系统误判为非法状态而强制回退。

:hammer_and_wrench: 三、排查与解决方案

:white_check_mark: 解决方案 1：确保 manifest 配置纯净，移除白牌相关配置

依据：Document Chunk 3 提示必须在 manifest 中删除白牌配置。

操作步骤：

  1. 检查 manifest 中是否引入了 wbd_up_file 或 web_custom.xml 文件。
  2. 删除以下节点（或确保不注入）：
    <CUSTOM_CONFIG>
    <CustomManufacturer VALUE="openUBMC" />
    <CustomAlarmName VALUE="openUBMC" />
    <CustomLogIbmaName VALUE="BMA" />
    <CustomLogIbmcName VALUE="openUBMC" />
</CUSTOM_CONFIG>
  3. 重新构建镜像并部署。

:light_bulb: 原因：白牌配置中的字段可能覆盖系统默认服务名、DBus 接口名等，导致 bmc.kepler.iam 无法注册。

:white_check_mark: 解决方案 2：检查 iam 和 rmcpd 服务是否被打包入固件

虽然构建成功，但仍需确认以下两点：

  1. iam 和 rmcpd 是否被正确编译进系统？

    • 检查构建产物中是否有：
      • /usr/bin/iam
      • /usr/bin/rmcpd
    • 检查 systemd 是否有对应服务文件：
      • /etc/systemd/system/iam.service
      • /etc/systemd/system/rmcpd.service

  2. 服务是否被禁用或依赖缺失？

    • 查看日志中是否有关于“missing dependency”或“failed to load library”的信息。
    • 检查是否缺少必要的共享库（如 libdbus, libopenssl 等）。

:white_check_mark: 解决方案 3：临时禁用防回退机制进行调试

若需验证是否因防回退策略导致自动切区：

  1. 修改 FirmwareComponentInfo 中对应组件的 RevisionNumber 为 0：
    {
    "ComponentID": "BMC",
    "RevisionNumber": 0
}
  2. 构建并升级，观察是否仍会回退。

若关闭后不再回退，则说明原版本存在版本号校验冲突或升级策略限制。

:white_check_mark: 解决方案 4：增加服务启动超时容忍与调试日志

在 init.lua 中，可对 StartupCheck 增加更详细的日志输出，例如：

for _, svc in ipairs(abnormal_svcs) do
    log("ERROR", "Service " .. svc .. " failed to start. Checking status...")
    local status = os.execute("systemctl status " .. svc)
end

并在目标设备上手动执行：

systemctl status iam
systemctl status rmcpd
journalctl -u iam -f

以获取更详细的失败原因。

:white_check_mark: 解决方案 5：确认是否执行了冷升级（Cold Upgrade）

参考知识库中 Cold Upgrade 概念：

升级后必须进行 AC 断电重启（AC Power Cycle），否则部分配置不生效。

请确保：

  • 升级完成后，手动断电再上电，而非仅软重启。
  • 避免仅使用 ipmitool mc reset cold，应进行物理断电。

:counterclockwise_arrows_button: 四、应急处理建议：快速回退机制

若问题频繁发生，可启用快速回退处理过程（快速回退处理过程）：

  1. 在检测到连续两次启动失败后，自动触发回退流程。
  2. 保留旧版本分区可用，保障系统基本可维护性。
  3. 通过日志分析回退原因，避免业务长时间中断。

这也是“升级不中断业务”的重要组成部分。

:white_check_mark: 总结与建议

项目 建议
根本原因 关键服务 iam/rmcpd 未启动 → 触发强制重启 → 多次失败 → 自动回退
首要解决措施 清理 manifest 中的白牌配置
次要排查项 确保关键服务被打包、依赖完整、可启动
版本控制 检查 RevisionNumber，避免防回退策略误触发
升级方式 使用冷升级（AC 断电重启）
推荐流程 构建 → 清理配置 → 冷升级 → 手动验证服务状态 → 持续监控

:books: 参考文献

  • Document Chunk 1：社区构建包回退问题日志对比
  • Document Chunk 3：manifest 中需删除白牌配置
  • Document Chunk 4：升级成功但版本号不变 → 实际为系统启动失败后回退
  • Knowledge Graph: Release Version, Version Backtrack, 回退机制, 升级不中断业务
  • CSR配置字典：FirmwareComponentInfo 防回退机制解析

如上述方案仍无法解决，请提供以下信息进一步排查：

  1. 构建所用 manifest 提交哈希
  2. 是否修改过 web_custom.xml
  3. iam 和 rmcpd 服务是否存在于根文件系统
  4. journalctl 完整启动日志（尤其是 dbus 相关）

祝您问题早日解决！

4

在 manifest 目录本地构建目录temp/board_xxx/manifest.yml (其中xxx为实际构建的单板名）， 查看下最终构建的account和iam组件版本。

5

检查了manifest.xml，发现没有配置conan: account，现在新增配置了account组件

查看temp/board_xxx/manifest.yml 里

是这样

conan: iam/1.110.4@openubmc/stable

conan: account/1.110.31@openubmc/stable

重新上机升级330版本包，现在可以升级成功，没有出现回退。

6

好的