IoT device update failure recovery
The disclosed technology is generally directed to IoT device update failure recovery. In one example of the technology, after writing an updated release to memory, a determination is made whether the updated release is valid. The updated release includes a plurality of image binaries. If the updated release is determined to be valid, the updated release is made the current release. A determination is made as to whether the current release is stable. Upon determining that the current release is unstable, an auto-rollback is performed. Performing the auto-rollback includes, via at least one processor, automatically: obtaining an uncompressed backup of a previous release; making the uncompressed backup of the previous release the current release; and executing the uncompressed backup.
1. An apparatus for update failure recovery, comprising:
a device including at least one memory adapted to store run-time data for the devices, and at least one processor that is adapted to execute processor-executable code that, in response to execution, enables the device to perform actions, including:
after writing an updated release to memory, determining whether the updated release is valid, wherein the updated release includes a plurality of image binaries;
if the updated release is determined to be valid, making the updated release the current release;
after making the updated release the current release, determining whether the updated release is stable;
if the updated release is determined to be unstable, performing an auto-rollback, wherein performing the auto-rollback includes automatically: obtaining an uncompressed backup of a previous release; making the uncompressed backup of the previous release the current release; and executing the uncompressed backup;
upon determining that the updated release is stable, determining whether the release becomes unstable at a subsequent time; and
upon determining that the release has become unstable at a subsequent time: obtaining an uncompressed backup of the current release, and refreshing the current release.
2. The apparatus of claim 1 , the actions further including:
if the at least a portion of the updated release is determined to be invalid, rejecting at least the portion of the update.
3. The apparatus of claim 1 , the actions further including:
beginning execution of the current release before determining whether the current release is stable.
4. The apparatus of claim 1 , the actions further including:
determining whether the current release is erratic; and
if it is determined that the current release is erratic: obtaining an uncompressed backup of the current release, and refreshing the current release.
5. The apparatus of claim 4 , the actions further including:
after refreshing the current release, determining whether the current release is still erratic; and
if it is determined that the current release is still erratic, performing an auto-rollback.
6. A method for update failure recovery, comprising:
after writing an updated release to memory, determining whether the updated release is valid, wherein the updated release includes a plurality of image binaries;
if the updated release is determined to be valid, making the updated release the current release;
determining whether the current release is stable;
if the updated release is determined to be unstable, performing an auto-rollback, wherein performing the auto-rollback includes, via at least one processor, automatically: obtaining an uncompressed backup of a previous release; making the uncompressed backup of the previous release the current release; and executing the uncompressed backup;
upon determining that the updated release is stable, determining whether the release becomes unstable at a subsequent time; and
upon determining that the release has become unstable at a subsequent time: obtaining an uncompressed backup of the current release, and refreshing the current release.
7. The method of claim 6 , further comprising:
if at least a portion of the updated release is determined to be invalid, rejecting the at least a portion of the update.
8. The method of claim 6 , further comprising:
beginning execution of the current release before determining whether the current release is stable.
9. The method of claim 6 , further comprising:
storing at least one backup copy for each previous update of a plurality of previous updates.
10. The method of claim 6 , further comprising:
if the updated release is determined to be invalid, determining whether the updated release is a forgery;
if the updated release is determined to be a forgery, rejecting the update and maintaining the current release.
11. The method of claim 10 , further comprising:
if the updated release is determined to be a forgery, sending an alert.
12. The method of claim 10 , further comprising:
if the updated release is determined not to be a forgery
attempting to re-download at least a portion of the updated release; and
if the attempt to re-download the current release is successful writing at least the portion of the updated release to memory; and
determining whether the re-downloaded portion of the updated release is valid
else
rejecting the update and maintaining the current release.
13. The method of claim 10 , further comprising:
if the updated release is determined not to be a forgery, rejecting the update and maintaining the current release.
14. The method of claim 6 , further comprising:
determining whether the current release is erratic; and
if it is determined that the current release is erratic: obtaining an uncompressed backup of the current release, and refreshing the current release.
15. The method of claim 14 , further comprising:
after refreshing the current release, determining whether the current release is still erratic; and
if it is determined that the current release is still erratic, performing an auto-rollback.
16. A processor-readable storage medium, having stored thereon process-executable code for computer network design, that, upon execution by at least one processor, enables actions, comprising:
after writing an updated release to memory, determining whether updated the release is valid, wherein the updated release includes a plurality of image binaries;
if the updated release is determined to be valid, making the updated release the current release;
after making the updated release the current release, determining whether the updated release is stable;
if the updated release is determined to be unstable, performing an auto-rollback, wherein performing the auto-rollback includes automatically: obtaining an uncompressed backup of a previous release; making the uncompressed backup of the previous release the current release; and executing the uncompressed backup;
upon determining that the updated release is stable, determining whether the release becomes unstable at a subsequent time; and
upon determining that the release has become unstable at a subsequent time: obtaining an uncompressed backup of the current release, and refreshing the current release.
17. The processor-readable storage medium of claim 16 , the actions further comprising:
if at least a portion of the updated release is determined to be invalid, rejecting at least the portion of the update.
18. The processor-readable storage medium of claim 16 , the actions further comprising:
beginning execution of the current release before determining whether the current release is stable.
19. The processor-readable storage medium of claim 16 , the actions further comprising:
determining whether the current release is erratic; and
if it is determined that the current release is erratic: obtaining an uncompressed backup of the current release, and refreshing the current release.
20. The processor-readable storage medium of claim 19 , the actions further comprising:
after refreshing the current release, determining whether the current release is still erratic; and
if it is determined that the current release is still erratic, performing an auto-rollback.