diff options
| author | Potin Lai <potin.lai@quantatw.com> | 2025-02-07 05:22:34 +0300 |
|---|---|---|
| committer | Patrick Williams <patrick@stwcx.xyz> | 2025-02-07 19:30:26 +0300 |
| commit | 3d555f78d27a9fa477db87387f65e2be0d5f5730 (patch) | |
| tree | a2b49ebfbb6c55292744f3729d4e71d8f6f7b4bf /meta-openembedded/meta-python/recipes-devtools/python/python3-stack-data_0.6.3.bb | |
| parent | 0663d339623db88560e2e9fc2e39ef3b16def3f3 (diff) | |
| download | openbmc-3d555f78d27a9fa477db87387f65e2be0d5f5730.tar.xz | |
meta-facebook: bletchley: Fix BMC state stuck in 'NotReady'
We observed that the BMC state remains in the 'NotReady' state, with
systemctl list-jobs showing chassis-poweron@X.service stuck in a running
state.
The issue is from the `ExecStartPost` in `chassis-poweron@.service`,
which attempts to start `phosphor-discover-system-state` and waits for
it to complete. However, `phosphor-discover-system-state` only starts
after `multi-user.target` is done, creating a circular dependency that
prevents proper initialization.
Removed the `ExecStartPost` from `chassis-poweron@.service`. Moved the
`power-ctrl sledX ac-on` and `phosphor-discover-system-state@X.service`
execution into a dedicated `chassis-poweron` script.
This approach ensures proper sequencing and prevents the circular
waiting condition, allowing the system to reach a 'Ready' state as
expected.
Test Results:
BMC success and get into Ready state, and no jobs remain.
```
root@bmc:~# systemctl list-jobs
No jobs running.
root@bmc:~# obmcutil bmcstate
CurrentBMCState : xyz.openbmc_project.State.BMC.BMCState.Ready
```
Change-Id: I75ef6d3f42eb826d952e0a2572d133d665fc14e4
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
Diffstat (limited to 'meta-openembedded/meta-python/recipes-devtools/python/python3-stack-data_0.6.3.bb')
0 files changed, 0 insertions, 0 deletions
