Download updates, reboot, boot into the updated container

Hi.

We have implemented the “Update when user interacts” strategy.

Let me summarize the process (Assume there’s a new release available):

  1. User initiates update by pressing a button on their device
  2. Create a lock file
  3. Pin the device to the new release
  4. Trigger update download using the endpoint: /v1/update
  5. Show “Downloading update…” message to user
  6. After download finishes, show “Reboot” button to user
  7. User pressed “Reboot” button
  8. Trigger device reboot using the endpoint: /v1/reboot with {'force': true}
  9. Device boots back, old containers are started (Old UI shows)
  10. Supervisor kills/deletes the old containers and applies updates
  11. New containers are started

The step we’re having problem is step 9. When device boots back the old containers are started and shows our old UI for a few seconds until after supervisor finishes applying the update.

Is there a way we can make it so the old containers are not started?
So we’d have a following for step 9:

    1. Device boots back, old containers are not started (Blank screen)

Hi there,

May I ask, what is the purpose of step 8? Is it to remove the lockfile?

Step 8 is the “onclick” action for Step 7.
We call /v1/reboot with {'force': true} to force a reboot. Device won’t reboot without {'force': true} flag since we still have the lockfile present.

We’re not removing the lockfile because it is removed automatically on reboot by the supervisor anyway.

Hi there, I was just asking as if the reboot wasn’t strictly necessary, you could disable the lockfile without rebooting, and the device would update to the new container and UI - this might provide a smoother experience

If the exact steps you detailed are all strictly required, then I don’t think there is a way to force the device to not start the old containers as it boots. As it seems like the main issue is the old UI is being displayed pot update, maybe you could disable the screen using an env var you set during step 7 and then remove when the running release matches the target one?

Thanks.

I ended up using this following solution. It works well.

On boot, from my old container poll /v2/state/status to detect if an update is being applied (appState == "applying") and show “Updating please wait…” UI. Then continue rendering regular UI when update finishes.

Nice work! Thank you for sharing, hopefully this forum thread will be of future use to anyone looking to achieve a similar effect :slight_smile: