Hello,
we want to run the update process manually rather than just letting it go on in the background automatically.
For this reason, we have deactivated the automatic reboot after an update and the user must confirm the restart via the GUI.
Is it possible to undo or invalidate an update that has just been installed with aktualizr-torizon?
For example reset the u-boot variable upgrade_available.
Best regards,
Markus
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 Markus,
To manually undo or invalidate an update that has just been installed with aktualizr-torizon before a reboot, you can reset the U-Boot environment variable upgrade_available to 0. This action tells the system that no update is pending, effectively preventing the new update from being applied upon the next reboot. Here’s how you can do it:
fw_setenv command. You might need to install the fw_printenv and fw_setenv utilities if they are not already available on your system.upgrade_available variable:fw_setenv upgrade_available 0
bootcount is also reset to avoid any unintended rollbacks, you can run:fw_setenv bootcount 0
This approach allows you to manually control the update process and decide when or if an update should be applied, giving you the flexibility to require user confirmation before proceeding with system reboots or applying updates.
Remember, this method is effective for updates that have been installed but not yet activated (i.e., before a reboot). Once the system reboots and the new update is applied, the rollback mechanism would need to be triggered by the conditions described previously (e.g., unsuccessful boot attempts).
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 @Mowlwurf,
I hope the Toradex AI was able to give you a suitable answer.
Is it possible to undo or invalidate an update that has just been installed with aktualizr-torizon?
For example reset the u-boot variableupgrade_available.
Out of curiosity, is this something you plan to do in production on your systems? What is the use-case here?
Would an update occur, but the user has the option to invalidate/not go through with the update?
Best Regards,
Jeremias
Hello @jeremias.tx,
Yes, the answer from the AI Assistant was exactly right. I also gave it a thumbs up 
Out of curiosity, is this something you plan to do in production on your systems? What is the use-case here?
Would an update occur, but the user has the option to invalidate/not go through with the update?
We currently use Mender as our update solution. Like Torizon, Mender offers an OTA client that installs an update fully automatically.
With Mender, however, it is also possible to manually control the installation and confirmation of an update from the user space using the mender install, mender rollback and mender commit commands.
As we currently only want to support offline updates, we have used this mode and implemented the update process in our application as follows:
When porting our system to Torizon, we want to keep this finished process for now without any changes if possible and integrate the Aktualizr-Torizon client into it (even if this will probably not succeed completely).
Whether it makes sense for the user to be able to undo an already installed update before rebooting is certainly open to debate. It would also be conceivable to omit the user confirmation of the reboot for an offline update. My cell phone does not do this either.
In the case of an OTA update that runs in the background, it would be better to simply inform the user that an update has taken place and to reboot the device at the next opportunity. But an automatic reboot would not be good, because the user wants to use the device right now.
I hope this answer your question of our use case.
I’m going to use the AI Assistant’s proposed solution for now in order to move forward with porting Mender to Torizon. But I’m guessing that it won’t go out to the customer like this, because I’m going to take a closer look at the subsystem update of Torizon and this will probably result in even bigger changes to our offline update process.
Unfortunately, the solution with fw_setenv upgrade_available 0 does not work for me.
I have installed an update with deactivated auto reboot as already described here. I then reset upgrade_available as described and checked the result. After a reboot, however, the newly installed version was booted.
Well that’s not surprising, those variables shouldn’t actually affect whether the update gets executed or not. Before the reboot, the new OSTree version is queued for deployment on next boot.
At this point to prevent the new OSTree version from being booted you need to either override the deploy to the old version before reboot. Or what I would suggest is forcing a rollback. Which would cause the previous version to be booted instead of the new version.
You could force a rollback via the rollback variable in U-Boot, but this is clunky. A lot of various processes in Torizon OS rely on this rollback variable. Changing it manually outside of the usual processes can cause unintended effects. What we typically suggest for rollback control is Greenboot: Aktualizr - Modifying the Settings of Torizon Update Client | Toradex Developer Center
You can add custom update check scripts that allow you to determine the success of an update via your own parameters. You could create a kind of script that will “fail” the update. This would cause the system to rollback to the previous version of the OS. This gives the effect of “un-doing” the update as you say.
Best Regards,
Jeremias
Yeah, I guess I’ll have to give up trying to force aktualizr’s offline mode into the way Mender can be used and adjust our update flow accordingly.