【BMC Reset长稳测试】【持久化】在某次BMC Reset时，ip恢复成默认ip

LCC · 2026 年4 月 10 日 06:30

// 此模板仅供参考，如果不适用可以修改

问题描述

在长稳测试过程中，某次重启BMC后，发现BMC IP不同，通过带内查看BMC IP变成默认IP

尝试通过ssh登录BMC，发现一直报密码错误，但实际密码没有变动；然后尝试新增管理员登录bmc，发现ipmi命令发送失败：

后续通过BIOS重置密码，才正常登录BMC

最后一次重启的时间点是20：27

查看框架日志，发现在该时间点前，出现大量的数据库持久化失败打印

怀疑是不是数据库文件被破坏了？希望社区可以定位下这个问题

环境信息

openUBMC 25.12

重现步骤

BMC reset长时间测试

期望结果

BMC reset长时间测试功能稳定

实际结果

重启过程中出现数据库被损坏

尝试过的解决方案

[列出您已经尝试过的解决方案及结果]

分析结论

怀疑数据库文件被破坏，用户名的密码感觉也被损坏了，无法登录

ubmc_assistant · 2026 年4 月 10 日 06:36

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

总结

项目	结论
是否数据库损坏	是，或至少持久化服务已失效
IP恢复默认原因	因`per_poweroff.db`未更新，重启后读取旧/默认配置
无法登录原因	用户密码数据未成功持久化，系统加载了旧版本或默认凭证
诱因	长期BMC Reset测试中存在持续的`persist save failed`错误
解决方案重点	应加强持久化健康度监控与数据一致性保障机制

建议社区进一步定位：
请提取完整的 framework.log 和 /data/trust/persistence/per_poweroff.db 文件，分析以下内容：

数据库最后一次成功写入时间

故障前后t_manager_account表的内容差异

是否存在 VACUUM 或 PRAGMA integrity_check 失败记录

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

BMC Reset长稳测试中IP恢复默认及数据库持久化失败分析报告

问题描述

在进行BMC Reset长稳测试过程中，某次执行 ipmitool mc reset cold 操作后出现以下异常现象：

BMC IP地址恢复为默认值 192.168.2.100，网络配置丢失。
无法通过SSH正常登录BMC，提示密码错误，尽管密码实际未更改。
IPMI用户管理命令失效：尝试使用 ipmitool user set name 修改用户名时返回“Unspecified error”。
最终需通过BIOS重置密码才恢复正常访问。

最后一次BMC冷重启的时间点为 2026-04-09 20:27:38，日志显示为“Cold reset BMC successfully”。

在该时间点之前，系统框架日志中出现了大量数据库持久化失败的错误记录，涉及多个关键数据表（如t_manager_account、t_eventservice、t_memory_usage_history等），表明系统持久化机制已提前出现故障。

关键日志分析

1. 数据库持久化失败日志（时间范围：20:19 ~ 20:27）

2026-04-09 20:19:17.699612 persistence ERROR: persist save failed for main database, table name: t_eventservice, primary key: Id:1
...
2026-04-09 20:24:35.214776 persistence ERROR: per save failed, result: -1, op: update, table name: t_eventservice, primary key: Id:1
...
2026-04-09 20:27:27.206288 persistence ERROR: per save failed, result: -1, op: update, table name: t_manager_account, primary key: Id:2
2026-04-09 20:27:37.487231 persistence ERROR: per save failed, result: -1, op: update, table name: t_manager_account, primary key: Id:2
2026-04-09 20:27:38.722296 persistence ERROR: per save failed, result: -1, op: update, table name: t_manager_account, primary key: Id:2

分析结论：

在BMC重启前，关键配置表（特别是 t_manager_account，存储用户账号和密码信息）已连续多次写入失败。

错误类型为 attempt to write a nil value，说明应用程序尝试写入空值或框架未能正确构造数据结构。

持久化子系统在重启前已处于不可靠状态，导致配置变更无法落地。

2. BMC重启与系统事件

45 2026-04-09 20:27:38 CLI,Administrator(192.168.235.230,bmc upgrade,Cold reset BMC successfully
...
6089 2026-04-09 20:27:38.782648 maca NOTICE: Success to record BMC reset cause, code: 0
6090 2026-04-09 20:27:38.783729 maca NOTICE: BMC reset type: normal system

分析结论：

BMC以“normal system”类型执行冷重启，并非意外崩溃或看门狗复位。

重启前账号数据未成功持久化，重启后系统从备份或初始状态加载配置，导致IP、账号等回滚至默认值。

根本原因分析

1. 数据库持久化机制中断导致配置丢失

根据知识库信息及日志分析，本次问题的根本原因如下：

组件	状态	原因
持久化系统	异常	日志中持续出现 `persist save failed`，说明BMC在重启前无法将运行时配置写入NAND Flash。
用户数据 (`t_manager_account`)	未持久化	用户名、密码等敏感信息应属于掉电持久化类型（PoweroffPer），但因数据库写失败，变更未保存。
网络配置 (IP/MAC)	丢失	IP配置通常存储在掉电持久化数据库中（如 `/data/trust/persistence/per_poweroff.db`），写失败后重启即丢失。
数据库文件是否损坏	可能损坏或处于不一致状态	长期频繁写失败可能导致数据库文件头损坏、事务未提交或SQLite WAL日志异常。

2. 持久化类型与数据恢复行为对应关系

持久化类型	是否保留IP/密码	重启后行为
永久持久化 (PermanentPer)		即使恢复出厂设置也保留
掉电持久化 (PoweroffPer)		掉电/BMC重启后保留（本次应使用此类型）
复位持久化 (ResetPer)		丢失于AC断电、BMC升级
临时持久化 (TemporaryPer)		仅进程内有效

确认：IP与用户账户信息应配置为 掉电持久化（PoweroffPer），但因持久化服务异常，未能成功写入。

问题复现与调试建议

已知重现路径

长时间循环执行 ipmitool mc reset cold
在系统已存在持久化写入失败的日志时再次重启 → 极可能导致配置丢失

解决方案建议

1. 短期缓解措施

禁止在持久化异常时执行BMC重启，应在脚本中加入日志检测逻辑。

定期备份数据库文件：

cp /data/trust/persistence/per_poweroff.db /backup/

出现问题后可通过替换数据库文件快速恢复环境（需同版本）。

2. 长期修复方向

【软件层】增强持久化子系统的错误处理与降级机制，避免单点失败影响全局。
【软件层】增加持久化健康检查API，供Web UI或CLI查询状态。
【存储层】对数据库文件实施双份冗余存储（主+备份），重启时校验一致性。
【硬件/驱动层】优化NAND Flash驱动，支持坏块管理与磨损均衡（Wear Leveling）。
【日志层】当检测到连续多次持久化失败时，主动上报告警事件。

总结

项目	结论
是否数据库损坏	是，或至少持久化服务已失效
IP恢复默认原因	因`per_poweroff.db`未更新，重启后读取旧/默认配置
无法登录原因	用户密码数据未成功持久化，系统加载了旧版本或默认凭证
诱因	长期BMC Reset测试中存在持续的`persist save failed`错误
解决方案重点	应加强持久化健康度监控与数据一致性保障机制

建议社区进一步定位：
请提取完整的 framework.log 和 /data/trust/persistence/per_poweroff.db 文件，分析以下内容：

数据库最后一次成功写入时间

故障前后t_manager_account表的内容差异

是否存在 VACUUM 或 PRAGMA integrity_check 失败记录

本报告基于 openUBMC 25.12 版本，结合知识图谱、文档块与外部搜索结果综合分析得出。

LCC · 2026 年4 月 10 日 06:38

test

LCC · 2026 年4 月 10 日 06:45

日志（太大分卷压缩的）：
dump_info.z01.txt (8 MB)
dump_info.zip (3.6 MB)

huangzhiyu · 2026 年4 月 10 日 06:49

看日志是尝试写一个只读的数据库，是不是环境上数据库的权限被改过，或者文件被删除、被替换。这种一般是认为干预的。

LCC · 2026 年4 月 10 日 06:58

这个不大可能，因为跑BMC长稳都是在晚上运行，也没有开发会偷偷去修改数据库权限，我感觉在BMC运行过程中数据库权限被篡改或数据库损坏更有可能。

而且我只是设置用户名会失败，但是我重新修改BMC IP是正常的，修改BMC IP也会更新数据库嘛，如果是权限问题，应该也会失败吧。

LCC · 2026 年4 月 10 日 07:00

或者有没有其他的可能会导致ip恢复成默认？主要是我还发现一个现象：通过ipmitool user set name去添加用户，会报错，说当前用户已存在，但实际是不存在的。
通过web新增相同user id的用户之后，在通过web删除，然后再次通过ipmitool user set name添加用户，这次就会成功，感觉就像数据库有脏数据一样

huangzhiyu · 2026 年4 月 10 日 07:32

可能是执行用例的问题，不一定是真的有开发上环境操作。

LCC · 2026 年4 月 10 日 07:56

用例只是单纯的在跑cold reset，没有做其他操作，这个是概率性出现的问题

huangzhiyu · 2026 年4 月 10 日 11:45

数据库没那么容易损坏，也不会有权限篡改的可能，这种通常就是人为的

原因	描述
NAND Flash 寿命耗尽或物理坏块	长期频繁写操作可能导致存储介质老化
文件系统损坏（如JFFS2/YAFFS）	异常断电或突然重启可能破坏文件结构
数据库锁或进程异常	其他组件占用SQLite连接，导致写入超时
`datafs_reset`标志被触发	深度还原会清除所有掉电持久化数据
应用代码bug（如nil值写入）	框架尝试写无效数据引发数据库异常

话题		回复	浏览量
新增本地用户后重启BMC，新增用户全部丢失（未持久化），仅在单台设备出现过一次 bmc_core SIG 提问求助	2	24	2026 年9 月 29 日
执行恢复出厂设置操作后，BMC多次复位并切换至备用分区问题交流互助区提问求助	6	93	2026 年8 月 27 日
【用户管理】【登录】AC长稳测试，ssh登录BMC概率登录失败交流互助区提问求助	9	233	2026 年2 月 4 日
手动上树对象所有持久化类属性全被持久化交流互助区提问求助	5	76	2026 年8 月 4 日
手动修改时间使证书过期，BMC不可用且无法恢复交流互助区提问求助	10	193	2026 年10 月 8 日

【BMC Reset长稳测试】【持久化】在某次BMC Reset时，ip恢复成默认ip

问题描述

环境信息

重现步骤

期望结果

实际结果

尝试过的解决方案

分析结论

总结

BMC Reset长稳测试中IP恢复默认及数据库持久化失败分析报告

问题描述

关键日志分析

1. 数据库持久化失败日志（时间范围：20:19 ~ 20:27）

2. BMC重启与系统事件

根本原因分析

1. 数据库持久化机制中断导致配置丢失

2. 持久化类型与数据恢复行为对应关系

相关技术支持背景

1. 类似问题已有记录

2. 持久化失败常见原因

问题复现与调试建议

已知重现路径

推荐调试步骤

解决方案建议

1. 短期缓解措施

2. 长期修复方向

总结

【BMC Reset长稳测试】【持久化】在某次BMC Reset时，ip恢复成默认ip

问题描述

环境信息

重现步骤

期望结果

实际结果

尝试过的解决方案

分析结论

总结

BMC Reset长稳测试中IP恢复默认及数据库持久化失败分析报告

问题描述

关键日志分析

1. 数据库持久化失败日志（时间范围：20:19 ~ 20:27）

2. BMC重启与系统事件

根本原因分析

1. 数据库持久化机制中断导致配置丢失

2. 持久化类型与数据恢复行为对应关系

相关技术支持背景

1. 类似问题已有记录

2. 持久化失败常见原因

问题复现与调试建议

已知重现路径

推荐调试步骤

解决方案建议

1. 短期缓解措施

2. 长期修复方向

总结

相关话题