// 此模板仅供参考，如果不适用可以修改
在UBMC25.09的web界面上更新UBMC的固件版本，同样还是25.09的openUBMC中构建的hpm升级包（做了一点修改，但是没有变更版本号，还是25.09.00.01），升级完成之后串口中看到的启动版本居然是iBMC版本，这是什么情况？
操作系统：[如 Ubuntu 24.04]
软件版本：OpenUBMC2509
硬件配置：Hi1711模组+KP920模组
[第一步]
[第二步]
[第三步]
是最新的openUBMC固件版本
回退到了iBMC版本
答案内容由AI生成，仅供参考：
根据您描述的问题，在 openUBMC25.09 的 Web 界面使用同版本（25.09）但经过修改的 HPM 升级包进行固件更新后，系统启动时却回退到了原始的 iBMC 版本。以下基于提供的知识库内容对该现象进行系统性分析和解释。
问题总结
核心原因分析关键实体：
Firmware Upgrade Failure,Upgrade Failure,Firmware Management Module
多个文档和知识图谱条目表明，当固件升级过程中出现任何验证失败、签名错误或启动异常时，系统会自动触发回退机制（rollback），以恢复到之前的稳定版本。
特别提示：
- 您使用的 HPM 包虽然版本号仍为
25.09.00.01，但“做了修改”可能导致其完整性校验失败或签名无效。- openUBMC 系统对固件包有严格的签名验证机制（Secure Boot），即使是微小改动，若未重新正确签名，也会被识别为非法包。
- 升级过程可能“显示成功”，但后续启动失败会导致系统自动切回原固件（即 iBMC）。
相关证据：
Firmware_Upgrade_Error 日志中明确指出：“failed signature validation”是常见升级失败原因。Firmware Management Module 负责监控整个升级流程，并在检测到失败时触发恢复或回退。关键实体：
OpenUBMC2509,iBMC,Rollback,Firmware Mgmt
通常，BMC 固件采用 A/B 双分区机制：
当新版本无法正常启动（如升级包异常、驱动不兼容、内核崩溃），系统会在几次尝试失败后自动切换回旧分区，从而表现出“回退到 iBMC”的现象。
关键实体：
OpenUBMC Firmware Package,HPM_FILE,Firmware Update Process
您提到：
“做了一点修改，但是没有变更版本号，还是25.09.00.01”
这可能是问题根源：
关键实体：
Hi1711,KP920,OpenUBMC2509,Ubuntu 24.04
从知识图谱可知：
Hi1711 BMC模组 + 鲲鹏920模组 是 openUBMC2509 的典型部署环境（如文档 chunk 1 所述）。Ubuntu 24.04 上。
因此，硬件和操作系统层面 不是主要原因。 解决方案建议| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | **确认 HPM 包的合法性依赖于构建和签名流程的完整性。您提到该包“做了修改但未变更版本号”，这极易导致以下问题： |
可能的构建/签名问题包括：ComponentID 和 RevisionNumber 校验实际内容一致性。一旦内容不符但版本号一致，可能被视为“异常更新”而拒绝激活。关键实体：
web upgrade,Web Interface,Firmware Update Process
虽然 Web 界面支持固件升级（路径：BMC管理 > 固件升级 > 固件更新），但存在以下风险：
建议解决方案| 步骤 | 操作说明 |
|---|---|
| 1. 验证固件包完整性 | 确保使用的 HPM 包是由标准 openubmc 2509sdk 流程构建，并经过正式签名。禁止手动修改二进制包。 |
| 2. 检查签名状态 | 使用命令行工具（如 ipmcget -d fru）查看当前运行固件来源及签名状态；也可通过串口日志观察启动阶段是否报出 signature verify failed。 |
| 3. 查看串口日志 | 在系统重启过程中捕获完整串口输出，重点查找： - rollback 相关提示- bmc_veth_drv 加载失败- ipmi_core 启动异常- nginx 未启动 |
| 4. 使用 CLI 强制指定升级模式 | 尝试使用 CLI 命令升级，避免 Web 界面不可靠问题：ipmcset -d upgrade -v <path> activemode=immediate |
| 5. 手动清除旧配置（谨慎操作） | 若怀疑是配置残留导致冲突，可在 BMC 正常运行时执行：ipmcset -d restore -v factory，再重新升级。 |
| 6. 避免版本号欺骗 | 即使功能变更微小，也应递增版本号（如 25.09.00.02），避免升级系统误判为“重复升级”或“回滚攻击”。 |
补充建议：为何能从 iBMC 升级到 openUBMC，却无法“重新刷”openUBMC？这是因为：
总结| 项目 | 内容 |
|---|---|
| 问题本质 | 固件包被修改但未合规重建和签名 → 升级后启动失败 → 自动回退至 iBMC |
| 根本原因 | 签名验证失败 / 启动异常触发系统级回退机制 |
| 技术机制 | 双固件分区 + 自动恢复（roll-back）+ 安全校验（Secure Boot） |
| 推荐做法 | 所有固件修改必须通过标准 SDK 构建并签名，严禁直接编辑 HPM 文件 |
结论：您观察到的现象并非异常，而是系统安全性设计的正常表现——防止非法或损坏固件长期驻留设备。
如需进一步排查，请提供串口启动日志中的关键错误信息（如 Failed to start XXX, Signature verification failed, Rolling back... 等），可帮助精准定位具体失败环节。
相关链接：
请附一下图以及相关日志。
目前iBMC版本与UBMC版本无法直接互升，如果按描述中说UBMC25.09上升UBMC版本，主备都是UBMC，不可能会出现iBMC版本。
确认版本是否回退可通过以下两点确认：
1.版本号是否与您构建的包相同（web首页或固件升级-版本信息界面即可看到固件版本信息）
2.如果备分区版本和主分区版本一致，则可以确认构建时间是否为您出的升级包的时间（命令ipmcget -d version，查看Active分区的构建时间）
这个帖子不是说明iBMC是可以直接升级的吗？ v2升级openubmc指导
你好！这个链接的信息可能对你解决本问题有所帮助，请参考，谢谢！