问题描述
如题
为什么通过ipmitool带外命令修改fru的内容断电重启后会失效？这个命令只是临时修改吗？
环境信息
-
操作系统：[如 Ubuntu 24.04]
-
软件版本：[如 OpenUBMC2506]
答案内容由AI生成，仅供参考：
总结
| 问题 | 原因 | 解决方案 |
|---|---|---|
fru edit 修改重启后失效 |
1. EEPROM 写保护开启 2. 未执行 refresh 刷新3. 系统启动时覆盖数据 4. fru edit 修改未真正写入 |
1. 关闭写保护 2. 执行 ipmitool raw 0x06 0x063. 检查启动逻辑是否重载 FRU 4. 确保目标区域有初始数据 |
点击此处查看详细分析解答
为什么通过 ipmitool 修改 FRU 内容后，重启或断电后会失效？
根据您提供的上下文信息和操作日志分析，通过 ipmitool fru edit 命令修改的 FRU 内容在重启或断电后失效，通常是因为修改未能持久化写入底层存储（如 EEPROM），或者系统在重启时从其他数据源重新加载了原始的 FRU 数据。
下面将从技术原理和具体原因两个层面进行详尽解释：
一、FRU 数据的存储与持久化机制
FRU（Field Replaceable Unit，现场可更换单元）信息是服务器硬件管理的核心数据之一，通常包括：
- 制造商（Board Mfg）
- 产品名称（Product Name）
- 序列号（Serial Number）
- 部件号（Part Number）
- 生产日期等
这些信息一般存储在硬件模块的 EEPROM 或 SPI Flash 中，并通过 BMC（基板管理控制器）读取和管理。
正常流程应为：
- 使用
ipmitool fru edit修改数据 - 工具将新数据写入目标设备的 EEPROM
- 数据被永久保存，即使断电、重启也不会丢失
但在您的案例中，修改后数据未被持久化，说明该流程未完整执行。
二、导致修改失效的常见原因分析
结合您提供的日志及知识库内容，以下是可能导致“重启后修改失效”的关键原因：
1. 目标设备的 EEPROM 写保护未关闭
即使 fru edit 命令成功执行并显示 “Writing new FRU. Done.”，但如果目标 FRU 设备的 EEPROM 写保护（Write Protect）未关闭，则写入操作实际上不会生效。
知识库佐证：
- 文档 Chunk 1 提到：“有几个器件的fru报Device not present”，且用户尝试
fru write失败。- 虽然
eeprom的写保护看起来是关闭的（通过mdbctl查看），但可能是特定 FRU 设备的物理写保护引脚或软件锁仍然生效。
建议检查项：
- 确认目标 FRU（ID=1，ExpBoard20）的 EEPROM 是否支持写入
- 检查是否启用了硬件写保护（如 WP 引脚拉高）
- 查看 BMC 是否通过 GPIO 或 I²C 控制了写保护开关
2. 修改的是“临时”内存副本，而非真实 EEPROM
某些 BMC 实现中，FRU 数据会被加载到内存中供快速访问。ipmitool fru edit 可能只修改了内存中的副本，而没有触发将数据刷新回持久化存储（EEPROM）的操作。
- 实体
0x06描述中提到：0x06 triggers a refresh of the FRU data into EEPROM。- 这意味着，在修改 FRU 后，必须触发 NetFn 0x06 的
refresh操作，才能将变更写入 EEPROM。- 如果未显式或自动执行此刷新操作，则数据仅停留在内存中，重启即丢失。
解决方案建议：
# 在修改完 FRU 后，手动执行 refresh 命令（示例）：
ipmitool raw 0x06 0x06
该命令使用 IPMI Raw 指令调用 NetFn=0x06, CMD=0x06，用于刷新 FRU 数据到 EEPROM。
3. 系统重启时重新从固件/配置文件加载原始数据
在一些 OpenUBMC 系统中，BMC 启动时会从预定义的配置文件（如 .bin 文件或 CSR 模型）重新生成或覆盖 FRU 数据，导致手动修改的内容被重置。
- 实体
Frudata表示其负责管理 FRU 数据，并在系统启动时初始化。frudata_app.lua脚本在重启时参与 FRU 数据的重建和管理。- 若系统配置为“启动时恢复默认 FRU 数据”，则外部修改会被覆盖。
建议排查点：
- 检查 FRU 数据源是否来自一个静态文件（如
fru.bin） - 查看
FruData_Expander配置中是否设置了固定路径或只读模式 - 确认是否启用了“生产模式”或“出厂固化”策略，阻止运行时修改
4. fru edit 命令本身限制：必须在已有数据基础上修改
IPMI 的 fru edit 命令有一个重要限制：不能对空的或未初始化的 FRU 区域进行写入。
- 文档 Chunks 中明确指出：
fru edit must modify fields with existing content, otherwise error occurs.- 您的操作日志显示：“Read All FRU area”、“Copying remaining of sections”，表明是在已有结构上修改字符串。
- 但如果原始数据结构损坏或部分为空，写入可能不完整。
风险提示：
虽然命令提示“Done”，但若底层数据结构不合法，EEPROM 可能拒绝写入或仅部分写入，导致重启后恢复旧数据。
如何确保修改持久有效？
以下是推荐的操作流程，以确保 FRU 修改在重启后依然生效：
解决方案步骤：
-
确认目标设备可写
ipmitool fru print 1确保设备状态为“present”，且无“Device not present”错误。
-
检查并关闭 EEPROM 写保护
- 通过 D-Bus 或
mdbctl查看eepromwp状态 - 如必要，使用命令关闭写保护（具体指令依赖硬件设计）
- 通过 D-Bus 或
-
使用
fru edit修改内容ipmitool fru edit 1 field p 0 'linkedhope' -
强制刷新 FRU 数据到 EEPROM
ipmitool raw 0x06 0x06该命令触发 NetFn=0x06 的 refresh 动作，确保数据落盘
-
重启系统并验证
ipmitool chassis power cycle sleep 30 ipmitool fru print 1确认
Product Manufacturer仍为'linkedhope' -
（可选）检查后台是否有自动恢复机制
- 查看
frudata_app.lua是否在启动时重载了默认数据 - 检查 CSR 配置或
Board_Name_OpenUBMC是否强制同步固件内嵌数据
- 查看
补充说明：0x06 的关键作用
| 属性 | 说明 |
|---|---|
| NetFn Code | 0x06 是 IPMI 协议中的网络功能码，用于识别命令类别 |
| Subcommand | 0x06 作为子命令，表示 Refresh FRU Inventory Area |
| 功能 | 将内存中修改后的 FRU 数据写回到 EEPROM 存储器中 |
| 必要性 | 若不调用，修改可能仅在内存中生效 |
fru edit不足以保证持久化，必须配合ipmitool raw 0x06 0x06命令完成刷新！
总结
| 问题 | 原因 | 解决方案 |
|---|---|---|
fru edit 修改重启后失效 |
1. EEPROM 写保护开启 2. 未执行 refresh 刷新3. 系统启动时覆盖数据 4. fru edit 修改未真正写入 |
1. 关闭写保护 2. 执行 ipmitool raw 0x06 0x063. 检查启动逻辑是否重载 FRU 4. 确保目标区域有初始数据 |
最终建议：
在通过
ipmitool fru edit修改数据后，务必执行ipmitool raw 0x06 0x06刷新命令，并验证 EEPROM 写保护状态。若仍失败，请检查系统是否存在启动时从固件重建 FRU 的机制。
如需进一步调试，可通过 busctl 或 frudata_app.lua 日志分析 FRU 数据加载行为。
注意看一下写保护的配置，如果配置的不对，就会有类似的情况，显示写成功了，但AC就恢复了
这个具体得看你们SMC是怎么样的，正常来说这个写保护默认开启，写入会自动关闭，写完，在开启。
正常来说是要进行配置的，要不然BMC也不知道哪个是开哪个是关闭，可以看看下面这个文档CSR配置字典之FruData类 | 文档中心 | openUBMC ，除了这个写保护问题，还有一个情况你的StorageType的问题，如果解析失败，是会默认显示Huawei，Huawei的，然后通过ipmitool写入的内容是没有实际写入到eeprom里面的