使用最新的社区版本进行构建，构建成功，但是上机验证发现会重启回退
软件版本：openUBMC2603
硬件配置：1711
正常升级不回退
会回退
根据BMC串口日志进行调试，删除tpcm的相关启动配置，仍然报错，下图是对比分析正常日志和重启日志的差异
答案内容由AI生成，仅供参考：
总结| 项目 | 内容 |
|---|---|
| 核心问题 | 新构建版本引入 Secure LiFW 和 tpqm 模块，导致关键服务（如 iam）启动失败，触发系统自动回退机制 |
| 根本原因 | 安全模块与当前硬件平台或配置不兼容，且分区挂载顺序异常加剧系统不稳定 |
| 解决方案 | 移除 tpcm/tpqm/LiFW 相关组件 → 修复分区挂载逻辑 → 检查 iam 服务状态 → 调试期间关闭回退机制 |
| 预防建议 | 在 CI 构建阶段增加“服务完整性检测”脚本，确保 bmc.kepler.iam 等核心服务可注册并启动 |
根据您提供的问题描述、环境信息、日志对比及上下文数据，以下是对“使用社区最新manifest构建成功但上机验证时出现重启回退”问题的全面分析与解决方案。
问题概述
manifest 构建的 openUBMC 固件（debug/release）在实际设备（硬件型号1711）上部署后，系统反复重启并最终自动回退到旧版本。openUBMC26031711Secure LiFW Start 启动项、tpqm 配置错误、分区挂载顺序异常等差异。
根本原因分析结合日志对比与知识库内容，可归纳出以下核心问题点：
S12345678!Secure LiFW Start!
相关证据：
tpqm（可信平台模块管理服务）报错为unknown deployConfig，说明配置文件缺失或格式不兼容。
tpcm/tpqm 组件未正确适配尽管您已尝试删除 tpcm 启动配置，但日志仍提示 tpqm 错误。这表明：
deployConfig 加载失败，意味着这些组件尝试运行但因配置缺失而崩溃，进而影响 devmon 或核心服务（如 iam）启动。
高危风险：若
iam（身份访问管理）组件因依赖缺失无法启动，会触发 BMC 主控进程bmc_core主动自杀重启（见知识库文档 chunk #1）。
| 项目 | 正常 | 异常 |
|---|---|---|
| 分区挂载顺序 | mmcb1k0gp0 → gp1 → gp2 | mmcb1k0gp2 → gp0 → gp1 |
这表明 UBI（Unsorted Block Images）布局或启动参数不一致，可能导致：
/etc, /var/log, /data）；persistence 任务报错（A storm occurs in table t_fructrl_tb，见知识库）；| 项目 | 正常 | 异常 |
|---|---|---|
| devmon 状态 | 多次 FAILED | 启动成功 |
表面看似“改善”，但结合上下文反推：
devmon 是硬件设备监控守护进程。tpcm 驱动而绕过安全检查）。从知识库中可确认以下机制存在：
自动回退触发条件包括：
如文档
#2所述：“升级成功后BMC起不来，然后自动回退成原来5月份的版本。重启原因是bmc_core中的event组件存在内存泄漏”。
在本例中，即使构建和烧录成功，但由于关键组件（如 iam）无法稳定运行，系统通过健康检测机制判定升级失败，触发自动回退。
解决方案建议 方案一：移除可信模块相关配置与组件tpcm/tpqm/LiFW在 manifest.yml 或相应 layer 的 local.conf 中添加：
DISTRO_FEATURES_remove = " tpcm tpqm secure_lifw "
PACKAGE_EXCLUDE += "tpcm-daemon tpqm-utils lifw-loader"
检查以下文件是否含有自动启动脚本：
/etc/init.d/tpcm/lib/systemd/system/tpqm.servicesource 或 exec 的 LiFW 相关注入逻辑若存在且非必要，注释或删除。
方案二：校验并修复 UBI 分区映射与挂载逻辑mtd 分区定义一致性确保 dts 文件中定义的 flash 分区与实际烧录工具匹配：
partition@0 {
label = "gp0";
reg = <0x0 0x800000>;
};
...
fstab 或 ubootenv 中的默认启动分区cat /etc/fstab
# 应明确设定 rootfs 从哪个 MTD 分区挂载
建议强制指定 root=mtd:gp0 或使用 label（如 root=ubi0:rootfs）。
方案三：启用调试模式，捕获 iam 实际启动失败原因添加调试命令查看 iam 是否真的正常运行：
systemctl status bmc.kepler.iam
journalctl -u bmc.kepler.iam --no-pager
如果日志中出现：
The name bmc.kepler.iam was not provided by any .service files
参考知识库 chunk #1，这是典型的 DBUS 服务注册失败，通常是由于：
解决方法：
find /usr/lib/systemd/system -name "*iam*"
ls -l /usr/bin/bmc-iam-daemon
ldd /usr/bin/bmc-iam-daemon | grep "not found"
注意：仅用于调试，生产环境慎用！
ipmcset -d rollback disable
或通过 DBus 调用：
busctl call bmc.kepler.UpdateService /bmc/kepler/UpdateService bmc.kepler.UpdateService SetTimeoutPolicy u 0
如知识库
firmware_mgmt.md所述，TimeoutPolicy=0表示超时不采取复位动作。
验证步骤建议| 步骤 | 操作 | 目的 |
|---|---|---|
| 1 | 使用修改后的配置重新构建镜像 | 排除可信模块干扰 |
| 2 | 刷机后通过串口观察是否仍有 Secure LiFW Start 输出 |
验证模块是否彻底移除 |
| 3 | 检查 dmesg 和 journalctl 输出 |
查看分区挂载是否恢复为 gp0 → gp1 → gp2 |
| 4 | 执行 systemctl list-units --state=failed |
检查是否有服务失败 |
| 5 | 查看 bmc_core 是否再次触发 KILL self |
判断升级是否通过健康检查 |
总结| 项目 | 内容 |
|---|---|
| 核心问题 | 新构建版本引入 Secure LiFW 和 tpqm 模块，导致关键服务（如 iam）启动失败，触发系统自动回退机制 |
| 根本原因 | 安全模块与当前硬件平台或配置不兼容，且分区挂载顺序异常加剧系统不稳定 |
| 解决方案 | 移除 tpcm/tpqm/LiFW 相关组件 → 修复分区挂载逻辑 → 检查 iam 服务状态 → 调试期间关闭回退机制 |
| 预防建议 | 在 CI 构建阶段增加“服务完整性检测”脚本，确保 bmc.kepler.iam 等核心服务可注册并启动 |
参考资料firmware_mgmt 接口文档 — Rollback, TimeoutPolicy, UpgradeFinishSignalopenUBMC 社区讨论记录 — 昆仑太科_安阳阳 解决升级失败问题的经验
社区建议：若此问题普遍存在于
openUBMC2603的社区包，请向社区提 issue，请求将tpcm/tpqm设为可选 feature，默认关闭。
如需进一步协助（例如分析完整的 .txt 日志文件），欢迎上传具体内容片段。
社区26年330_Q1构建的包会回退 - 交流互助区 - openUBMC 论坛 看下这个帖子，是不是相同的问题。或者看下本地bingo的版本，有没有什么变更。
参考这个帖子已经解决