[在这里详细描述您遇到的问题]
25.12-LTS-SP1
环境之前升级过编译成功的openUBMC（0507）版本和对应的S920X20（0509）版本号
再次编译openUBMC后升级，页面显示升级成功，但是起来后会自动到之前的openUBMC（0507）版本
再次编译S920X20后升级，页面显示升级成功，但是起来后会自动到之前的S920X20（0509）版本
查看framework日志
升级日志.txt (168.8 KB)
把本地所有conan仓都删除，manifest所有修改都回退，编译出来的版本升级依旧无法生效，还是自动回滚到旧版本
答案内容由AI生成，仅供参考：
总结您遇到的问题是典型的 “升级成功但回滚” 现象，由构建包与运行环境不一致引发，触发了 BMC 的自动回滚机制。
根本原因在于：构建配置不当 → 关键服务缺失/启动失败 → 自动回滚 → 回到旧版本。
最佳实践建议：-bt=release；clearcfg；完成上述流程后，升级应能稳定生效。
如问题持续，请提供 完整串口日志 + HPM 包 SHA256 值 至 OpenUBMC 官方论坛，我们将进一步协助排查。
根据您提供的详细信息，您的系统在执行 openUBMC 25.12 LTS SP1 版本升级时，虽然 Web 界面显示“升级成功”，但设备重启后自动回滚至之前的版本（如 openUBMC 0507 和 S920X20 0509）。以下基于 知识图谱（KG）、文档片段（DC） 以及 搜索结果 进行综合分析，并提供系统性解决方案。
问题本质固件升级虽报告成功，但由于关键服务启动失败或校验异常，触发系统自动回滚机制，导致 BMC 切换回原分区的旧版本固件。
这种现象被称为 Version Backtrack（版本回退），是 Auto Rollback（自动回滚）机制 的典型表现。
根本原因分析结合多源信息，可确定如下根本原因：
知识图谱证据：
Auto Rollback 被 Upgrade Failure 触发。Automatic Rollback 是当核心服务（如 Redfish、Web Backend）无法初始化时，系统行为。#1 明确指出日志中出现：[redfish]StartupCheck failed
[web_backend]StartupCheck failed
maca（启动监控模块）判定为异常。结论：
.service 文件），或其依赖未正确打包。知识图谱 & 搜索结果佐证：
mismatched command /bin/tar, execve: mismatched command，提示 安全策略拦截系统调用（如 SELinux、签名校验）。crc 校验失败 回退。结论：
manifest 或 SDK 来源于非标准源，可能导致：
搜索结果 #1 分析精辟：
M3 固件层检测到
tmp region rootfs尺寸不匹配，导致 rootfs 校验失败（ret:-22），active 分区未更新。重启后主备分区均不可用，触发回滚机制。
知识图谱印证：
Upgrade Failure 可发生于 write bmc package to flash failed 阶段。Quick Rollback Mechanism 包含“文件恢复、配置还原、服务重启”流程。openubmc_25.12 是 Conan SDK 仓库，若本地缓存污染或未强制清理，即使重新构建也可能复用旧组件。bingo build -bt=release 才能确保构建 release 版本（见 DC7）。 解决方案与建议步骤
推荐操作顺序（逐级排查）| 步骤 | 操作内容 | 目的 |
|---|---|---|
| 1 | 清空所有本地缓存 | 防止使用旧组件 |
| 2 | 使用官方 clean manifest 构建 release 包 | 排除定制干扰 |
| 3 | 升级前执行 clearcfg（清根） | 避免旧配置影响新版本启动 |
| 4 | 临时禁用自动回滚机制 | 便于观察真实失败原因 |
| 5 | 升级并查看串口日志 | 定位具体服务/校验失败点 |
| 6 | 确认无误后重新启用自动回滚 | 恢复生产环境可靠性 |
具体执行方法 步骤 1：彻底清理本地构建环境# 删除 conan 缓存
conan remove "*" -f
# 清理 bingo 构建产物
bingo clean --all
# 删除临时目录
rm -rf /tmp/openubmc_build /dev/shm/upgrade
关键点： 必须确保使用的是
br_release_openUBMC2512_20261231_LTS_SP1分支的纯净代码。
步骤 2：使用标准流程构建 Release 版本# 构建 release 包（必须指定 -bt=release）
bingo build -b openUBMC -r openubmc_dev -bt release
# 打包 HPM 文件
bingo packethpm
注意： debug 构建可能带调试服务导致行为差异，版本发布必须用
-bt=release（见 DC7）。
步骤 3：升级前清根（clearcfg）通过命令行或 BMC 工具清除当前配置：
# 登录 BMC 后执行
ipmcset -d clearcfg
目的： 解决因配置版本不兼容导致的服务启动失败，如
product_mgmt启动报错 “unknown object path error on the dbus”。
步骤 4：临时禁用自动回滚机制通过串口或调试接口关闭自动回滚功能，避免升级后立即切换：
# 禁用快速回滚机制
echo "disable_quick_rollback" > /proc/bmc_upgrade/control
或通过内核参数
rollback_disabled=1临时关闭。
步骤 5：升级并观察串口日志（最关键步骤）.hpm 包进行升级；[maca] StartupCheck failed for redfish
[firmware_mgmt] verify signature error
[FWUPD] rootfs tmp verify fail, ret:-22
[bmc_upgrade] decompress_img.lua: Failed to exec /bin/tar
建议： 录制完整串口日志，上传至论坛以供进一步分析。
步骤 6：检查 rootfs 分区与镜像大小是否匹配ls -l build/images/rootfs.img
rootfs_a 和 rootfs_b 的大小是否足够容纳该镜像。
附加建议| 建议项 | 说明 |
|---|---|
 使用一键日志收集工具 |
收集 app.log, framework.log, m3_log, kernel log 打包上传 |
| 检查 manifest.yml 是否声明所有必要组件 |
确保包含 redfish, web_backend, dcmid 等服务 |
| 启用 manufacture 模式构建用于调试 |
便于调试签名与启动过程 |
| 论坛求助时提供 SHA256 哈希值 |
方便他人验证包完整性 |
参考资料与链接
官方下载地址：https://www.openubmc.cn/zh/download（openUBMC 25.12 LTS SP1 发布页） SDK 仓库：https://conan.openubmc.cn/openubmc_25.12 文档中心：https://discuss.openubmc.cn 相似案例参考：
总结您遇到的问题是典型的 “升级成功但回滚” 现象，由构建包与运行环境不一致引发，触发了 BMC 的自动回滚机制。
根本原因在于：构建配置不当 → 关键服务缺失/启动失败 → 自动回滚 → 回到旧版本。
最佳实践建议：-bt=release；clearcfg；完成上述流程后，升级应能稳定生效。
如问题持续，请提供 完整串口日志 + HPM 包 SHA256 值 至 OpenUBMC 官方论坛，我们将进一步协助排查。
734d33a9a078a71f0bb485dbd144b076d0de97fc4d05a8e8d4fcc1eb54215bc9 output/rootfs_openUBMC.hpm
a7e4c38191b841de81bebd2ba2f23a671f99ce22df16ec4d34703c57814eaba3 output/rootfs_S920X20.hpm
S920X20_null_19700101-0800.tar.gz (8.4 MB)
一键收集的日志
解决了没，一般先去fremework.log看看maca组件有没有什么异常打印