Module: Verdin iMX8M Plus Carrier-Board: Verdin Development Board
I created a custom image with a logo and bundled docker application and pushed it to the Torizon Cloud, following the instructions on TorizonCore Builder Tool - Customizing Torizon OS Images | Toradex Developer Center.
(Image-Base is the 6.8.1 Build 25 TEZI Image)
Once I deploy it to our Device via the Cloud it boots up (displaying the custom logo) but not with our application. Instead it keeps showing the Pairing Screen.
If I check /var/sota/storage/docker-compose/docker-compose.yml it is set to the one from the pairing instead of our bundled application.
The build command shows, as far as I understood it, that it merged the bundle into the image:
Building image as per configuration file 'config/tcbuild-gsd-bundle.yaml'...
=>> Handling input section
Unpacking Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 9d92502e38e6664178fb47775aef559409adf9f562e796c63351e4c8d9f63e52 from local repository...
1060 metadata, 9444 content objects imported; 590.3 MB content written
0 metadata, 0 content objects imported; 0 bytes content written
Unpacked OSTree from Toradex Easy Installer image:
Commit checksum: 9d92502e38e6664178fb47775aef559409adf9f562e796c63351e4c8d9f63e52
TorizonCore Version: 6.8.1+build.25
=>> Handling customization section
=> Setting splash screen
splash screen merged to initramfs
=>> Handling output section
Applying changes from STORAGE/splash.
Applying changes from WORKDIR/custom/fs-docker-config.
Commit 47d79677a9d34e6033f94a3c3d7d274e73dde31a0ce6bb0af86943b751d49306 has been generated for changes and is ready to be deployed.
Deploying commit ref: gsdDemo
Pulling OSTree with ref gsdDemo from local archive repository...
Commit checksum: 47d79677a9d34e6033f94a3c3d7d274e73dde31a0ce6bb0af86943b751d49306
TorizonCore Version: 6.8.1+build.25-tcbuilder.20250520142829
Default kernel arguments: quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3
1060 metadata, 9445 content objects imported; 590.3 MB content written
Pulling done.
Deploying OSTree with checksum 47d79677a9d34e6033f94a3c3d7d274e73dde31a0ce6bb0af86943b751d49306
Bootloader found in unpacked image: U-Boot
Deploying done.
Copy files not under OSTree control from original deployment.
Packing rootfs...
Packing rootfs done.
Updating Torizon OS image in place.
Combining Torizon OS image with Docker Container bundle.
=>> Build command successfully executed!
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer?
Hello, and thank you for your detailed description of your setup and process!
This behavior is expected when using Torizon Cloud for device provisioning and image deployment:
When you push a custom Torizon OS image with pre-bundled Docker containers to the Torizon Cloud and deploy it to a device, the device software management on first boot will perform cloud provisioning.
By design, if the device is enrolled in the Torizon Cloud, the cloud server takes control of application deployment. This means that the cloud-provided application configuration (for example, the pairing screen or any application you subsequently deploy from the cloud) will override any pre-bundled applications from the image itself.
Key points to consider:
Cloud Provisioning Takes Precedence:
The pairing screen and its docker-compose configuration are managed by Torizon Cloud upon first provisioning. The /var/sota/storage/docker-compose/docker-compose.yml is set based on the cloud’s instructions, not what was bundled in your image.
How to Update OS and Application Together:
If you want to deploy both a customized OS (with your splash/logo, etc.) and your application in synchrony via Torizon Cloud, you should not pre-bundle the application inside the image.
Instead, use the synchronous update feature of Torizon Cloud which allows you to deploy OS and application updates together in one operation.
What to do next:
Remove Container Bundling:
When generating your custom OS image, do not bundle your application into the image itself.
Upload Custom OS to Cloud:
Push your OS (with your custom logo) to Torizon Cloud.
Deploy your Application via Torizon Cloud:
Use Torizon Cloud’s application deployment feature to push your docker-compose (application) configuration as a separate deployment.
Use Synchronous Updates for Future Deployments:
When you need to update both OS and application, leverage synchronous updates via Torizon Cloud, which orchestrates both in one transaction for your devices.
Pre-provision container images onto Torizon OS: to be used when you are preparing your own custom Torizon OS image for production programming, allowing it to boot with your containers from the first time, without the need to pull those from the internet.
Is this only done when I flash the Image directly onto the board?
Maybe you could add a remark to the bundle section in which cases the bundled application is shown and in which it defaults to the pairing screen.
For example If I configure my tcbuild.yaml to have no pairing or automatic pairing, does that mean it then shows my bundled application automatically?
I for example assumed that a bundled application would take priority, especially when I deploy the image from the cloud to an already paired device. Because why would I need to pair it again?
Or, take the output of the build command and flash that to your device using Toradex Easy Installer. This will re-flash the entire device OS, docker-compose, everything.
