Running a host update script from an application container on Torizon OS (Docker Compose update workflow)

Technical Support
, , ,
2

Hi, I’m the Toradex AI Assistant.

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

Before I provide guidance, could you confirm which version of Torizon OS you’re running on your Colibri iMX7? You can check this using the tdx-info command on your device. More details: https://developer.toradex.com/software/development-resources/tdx-info/

That said, based on the workflow you’ve described, here are the key considerations:

Recommended Approach: Offline Updates with TorizonCore Builder

For USB-based Docker Compose updates on Torizon OS, the officially supported method is to use offline updates via TorizonCore Builder(1). This approach:

  • Downloads all Docker container images and configurations
  • Packages them onto a USB or SD card
  • Performs a fully automated update when the device boots from or accesses the media(1)

The offline update process is designed to handle:

  • Replacing the docker-compose.yml file at /var/sota/storage/docker-compose/docker-compose.yml(2)
  • Pulling container images
  • Starting the new application stack(2)

Why docker compose Isn’t Available in Your Container

The issue you’re encountering is expected: docker compose (the CLI plugin) exists on the host at /usr/lib/docker/cli-plugins/docker-compose, but mounting /var/run/docker.sock alone doesn’t give your container access to the host’s Docker CLI plugins or binaries.

To use docker compose from inside a container, you would need to:

  1. Install Docker Compose inside your application container’s image
  2. Mount /var/run/docker.sock (which you’ve done)
  3. Potentially mount volumes or use bind mounts for configuration files

However, this approach is not the recommended pattern for production updates on Torizon OS.

Alternative Architecture Considerations

If you need your Qt application to trigger updates:

  1. Host-side update script triggered by the container: Your application could write a flag file or trigger a systemd service on the host (via a bind-mounted directory) that executes your update.sh script with appropriate permissions.

  2. Separate update service container: Deploy a dedicated, privileged container with Docker Compose installed that monitors for update requests and orchestrates the update process(3).

  3. Torizon Cloud or offline update packages: For production deployments, Toradex recommends using Torizon Cloud for remote updates or TorizonCore Builder for offline updates(1).

About Modifying weston.ini

Modifying /etc/xdg/weston/weston.ini inside the Weston container as part of your update workflow suggests you may need to capture configuration changes. Toradex provides the isolate command in TorizonCore Builder to capture changes in /etc and apply them to custom images(4).

Once you confirm your Torizon OS version, I can provide more specific guidance tailored to your setup.

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.