OTA for a Raspberry Pi 3+

[djalpiza]

Hi I am trying to enable OTA for a Raspberry Pi 3+, using the Device Update Service from Azure IoT Hub. I am following the tutorial available here: https://learn.microsoft.com/en-us/azure/iot-hub-device-update/device-update-raspberry-pi
I am able to complete the tutorial and get the device connected and ready to receive updates from the Azure IoT Hub. My question is, basically, how can I modify the "functions" that my Raspberry Pi is running?
For example, a basic blink function that will turn on and off the LED of the board on a given frequency, for example, Program 1, blinks 2 times per second. And now I want to change my configuration to blink only 1 time per second, using the Azure Device Update Service.

Taking the file from: https://github.com/Azure/iot-hub-device-update/releases. Can you guide me on what has to be modified in order to add new functionalities or change the current functionalities to the updated image on the Raspberry Pi? Keeping the connectivity and availability for new updates from the Azure IoT Hub.

[jw-msft]

Assumptions:

• There exists, say, a python program on the device that sets up GPIO pin for output (e.g. pin 8) and that toggles low/hi on it with sleep in between
• init system (system.d, sysv init.d, openrc, runit, etc) is setup so that above program will auto-run on bootup and get restarted after program crashes, etc.

Depending on the requirements, there are several approaches one could take:

• The simplest would probably be to replace the files that comprise the blink program using script handler, which would mean authoring a script (shell or scripting language) that would do the steps necessary to unpack and install a 2nd tarball update payload.

  • See script_handler README.md and example script

• A slightly more secure variant (in cases where there is concern about compromised shell) would be to author a custom handler .so plugin (in a language that supports interfacing with native C ABI) that exports the IsInstalled, Download, Install, Apply symbols.

  • See how to implement custom update handler doc

• image-based update for separate app partition. The blink program could be on its own partition and a 2nd similar partition would also be reserved. You could use script handler, a custom handler, or swupdate v2 handler to overwrite the 2nd partition and a 2nd step in multi-step update (or logic in the script or custom handler) could update fstab (with, say, sed) to change which app partition is mounted, or update a symlink to the blink program if always mounting both partitions.

• Full A/B system image updates. If you want to just update the entire system so as to also deterministically apply security patches and other patches along with the updated blink program (ideally as a single, read-only-mounted partition), then one could use swupdate v2 handler and build disk images with something like Yocto or RPi-gen (it could be compressed and/or encrypted). To keep the image payloads smaller (and not encrypting the image), then one could use the current [delta updates]](https://learn.microsoft.com/en-us/azure/iot-hub-device-update/delta-updates) that's in public preview.