Hello,
I see that balenaOS uses redundant partitions to ensure fallback is always possible. However what could trigger a fallback ? For example if the update is corrupted and the raspberry pi is stuck on boot (cannot load Kernel for example) what will trigger the recovery process ?
Thanks
Hello Quentin,
Thanks for reaching out. There is some documentation on the process here: https://www.balena.io/docs/reference/OS/updates/update-process/
But essentially, if the device cannot boot, at all, then you are correct, manual intervention will probably be necessary. This is ultimately why the balenaCloud platform exists though, which is to containerize applications, and only update the containers themselves for the most part. That presents a safer method for updating your applications, and HostOS Updates should be performed when necessary, and after testing.
Would it be possible to manage this problem using hardware watchdogs that could trigger a reboot and finally the bootloader would manage the fallback process on the redundant partition?
Is this included in the balenaOS for the Raspberry Pi 3B+ ?
Thank you
Hey,
Some more in-depth information can be seen here: https://github.com/balena-os/meta-balena/blob/development/docs/rollbacks.md#rollback-altboot
The new OS is unbootable and does not get to Linux userspace. (A kernel panic, something crashes before the OS reaches userspace and is able to run systemd). This requires the bootloader and userspace to work together. The bootloader needs to count the number of boots and userspace needs to reset the bootcount if the OS is functional.
It looks like this should be what you’re after 
Thank you!