Updates¶
Getting back to revisions, these can be modified and upgraded, thus creating a new revision of the device.
Updates will be processed differently depending on the source being remote or local.
Pantavisor will report the update state from the moment the update is acknowledged until it is finished. Pantavisor will only progress to the new revision in case of success. Otherwise, no action or rollback will ensue, depending on the point where the error is detected. This is the list of update states:
Note
At every moment, the update progress information is avaliable from the Hub in case of remoted managed device and from the control socket. Additionally, in case of WONTGO or ERROR, a Pantavisor log snippet with relevant information is included in this progress report.
QUEUED¶
Only valid for remote updates.
Pantavisor has got the state JSON of the new revision, but is performing other operations and has put it to the queue to be processed later.
DOWNLOADING¶
Only valid for remote updates.
Downloading the artifacts for the new revision.
INPROGRESS¶
Installing or progressing to this revision. Transitions to new revisions can either require a reboot or not.
To finish this state, it is necessary that all status goals existing in the new revision have been achieved. Also, in the case of a remote update, Pantavisor needs to have performed communication with Pantacor Hub. If these two conditions are not met within a configurable time, Pantavisor will rollback the revision.
Reboot transition¶
Reboot transitions are performed based on the location of the changes belonging to the new revision update:
- In the root of the status JSON
- In the BSP
- In any of the containers with a system restart policy
- In any additional file that belongs to a container with system restart policy
- In any additional file that does not belong to any container
In this case, Pantavisor will stop all the containers and reboot the board.
Non-reboot transition¶
Non-reboot transitions are performed after an update that does not contain any changes in any of the components described for the reboot updates.
In this case, Pantavisor will only stop the containers that were affected by the update and restart them with the recently installed new revision artifacts.
TESTING¶
Waiting to see if the revision is stable. During this stage, Pantavisor checks if all containers are running and will rollback if any of them exits. Besides that, in the case of a remote update, it will also rollback in case Pantacor Hub communication is lost.
UPDATED¶
The revision is stable, but the update did not need a board reboot, so the rollback point is not set until you force a reboot.
DONE¶
The revision has been fully booted and is stable. The rollback point is set.
WONTGO¶
The new revision cannot be installed because of a bad state JSON, so it is aborted before getting into INPROGRESS or TESTING.
This table contains the possible causes for a WONTGO:
| Error |
|---|
| Internal error |
| State not fully covered by signatures |
| Signature validation failed |
| State JSON has bad format |
| Update aborted |
| Max download retries reached |
| Space required X B, available Y B |
ERROR¶
The new revision failed during INPROGRESS or TESTING stages. Pantavisor will try to rollback to the latest DONE revision.
This table contains the possible causes for an ERROR:
| Error |
|---|
| Internal error |
| State not fully covered by signatures |
| Signature validation failed |
| Object validation went wrong |
| Error during update |
| A container could not be started |
| Status goal not reached |
| Hub not reachable |
| Hub communication not stable |
| Stale revision |