问题描述
1、920BS机型调用装备定制化接口BMCSet_RedfishCustomManuName设置厂商名称无法立即生效，需要重启bmc后定制信息才可以成功；
2、重启生效后，再次保留配置升级bmc，升级完成后发现BMCSet_RedfishCustomManuName对应的厂商名称被改回openubmc
期望结果
执行完装备定制化接口后应该立即生效，保留配置升级bmc版本也应该保存配置信息
答案内容由AI生成，仅供参考：
关于 BMCSet_RedfishCustomManuName 定制厂商名称不即时生效及升级后丢失的问题分析与解决方案
根据您提供的详细信息，您在使用装备定制化接口 BMCSet_RedfishCustomManuName 设置 Redfish 接口厂商名称时，遇到了两个核心问题：
- 设置后无法立即生效，需重启 BMC 才生效；
- 保留配置升级 BMC 固件后，定制的厂商名被重置为
openUBMC。
以下基于知识图谱、文档碎片和外部检索结果，对这两个问题进行系统性分析并提供解决方案。
问题一：BMCSet_RedfishCustomManuName 设置后不立即生效，需重启 BMC
根本原因分析
尽管您已通过 D-Bus 成功调用 Import 接口将 BMCSet_RedfishCustomManuName="JD" 写入配置，并可通过 Export 验证配置已写入内存数据库（ConfigData），但 Redfish 接口仍返回：
"Oem": {
"openUBMC": { ... }
}
这表明 配置虽已写入，但未触发 Redfish 服务的动态刷新或未重新加载配置上下文。
推论依据如下：
-
知识图谱中明确指出：
BMC Restartis a system-level operation required to reload sensor configurations after modifications.
Performing a BMC restart resets the system state and ensures that sensor values and alert data become consistent.虽然
BMCSet_RedfishCustomManuName不是传感器配置，但其属于 全局 BMC 静态属性，通常由构建阶段或 BMC 启动初始化流程加载。运行时修改该值后，不会自动广播到所有依赖组件（如 Redfish 服务）。 -
检索结果中的《BMC Studio 使用指导》提到：
“文件会自动生效到 Qemu，并重启对应子系统进程。重启后，接口信息会发生更改。”
表明：要使配置生效，需要服务或组件重启。
-
Redfish 接口在 BMC 启动时初始化 Oem 命名空间，若未设计运行时热更新机制，则不会监听运行态的 CSR 配置变更。
解决方案：执行服务级重启或动态重载
方案 1：重启 Redfish 相关服务（推荐非破坏性方式）
尝试仅重启依赖此配置的服务，避免整机 BMC 重启：
# 重启 web_backend 和 redfish 相关服务
systemctl restart bmc.kepler.web_backend
systemctl restart bmc.kepler.redfish
或使用 busctl 发送热重载命令（若支持）：
busctl call bmc.kepler.config_mgr /bmc/kepler/config_mgr bmc.kepler.ConfigManager Reload
若系统支持运行时重载（Runtime Reload），此操作可避免重启。
方案 2：使用平滑重启接口（Graceful Reset）
可调用资源协作接口进行“平滑重启”，最小化业务中断：
busctl call bmc.kepler.reset_mgr /bmc/kepler/reset_mgr bmc.kepler.ResetManager GracefulReset y 0
注：
0表示从正常系统启动。该方式优于强制重启，符合 openUBMC 设计规范。
方案 3：确认配置是否支持运行时生效
查阅 product_mgmt 组件是否对 BMCSet_RedfishCustomManuName 支持动态绑定。
多数此类“装备定制项”在 BMC 启动阶段由初始化脚本读取并固化到 Redfish Schema 中，运行时修改不触发 Schema 重建。
结论：目前来看，BMCSet_RedfishCustomManuName 并非设计为运行时可动态刷新的参数，故 必须通过重启服务或 BMC 才能生效，这是预期行为。
问题二：保留配置升级 BMC 后，厂商名回退为 openUBMC
根本原因分析
您在升级 BMC 固件后，发现即使“保留配置”，BMCSet_RedfishCustomManuName 的值仍被重置为 openUBMC。
主要原因来自 持久化机制层级缺失 与 固件包构建逻辑覆盖。
原因 1：BMCSet_RedfishCustomManuName 属于“静态构建期配置”，不纳入运行时持久化
根据知识图谱及文档：
-
BMCSet_RedfishCustomManuName是 装备定制化阶段的高优先级字段，其值应在 固件构建时写入 CSR 配置文件，而非运行时动态写入。 -
检索结果《持久化机制介绍》指出：
掉电持久化 (PoweroffPer)：BMC掉电后需保留的数据，存储于nandflash文件系统中，BMC 深度还原或恢复出厂设置后数据将被清除。
但
BMCSet_RedfishCustomManuName往往存储在 固件镜像的只读 CSR 区域 或由构建系统注入，不在 PoweroffPer 数据库中。
因此，即使运行时修改了该值，升级过程中的“解包-合并-应用”流程可能未将其纳入增量配置合并范围，导致被默认值覆盖。
原因 2：升级流程触发 datafs_reset 或深度还原（见检索案例）
检索结果《网络管理常见问题指南》#3.15 明确指出：
“带外IPMI升级BMC成功后，BMC不通，查看IP变化为初始192.168.2.100；https不通、ssl证书丢失、数据库字段丢失”
根因是环境升级前设置了datafs_reset标志，触发了深度还原导致分区数据全部丢失。
类似地，某些升级流程或固件包标记了 datafs_reset，会清除所有运行时持久化数据，包括您通过 API 修改的配置。
解决方案：确保配置持久化且升级流程正确合并
方案 1：将 BMCSet_RedfishCustomManuName 写入 CSR 构建配置（推荐）
最根本的解决办法是：
将
BMCSet_RedfishCustomManuName=JD写入产品型号的 CSR 配置文件中，在构建固件包时固化进去，而不是运行时设置。
例如，在 920BS 的 csr/custom_settings.json 中添加：
{
"CustomSettings": {
"BMCSet_RedfishCustomManuName": {
"Value": "JD"
},
"BMCSet_PackageCustomer": {
"Value": "JD"
}
}
}
然后构建并发布该定制化固件包。如此可确保：
- 升级后自动生效；
- 不依赖运行时配置写入；
- 避免持久化丢失。
方案 2：检查升级包是否启用 datafs_reset
确认升级包中的 update.cfg 或元数据是否包含：
ResetFlag=datafs_reset
或 CSR 中配置：
#define BMCSet_ResetFlag datafs_reset
若有，请移除或改为：
ResetFlag=none
或使用
保留配置升级模式（Retain Configuration Upgrade），确保不触发数据区重置。
方案 3：将运行时配置写入持久化数据库（PoweroffPer）
若必须运行时修改，需确保：
BMCSet_RedfishCustomManuName的写入操作调用persistence服务；- 属性标记为
PoweroffPer类型； - 升级流程支持“配置合并”机制（Config Merge）。
可尝试通过以下命令验证持久化状态：
# 查看是否写入持久化数据库
persistence_cli list | grep BMCSet_RedfishCustomManuName
若无输出，则说明未持久化。
综合建议与最佳实践
| 问题 | 推荐方案 |
|---|---|
| 设置后不生效 | 使用 systemctl restart bmc.kepler.web_backend 或调用 GracefulReset 接口 |
| 升级后配置丢失 | 将 BMCSet_RedfishCustomManuName 固化到 CSR 构建配置中，避免运行时写入 |
| 确保配置持久 | 确认该属性支持 PoweroffPer，并避免升级包含 datafs_reset |
| 调试验证方式 | 使用 busctl 查看服务状态，curl 验证 Redfish 输出 |
验证方法
1. 检查 Redfish 输出是否更新
curl -k -u Administrator:Admin@9000 https://192.168.16.105/redfish/v1/Systems/1
应出现：
"Oem": {
"JD": { ... }
}
2. 检查配置是否导出成功
busctl --user call bmc.kepler.product_mgmt /bmc/kepler/product_mgmt/MicroComponent bmc.kepler.MicroComponent.ConfigManage Export a{ss}s 0 custom
验证返回中是否包含：
"BMCSet_RedfishCustomManuName": "\"JD\""
3. 检查是否持久化
# 查看持久化数据库
find /data -name "*.db" | xargs strings | grep JD
或使用专用工具查看 persistence 数据库。
参考链接
总结
| 问题 | 原因 | 解决方案 |
|---|---|---|
| 修改后不生效 | Redfish 服务未重载或未支持运行时刷新 | 重启 web_backend 或执行 GracefulReset |
| 升级后回退 | 配置未持久化或升级触发 datafs_reset |
将配置写入 CSR 构建文件，禁用深度还原 |
强烈建议：对于
BMCSet_RedfishCustomManuName这类 静态、高优先级定制项，应在固件构建阶段完成配置，而非运行时通过 API 修改，以保证一致性与升级兼容性。
相关链接：
保留配置升级bmc，升级完成后发现BMCSet_RedfishCustomManuName对应的厂商名称被改回openubmc
–—––-------–-------–---------––—–—
应该是出的BMC版本自带了白牌效果，
请在manifest中删除白牌配置
修改这个配置确实可以解决升级BMC后改为openubmc了，感谢！
不过调用接口后还是不能立马生效，需要重启bmc
应该是正常机制
直接修改了manifest/build/product/BMC/openUBMC/wbd_up_file/web_custom.xml文件中的CustomManufacturer属性也能解决了