I’m glad to ask for your assistance again,
I have been trying to upload a verdin-imx8mp from 6.7.0 to 6.7.0 with synchronous offline updates but everytime i start the update, i get this following error
I’m creating a file located at /etc/sota/conf.d named 100-offline-updates.toml
I’m providing the file with the following line
After that i’m desabling automatic reboot witht he following command :
sudo systemctl stop ostree-pending-reboot.path
sudo systemctl disable ostree-pending-reboot.path
In the end I am restarting Aktualizr : sudo systemctl restart aktualizr
After that I’m able to create an apropriate lock box and send it to my device.
It seems that the device is recognizing the updates but the reboot is failing and the device is maintaining to the older version. Moreover, when I’m performing the updates and it fails, if I manually perform a reboot “sudo reboot now” the device is rebooting and it’s reconnecting with the new updates.
The above procedure was working perfectly with the device in 5.7.0 Torizon OS.
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?
It seems like you’re encountering an issue with the synchronous offline updates on Torizon OS 6.7.0. Here are a few steps to troubleshoot and potentially resolve the issue:
Configuration File: Ensure that your 100-offline-updates.toml file is correctly configured. It should look something like this:
Restart Aktualizr: After making changes, restart the Aktualizr service:
sudo systemctl restart aktualizr
Check Logs: Check the logs for any errors or warnings that might give more insight into why the update is failing. You can use journalctl to view the logs:
journalctl -u aktualizr -f
Manual Reboot: Since the manual reboot seems to apply the updates correctly, it indicates that the update process itself is working, but the automatic reboot is not triggering as expected. Ensure that there are no additional services or configurations that might be interfering with the reboot process.
Update Method: Verify that both online and offline updates are not enabled simultaneously unless intended. For Torizon OS versions 6.6.0-devel-202402 and later, you can enable both methods:
Lockbox: Ensure that the lockbox is correctly defined and contains the necessary update artifacts. Verify that the lockbox is correctly mounted and accessible at the specified path.
If the issue persists, it might be helpful to compare the configurations and logs between the working version (5.7.0) and the current version (6.7.0) to identify any discrepancies.
Just to make sure I understand your entire situation, I have some questions.
To summarize you are doing an offline synchronous update and the main issue is that your reboot is failing. Do note the error about the PROXY is not really related to the update, nor is it a critical issue and can be ignored in this context.
So you said you “disabled” the automatic reboot. If that is the case then why are you still expecting the system to automatically reboot during the update process? Also why did you disable the automatic reboot mechanism in the first place?
Because in that thread I said the issue was fixed now in the latest versions of 6.X. Meaning you don’t need to do this workaround stuff anymore. In fact it doesn’t even work the same anymore in the latest version which is probably why you’re seeing the behavior you’re describing.
If you’re on the latest version of Torizon OS you can just use offline sync updates normally as documented.
Thank you for your help,
Actually, I was disabling automatic reboot because of this old thread,
I want to migrate from 5.7.0 to 6.7.0,
I was testing upgrades from 6.7.0 to 6.7.0 and I was facing this problem,
So if I delete the " force_install_completion = true" in my uptane file and I’m enabling the automatic reboot it should work fine ?
What about updating from 5.7.0 to 6.7.0 ? What should I do ? Keep the old configuration in place until the system reach the 6.7.0 ?
So if I delete the " force_install_completion = true" in my uptane file and I’m enabling the automatic reboot it should work fine ?
Yes just perform the update as documented with no extra configurations or commands. I tried myself on 6.7.0 and sync updates work as expected with the minimal configuration.
What about updating from 5.7.0 to 6.7.0 ? What should I do ? Keep the old configuration in place until the system reach the 6.7.0 ?
Well if the old configuration is working on 5.7.0 just fine then keep that, but as shown here you will need to change the configuration for 6.7.0. Also keep in mind if you’re going from 5.7.0 to 6.7.0 via the way of an update, you’ll need to follow a specific procedure as documented here: Bootloader Updates in Torizon OS | Toradex Developer Center
Thank you, I did not see the fact that a Bootloader update was needed.
But I’ve seen that the Offline updates for bootloader are not supported yet and I’m only using Offline updates for now,
Concerning this I have some questions :
What are the risks of not performing a bootloader update while performing an OS update from 5.7.0 to 6.7.0 ?
Would it be possible to perform a bootloader on a systeme that is already in 6.7.0 once the Offline bootloader update will be available ?
But I’ve seen that the Offline updates for bootloader are not supported yet and I’m only using Offline updates for now,
As a note we only state this because we don’t strictly test this use-case as of yet. It can work and some people still use offline bootloader updates.
What are the risks of not performing a bootloader update while performing an OS update from 5.7.0 to 6.7.0 ?
The effects could range from strange behavior of the OS to even the system not being able to properly boot. This is why we strongly recommend the bootloader be updated to avoid such possible issues.
Would it be possible to perform a bootloader on a systeme that is already in 6.7.0 once the Offline bootloader update will be available ?
It could. Though as my first point said, there’s nothing actually strictly preventing an offline bootloader update from working currently. It’s just not well-tested at the moment. So it’s more like use with caution, rather than “this does not work at all”.
I would like to perform updates to devices that are offline and cannot be put online.
What would be the solutions for me to provide a new bootloader to these devices ?
I would like to perform updates to devices that are offline and cannot be put online.
What would be the solutions for me to provide a new bootloader to these devices ?
As I said you can still perform the bootloader update offline. We don’t officially test this, but there shouldn’t be any issue preventing this from working.
Okay @jeremias.tx thank you for your time and your help,
I will try to implement a lockbox with a bootloader update in it and try to perform it offline,
I will come back to you if a problem is encountered,