ajie9115
(翁英杰 苏州科达)
1
问题描述
bmc模组，刚拿到手的时候里面是ibmc的系统，通过ibmc的网页升级了自己本地编译的openUBMC（25.12.01.01），升级成功，可以进入openUBMC的网页。
然后本地再次编译openUBMC 将版本号加一 (25.12.01.02) 得到新的hpm包。
在openUBMC（25.12.01.01）的网页里面升级25.12.01.02版本的openUBMC， 网页提示升级成功了，但是自动重启后进入的还是老的25.12.01.01的系统。
环境信息
- 软件版本：[OpenUBMC25.12-LTS-SP2]
期望结果
希望可以进入新的25.12.01.02的系统
实际结果
实际进入的还是老的25.12.01.01的系统
分析结论
升级的时候，老系统25.12.01.01位于mmcblk0gp0分区，通过查看升级日志 目的分区应该是mmcblk0gp2
重启后 进入了老的25.12.01.01系统，尝试挂载mmcblk0gp2
发现 mount /dev/mmcblk0gp2 /mnt 会挂载失败 伴随内核mmc的报错：
尝试使用 mount -o ro,noload /dev/mmcblk0gp2 /mnt/ 可以挂载成功 读取gp2分区里的/etc/version.json 也确实是25.12.01.02系统
所以在怀疑是否是存储有问题 导致在启动的时候 去加载gp2分区里的新系统的时候失败了 继而回退到了gp0分区里的老系统？ 是否是存储硬件上的问题 还是软件上的问题
也尝试查看bmc模组升级后 自动重启的串口日志 里面并没有gp2失败 加载gp1之类的日志。
烦请各位大佬们帮忙看看，感谢。
UbmcUpdateUbmc.txt (262.9 KB) 网页升级到下次重启进入系统抓取的/var/log/app.log
ubmc-up.txt (36.2 KB) 重启后输出的串口日志
答案内容由AI生成，仅供参考：
根据您提供的上下文信息，我将为您分析openUBMC网页升级成功后自动重启却回退到旧系统的问题。
问题分析
您遇到的问题（升级成功，但重启后回退到旧版本）在openUBMC系统中是一个已知现象。根据知识库和提供的文档，这种情况通常与以下几个原因有关：
1. 根本原因：升级后的启动检查失败触发回滚机制
这是最核心的原因。根据《微组件管理介绍》文档，openUBMC具有一套严格的启动状态检查机制。在BMC升级后，系统会检查各个组件的启动状态。
- 触发条件：升级后，如果微组件（MACA组件）的启动状态检查连续失败2次，系统会自动触发分区切换，回滚到升级前的旧版本。
- 机制目的：这是系统的一种安全保护机制，当新版本的固件因为某种原因（如文件系统损坏、配置不兼容、硬件驱动问题等）无法正常启动时，系统会自动切回已知的稳定版本，避免BMC“变砖”。
这与您的现象高度吻合：升级过程看似成功（100%，State=Completed），但重启后新系统未能正常完成启动检查，导致系统认为新版本“不健康”，从而自动回滚。
2. 确认版本回退的方法
根据论坛专家 linyao 的回复，确认版本是否回退可以通过以下两点：
- 查看版本号：在Web首页或“固件升级 → 版本信息”界面，查看当前主分区的版本号是否为您构建的
25.12.01.02。
- 检查构建时间：使用命令
ipmcget -d version 查看Active分区的构建时间，如果时间与您出升级包的时间不一致，则说明系统已回滚。
3. 您提到的 mmcblk0gp2 挂载问题
您发现 mount /dev/mmcblk0gp2 /mnt 失败，但 mount -o ro,noload /dev/mmcblk0gp2 /mnt/ 可以成功，这强烈暗示了该分区（gp2）上的文件系统存在不一致或损坏。
- 根因推断：
read-only (ro) 和 noload 选项跳过了文件系统日志的回放和检查，所以能挂载。而普通挂载尝试回放日志时失败，这通常意味着文件系统元数据损坏。
- 结论：这更倾向于是一个软件/文件系统问题，而不是硬件存储故障。可能是升级过程写入数据时发生了错误，或者新固件中的文件系统有缺陷，导致内核无法正常挂载。
4. 双镜像分区的工作机制
- 升级原理：openUBMC使用A/B双分区架构。升级时，新固件被写入备用分区（您这里的
mmcblk0gp2），然后系统重启，尝试从备用分区启动。
- 回滚原理：如果从备用分区启动失败（例如，文件系统挂载失败，或启动状态检查失败），系统会触发回滚机制，切回主分区（
mmcblk0gp0）的旧版本启动。这解释了为什么您重启后看到的还是旧系统。
解决方案与建议
根据《升级常见问题指南》和《微组件管理介绍》中的描述，您可以尝试以下步骤：
方案一：手动切换回新版本（直接尝试启动新分区）
- 通过串口登录BMC。
- 切换串口到BMC侧（如果串口默认在OS侧）：
ipmcset -d serialdir -v 1
- 强制切换到新版本所在分区（gp2）：
ipmcset -d rollback
注意：rollback 命令会将系统切换到备用分区启动。如果您确认 gp2 是备用分区，此命令应将系统切到 25.12.01.02 版本。
- 重启BMC：
reboot
- 观察新系统是否能正常启动。如果仍无法启动，请检查串口日志，看是否再次触发回滚。
方案二：修复文件系统并重新升级
如果方案一失败，说明 gp2 分区的文件系统确实存在问题，需要先修复。
- 从旧系统（gp0）启动，进入系统。
- 尝试修复 gp2 分区的文件系统：
fsck -y /dev/mmcblk0gp2
注意：fsck 命令可能因您的系统缺少该工具而无法使用。如果不可用，请跳过此步骤。
- 重新上传并升级
25.12.01.02 的 HPM 包。这次升级会覆盖 gp2 分区的内容，可能修复之前损坏的文件系统。
- 观察重启后是否能正常进入新系统。
方案三：恢复出厂设置（最后手段）
如果以上方案均无效，可以尝试恢复出厂设置，这可能会清除所有配置并重置分区状态。
- 在Web界面：通常可以在“维护”或“系统管理”菜单中找到“恢复出厂设置”选项。
- 通过串口：使用命令
ipmcset -d factory 进行恢复。请谨慎使用，此操作会清除所有用户配置。
ajie9115
(翁英杰 苏州科达)
5
问题已解决
上述问题还是因为我制作hpm包的方式不对
ibmc升级到ubmc的升级包 和 ubmc升级ubmc的升级包 他们的制作方法应该是不同的。
至于为什么升级了一个不对的hpm后 导致挂载时的emmc报错还不清楚。
提供一下我目前测试OK的操作步骤：
1.刚拿到手里的bmc模组 hi1711的 里面自带的是ibmc
2.制作用于ibmc升级ubmc的升级包：
参考 自签名CA创建以及HPM签名指导 在manifest里配置了自己生成的一些证书
参考 BMC 3.xx.xx.xx版本升级openubmc指导 修改了一些manifest里的配置
完成修改后 编译了一个openUBMC的hpm包 (25.12.01.01)
3.在ibmc的网页上 升级自己构建的openUBMC 可以升级成功 导入ssl密钥后 也可以开启openUBMC的网页
4.制作用于ubmc升级ubmc的升级包：
重新拉取一个新的manifest 仅修改一个里面的版本号 改成 25.12.01.02 (需回退2里面修改的系统目录下的改动) 再编译一个openUBMC的hpm包
5.然后在openUBMC (25.12.01.01)的网页上 升级新编译openUBMC-25.12.01.02 升级成功后可以进入25.12.01.02的新系统
请教一下，你们BMC的PHY是哪个型号。需要在BMC里面配置吗
ajie9115
(翁英杰 苏州科达)
7
bmc模组应该是买的hi1711的模组 你说的phy应该就在模组里面的 这都是内核里调好的吧 不用配啥吧
