Is it possible to downgrade application container for one built earlier than current installed when offline update?
Greetings @Serghey,
Could you clarify what you mean by “downgrade application container”?
Our update framework has no concept of newer or older so things like downgrades don’t make sense in that context.
All that happens is that when an update is initiated, if the requested package is different than what is installed on the system then an update will occur.
So for your case, if the Lockbox for your offline update contains an application container package that is different from the one currently installed on the device then an update will happen. It doesn’t matter if the container is “newer” or “older”, just matters if it’s different.
But perhaps you’re describing something else maybe? Could you elaborate on exactly what kind of behavior or use-case you seek?
Best Regards,
Jeremias
Hi Jeremias.
“All that happens is that when an update is initiated, if the requested package is different than what is installed on the system then an update will occur”.
Update also does not start, if requested package was ever installed on the device.
In this case we receive the following message*: ” Nov 08 23:01:37 colibri-imx8x-07021175 aktualizr-torizon[867]: Director metadata update failed: The version of role offline-updates does not match the entry in Snapshot metadata.*
Nov 08 23:01:37 colibri-imx8x-07021175 aktualizr-torizon[867]: Event: UpdateCheckComplete, Result – Error”
Regards.
In this case we receive the following message*: ” Nov 08 23:01:37 colibri-imx8x-07021175 aktualizr-torizon[867]: Director metadata update failed: The version of role offline-updates does not match the entry in Snapshot metadata.*
This means there’s something wrong or outdated with the security metadata that is on that Lockbox. You can try fixing this by re-downloading the Lockbox with TorizonCore Builder. This will re-create the Lockbox, but with up-to-date security metadata.
Try this and see if the update works with the updated Lockbox.
Best Regards,
Jeremias
Yes, this is what I am doing now: prepare the update for the old project revision like a new. This takes time.
Also, when I completely reprogram unit with TEZI, I can implement update1(created earlier) and then update2(created later). But if after TEZI reprogramming I apply update2(latest) first, then trying to apply update1(oldest) it gives me this error. Looks like system analyses time when update was created and does not allow to install older package? If so, is it possible to disable this check (probably delete some history)?
Regards.
If so, is it possible to disable this check (probably delete some history)?
It is not possible to disable this as it would break the security framework that our updates are built on top of.
It’s expected for users to create Lockboxes continually when needed to update this security metadata. Using old Lockboxes will continue to cause this issue you experienced. This limitation only applies for offline updates since there is no network connection.
Best Regards,
Jeremias
Ok,
Thank you for clarification.
Best regards.
Just follow up,
We found solution how disable lockboxes sequence check.
Looks like works fine.
Regards.
We found solution how disable lockboxes sequence check.
Could you clarify what solution you found? There shouldn’t be a way to bypass this unless you’re erasing the history or re-provisioning the device which has other issues.
Best Regards,
Jeremias
Ater the initial device programming from TEZI, save /var/sota folder somewhere else (like as in /ets/save). Then when initiate the update just copy the content of /etc/save into /var/sota. Of course, stop aktualizr before and restart it after copy.
Well you’re just manipulating the update system in this way. It’s not something I would recommend and may lead to things breaking so it’s risky in a way. So while this workaround may be fine for you it’s certainly at your own risk.
Be warned that if things break in your system due to this our initial response is going to be asking you to stop doing this workaround.
Best Regards,
Jeremias
This was done for our internal procedure, since application is under the development, and we need to jump between older and earlier revisions. It was the purpose and will not go to the customer.
Best regards.
This was done for our internal procedure, since application is under the development, and we need to jump between older and earlier revisions.
So you’re only using offline updates to move between different versions of your application during development?
If you’re still in development is there a reason you’re using offline updates for this purpose?
I imagine there’s simpler ways to swap the version of your application on the system without having to use something like our offline updates. Which while secure can be quite cumbersome during development.
Best Regards,
Jeremias