BMC 3.01.00.10版本升级 openubmc失败

embedway-xiewenlong · 2026 年5 月 9 日 02:46

问题描述

参考着BMC 3.xx.xx.xx版本升级openubmc指导的指导升级BMC，
但是升级到67%左右的时候查看BMC串口发现内核panic报错自动重启了；

按照指导文档里确认修改了步骤3的 BMC->iBMC，还会是什么问题？麻烦指导下

环境信息

软件版本：openUBMC 25.12 LTS SP1

ubmc_assistant · 2026 年5 月 9 日 02:51

答案内容由AI生成，仅供参考：

结论

您的升级失败根本原因极有可能是：

OpenUBMC 固件在构建时未正确配置 Hi1711 平台的设备树（尤其是 reserved memory），导致系统启动时 init 进程因内存访问异常崩溃，触发 Kernel Panic。

尽管升级进度显示 67%，但此阶段可能仅为固件写入完成，尚未完成完整启动验证。

点击此处查看详细分析解答

BMC 3.01.00.10 升级 OpenUBMC 失败问题分析与解决方案

您在尝试将 BMC 版本 3.01.00.10 升级至 OpenUBMC 25.12 LTS SP1 时，遇到了在升级进度达到 67% 左右触发内核 Panic 并自动重启 的问题。尽管已按照官方指导修改了 manifest.yml 中的 manufacture: true 配置，仍出现故障。

以下是对该问题的全面分析及解决建议。

问题现象总结

升级过程：使用 OpenUBMC 固件包通过 Web 界面进行升级。
失败节点：升级进度显示约 67%，串口日志中出现 Kernel Panic。

关键错误日志：

kernel panic - not syncing: Attempted to kill init! exitcode=0x00000000b
CPU: 2 PID: 1 Comm: init Tainted: G        O   5.10.0 #1
Hardware name: Hisilicon Hi1711 ASIC (DT)
Call trace: ...
Rebooting in 1 seconds...

结果：系统自动重启，升级失败或回退到原 iBMC 版本。

根本原因分析

根据知识库中的信息和社区经验，结合内核 Panic 的典型特征，可能的原因包括：

1. 构建固件时配置不完整或不兼容

虽然已设置 manufacture: true，但可能存在其他构建配置未正确适配目标硬件平台（如 Hi1711），导致系统在初始化阶段无法启动 init 进程。

已知关键点：
在首次从 iBMC 升级到 OpenUBMC 时，必须确保：

manifest.yml 中的 account.option.manufacture: true

使用正确的根文件系统镜像：rootfs_openUBMC.img（不能是 rootfs_iBMC.img）

分区命名、激活策略标准化

若上述任一环节出错，可能导致新系统启动时服务初始化失败。

2. 内核模块或驱动不兼容（Hi1711 平台特有）

错误发生在 init 进程启动阶段，且硬件为 Hi1711，表明可能是以下问题之一：

缺少适配 Hi1711 的设备树（Device Tree）或设备树配置错误
必需的内核模块（如存储、网络驱动）未正确编译进镜像
内存保留区（reserved memory）或地址映射配置错误，导致 init 被异常终止

日志线索提示：
write reserved mem: make sure reserved mem had configure? returned -22
此错误明确指出系统尝试写入保留内存区域失败，说明 设备树中关于 reserved memory 的定义缺失或配置不当，是引发 init 崩溃的直接技术原因。

3. 固件包签名或完整性验证失败

尽管是社区无签名版本，部分系统仍可能因启用安全启动（Secure Boot）或校验机制而导致执行中断。

提示：OpenUBMC 构建系统若加入签名校验逻辑（如 2512 版本），但未正确处理 /bin/tar 等命令白名单，也可能导致解包失败（参考文档 chunk 8）。

4. 双分区回滚机制导致“假成功”

即使升级显示 67%，实际可能只是完成了解压和写入部分数据。当新系统首次启动失败时，BMC 会自动切换回 备份分区的旧 iBMC 固件，表现为“升级后变回 iBMC”。

来自文档 chunk 1 的结论：
“并非系统实际回退，而是因构建包携带 iBMC 标识，导致 ipmcget -d v 输出误导性信息。”

解决方案建议

步骤一：确认使用纯净 OpenUBMC 构建环境

确保构建流程完全遵循 OpenUBMC 社区标准：

检查项	是否满足
源码来自官方仓库（如 GitCode）
`manifest.yml` 设置 `manufacture: true`
镜像名称为 `rootfs_openUBMC.img`
不复用旧 iBMC 的配置模板

参考链接：https://discuss.openubmc.cn/t/topic/2372 提供了完整的 manifest.yml 修改指南。

步骤二：检查并修正设备树（Device Tree）配置

针对 Hi1711 平台，需特别验证 .dts 文件中是否正确定义了：

Reserved Memory Regions
Memory Layout 与 U-Boot 一致
NAND/Flash 分区表

建议操作：

查看日志中是否有 FDT_ERR_NOTFOUND 或 no memory reserve 类似报错

对比出厂 iBMC 固件的 FDT 结构，确保 OpenUBMC 使用相同或兼容的设备树

若自定义设备树，请在编译时启用调试信息：CONFIG_OF_RESOLVE=1

步骤三：清理历史残留并禁用自动回滚

为避免旧配置干扰，执行 清根操作：

# 清除所有配置和日志
ipmcset -t maintenance -d clearcfg

# 可选：清除证书、日志、临时文件等
# 手动进入 recovery 模式执行格式化

注意：此操作会丢失所有用户配置！

同时，临时关闭自动回滚机制，以便观察真实启动过程，而非被立即切回旧版本。

步骤四：使用带调试信息的开发版镜像

建议构建一个带有以下特性的开发镜像用于测试：

启用 printk 和早期控制台输出
包含 initramfs 以用于早期调试
开启 kdump 或 ramoops 捕获 panic 日志

这样可以在下一次崩溃时获取更完整的调用栈，定位具体模块问题。

步骤五：联系 PAE 获取专用刷机包

根据文档 chunk 1 中昆仑太科_张红涛和社区指南指出：

“第一次升级失败报错或者升级后回退请联系 PAE。”

PAE（产品支持工程师）可提供：

经过验证的专用刷机包
针对 Hi1711 的定制设备树补丁
跳过签名检查的测试版本

结论