I am trying out updates, offline updates, and interactions with the cloud. I noticed a few things and I am not sure if I am doing something wrong or if this is intended:
Lockbox Creation
I want to interact with the torizon API to create a lockbox with just the application. For proof-of-concept, I created this very simple script:
#!/usr/bin/env bash
# Usage: bash scripts/bash/create_lockbox -i ${TORIZON_CLIENT_ID} -s ${TORIZON_CLIENT_SECRET} -l ${INTENDED_LOCKBOX_NAME} -p ${APPLICATION_ID_TO_INCLUDE}
while getopts i:s:l:p: flag
do
case "${flag}" in
i) CLIENT_ID=${OPTARG};;
s) CLIENT_SECRET=${OPTARG};;
l) LOCKBOX_NAME=${OPTARG};;
p) APPLICATION_PACKAGE_NAME=${OPTARG};;
esac
done
TOKEN_URL="https://kc.torizon.io/auth/realms/ota-users/protocol/openid-connect/token"
# Token expires after 7 days
TOKEN=$(curl -X POST \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "grant_type=client_credentials&client_id=$CLIENT_ID&client_secret=$CLIENT_SECRET" \
$TOKEN_URL)
TOKEN=$(echo $TOKEN | jq -r '.access_token')
# Json POST data contains the list of packages to add to the lockbox and the expiration date of it.
generate_post_data()
{
cat <<EOF
{
"packageIds": [
"$APPLICATION_PACKAGE_NAME"
],
"expiresAt": "2025-08-08T12:16:02.707Z"
}
EOF
}
# Create a lockbox. See https://app.torizon.io/api/docs for documentation and testing
curl -X POST \
"https://app.torizon.io/api/v2beta/lockboxes/$LOCKBOX_NAME" \
-H 'accept: */*' \
-H "Authorization: Bearer $TOKEN" \
-H 'Content-Type: application/json' \
-d "$(generate_post_data)"
This works for almost everything. Except if I have dots in the lockbox name. If I do I receive the error message:
{"msg":"DirectorHttpClient|Unexpected response from remote server at http://director/api/v1/admin/repo/offline-updates/my-app_lockbox_V0.1.1.0|POST|404|The requested resource could not be found.","description":null,"code":"Not Found","cause":null,"errorId":"cfe8d22c-a916-4772-879e-f7a3db40dad5"}
I tried replacing dots with %2E and I still got the same error. Is it a problem with the curl command?
It can be problematic because I wished I could put version strings in the names of the lockbox
Starting Offline Updates
I have a device on Torizon OS 6.8.0. A conf file for offline updates is configured as is:
Updates start as expected when plugging in an USB.
Updates start as expected if I mount a folder containing a lockbox to the /media/USB/update folder.
But, if I move the lockbox to the folder, then nothing happens.
It isn’t really a problem. I just wonder if that is intended?
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,
For the issue you’re encountering with lockbox creation when including dots in the lockbox name, it appears to be related to how the backend service interprets the lockbox name in the URL. The error message indicates that the resource cannot be found, which suggests that the service does not recognize lockbox names with dots as valid identifiers. This is likely not an issue with your curl command per se but rather with the naming conventions enforced by the backend service. As a workaround, consider using alternative characters that are URL-friendly and accepted by the service, such as hyphens (-) or underscores (_), instead of dots.
Regarding the behavior you’ve observed with starting offline updates, the process you described indicates that the system is designed to trigger updates from a specific source directory (/media/USB/update in your case). If the lockbox is initially outside this directory and then moved into it, the system might not detect this change automatically to initiate the update process. This behavior could be intended, designed around the expectation that the update source (lockbox) will be available in the specified directory at the time the system checks for updates, rather than being moved into it afterward. For consistent behavior, ensure that the lockbox is placed in the designated update source directory before the system checks for updates.
Both of these behaviors—naming conventions for lockboxes and the mechanism for detecting updates—reflect specific design choices within the Torizon platform. Adhering to these conventions and understanding the expected behavior of the update mechanism will help ensure smoother operation and fewer errors.
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
And checking internally, having the version on the lockboxes’ names is not a great use of lockboxes, since you will want to be able to update them.
This I will need to ask internally to get more information.
But before that, would you be able to share more details about your use case? How would be this workflow where you need to move a lockbox into the expected “update folder”? Understanding your use case would make it easier to ask internally about it.
The use case is not fully defined yet, but this is for medical devices. The original idea was to handle updates from our cloud. The target device will not be expected to be always connected. Additionally, a number of customers will likely not want to perform updates. Nothing is set in stone, but the idea is that we use offline updates only. Our devices can then be updated from USB by a technician or download the update when they are connected. Then the customer (or technician/support) can apply this update whenever he wants to. Mounting simulate the operation from a USB stick and works, moving the lockbox to the expected folder does not.
I understand that moving the lockbox to a folder would be one of your use cases right? Do you intend to give direct access to the rootfs so someone can move files around?
Feels like simply inserting a USB-stick into the device is less error prone.
It is done for an automated test system. We want that system to replicate closely how real users will update their devices (using an USB-stick). But for other reasons, we cannot use a USB stick on that test system. In consequence, we have to ‘simulate’ the insertion of an USB stick.
Creating a symbolic link to the folder where the lockbox is when you want to trigger the update in the test system should be an alternative here.
As can be seen from aktualizr’s source code, it only detects that the update directory is available when it is created/mounted.
With the intended use of the offline updates this should be adequate.
This logic is implemented in order to avoid failed offline updates to be retried indefinitely while the update storage is not removed.
