Torizon Lockboxes, TEZI and major updates

Technical Support
, , , ,
1

Hi Community,
I was not able to find this information about using lockboxes with TEZI and major updates in the documentation, so I have two open questions:

a) is it possible to combine first factory programming with TEZI, including auto-provisioning to Torizon Cloud and installing a lockbox at the same time?

b) in the Torizon Cloud UI I see a bootloader package can be part of the lockbox. Would an offline update work also across major updates from TCv5.x to TCv6.y?

Thanks in advance for any feedback and good development,
ldvp

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!

Did you like my answer?

:+1: :-1:

Hello,

Addressing your inquiries on the integration of lockboxes with TEZI (Toradex Easy Installer) and handling major updates:

a) Yes, it is possible to combine the first factory programming with TEZI, including auto-provisioning to Torizon Cloud and installing a lockbox simultaneously. This process allows for a streamlined setup where devices can be provisioned and secured with the necessary software and configurations right from the initial setup. The integration of lockbox installation with TEZI facilitates secure and efficient deployment of devices, ensuring they are immediately ready for operation with the required software versions and configurations.

b) Regarding the inclusion of a bootloader package in the lockbox and the capability for offline updates across major versions, such as from TorizonCore version 5.x to 6.y: Yes, an offline update can accommodate major updates, including bootloader changes. The lockbox mechanism is designed to ensure the integrity and authenticity of the software being installed, regardless of the version jump. This means that as long as the lockbox has been properly defined and includes the necessary components for the update, devices can securely transition between major versions of TorizonCore offline. It’s important to ensure that the lockbox is correctly prepared with all required components and metadata to facilitate a smooth and secure update process.

These capabilities highlight the flexibility and security of the Torizon platform, especially in scenarios requiring secure, reliable software deployment and updates in environments without constant network connectivity.

Best regards,
Toradex AI Assistant

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

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

3

Greetings @ldvp

is it possible to combine first factory programming with TEZI, including auto-provisioning to Torizon Cloud and installing a lockbox at the same time?

I’m not sure if I understand what you mean by this exactly. What are you envisioning here?

Do you want to flash an initial image with TEZI. Then after flashing update the newly flashed image immediately with a Lockbox? In that case why not just flash the complete image from the start instead of doing an initial update?

in the Torizon Cloud UI I see a bootloader package can be part of the lockbox. Would an offline update work also across major updates from TCv5.x to TCv6.y?

First of all, we do document that Offline bootloader updates are not supported: Bootloader Updates in Torizon OS | Toradex Developer Center

Though to be clear we say this in the sense that this is not regularly tested/validated. Not that it won’t work period. In fact I believe it has worked in the past, last time I checked. Though do heed some caution since it’s not as fully tested/validated as online bootloader updates.

All that said, assuming offline bootloader updates works at the moment then yes you should be able to do an offline major update. As long as you still follow the same update procedure as stated in our documentation for major updates.

Best Regards,
Jeremias

4

Hi @jeremias.tx,

Thanks for your answers and all the details, then I’ll try lockboxes with bootloaders and major updates.

Regarding the other TEZI point:

Do you want to flash an initial image with TEZI. Then after flashing update the newly flashed image immediately with a Lockbox? In that case why not just flash the complete image from the start instead of doing an initial update?

I confirm I would like to flash the complete lockbox (target packages OS + Apps + bootloader) since the beginning, but I’m not sure if TEZI supports that. I try to explain my concern:

  • So far, I successfully used TEZI to flash classic “TEZI images”.
  • My understanding is a TEZI image is a folder with an image.json configuration, the OS archive like torizon-core-docker-hardware-id.ota.tar.zst and Apps like docker-storage.tar.xz, other files.
  • When I create a Torizon Lockbox using Torizon Platform and TC Builder, it seems to me that the lockbox is something different, the set of files does not look like a TEZI image.
  • I cannot find in the documentation info about using TEZI to flash a lockbox. This is why I’m asking that.

Hope this helps, thanks and bests,
ldvp

5

Oh I see you want to use TEZI to “flash” a Lockbox? That’s not possible.

First of all, I must ask why would you want to do this?

If you want to flash an entire image, then you would just use TEZI with the usual TEZI images. If you want to update a currently running image you could just use offline or online updates. For what purpose would it accomplish to use TEZI to “flash” a Lockbox?

Also keep in mind it does not even make sense to say “flash” a Lockbox. A Lockbox is just a collection of binaries and metadata that relates to an update package. It does not contain an entire image to flash. TEZI is suppose to be used to flash an entire image so it doesn’t make a whole lot of sense to talk about Lockboxes and TEZI images as comparable objects.

Best Regards,
Jeremias

6

Hi @jeremias.tx ,

thanks for your feedback and for your answers, now it is all clear and the factory programming will be two-steps like this:

  1. TEZI image written by TEZI, with auto-provisioning,
  2. Offline update to Lockbox as factory firmware.

The reason why I’d like to flash a lockbox is to do the process in one step.
Moreover, so far we have flashed TEZI images without offline update, but the factory firmware is then showed in Torizon Platform as “Not authorized in this repository” and this confuses some of our colleagues using the platform.

Cheers,
ldvp

7

The reason why I’d like to flash a lockbox is to do the process in one step.

You’re doing an offline update right after flashing an image with TEZI. Is there a reason you don’t just flash the image with the updated content from the start? I mean if you have the base image you’re flashing with TEZI, and you have the contents of the update from the Lockbox. You should be able to just create a new base image with the contents from the Lockbox already integrated. That way you just flash the image with TEZI and you no longer need to do an offline update. Or is there something about your factory programming I’m still not understanding?

Moreover, so far we have flashed TEZI images without offline update, but the factory firmware is then showed in Torizon Platform as “Not authorized in this repository” and this confuses some of our colleagues using the platform.

Wait, have you reported this behavior to us before? Could you elaborate on what you mean here.

So you flash an image with TEZI “without offline updates”, what does that mean? The image you flashed isn’t configured for offline updates? Or something else?

Then, you say the “factory firmware” are you talking about the Lockbox now?

Finally about the “Not authorized in this repository”. You’re seeing this on our Web UI? Or what are you seeing exactly?

Best Regards,
Jeremias

8

Hi @jeremias.tx,

Thanks for the additional feedback and questions to understand each other.

You’re doing an offline update right after flashing an image with TEZI. Is there a reason you don’t just flash the image with the updated content from the start?

At the moment we are exactly doing what you mention as “flash the image with the updated content from the start”, but the TEZI image is something unknown to Torizon (it is coming directly as output from TCB) and in Torizon I see the following warning “This package is not authorized by your repository” for both Base OS and Application Stack, which works but it is not ideal.
image

Wait, have you reported this behavior to us before?

I think I’ve already talked about this topic with some of your colleague in the past, but it is not a major issue and my understanding is that is because the TEZI image is unrelated from Torizon Platform and not signed/authorized with its KPI.

So you flash an image with TEZI “without offline updates”, what does that mean? The image you flashed isn’t configured for offline updates? Or something else?

I was meaning our current process of 1) flashing a factory firmware as TEZI image with TEZI and then 2) after production, online-updating. At the moment we don’t use offline updates in our processes yet, we may enable it in future.

Then, you say the “factory firmware” are you talking about the Lockbox now?

No, with “factory firmware” I mean the current way of factory programming a TEZI image with TEZI. Sorry for the confusion, but the initial question was in the perspective of switching to Lockboxes as “factory firmware”, something different from the current process.

Finally about the “Not authorized in this repository”. You’re seeing this on our Web UI? Or what are you seeing exactly?

As in the picture above, it is seen in the Torizon Cloud UI. Our TEZI image used as factory firmware are still relatively old, I am not sure if something changed on this with TCv6.

Cheers,
ldvp

9

Oh I see what you mean now. The message “This package is not authorized by your repository”, is not anything harmful. It just means the packages found on this device do not correspond to any known packages in your torizon.io account. The server looks at the hashes for the packages installed on your device, and if it can find matching hashes for packages that are uploaded to your account it will reflect so in the UI. But, just having these messages isn’t problematic in any way.

Is this actually problematic for you and your team somehow? Or is it just the presence of the message itself that is worrying? At worst this should just be a warning message with no actual impact on anything. But, if it’s causing real problems for you then I would like to know, because that wouldn’t be expected.

Best Regards,
Jeremias

10

Agree, it is a minor issue and only transitory between factory programming and first update request (offline or online).

On a second thought, I’ll try the following sort of “two-installation-one-USB” process:

  1. have both the TEZI factory programming image and the Torizon lockbox on the same USB stick,
  2. plug the USB stick in a brand new board board,
  3. TEZI should just see the TEZI image and install Torizon OS, auto-reboot is configured in image.json,
  4. after reboot, Torizon OS should boot and find the Torizon Lockbox to install the final packages

I keep you posted how it goes.

Thanks again and best regards,
ldvp

11

On a second thought, I’ll try the following sort of “two-installation-one-USB” process:

Wait, I don’t think this will work like you think it does. Offline updates are designed so that the Lockbox needs to become available after Aktualizr has started running. If the Lockbox already exists in the path defined by offline_updates_source, before Aktualizr starts, then the offline update won’t occur. This was to prevent scenarios where the device would reboot see the Lockbox, update, then reboot again and see the same Lockbox causing a weird update loop.

In theory you could have offline_updates_source be something like /home/torizon/lockbox-here, then have a service/script copy the Lockbox to this location after Aktualizr starts. That would work to initate the update.

But again, I have to ask why not just flash the updated content to begin with? Why go through this weird process of doing an offline update right after flashing?

Is it all just to avoid the “This package is not authorized by your repository” message? Is it something that bothers your team that much?

If it does truly bother you that much you can just upload these packages to your repository account so that when the device goes online it can match the installed packages on the device, to existing packages on your account. Then this message would not appear.

Best Regards,
Jeremias

12

Wait, I don’t think this will work like you think it does. Offline updates are designed so that the Lockbox needs to become available after Aktualizr has started running.

Thanks for the additional thoughts, very good to know. I was not aware of that mechanism.

But again, I have to ask why not just flash the updated content to begin with? Why go through this weird process of doing an offline update right after flashing?
Is it all just to avoid the “This package is not authorized by your repository” message? Is it something that bothers your team that much?

Removing the “not authorized” message from the process is a nice-to-have at the moment. I was also considering this evolution of the process for other nice-to-have reasons: 1) to simplify the production process to have less steps and less USB sticks, ideally one, 2) because the Production team have no access to Torizon Platform, so they cannot do online updates.

If it does truly bother you that much you can just upload these packages to your repository account so that when the device goes online it can match the installed packages on the device, to existing packages on your account.

This sounds interesting, thanks. How can we do that?

Cheers,
ldvp

13

This sounds interesting, thanks. How can we do that?

As I said if the package that is installed on the device is the exact same as a package that is on the platform account the device is provisioned to then the Web UI should recognize the package.

For example if you have OS package FOO installed on the device you should also upload this exact same package FOO to our platform. If the version hashes match then the web UI will be able to connect the package on the device to the package uploaded to your account and then there will be no “This package is not authorized by your repository” message.

As I said, all this message means is that the package that is installed on your device can not be matched to a package that is on your platform account. Therefore just make the package available in your account.

All that said, you still have not really explained to me why you’re trying to do such a strange production programming process. If your goal is to make your production programming simpler. Then why not just flash the image with the full updated contents from the start. Rather than flash an initial image, then do an offline update. It just seems like you’re making the process more complicated for reasons I do not understand.

Best Regards,
Jeremias

14

Thanks for the additional information. Our current process is the following:

  1. We build the TEZI image from your TC OS and our customizations with “TCB build” command
  2. The TEZI image is pushed to Torizon Cloud with the “TCB platform push” command.
  3. The TEZI image is configured for auto-provisioning with the “TCB images provision” command.
  4. The TEZI image is flashed with TEZI on new boards, but not recognized (“Not authorized”) by the cloud.

Maybe we have to run “TCB platform push” or “TCB images provisions” with different options to have the TEZI image packages recognized by Torizon Cloud?

If your goal is to make your production programming simpler. Then why not just flash the image with the full updated contents from the start.

You are right, I get the point. We’ll then transfer always to Production Team a new TEZI image any time we release a new software version, this is clear now. :+1:

Thanks and bests,
ldvp

15

Maybe we have to run “TCB platform push” or “TCB images provisions” with different options to have the TEZI image packages recognized by Torizon Cloud?

Could you check the OSTree commit hash that is running on your device and compare it to the hash for the OS package you upload? If the hashes match then the Web UI should correspond them to one another.

Best Regards,
Jeremias

16

Hi @jeremias.tx,
maybe I’ve found the missing piece of configuration to make the mechanism working:

tcb build --set OSTREE_REF=SOME_UNIQUE_ID
tcb platform push SOME_UNIQUE_ID

whereas in my previous builds was always the same constant and probably was preventing the correct association of the same OS between TEZI and Torizon. Now I see the OS installed by TEZI is recognized as the same OS in Torizon.

For SOME_UNIQUE_ID I’m using the git SHA of the current version of configuration I’m building, but I guess it could be some timestamp as well.

Cheers,
ldvp

17

Hi @ldvp

You can also set the ref in your tcbuild.yaml file.

In the “output” section, something like the following should work.

 ostree:
   branch: "RANDOM_REF_HERE"
   commit-subject: "Commit subject"
   commit-body: "Commit body"

HTH,
Drew

18

whereas in my previous builds was always the same constant and probably was preventing the correct association of the same OS between TEZI and Torizon. Now I see the OS installed by TEZI is recognized as the same OS in Torizon.

That makes sense. Every time you run build it produces a unique reference. If you want consistency you need to track this reference for subsequent commands like platform push, like you did.

Best Regards,
Jeremias