TCB: Incompatible Docker Storage Driver 'overlayfs'

I have a pipeline that has been running successfully for months in Azure DevOps on Ubuntu 24.04 image (Microsoft-hosted) with TCB 3.14.0.

Starting from yesterday the same pipeline fails with the following error:

2026-02-13 07:02:01,348 - root - ERROR - Error: Error trying to bundle Docker containers
2026-02-13 07:02:01,349 - root - DEBUG - Traceback (most recent call last):
 File "/builder/tcbuilder/cli/build.py", line 578, in handle_bundle_common download_containers_by_compose_file(**download_params)
 File "/builder/tcbuilder/backend/bundle.py", line 653, in download_containers_by_compose_file manager = DindManager(output_dir, host_workdir)
 File "/builder/tcbuilder/backend/bundle.py", line 178, in __init__
 raise InvalidStorageDriverError(
tcbuilder.errors.InvalidStorageDriverError: Error: Incompatible Docker Storage Driver 'overlayfs'; only 'overlay2' is currently supported.
Learn more on https://developer.toradex.com/software/torizon/torizoncore-builder-issue-tracker?issue=TCB-328

I found this announcement from Microsoft on the Docker upgrade inside its hosted Ubuntu images.

Docker Server and Client will be upgraded from earlier major versions (27.x and 28.x) to version `29.1.x.

Possible impact

Workflows that rely on deprecated or changed Docker behavior may require adjustments after the upgrade.

And I think this is the issue.

Toradex team had been already informed about the issue a couple of months ago, but the customer never recevied any feedback. And the issue has not been fixed yet.

Can someone in Toradex fix the issue ASAP, please?

Moreover (minor): the link provided after the error is not related to the issue itself (it’s for a different error).

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 understand your frustration with the pipeline failure. This issue is indeed related to Docker’s storage driver compatibility with TorizonCore Builder, as you correctly identified.

Current Workaround

Based on the available documentation, there is a known workaround for this InvalidStorageDriverError (1). The issue occurs when Docker is using the overlayfs storage driver instead of the required overlay2 driver.

Solution for Docker Desktop (Windows/WSL2)

If you’re able to configure the Docker daemon in your Azure DevOps environment, you can modify the Docker Engine configuration (1):

  1. Locate the Docker Engine configuration file (typically ~/.docker/daemon.json or /etc/docker/daemon.json)
  2. Add or modify the storage driver setting:
    {
      "storage-driver": "overlay2"
    }
    
  3. Restart Docker for the changes to take effect
  4. Verify the change by running docker info | grep Storage to confirm it shows ‘overlay2’

Alternative Approach for CI/CD Environments

Since you’re running on Microsoft-hosted agents where you may have limited control over Docker configuration, you might need to:

  1. Consider using self-hosted agents where you can control the Docker configuration
  2. Use a Docker-in-Docker approach with a specific Docker version that uses overlay2 by default
  3. Explore using an earlier Docker version in your pipeline if possible

Known Compatibility Issues

The community has reported similar issues with Docker Desktop versions, where reverting to Docker Desktop v4.34.1 from v4.36.0 resolved the problem (1). This suggests that newer Docker versions may have changed their default storage driver behavior.

Additional Context

TorizonCore Builder requires specific Docker configurations to function properly (2). The tool uses Docker volumes and containers extensively for its operations, and storage driver compatibility is critical for proper functionality.

I recommend reporting this specific Azure DevOps compatibility issue to the Toradex team through the Community platform, as this appears to be a new manifestation of the storage driver compatibility problem with the latest Docker versions in Microsoft-hosted environments.

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.

I’ve just printed the outptut of docker info and I can confirm that now the Storage Driver is overlayfs.

Client: Docker Engine - Community
 Version:    29.1.5
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 29.1.5
 Storage Driver: overlayfs
  driver-type: io.containerd.snapshotter.v1
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.0-1017-azure
 Operating System: Ubuntu 24.04.3 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 7.757GiB
 Name: runnervmkz8fe
 ID: 169aa517-19ec-4d49-bd61-4bb79f5886f6
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: githubactions
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Thank you for confirming that the Storage Driver is indeed overlayfs with Docker version 29.1.5. This confirms the root cause of your pipeline failure.

The Problem

Your Azure DevOps Microsoft-hosted Ubuntu 24.04 environment now uses Docker 29.1.5 with the overlayfs storage driver, but TorizonCore Builder requires the overlay2 storage driver (1). This is exactly the incompatibility error you’re encountering.

Immediate Workarounds

Since you’re using Microsoft-hosted agents where you cannot modify the Docker daemon configuration directly, here are your options:

Option 1: Use Self-Hosted Agents

Consider switching to self-hosted Azure DevOps agents where you can:

  • Install Docker with overlay2 storage driver
  • Configure the daemon.json file with "storage-driver": "overlay2" (1)
  • Have full control over the Docker environment

Option 2: Docker-in-Docker Approach

You could potentially use a Docker-in-Docker container with an older Docker version that defaults to overlay2:

# In your Azure DevOps pipeline
- task: Docker@2
  displayName: 'Run with specific Docker version'
  inputs:
    command: 'run'
    arguments: '--privileged -v /var/run/docker.sock:/var/run/docker.sock docker:24-dind'

Option 3: Container-Based Build

Run your entire TorizonCore Builder workflow inside a container that has the correct Docker configuration.

Known Issue Status

As you correctly noted, this issue was reported previously (1), and the community member experienced the same problem with Docker Desktop versions. The workaround that worked was reverting to Docker Desktop v4.34.1 from v4.36.0 (1).

Microsoft’s Docker Upgrade Impact

Your analysis is correct - Microsoft’s announcement about upgrading Docker to version 29.1.x has introduced this breaking change. The new Docker version uses overlayfs as the storage driver, which is incompatible with TorizonCore Builder’s current implementation.

Recommendation

For immediate resolution, I recommend:

  1. Switch to self-hosted agents if possible, as this gives you full control over the Docker configuration
  2. Report this specific issue with Microsoft-hosted agents to the Toradex team via Community, including your Docker version details
  3. Consider using Ubuntu 22.04 Microsoft-hosted agents temporarily if they still use older Docker versions

This is indeed a compatibility issue that needs to be addressed in TorizonCore Builder to support the newer Docker storage drivers used in current Docker versions.

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.