Yocto build TorizonOS doesn't recognize lockbox

Hi, I am trying to add a chrony NTP client to the TorizonOS build by using Yocto approach decribed here Build Torizon OS from Source With Yocto Project/OpenEmbedded | Toradex Developer Center. After I successfully created a custom TorizonOS image (my only modification is adding IMAGE_INSTALL:append = " chrony" in the local.conf) I use our usual system customization approach with torizoncore builder to provide specific files / configs changes. After that I generated another torizoncore customized build and got a new Lockbox to try the offline updates mechanism. The issue that I’m getting is that the Aktualizr doesn’t recognize the new Lockbox as an update.

Here is the tdx-info output:


Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           5.15.148-6.6.0-devel-6.6.0-devel+git.23a8e831749d #1-TorizonCore SMP PREEMPT Thu Feb 29 20:25:21 UTC 2024
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.0/torizon/792b69f28c810ea81485e10211ce42d659622af965ed2480d703fd7358e7ad1d/0 clk-imx8mp.mcore_booted=1
Distro name:              NAME="TorizonCore"
Distro version:           VERSION_ID=6.6.0-devel-20241114171935-build.0
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15230140
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Yavia Board
Toradex version:          0058 V1.1B
Serial number:            15230140
Processor arch:           aarch64
------------------------------------------------------------

Here is the Aktualizr config for offline updates:

root@verdin-imx8mp-15230140:~# cat /etc/sota/conf.d/99-offline-updates.toml 
[uptane]
enable_offline_updates = true
enable_online_updates = false
offline_updates_source = "/var/lib/docker/volumes/torizon_application/_data/update"

Here are the contents of offline update metadata file:

{"signatures":[{"keyid":"6530a8f5a72ff4c2080f9fb5542bcfbb8682164fce432cfa2bb33a0ae42fcf22","method":"ed25519","sig":"FltUdXd2FXjg+bKKP6Q1C3iFgdenB+5G392NBOrZPAKPjRmZwqGcAWUb+d8vlWloA0HEIgQdv7nyHrIDqDkdBg=="}],"signed":{"_type":"Offline-Updates","expires":"2025-11-15T15:28:15Z","targets":{"abc3-nema-gateway-docker-apps-release-0.0.9":{"custom":{"canonical_compose_file":true,"createdAt":"2024-11-15T15:28:10Z","hardwareIds":["docker-compose"],"name":"abc3-nema-gateway-docker-apps","targetFormat":"BINARY","updatedAt":"2024-11-15T15:28:10Z","uri":null,"version":"release-0.0.9"},"hashes":{"sha256":"7ce6fa4d96a37f5c6d7a4abe01ce0a16ed47789389e63d191ed17056f40b094d"},"length":977},"aktina-abc3-nema-gateway-os-package-release-0.0.9":{"custom":{"commitBody":"","commitSubject":"TorizonCore Builder union commit created at 2024-11-15T15:27:11","createdAt":"2024-11-15T15:27:52Z","hardwareIds":["verdin-imx8mp"],"name":"aktina-abc3-nema-gateway-os-package","ostreeMetadata":{"oe.arch":"aarch64","oe.distro":"torizon","oe.distro-codename":"kirkstone","oe.image":"torizon-core-docker","oe.kernel-source":["git.toradex.com/linux-toradex.git","toradex_5.15-2.2.x-imx","23a8e831749da"],"oe.machine":"verdin-imx8mp","oe.package-arch":"cortexa53","oe.tdx-build-purpose":"testing","oe.tdx-major":"6","ostree.ref-binding":["tcbuilder-20241115152711"],"version":"6.6.0-devel-20241114171935+build.0-tcbuilder.20241115152711"},"targetFormat":"OSTREE","updatedAt":"2024-11-15T15:27:52Z","uri":null,"version":"release-0.0.9"},"hashes":{"sha256":"1d3020b84c1ae7b8aa071c028a78c0fe36d7d21cd6011eb18b523a725d1abd9d"},"length":0}},"version":36}}

If I build the torizoncore builder customization on top of one of the pre-built images I can run the offline update without any issue. Everything works perfectly.

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Based on the context provided, it seems that the issue with the Lockbox not being recognized as an update by Aktualizr is likely related to the custom TorizonOS image you created using Yocto. Since the offline update mechanism works correctly with pre-built images, the problem might be in the custom build process or the specific configurations applied during the build.

Here are a few suggestions to investigate and potentially resolve the issue:

  1. Verify Metadata Consistency: Ensure that the metadata file generated for the offline update is consistent with what Aktualizr expects. Any discrepancies in the metadata, such as incorrect signatures or missing fields, could cause the update to be unrecognized.

  2. Compare with Pre-built Images: Since the offline update works with pre-built images, compare the metadata and configuration files of the custom image with those of a pre-built image. Look for any differences that might affect the recognition of the Lockbox.

  3. Check Yocto Build Configuration: Review the Yocto build configuration, especially the local.conf and any other configuration files that might affect the build process. Ensure that the addition of chrony does not inadvertently alter other aspects of the build that could impact the update mechanism.

  4. Rebuild and Test: Try rebuilding the custom image with minimal changes to isolate the issue. Start with a basic custom image and gradually add modifications, testing the offline update mechanism at each step to identify when the issue arises.

  5. Consult Documentation and Support: If the issue persists, consult the Toradex documentation for any additional guidance on building custom TorizonOS images and using offline updates. You may also consider reaching out to Toradex support for further assistance.

If these steps do not resolve the issue, it may require a deeper investigation into the specific build process and configurations used in your custom image.

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

[aktualizr, offline updates] Found in archive a file with bad file type: 40960.

Greetings @ollamh,

Could you elaborate on what you mean by “Aktualizr doesn’t recognize the new Lockbox as an update”? Is there some logs from Aktualizr or something to show what is happening?

I assume the device here has been provisioned with information corresponding to the account that the Lockbox originated from correct?

Best Regards,
Jeremias

Thanks for the quick response @jeremias.tx !
Actually I cannot run offline update because the lockbox is not recognized as a valid update.
Yes, we are using the same Torizon account for building all of the builds. The only difference is the TorizonOS image which is used as the base image for torizoncore builder.

I tried to produce two builds with the prebuilt image and everything was fine. E.g. I reset and installed the first build via easy installer and then tried to run the update on the next build lockbox and it was recognized correctly and the update went well.

Actually I cannot run offline update because the lockbox is not recognized as a valid update.

Okay, but you need to clarify to me, what are you seeing that is telling you this? Is it Aktualizr that is not recognizing the update, something else?

When you plug in your Lockbox to the system what does Aktualizr do? This is why I am asking you for the logs.

Either that or just give me your custom image so I can observe this myself.

Best Regards,
Jeremias

Sorry, I can provide right now only limited log, the one that I’ve got when calling aktualizr-torizon once command. Tomorrow or on Monday I can reproduce the issue and get some more logs

root@verdin-imx8mp-15230140:~# aktualizr-torizon once
Aktualizr version tdx-171aba3c starting
Reading config: "/usr/lib/sota/conf.d/20-sota-device-cred.toml"
Reading config: "/usr/lib/sota/conf.d/30-rollback.toml"
Reading config: "/usr/lib/sota/conf.d/40-hardware-id.toml"
Reading config: "/usr/lib/sota/conf.d/50-secondaries.toml"
Reading config: "/usr/lib/sota/conf.d/60-polling-interval.toml"
Reading config: "/usr/lib/sota/conf.d/70-reboot.toml"
Reading config: "/etc/sota/conf.d/99-offline-updates.toml"
Use existing SQL storage: "/var/sota/sql.db"
Couldn`t import data: empty path received
Couldn't import client certificate: "/var/sota/import/client.pem" doesn't exist.
Couldn't import client TLS key: "/var/sota/import/pkey.pem" doesn't exist.
Initializing docker-compose Secondaries...
Use existing SQL storage: "/var/sota/storage/docker-compose/sql.db"
No valid metadata found in storage.
Adding Secondary with ECU serial: 49797169402852f2a2f5e2425bca33f46396689b0e2a1d52097e927a7daffa80 with hardware ID: docker-compose
Initializing torizon-generic Secondaries...
Use existing SQL storage: "/var/sota/storage/bootloader/sql.db"
No valid metadata found in storage.
Adding Secondary with ECU serial: fd8059f8d11b886d3a523da46b837f2251682df240731564da685aa55dad8af5 with hardware ID: verdin-imx8mp-bootloader
Offline Updates are enabled
curl error 7 (http code 0): Couldn't connect to server
curl error 7 (http code 0): Couldn't connect to server
curl error 7 (http code 0): Couldn't connect to server
curl error 3 (http code 0): URL using bad/illegal format or missing URL
curl error 3 (http code 0): URL using bad/illegal format or missing URL
curl error 3 (http code 0): URL using bad/illegal format or missing URL

Oh you’re using the once command? You should have mentioned this and all other details at the the start. Otherwise I’m assuming you’re following the standard offline update process.

The once command doesn’t work with Lockboxes on more recent versions of Torizon OS. What probably happened is that when you built your custom image with Yocto, it ended up using a more recent version of Aktualizr where once no longer works with Lockboxes.

When you used the pre-built images I assume you’re using an older version of Torizon OS where once still works with Lockboxes. If you want to do this in Yocto, then you need to pin Aktualizr to a version where this still works like this other user here did: Offline updates not searching for lockbox - #10 by Mowlwurf

Best Regards,
Jeremias

Thank you very much for pointing out this! I tried to build the same version (6.4.0) as we are currently using for torizoncore builder and I failed due to this bug Rac error, bitbake unable to build and there is no backport of the fix to any branch before 6.6.0 (correct me if I’m wrong). Therefore the minimal branch that I could build is 6.6.0 where this issue with Aktualizr once command already exists. Is there any plan to fix this behavior for “once” command in the future? We heavily rely on the manual invocation of Aktualizr and we definitely need this fix. And what is the situation with 7.x.y branch about aktualizr once call?

Is there any plan to fix this behavior for “once” command in the future? We heavily rely on the manual invocation of Aktualizr and we definitely need this fix. And what is the situation with 7.x.y branch about aktualizr once call?

As of now, we have no immediate plans to work on this, same with 7.X.Y. Honestly speaking there’s not many users who use once with offline updates. This is compounded by the complexities with getting it working without compromising other parts of the client. Since the client today has undergone quite a bit of changes since the time where once did work. So it’s not really a simple matter of just “undo” the changes to get it working again.

If I recall correctly from your previous threads. The reason you use once is to have more direct control over when an update occurs rather than just having it happen automatically, correct?

If that is the case, then the good news is that we are working on a new functionality that may help you with this, without using the once command. We’re basically planning and working on having a mechanism that will allow external processes to send and receive data from the Aktualizr client. The idea would be to allow such actions like checking and installing updates on command rather than just relying on Aktualizr to do these things automatically.

This seems like it would be of interest to your use-case. It would also probably be more proper of an approach, than using once for this purpose.

Best Regards,
Jeremias

2 Likes

Hi @jeremias,

That sounds very good. I look forward to hearing from you soon that this functionality is usable.

Best regards,
Markus

Thank you @jeremias.tx ! We’re looking forward to hear about it!

Just some notes about the functionality I mentioned here. While we are working on it at the moment, it’s still relatively early in the R&D process for this new feature. That is to say I don’t have an exact timeline to provide since it’s truly too early for me to say anything with certainty.

Also, this new feature may only be available with Torizon OS 7.X. Something to keep in mind if you are currently on 6.X.

Finally, the main functionality we have planned so far with this feature is for the ability to send Aktualizr explicit consent from another process/application on whether it should proceed with an update or not. As well as being able to receive information from Aktualizr on whether updates are available or not and other pertinent status information.

If you believe your use-case requires something more than this level of control I described, then do give us the feedback and let us know while we’re still early on in the design.

Best Regards,
Jeremias