IoT device update failure recovery

• US 10,402,273 B2
• Filed: 02/27/2017
• Issued: 09/03/2019
• Est. Priority Date: 12/14/2016
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Inventors: Olinsky, Reuben R., Nightingale, Edmund B.
• Primary Examiner(s): Manoskey, Joseph D
• Application Number:
  US15/444,108
• Publication Number:
  US 20180165157A1
• Time in Patent Office: 918 Days
• CPC Class Codes: G06F 11/1433 during software upgrading
• CPC Class Codes: G06F 2201/83 the solution involving signatures
• CPC Class Codes: G06F 2201/84 Using snapshots, i.e. a logical point-in-time copy of the data
• CPC Class Codes: G06F 8/63 Image based installation; Cloning; Build to order
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G06F 8/71 Version control security arrangements therefor G06F21/57; Configuration management
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416
• CPC Class Codes: H04L 69/40 for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection management of faults, events, alarms or notifications in data switching networks H04L41/06
• CPC Class Codes: H04W 4/50 Service provisioning or reconfiguring
• CPC Class Codes: H04W 4/70 Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Abstract

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.

Claims

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.