版本：2509
在执行配置更新操作时，配置文件导出正常
导入时，会卡在91%不动，也会出现失败报错
这种情况应该如何定位呢？
答案内容由AI生成，仅供参考：
总结
| 项目 | 内容 |
|---|---|
| 最可能原因 | 配置导入触发 BIOS 恢复默认配置，且 BIOS 配置写入失败，导致流程阻塞在后期阶段（约91%） |
| 辅助原因 | 配置文件缺少 Components 字段、关键服务缺失、OMS 处理异常 |
| 推荐动作 | 检查 app.log 日志、验证配置文件结构、升级至 25.2.0+ 版本 |
| 临时规避方案 | 手动配置替代导入，或分步导入（先 openUBMC，再 BIOS） |
建议在非关键时段进行测试，并备份当前配置以防意外丢失。
点击此处查看详细分析解答
openUBMC 2509 版本配置文件导入卡在91%问题分析与定位
在使用 openUBMC 2509 版本进行配置文件导入时，出现进度卡在 91% 无法完成或导入失败的问题，需要结合系统行为、日志信息和已知问题进行综合分析。以下是详细的定位步骤与可能原因。
问题现象总结
- 软件版本：OpenUBMC2509
- 操作流程：
- 配置导出正常（生成
config.json文件） - 配置导入时进度条卡在 91%
- 偶尔伴随“导入失败”提示
- 配置导出正常（生成
- 用户界面：通过 Web 界面的 openUBMC管理 → 配置更新 → 配置导入 功能操作
可能原因分析
根据知识库内容及 openUBMC 系统机制，导致该问题的原因可能有以下几类：
1. BIOS 配置恢复触发阻塞
关键证据来自文档 chunk 1
- 在 OpenUBMC2509 中，配置导入功能会触发 BIOS 恢复默认设置。
- 日志显示：
2026-03-12 15:26:04 WEB,Administrator@192.168.34.16,BIOS, Restoring BIOS Setup default settings issued successfully... - 虽然 BIOS 配置被重置，但后续日志显示
"BIOS configuration failed"，说明配置应用过程异常。 - 推论：在导入过程中，当执行到 BIOS 配置写入阶段（可能对应进度91%），因 BIOS 接口调用失败或响应超时，造成整体流程卡住或中断。
此阶段恰好处于导入后期，吻合“卡在91%”的现象。
2. 组件字段缺失导致部分导入失败
来自知识图谱实体与关系分析
Configuration File必须包含Components字段，否则会导致导入失败。- 关系：
Components -(required for)-> Configuration File“The import process fails because the configuration file does not contain a Components field, which is required.”
- 如果导出的
config.json文件缺少顶层Components键，则系统无法完整解析，可能导致特定阶段（如服务初始化或组件注册）失败。
虽然文件能上传并通过前端校验，但后端处理时若发现结构不全，可能在后期处理阶段失败。
3. 某些组件缺失或未启动（如 firmware_mgmt, maca 等）
来自知识图谱：
firmware_mgmt,maca,hwproxy,hwdiscovery是 required component missing from openUBMC project
- 导入过程依赖多个后台服务协同工作，例如：
oms：负责记录事件Import Configuration Startedthermal_mgmt：接收温度策略配置BIOS：接收 BIOS 设置firmware_mgmt：可能参与配置校验或数据迁移
若关键后台服务缺失或异常，可能导致任务执行中止，表现为前端卡住。
4. Oms 系统处理延迟或异常
来自日志记录：
Import configuration started
...
The configuration import was partially successful
Oms是配置导入事件的接收与分发中心。- 前端显示“导入中”，实际由 OMS 协调各微服务处理。
- 若 OMS 处理缓慢、任务队列堆积或通信超时，前端无法及时获取状态更新，导致进度条停滞。
91% 可能表示“已接收文件并完成解析，正在向各组件分发”，此时等待 OMS 或组件响应。
定位步骤建议
以下为具体的故障排查与定位方法：
步骤 1：检查系统日志（app.log）
路径：
/var/log/app.log
搜索关键词：
"Import configuration started"
"configuration import was partially successful"
"BIOS configuration failed"
"error" after timestamp of import
重点关注：
- 是否有
BIOS返回错误码？ thermal_mgmt是否成功应用了策略？oms是否报告任务中断？
示例：
2026-03-12 15:26:04 ... BIOS, BIOS configuration failed
步骤 2：验证配置文件结构完整性
打开 config.json，确认是否存在以下顶层字段：
{
"Components": { ... },
"openUBMCVersion": "25.09",
...
}
重点检查：
- 是否包含
"Components"字段？ 必须存在 openUBMCVersion是否匹配当前版本？
不匹配可能引发兼容性警告
提示：即使导出正常，某些定制化版本可能未正确序列化所有组件。
步骤 3：确认是否触发 BIOS 重置副作用
观察日志中是否有：
Restoring BIOS Setup default settings issued successfully
若有，则说明：
- 导入流程主动触发了 BIOS 默认化
- 若随后无
"BIOS configuration applied"成功日志 → 说明写入失败
已知问题：OpenUBMC2509 导入配置会导致 BIOS 恢复默认值，这是一个设计缺陷或副作用。
步骤 4：检查后台服务运行状态
通过 SSH 登录 BMC，执行：
ps | grep -E "(oms|firmware_mgmt|thermal_mgmt|maca)"
确认关键服务是否运行。
若
maca、firmware_mgmt等缺失，需检查镜像是否完整构建。
步骤 5：尝试最小化配置导入测试
创建一个极简 config.json，仅包含必要字段：
{
"openUBMCVersion": "25.09",
"Components": {}
}
测试能否顺利导入。若成功，则原文件中某组件配置存在兼容性问题。
已知问题汇总（来自 Context）
| 问题 | 描述 | 关联性 |
|---|---|---|
 配置导入触发 BIOS 恢复默认 |
在 OpenUBMC2509 上确认存在 |  高度相关 |
| Components 字段缺失导致失败 |
结构性要求，否则解析失败 | 相关 |
| Import 功能未能更新 User5 状态 |
表明导入逻辑存在缺陷 | 相关 |
| firmware_mgmt 等组件缺失 |
影响配置处理流 | 相关 |
解决建议
-
升级至 openUBMC 25.2.0 或更高版本
openUBMC 25.2.0已引入 RAID卡管理解耦等新特性，可能修复了配置管理模块的稳定性。- 更完善的组件管理和导入机制有望解决当前问题。
-
避免在生产环境频繁使用配置导入
- 当前版本存在副作用（BIOS重置），建议仅用于一次性部署。
-
手动补录 BIOS 配置
- 若必须使用配置导入，导入完成后需手动重新配置 BIOS 关键项。
-
反馈给社区并提交日志
- 向 openUBMC 论坛提交
app.log及config.json（脱敏后）以协助定位。
- 向 openUBMC 论坛提交
总结
| 项目 | 内容 |
|---|---|
| 最可能原因 | 配置导入触发 BIOS 恢复默认配置，且 BIOS 配置写入失败，导致流程阻塞在后期阶段（约91%） |
| 辅助原因 | 配置文件缺少 Components 字段、关键服务缺失、OMS 处理异常 |
| 推荐动作 | 检查 app.log 日志、验证配置文件结构、升级至 25.2.0+ 版本 |
| 临时规避方案 | 手动配置替代导入，或分步导入（先 openUBMC，再 BIOS） |
建议在非关键时段进行测试，并备份当前配置以防意外丢失。
导出一键收集日志，看看app.log有什么相关报错
我这边使用最小的配置文件：
{
“openUBMCVersion”: “25.09”,
“Components”: {}
}
可以成功导入，但是导入我自己的配置文件（当前环境导出的），就会卡在91%不动，附件有app.log和config.json，麻烦您看一下
config.txt (140.1 KB)
app.txt (190.5 KB)
根据app.log，frudata初始化阶段读电子标签失败，请问该环境能正常查询frudata对象吗
在导入阶段，frudata有如下报错
2026-03-26 09:36:51.235527 frudata ERROR: manage.lua(239): get fru(0) info faild.
2026-03-26 09:36:51.235605 alarm ERROR: frudata_handler.c(1043): [frudata]get_fru_file_by_id: get fru info failed, fru_id = 0
2026-03-26 09:36:51.236219 frudata ERROR: frudata_service.lua(147): write_fru_area failed. fru_id = 0, ret=...c/apps/frudata/lualib/frudata_object/frudata_tianchi.lua:57: get frudata failed, fru_id = 0
建议修改下标题为， 配置导入frudata配置项失败，标签打上Hardware Sig，由 Hardware Sig 的人来帮忙定位。
好的非常感谢
frudata应该是归属bmc_core sig
好的谢谢，已更改