We have added a Greenboot script to check if we have mobile connectivity. I understand this will be checked every boot as it is in /etc/greenboot/check/required.d If we have had a successful upgrade, what is the behaviour if this script starts failing after that. Some documentation states that the rollbacks will happen only after an unsuccessful upgrade. My concern is we are seeing greenboot failures because of the lack of mobile connectivity (as expected by out script) outside of any upgrade and need to understand if this will cause a software rollback
Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello,
Greenboot is designed to manage system health checks and can trigger rollbacks based on the outcome of these checks. If your Greenboot script in /etc/greenboot/check/required.d is designed to verify mobile connectivity and it fails, this will indeed cause the system to enter a “RED” state, indicating a failed health check.
However, it’s important to distinguish between the behavior during an update process and the normal operation of the system. During an update, if the system fails to reach the boot-complete.target successfully after three attempts due to failing health checks (like your mobile connectivity check), it will trigger a rollback to the previous version of the software. This is to ensure that updates do not render the system inoperable.
Outside of an update context, if your system has already successfully updated and the Greenboot script starts failing (e.g., due to lack of mobile connectivity), the system will still attempt to reboot up to three times, trying to reach a “GREEN” state. If after three attempts the system still fails to reach a “GREEN” state, and if this occurs outside of an update process, it will not automatically rollback to a previous software version. Instead, it will remain in the “RED” state until the issue is resolved. This behavior ensures that transient issues or issues unrelated to software updates do not trigger unnecessary rollbacks.
It’s crucial to design your Greenboot scripts with this in mind, considering how they will behave both during and after software updates. For critical checks like mobile connectivity, you might want to implement additional logic to handle temporary connectivity issues gracefully, to avoid unnecessary reboots or service disruptions.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
Torizon Updates Technical Overview | Toradex Developer Center.
Greetings @DuncanNapier,
Glad to see you found the response from the ToradexAI satisfactory. Out of curiosity, does still Greenboot work for your use-case here?
From what I understood from your post it sounds like you just want the system to rollback only in the case mobile connectivity is down after an update. Is that right?
Best Regards,
Jeremias
Yes we have the need to make sure any changes to our software does not have and adverse effect on the connectivity via a mobile modem. This is done in a Greenboot script to take advantage of the rollback feature after an upgrade if things fail. Is there a better mechanism for this?
Greenboot should be fine for that case. It’s purpose in our system is to make sure everything is “okay” after an update as defined by the user. I just wanted to make sure it was fulfilling your requirements.
Best Regards,
Jeremias