Code update: Image priority setting post activation #2857
Comments
|
Setting the Priority value triggers a chain reaction to update the priorities for other versions and set the boot version via systemd service files that are async. The user can reboot the BMC before all the services are done, so ideally the setting the Priority value would monitor the service files and return until they're done. |
|
There are journal entries that pop up when priority values are set - do we need additional indication beyond that? |
|
If this is something that takes time then you need to provide a progress indicator on the REST interface. Having said that, how long does it take for the changes to complete? It seems surprising that it's long enough for people to trigger a race with a reboot. |
|
It takes about 5 seconds, the issue has been seen during automation test cases, where the reboot is issued immediately after the call to set the Priority value returns.
Yeah, we need to hold on returning because we can't have a requirement for the user to rely on the journal to determine if an operation has completed. Also to support automation. |
|
5 seconds to change the priority is way to long. It should be much less, we just need to erase and program 2 blocks to change the priority. Is this including time to write the partition? That being said, we still need to provide a way for rest to determine the activation has completed. |
Setting the "Priority" value triggers a chain reaction to update the priorities for other versions and set the boot version via systemd service files that are async. As a work-around for openbmc/openbmc#2857, explicitly wait 10s after writting the "Priority" value. Change-Id: I69bac0712ad6e4356f7cc14d50ebca9826783280 Signed-off-by: George Keishing <gkeishin@in.ibm.com>
|
https://gerrit.openbmc-project.xyz/9418 Delay return from updateUbootEnvVars() until service file finishes |
|
This change has been reverted via https://gerrit.openbmc-project.xyz/#/c/10022/ because it causes intermittent issue #3069 |
|
This issue has been automatically marked as stale because no activity has occurred in the last 6 months. It will be closed if no activity occurs in the next 30 days. If this issue should not be closed please add a comment. Thank you for your understanding and contributions. |
|
This issue has been closed because no activity has occurred in the last 7 months. Please reopen if this issue should not have been closed. Thank you for your contributions. |
Once the update is successful, mark the version as primary so that it boots from the updated version upon BMC reboot. Add a sleep to wait for the service file to complete setting the primary version. Otherwise, the BMC could mark a Delete or Priority value change as complete and the service is not done yet, and if the BMC is rebooted it could try to boot from a non-existent version. As backgroung, reference issue openbmc/openbmc#2857 that attempted to create a 'wait for service' function but was not successful. This could be investigated further at a later time, which would benefit other functions like Factory Reset that are also using sleep as a workaround to wait for systemd service files. Tested: Verified the version was set to primary during code update and delete, and that 3s passed (service file finished in about 1s) before the delete/update continued. Change-Id: I4f9afdb020d8cc7c18cfdafe468dbff2dc8046c1 Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Once the update is successful, mark the version as primary so that it boots from the updated version upon BMC reboot. Add a sleep to wait for the service file to complete setting the primary version. Otherwise, the BMC could mark a Delete or Priority value change as complete and the service is not done yet, and if the BMC is rebooted it could try to boot from a non-existent version. As backgroung, reference issue openbmc/openbmc#2857 that attempted to create a 'wait for service' function but was not successful. This could be investigated further at a later time, which would benefit other functions like Factory Reset that are also using sleep as a workaround to wait for systemd service files. Tested: Verified the version was set to primary during code update and delete, and that 3s passed (service file finished in about 1s) before the delete/update continued. Change-Id: I4f9afdb020d8cc7c18cfdafe468dbff2dc8046c1 Signed-off-by: Adriana Kobylak <anoo@us.ibm.com>
Sunny Srivastava (1): Reset fault LED after CM (openbmc#434) Change-Id: I1853f811ea1beb68e76cc234b784d8b49f020487
Looks like the user can’t know for sure when setting the priority value set is completed.
It could take from few seconds to more depending on the scenario. So there is no real synchronous way to tell when it is done.
Post discussion with @anoo1 @geissonator we would need to provide something for the user using which it can query to know when done.
The text was updated successfully, but these errors were encountered: