Dealing with torizoncore-builder

didier2018 · November 24, 2025, 1:20pm

Hi,

I have different issue when I try to deploy Torizon OS with one container on a IMX6ULL colibri.

here my tcbuild.yaml:

input:
easy-installer:
local: image/torizon-docker-colibri-imx6ull-emmc-Tezi_7.4.0+build.28.tar

customization:
filesystem:

overlay1/

output:
easy-installer:
local: output_directory
EOF

I build image with:

torizoncore-builder build --file tcbuild.yaml --force

I use TEZI to flash the IMX6ULL. All work without issue, but image is deploy on target with registry naming convention:

docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
localhost:5002/torizon_prod 02b67feba2a0 3 days ago 116MB

I would like that the deploy process directly deploy torizon_prod image.

I guess it’s because I use localhost:5002/torizon_prod for the image in my bundle, but torizoncore-builder only want images in registry.

I know I can ‘docker tag’ on host with correct name but I would like this action made in deploy process.

Any clue ?

ToradexAI · November 24, 2025, 1:21pm

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 see you’re encountering an issue with container image naming when using TorizonCore Builder to pre-provision Docker containers. Based on your configuration, you’re only using filesystem customizations but not actually pre-provisioning containers through the proper TorizonCore Builder method.

Understanding Container Pre-provisioning with TorizonCore Builder

To pre-provision Docker containers onto a Torizon OS image, TorizonCore Builder provides specific configuration options in the output section (1). Your current tcbuild.yaml only includes filesystem overlays but doesn’t specify container bundling.

Proper Configuration for Container Pre-provisioning

Method 1: Auto-Pull Containers from Docker Compose

You can configure TorizonCore Builder to automatically pull and bundle containers by specifying a Docker Compose file (2):

output:
  easy-installer:
    local: <path>
    bundle:
      compose-file: custom/docker-compose.yml

(2)

Method 2: Pre-bundled Container Directory

Alternatively, you can pre-bundle containers using the bundle command and then reference the directory (1), (2):

First, create a bundle from your Docker Compose file:

$ torizoncore-builder bundle docker-compose.yml --bundle-directory bundle --platform=linux/arm/v7

(1)

Then reference the bundle directory in your configuration:

output:
  easy-installer:
    local: path/to/your/custom-image-folder
    bundle:
      dir: bundle/

(2)

Complete Configuration Example

Here’s how your tcbuild.yaml should look to properly pre-provision containers:

input:
  easy-installer:
    local: image/torizon-docker-colibri-imx6ull-emmc-Tezi_7.4.0+build.28.tar

customization:
  filesystem:
    - overlay1/

output:
  easy-installer:
    local: output_directory
    bundle:
      compose-file: docker-compose.yml  # or use 'dir: bundle/' for pre-bundled

Platform Specification

Since you’re using an i.MX6ULL (32-bit ARM), make sure to specify the correct platform when bundling (1):

$ torizoncore-builder bundle --platform=linux/arm/v7 docker-compose.yml --bundle-directory bundle

(1)

This approach will ensure that your containers are properly integrated into the Torizon OS image during the build process, eliminating the need for manual Docker tagging after deployment.

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

didier2018 · November 25, 2025, 6:30am

I tried this method but container image on target always have localhost:5002/app:arm

This is a “registry naming”, when I try to docker run this image it doesn’t start.

I expected a image tag without localhost:5002 in its name.

didier2018 · November 27, 2025, 9:36am

@ToradexAI

I tested your solution but I always have localhost:5002/torizon_prod images on container that cannot be run.

ToradexAI · November 27, 2025, 9:36am

Understanding the Container Naming Issue

The localhost:5002 prefix you’re seeing is part of how TorizonCore Builder handles container images during the bundling process (1). This is expected behavior when TorizonCore Builder creates a tarball containing all the containers and generates a Docker Compose file referencing those containers using a specific hash (1).

Root Cause of the Issue

The issue you’re experiencing relates to how the bundled containers are referenced in the modified Docker Compose file that TorizonCore Builder generates (1). When TorizonCore Builder bundles containers, it creates a modified version of the Docker Compose file that references the container images with specific registry paths (1).

Solution: Verify Your Docker Compose File

To resolve this issue, ensure your original Docker Compose file references the container images correctly before bundling. The container images in your Docker Compose file should be referenced by their intended names, not with the localhost:5002 prefix.

For example, your docker-compose.yml should look like this:

services:
  torizon_prod:
    image: torizon_prod:latest
    # other service configurations

Alternative Approach: Use Variable Substitution

You can also use TorizonCore Builder’s variable substitution feature to manage image names more flexibly (2). This allows you to define variables that can be substituted during the build process:

services:
  app:
    image: "${IMAGE_NAME:-torizon_prod}:${IMAGE_TAG:-latest}"

(2)

Then run the build command with variables:

$ torizoncore-builder build --set IMAGE_NAME=torizon_prod --set IMAGE_TAG=latest

Troubleshooting Steps

Check your original Docker Compose file - Ensure it doesn’t already contain localhost:5002 references
Verify the bundle process - The bundle command should create a directory with both the container images and a modified Docker Compose file (1)
Review the generated compose file - Check the compose file in your bundle directory to see how the images are being referenced

The localhost:5002 naming convention is part of TorizonCore Builder’s internal process for managing bundled containers, but the final deployed containers should be runnable with standard Docker commands once properly configured.

Best regards, Toradex AI Assistant.

Did you like my answer?

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

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

didier2018 · November 27, 2025, 3:56pm

Here my real docker-compose.prod.yml

version: “2.4”

services:
torizon_buoy:
image: torizon_buoy_prod:latest
container_name: torizon_buoy_prod
restart: always
working_dir: /home/torizon/app

devices:
  - /dev/colibri-i2c:/dev/colibri-i2c
  - /dev/colibri-uarta:/dev/colibri-uarta
  - /dev/colibri-uartb:/dev/colibri-uartb
  - /dev/colibri-uartc:/dev/colibri-uartc
  - /dev/rtc:/dev/rtc
  - /dev/ttyUSB0:/dev/ttyUSB0
  - /dev/ttyUSB1:/dev/ttyUSB1
  - /dev/ttyUSB2:/dev/ttyUSB2
  - /dev/ttyUSB3:/dev/ttyUSB3

volumes:
  - ${SDCARD_DIR}:${SDCARD_DIR}
  - /local/user/etc/torizonbuoy:/home/torizon/app/.buoy:rw

cap_add:

SYS_TIME

the application name is torizon_buoy_prod and i want tag latest

I get this error when running bundle command:orizoncore-builder bundle --platform=linux/arm/v7 docker-compose.prod.yml --bundle-directory bundle
Creating Docker Container bundle…
NOTE: TCB no longer expands environment variables present in the compose file.

Starting DIND container
Using Docker host “tcp://127.0.0.1:22376”
Connecting to Docker Daemon at “tcp://127.0.0.1:22376”
Fetching container image torizon_buoy_prod:latest in service torizon_buoy
Stopping DIND container
Error: container images download failed: 404 Client Error for https://127.0.0.1:22376/v1.44/images/create?tag=latest&fromImage=torizon_buoy_prod&platform=linux%2Farm%2Fv7: Not Found (“pull access denied for torizon_buoy_prod, repository does not exist or may require ‘docker login’: denied: requested access to the resource is denied”)

lucas_az.tx · January 15, 2026, 2:54pm

Hi @didier2018!

Were you able to solve this issue? If so, could you please share how you did it?

Best regards.

didier2018 · January 16, 2026, 6:22am

Hi,

I don’t remember exactly what I did but most of my problems was due to Fedora and its SELinux / Filesystem management. I uninstalled the native Fedora docker to install the official docker CE and make docker image storage a independant virtual disk:

/var/lib/docker-ext/disk.img on /var/lib/docker type ext4 (rw,relatime,seclabel)

Others problems was my misunderstanding of how TCB work.