通电开机策略设置与上次保持一致，多次AC后OS无法上电

交流互助区
1

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

问题描述

通电策略设置与上次保持一致，测试前OS为上电状态，多次AC测试后OS无法自己保持上电。

环境信息

  • 操作系统：[如 Ubuntu 24.04]

  • 软件版本：OpenUBMC2606

  • 硬件配置：[如 CPU、内存等]

重现步骤

  1. 测试前OS为上电状态,通电策略设置为与上次保持一致

  2. 进行单次AC测试，发现OS能够正常上电

  3. 进行连续多次AC测试后，发现OS不能正常保持上电，可以手动点上电按钮上电

期望结果

OS保持上电状态

实际结果

OS未上电

22
221466×599 56.2 KB

尝试过的解决方案

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

分析结论

目前分析是由于一次AC结束后，OS还未上电时就进行了AC掉电，导致下次上电时OS无法自己上电，fructrl中的mdb_info.log可以看到PreviousPowerState value为off

.PreviousPowerState
signature: s
value: “OFF”
flags: -
readonly: true

如果是这种情况，通电策略设置为与上次保持一致OS是否应当正常上电

2

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

总结

根据知识库中的定义，在LastState策略下，如果 PreviousPowerState 为 OFF，OS不自动上电是正常行为。但您的场景中 PreviousPowerState 被异常记录为 OFF，根因可能是BMC复位或连续AC时序导致策略未能正确执行。建议从日志中确认复位类型和事件顺序，或切换为“保持上电”策略以满足持续供电需求。

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

问题分析

您反馈的问题核心是：通电开机策略设置为“与上次保持一致”（LastState），测试前OS为上电状态，但经过连续多次AC操作后，OS无法自动上电，同时观察到 PreviousPowerState 值为 OFF。您询问在这种情况下OS是否应该正常上电。

根据OpenUBMC知识库中的信息，可以给出以下分析。

1. 策略定义明确

  • PowerOnStrategy 是控制系统在电源循环后行为的设置，当其设置为 LastState 时，系统应保持上一次的电源状态（来自KG实体描述）。
  • 与之相关的 Power-On Strategy 也明确指出，该策略包含“维持上次状态”或“恢复默认”等选项。

结论：如果上一次记录的电源状态是 OFF，则按照LastState策略，系统不会自动上电，OS保持下电状态是符合策略设计预期的行为。

2. 分析 PreviousPowerState 为何变为 OFF

您期望OS始终保持上电（即上一次状态应为 ON），但实际记录为 OFF，这提示在连续AC过程中状态记录出现了不期望的改变。

结合知识库中已知的类似问题（如 AC压测中偶现不上电的分析），可能的原因包括：

  • BMC组件复位导致策略未执行：在topic6036的分析中指出，AC时BMC存在组件未拉起导致复位，fructrl 读取到的 rest_type 为 softreset 而非 poweron，导致未走通电开机策略。
  • 时序问题：您自行分析提到“一次AC结束后，OS还未上电时就进行了下一次AC掉电”，此时系统可能未完成电源状态的完整记录与更新，导致 PreviousPowerState 被错误记录为 OFF。

KG中相关关系也证实：

  • AC闪断 会触发 执行通电开机策略（fructrl 执行），但如果 rest_type 因复位而改变，该策略可能被跳过。
  • fructl_mdb.lua 负责记录和更新系统电源状态，其日志中的 PreviousPowerState 反映了最终记录的数值。

因此，PreviousPowerState 为 OFF 可能不是一次完整上电后的状态，而是因复位或过早断电导致的状态异常。

3. 结合策略设计的预期行为

在LastState策略下，系统完全依赖 PreviousPowerState 的准确值来决定是否上电。如果该值被异常记录为 OFF，则后续AC自动上电自然会被抑制。这并非策略本身的错误，而是状态记录与事件时序不匹配导致的结果。

与之对比，如果策略设置为 “保持上电”（AlwaysPowerOn），则系统在任何AC恢复后都会强制上电，不依赖上次状态。您的测试场景若期望OS始终上电，可考虑使用“保持上电”策略（但需注意该策略在其他场景下的行为差异）。

4. 建议与后续排查方向

  • 检查AC过程中的事件日志：重点关注 fructrl（如 mdb_info.log）和 power_mgmt 组件的日志，确认每次AC后 rest_type 的值、以及 PreviousPowerState 是否被正确更新。
  • 验证BMC复位情况：在连续AC测试中，观察是否出现组件未拉起导致BMC复位（如 framework.log 中的 certificate 组件异常），这可能导致策略判断异常。
  • 调整测试间隔：确保一次AC结束后，系统（包括BMC和OS）完全稳定启动并记录好电源状态，再进行下一次AC操作，避免时序重叠。

总结

根据知识库中的定义，在LastState策略下，如果 PreviousPowerState 为 OFF，OS不自动上电是正常行为。但您的场景中 PreviousPowerState 被异常记录为 OFF，根因可能是BMC复位或连续AC时序导致策略未能正确执行。建议从日志中确认复位类型和事件顺序，或切换为“保持上电”策略以满足持续供电需求。

3

如果是依据PreviousPowerState这个判断，那么下次AC就不会上电

4

社区最近不是优化过一次上电策略的执行逻辑吗，按新的逻辑应该不会有该问题

6

你好，能知道是哪个版本修正的么，我们现在用的是fructrl组件是1.70.91版本

7

参考这个issue关联的PR：[缺陷]: 在进行AC Cycle测试时获取到的 ResetType 错误导致通电开机出现问题-fructrl-AtomGit

8

不确定是不是同一个问题，我这里通电策略用的是与上次保持一致，不是保持开机。我使用的是630版本的组件应该已经包含了这个改动

9

如果通电开机策略选择的是"与之前保持一致"，执行通电开机策略时会根据私有属性PwrStateBeforeACLost来判断AC前OS的上电状态（日志打印：“[System:%s]pwr_state is %s”），PreviousPowerState属性与PwrStateBeforeACLost同步更新，通过PwrStateBeforeACLost是OFF可以推断AC前OS是下电状态，因此不会执行上电操作。