* [phosphor-software-manager] potential out of order for reboot guard enable and disable procedure
@ 2022-03-05 14:03 Heyi Guo
0 siblings, 0 replies; only message in thread
From: Heyi Guo @ 2022-03-05 14:03 UTC (permalink / raw)
To: openbmc; +Cc: George Liu, Adriana Kobylak, Gunnar Mills, Jayanth Othayoth
Hi all,
We found reboot might be permanently disabled after running BMC image
update with curl command. The journal log showed the steps of reboot
guard enable and disable were out of order:
Mar 05 20:32:58 ali2600 systemd[1]: Starting Enable a guard that blocks
BMC reboot...
Mar 05 20:32:58 ali2600 phosphor-image-updater[370]: BMC activation has
ended - BMC reboots are re-enabled.
Mar 05 20:32:58 ali2600 systemd[1]: Starting Removes the guard that
blocks BMC reboot...
Mar 05 20:32:58 ali2600 phosphor-image-updater[370]: BMC image ready,
need reboot to get activated.
Mar 05 20:32:58 ali2600 systemd[1]: reboot-guard-disable.service: Succeeded.
Mar 05 20:32:58 ali2600 systemd[1]: Finished Removes the guard that
blocks BMC reboot.
Mar 05 20:32:59 ali2600 systemd[1]: reboot-guard-enable.service: Succeeded.
Mar 05 20:32:59 ali2600 systemd[1]: Finished Enable a guard that blocks
BMC reboot.
It seems systemd would not guarantee the completion order for StartUnit
operations, while I think this is critical for firmware upgrade
procedure. Shall we switch to normal C++ implementation to create and
remove reboot guaud configuration files, to guarantee the order of these
sequential steps?
Thanks,
Heyi
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2022-03-05 14:04 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-05 14:03 [phosphor-software-manager] potential out of order for reboot guard enable and disable procedure Heyi Guo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).