Version handling during online- and offline-updates

Hello,

I have got some questions about the online- and offline-updates via torizon-cloud.
Is it possible to get information about a pending online-update on the client?
As far as I understand it is currently only possible to detect that an update is pending, but not what would be updated or to which version.

Similar for offline-updates:
It seems like there isn’t any information whats contained in the update, besides the name of the update in metadata/director/
Is there somewhere else where we could place or read information about the update? Or is it better to add our own meta-file to any offline-updates?
Is it possible to add tags to a canonicalized docker-compose file?

Best regards

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I’d be glad to help with your questions about Torizon Cloud updates! To provide you with the most accurate guidance, could you let me know which OS and version you are using? You can run the tdx-info command to get detailed information about your hardware and OS setup. For more details about this command, see tdx-info.

Update Information and Metadata

Based on the available documentation, here’s what I can tell you about update information:

Online Updates Information

For online updates, Aktualizr handles the update process and logs detailed information that you can monitor (1). You can track update progress and completion by monitoring the logs generated by Aktualizr using the journalctl command (1).

Package Metadata for Updates

When pushing packages to Torizon Cloud, you can specify custom metadata and versioning information (2):

For Docker Compose packages:

  • Use --package-name to set a custom name for the update package (2)
  • Use --package-version to specify the version (can be any legitimate string, not just numerical) (2)
  • The package name and version will appear in the Torizon Cloud web UI (2)

For generic packages:

  • Use --custom-meta to add custom metadata in JSON format (2)
  • This custom metadata is available on the device during the installation phase (2)

Example command for adding custom metadata to a generic package:

torizoncore-builder platform push --credentials credentials.zip --hardwareid genpack --package-name tcb-test-genpack --custom-meta '{"fw_ver": "000007"}' --package-version 1.1 generic-package.bin

(2)

Canonicalized Docker Compose Files

Regarding canonicalized docker-compose files, the documentation explains that canonicalizing puts the file into a specific YAML format, removes comments, and associates HASH values to Docker images (2). When using the --canonicalize option, TorizonCore Builder will save a copy with .lock.yml or .lock.yaml extension (2).

Recommendations

For better tracking of update contents, consider:

  1. Using descriptive package names and versions when pushing updates (2)
  2. Adding custom metadata to generic packages using the --custom-meta option (2)
  3. Implementing your own meta-file approach for additional information as you suggested

The metadata approach you mentioned could indeed be a good solution for providing more detailed update information beyond what’s available in the standard update metadata.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Greetings @aigF,

Regarding getting information on a pending update. If I understood you correctly, you want to be able to get this information on the device-side, correct?

If that is the case perhaps the following will help. We have a dbus-based API available on the Aktualizr update client: aktualizr/docs/dbus-api.md at toradex-develop · toradex/aktualizr · GitHub

As seen in the linked documentation there is an API that shows the update metadata for any currently pending updates. This would include information like the name and version of the packages to be installed as well as the corresponding hashes. This sounds like it should be enough identification information for your needs.

Would something like this suffice or are you looking for something more, or different?

By the way if you do want to try this dbus-api feature, it’s relatively recent so you’ll need a fairly new version of Torizon OS.

Best Regards,
Jeremias

Hi @jeremias.tx ,

I have seen the dbus-api, but did not see the part about the update-information. I take it that this is part of the consent-api reply? (aktualizr/docs/dbus-api.md at toradex-develop · toradex/aktualizr · GitHub)
If that is the case I might need to check out dbus.

As for the offline updates, I guess we will need to just bundle out own meta-file into the update.

Best regards

Hi @jeremias.tx ,

while testing the tdx-info command I might have encountered a bug:

My current image was built with a custom device-tree, which is applied via torizoncore-builder like this:

# >> The customization section defines the modifications to be applied to get
# >> the desired output image.
customization:
  device-tree:
    include-dirs:
      - linux_OS7/include
    custom: linux_OS7/arch/arm64/boot/dts/freescale/imx8mp-verdin-pm2-wifi-dev.dts

The custom device tree is a copy of the imx8mp-verdin-wifi-dev.dtb, with adjustments for our custom board.

/dts-v1/;

#include "imx8mp-verdin-pm2.dtsi"
#include "imx8mp-verdin-pm2-wifi.dtsi"
#include "imx8mp-verdin-pm2-dev.dtsi"

/ {
	model = "Toradex Verdin iMX8M Plus WB for custom module";
	compatible = "toradex,verdin-imx8mp-wifi-dev",
		     "toradex,verdin-imx8mp-wifi",
		     "toradex,verdin-imx8mp",
		     "fsl,imx8mp";
};

The custom device tree seems to be applied, since for example our custom ethernet-phy is working(which would never be the case with the default imx8mp-verdin-wifi-dev.dtb).

But the output of tdx-info -dt is as follows:

sudo tdx-info -dt
Password: 

Device tree
------------------------------------------------------------
Device tree enabled:      imx8mp-verdin-wifi-dev.dtb
Compatible string:        toradex,verdin-imx8mp-wifi-devtoradex,verdin-imx8mp-wifitoradex,verdin-imx8mpfsl,imx8mp
Device trees available:
                          imx8mp-verdin-nonwifi-dahlia.dtb
                          imx8mp-verdin-nonwifi-dev.dtb
                          imx8mp-verdin-nonwifi-ivy.dtb
                          imx8mp-verdin-nonwifi-mallow.dtb
                          imx8mp-verdin-nonwifi-yavia.dtb
                          imx8mp-verdin-pm2-wifi-dev.dtb
                          imx8mp-verdin-wifi-dahlia.dtb
                          imx8mp-verdin-wifi-dev.dtb
                          imx8mp-verdin-wifi-ivy.dtb
                          imx8mp-verdin-wifi-mallow.dtb
                          imx8mp-verdin-wifi-yavia.dtb 

Is there something I am missing in the .dts-file itself, or is it possible that there might be a bug in tdx-info?

Best regards

As for the offline updates, I guess we will need to just bundle out own meta-file into the update.

I’m confused why do you still need a separate meta-file for offline updates? I believe the update information from the dbus-api should still work for offline updates as well.

Is there something I am missing in the .dts-file itself, or is it possible that there might be a bug in tdx-info?

This is a known bug. The tdx-info tool determines the device tree by parsing the fdtfile environment variable from U-Boot. However, TorizonCore Builder sets device trees by modifying the boot script, not by setting fdtfile. Therefore tdx-info will just parse the unchanged variable from U-Boot even though it’s no longer accurate.

This hasn’t been a super high priority issue for us to address which is why it’s still present.

Best Regards,
Jeremias

I’m confused why do you still need a separate meta-file for offline updates? I believe the update information from the dbus-api should still work for offline updates as well.

If that’s the case, that the consent API also applies to offline updates, that’s great!

With that I believe all my questions are answered for now.

Thank you and best regards

If that’s the case, that the consent API also applies to offline updates, that’s great!

I believe it should last I checked.

That said. please do double-check and test for yourself of course. The dbus-api is still a relatively new feature for us and not something we have had time to strenuously test. If you notice any issues or have any feedback about it, please don’t hesitate to tell us. This early feedback is crucial for improving on the initial work we have done.

Otherwise, I’m glad I was able to help.

Best Regards,
Jeremias