Offline updates not finding lockbox

Technical Support
, ,
1

Hello,

We are having an issue with utilizing offline updates on an apalis imx8 SOM with a custom TorizonOS image with build 6.5 as the base image.

We are attempting to just perform an application update. We have created the docker-compose canonicalized file utilizing the torizoncore-builder command and then pushed it to the torizon cloud and created a lockbox there. We then put this on a fat32 USB drive and plug it into the machine. The logs from aktualizr shows that it sees the usb and searches for updates but does not find any. The path we use is /media/USB/update where the update folder contains the images and metadata folders from the lockbox

It seems like a similar issue is happening here: https://community.toradex.com/t/offline-updates-usb-fail/22379/6

We attempted to logout, clear cookies and then rebuild the lockbox from the solution but still no luck on aktualizr finding an update. Below is the json file referenced in the post linked above for our lockbox in the previous post if it is helpful:

{“signatures”:[{“keyid”:“2c8c6b63eaf49afc6cc46a2fb9b87683f8794a55aeeadd8bf351b6933dc3b908”,“method”:“ed25519”,“sig”:“HQ+8qWnQqjFNjSxRt2C/ilSCOEnIw5AgW+lb8bNvUafEcd01Dz4IVvEhCBnKgca4SaAzCuLR99utWVIvrBt8CQ==”}],“signed”:{“_type”:“Offline-Updates”,“expires”:“2025-05-06T20:57:44Z”,“targets”:{“BV1-0.16.0-bv1-rc7”:{“custom”:{“hardwareIds”:[“docker-compose”]},
“hashes”:{“sha256”:“d3a6e800c55bd81568d952b051c9cb16c2906c6110fcd43c8fa37b13a63810ad”},“length”:3008}},“version”:5}}

Another thing that was unusual although might be normal is that the 3.root.json file cannot be found while pulling down the lockbox. It returns “version not available, stopping”. See the logs from the --verbose flag below:

2024-05-08 13:13:06,766 - torizon.tcbuilder.backend.platform - INFO - Fetching ‘3.root.json’
2024-05-08 13:13:06,767 - urllib3.connectionpool - DEBUG - Starting new HTTPS connection (1): api.torizon.io:443
2024-05-08 13:13:07,123 - urllib3.connectionpool - DEBUG - https://api.torizon.io:443 “GET /director/api/v1/admin/repo/3.root.json HTTP/1.1” 424 154
2024-05-08 13:13:07,123 - torizon.tcbuilder.backend.platform - INFO - Fetching ‘3.root.json’ (version not available, stopping)

Thanks for any assistance, Mike

2

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!

Hello Mike,

I understand you’re encountering issues with the offline updates not recognizing the lockbox on your Apalis iMX8 with a custom TorizonOS image. Let’s address the concerns you’ve raised.

  1. Lockbox Not Found by aktualizr: The primary issue seems to be that aktualizr does not recognize the lockbox despite the USB being detected. This could be due to several reasons, including the path not being correctly recognized, issues with the lockbox format, or the metadata not matching what aktualizr expects. Given that you’ve followed the steps for creating a lockbox and placing it in the specified directory, let’s consider other factors.

  2. Path and Filesystem Format: You mentioned using a FAT32 USB drive and placing the lockbox in /media/USB/update. Ensure that the filesystem is correctly mounted by the system and that aktualizr has the necessary permissions to access this path. FAT32 should be supported, but it’s worth double-checking that the drive is not mounted with restrictive permissions that might prevent reading by the aktualizr process.

  3. Lockbox and Metadata: The JSON snippet you’ve provided indicates that the lockbox was created correctly. However, the issue with 3.root.json not being found is concerning. This file is crucial for the update process as it’s part of the chain of trust in the Uptane security framework used by TorizonCore for updates. The error message “version not available, stopping” suggests that there might be a version mismatch or an issue with how the metadata is being fetched or interpreted.

  4. Troubleshooting Steps:

    • Verify Path and Permissions: Double-check the path where the lockbox is located and ensure that aktualizr has read access. You might want to test with a different USB drive or reformat the current one to ensure it’s not a filesystem issue.
    • Review Lockbox Creation Process: Ensure that the lockbox was created with the correct parameters and that all necessary files are included. It might be helpful to recreate the lockbox from scratch to rule out any corruption or misconfiguration.
    • Check Metadata Consistency: The issue with 3.root.json suggests there might be a discrepancy in the metadata. Ensure that all metadata files are correctly generated and consistent with what aktualizr expects. This might involve verifying the versions and ensuring that the metadata on the Torizon Cloud matches what’s expected by the device’s aktualizr client.

  5. Further Investigation: If the above steps do not resolve the

Please, also check if these links can help you solve your problem:

How to Use Secure Offline Updates with Torizon OS | Toradex Developer Center.

How did you like my response?

:+1: :-1:

3

To clarify it is specifically failing 3.root.json for the director-repository metadata handler

4

Greetings @MikeHA,

Well first of all your issue does not appear to be the same as that other issue you linked. Your metadata in your json file looks proper to me, unlike the other case.

Could you share your full Aktualizr logs of the attempted update.

So from your Lockbox information I can see it contains your docker-compose package BV1-0.16.0-bv1-rc7. Is there already an existing docker-compose package installed on your device? Typically the only way Aktualizr would decide that an update is not available is if the same package is already installed on the device.

If you start this process from scratch with a freshly flashed OS, can you reproduce it?

Another thing that was unusual although might be normal is that the 3.root.json file cannot be found while pulling down the lockbox. It returns “version not available, stopping”. See the logs from the --verbose flag below:

This is completely normal, that just means you only have up to 2.root.json. The tool is just iterating upwards until it can’t download anymore root.json files from your account.

Best Regards,
Jeremias