Checksum error when trying to deploy source-built Torizon image

Florens · April 13, 2026, 10:46pm

I followed the instructions to build Torizon from source here: Build Torizon OS from Source With Yocto Project/OpenEmbedded | Toradex Developer Center
I used the option with the crops docker container for this build.

NOTE: Tasks Summary: Attempted 9282 tasks of which 0 didn't need to be rerun and all succeeded.
NOTE: Writing buildhistory
NOTE: Writing buildhistory took: 8 seconds

Summary: There were 7 WARNING messages.

The build completes without any errors (just a couple of warnings), but when I try to deploy it using torizoncore-builder, I get a checksum error.

First unpacked like this:

❯ torizoncore-builder images unpack source-build/workdir/build-torizon/deploy/images/toradex-smarc-imx95/torizon-docker-toradex-smarc-imx95-Tezi.tar 
Storage not empty. Delete current image before continuing? [y/N] y
Unpacking Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 9ccd1d6a4a1c4c55eba6525d4a2863cdb812f4e5d4c7f927c585e74bfb3b9fa0 from local repository...
1284 metadata, 9867 content objects imported; 726.0 MB content written                                                                                                                                                                                        
0 metadata, 0 content objects imported; 0 bytes content written                                                                                                                                                                                               
Unpacked OSTree from Toradex Easy Installer image:
  Commit checksum: 9ccd1d6a4a1c4c55eba6525d4a2863cdb812f4e5d4c7f927c585e74bfb3b9fa0
  TorizonCore Version: 7.5.0-devel-20260413203527+build.0

Then deploy:

❯ torizoncore-builder deploy --remote-host 192.168.0.121 --remote-username torizon --remote-password torizon --reboot
WARNING: Beware that artifacts not managed by OSTree (e.g. bootloader, container images, platform provisioning data, fuse values, U-Boot environment) will not be deployed by this operation.
Pulling OSTree with ref base (checksum 9ccd1d6a4a1c4c55eba6525d4a2863cdb812f4e5d4c7f927c585e74bfb3b9fa0) from local archive repository...
Starting http server to serve OSTree.
OSTree server listening on "localhost:42153".
97417c0066dda6e1f0deb8168817a551474349f1c1e67af2725b8199f221f4e0
'toradex-smarc-imx95'
Starting OSTree pull on the device...
An unexpected Exception occurred. Please provide the following stack trace to
the Toradex TorizonCore support team:


Traceback (most recent call last):
  File "/builder/torizoncore-builder", line 234, in <module>
    mainargs.func(mainargs)
  File "/builder/tcbuilder/cli/deploy.py", line 227, in do_deploy
    do_deploy_ostree_remote(args)
  File "/builder/tcbuilder/cli/deploy.py", line 190, in do_deploy_ostree_remote
    deploy_ostree_remote(
  File "/builder/tcbuilder/cli/deploy.py", line 184, in deploy_ostree_remote
    dbe.deploy_ostree_remote(remote_host, remote_username, remote_password,
  File "/builder/tcbuilder/backend/deploy.py", line 573, in deploy_ostree_remote
    run_command_with_sudo(
  File "/builder/tcbuilder/backend/deploy.py", line 448, in run_command_with_sudo
    result = ssh_connection.sudo(command, pty=True, hide=True, timeout=REMOTE_CMD_TIMEOUT)
  File "/usr/local/lib/python3.9/dist-packages/decorator.py", line 235, in fun
    return caller(func, *(extras + args), **kw)
  File "/usr/local/lib/python3.9/dist-packages/fabric/connection.py", line 23, in opens
    return method(self, *args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/fabric/connection.py", line 777, in sudo
    return self._sudo(self._remote_runner(), command, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/invoke/context.py", line 232, in _sudo
    return runner.run(cmd_str, watchers=watchers, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/fabric/runners.py", line 83, in run
    return super().run(command, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/invoke/runners.py", line 395, in run
    return self._run_body(command, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/invoke/runners.py", line 451, in _run_body
    return self.make_promise() if self._asynchronous else self._finish()
  File "/usr/local/lib/python3.9/dist-packages/invoke/runners.py", line 518, in _finish
    raise UnexpectedExit(result)
invoke.exceptions.UnexpectedExit: Encountered a bad command exit code!

Command: "sudo -S -p '[sudo] password: ' ostree pull tcbuilder:9ccd1d6a4a1c4c55eba6525d4a2863cdb812f4e5d4c7f927c585e74bfb3b9fa0"

Exit code: 1

Stdout:

[sudo] password: 

error: Writing content object: Corrupted file object; checksum expected='d84ffb0772ed6cc2f33adaa8f1bf72edecb83e391334901a54010afc9cc67095' actual='4cbd558a36a7b7e1804f958177474f00133cd76593dc9326c24803258d5681f3'

Stderr: n/a (PTYs have no stderr)

ToradexAI · April 13, 2026, 10:47pm

Hi, I’m the Toradex AI Assistant.

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

Looking at your checksum error when deploying a source-built Torizon image, this appears to be a corruption issue during the OSTree pull operation. The error indicates that the expected checksum doesn’t match the actual checksum of a content object:

error: Writing content object: Corrupted file object; checksum expected='d84ffb0772ed6cc2f33adaa8f1bf72edecb83e391334901a54010afc9cc67095' actual='4cbd558a36a7b7e1804f958177474f00133cd76593dc9326c24803258d5681f3'

Troubleshooting Steps

1. Verify Image Integrity

First, verify that your source-built image wasn’t corrupted during the build process. You can check this by examining the OSTree repository structure and ensuring the build completed successfully.

2. Network Connection Issues

The checksum mismatch often occurs due to network transmission issues during the OSTree pull operation. Try deploying over a more stable network connection or using a wired connection instead of Wi-Fi.

3. Alternative Deployment Method

Instead of using the deploy command with remote deployment, try creating a Toradex Easy Installer image and flashing it directly to an SD card:

torizoncore-builder images deploy --output-directory ./output-tezi

(1)

This creates a Toradex Easy Installer image that you can flash using the Toradex Easy Installer without network dependency.

4. Clean and Retry

Clear the TorizonCore Builder storage and try the process again:

torizoncore-builder images unpack source-build/workdir/build-torizon/deploy/images/toradex-smarc-imx95/torizon-docker-toradex-smarc-imx95-Tezi.tar

(1)

When prompted, delete the current image storage and start fresh.

5. Check Source Build

Since you’re using a source-built image, ensure that the Yocto build process completed successfully without any critical errors that might have affected the OSTree repository integrity.

The issue appears to be related to data corruption during network transmission rather than a problem with TorizonCore Builder itself. Using the Toradex Easy Installer method should bypass this network-related checksum issue.

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.

Florens · April 13, 2026, 10:51pm

I do not suspect network issues. I have succesfully used torizoncore-builder deploy before with other images (not built from source).

ToradexAI · April 13, 2026, 10:51pm

You’re right to rule out network issues since you’ve successfully deployed other images before. The checksum error specifically with your source-built image suggests an issue with the OSTree repository integrity during the Yocto build process.

Potential Causes for Source-Built Images

The issue is likely related to how the OSTree repository was generated during your Yocto build. Since the error occurs during the OSTree pull operation with a specific content object checksum mismatch, this indicates corruption in the OSTree repository itself.

Alternative Deployment Approach

Instead of using remote deployment, try creating a Toradex Easy Installer image first. According to the TorizonCore Builder documentation, you can use the deploy command to create a local Easy Installer image(1):

torizoncore-builder deploy --output-directory ./output-tezi

This approach bypasses the remote OSTree pull operation that’s causing the checksum error and creates a complete Toradex Easy Installer package that you can flash directly to your device.

Verify OSTree Repository Integrity

You might also want to verify the integrity of your source-built OSTree repository. The unpacking process showed this commit:

Commit checksum: 9ccd1d6a4a1c4c55eba6525d4a2863cdb812f4e5d4c7f927c585e74bfb3b9fa0

The fact that the unpack operation succeeded but the deploy fails suggests the corruption might be in specific content objects that aren’t accessed during unpacking but are needed during deployment.

Rebuild Recommendation

If the Easy Installer approach doesn’t resolve the issue, you may need to rebuild your Torizon image from source, as the OSTree repository appears to have integrity issues that occurred during the Yocto build process.

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.

jeremias.tx · April 14, 2026, 1:37am

Greetings @Florens,

Did you modify the default build at all in Yocto?

Furthermore, does this issue happen consistently if you re-build Torizon OS?

On first impression it seems the OS image you built here has some file corruption. I suppose this could happen during the build somehow, though it’s fairly rare.

Best Regards,
Jeremias

Florens · April 14, 2026, 7:21pm

I can reproduce this without any modifications to the default build, from a fully clean workspace. It seems to hit the exact same hash mismatch. This is the full log for the build I just ran:

build.txt (25.1 KB)

jeremias.tx · April 15, 2026, 12:20am

Strange, your build seems to be creating a “reproducible file corruption” of sorts. It is difficult to say what exactly is happening since you didn’t change anything, and it’s not reproducible on my end as far as I can tell. Without further information, I can only assume it’s somehow unique to your setup. Though I recognize that’s not very helpful.

I suppose just to back up a bit. Why exactly are you building Torizon OS from scratch, but also using TorizonCore Builder? What is your end goal here?

Best Regards,
Jeremias

Florens · April 23, 2026, 11:55am

I have not continued much with testing here, but I could confirm that manually copying the ostree repo to the imx95 and deploying from there works without any issues.

I’m building from scratch, because I need to apply a kernel patch to add jumbo frames support. See iMX95 MTU limit - #3 by Florens. I was only using TorizonCore Builder as a convenience to deploy a bit quicker.

jeremias.tx · April 23, 2026, 8:07pm

How strange. I don’t have any further comments to add since we’re unable to reproduce this behavior on our end. Also, there’s not much information here to investigate. But in any case it sounds like it’s not much of an issue in the end for you, correct?

Best Regards,
Jeremias

bw908 · July 7, 2026, 3:10pm

Just wanted to chime in that I’ve started seeing this too after relocating to a new development machine - I’ve tried clean rebuilds and am still trying to understand the issue/troubleshoot it. It does not seem network related because the issue persists even if trying to transfer the data via ethernet RNDIS (USB gadget) - and it’s always the same object/same checksum that fails.

I will follow up with any findings. My suspicion is SELinux or some other security tool issue causing docker problems - I already know it doesn’t seem to add the trailing :z for volume mounts that is required if SELinux is enabled on the host.

jeremias.tx · July 7, 2026, 7:32pm

Hi @bw908,

If you do happen to find what the root cause is on your new machine do let us know. This thread is the only reports I’ve seen of this issue. Of course we don’t encounter this issue internally in our team, or automated builds. So any information would be helpful.

Best Regards,
Jeremias

bw908 · July 7, 2026, 8:29pm

Thanks Jeremias - can you provide some insights how I can inspect the state of TCB’s internal OSTree repository? if I can identify the object file itself and look at it perhaps we’ll get some clarity on the issue. I did confirm it seems to persist even with SELinux disabled so it’s not solely that which is causing it.

The output is always the same:

Deploying to device (torizon@10.90.8.1)...
Copying Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 75c6707fdef0a153e55d957cf074c41f08e954dbac7fa1e6c9d881fc41c48760 from local repository...
1318 metadata, 10114 content objects imported; 661.9 MB content written
0 metadata, 0 content objects imported; 0 bytes content written
Unpacked OSTree from Toradex Easy Installer image:
  Commit checksum: 75c6707fdef0a153e55d957cf074c41f08e954dbac7fa1e6c9d881fc41c48760
  TorizonCore Version: 7.4.0-devel-20260415182323+build.0-tcbuilder.20260707194435
Pulling OSTree with ref base (checksum 75c6707fdef0a153e55d957cf074c41f08e954dbac7fa1e6c9d881fc41c48760) from local archive repository...
Starting http server to serve OSTree.
OSTree server listening on "localhost:37161".
Starting OSTree pull on the device...
Password: error: Writing content object: Corrupted file object; checksum expected='9cc0a6b36b8b0452f388251eede24b29995da2a755f9a1c03cdcd94c391bfb08' actual='27465cd90f1182de43b7c165fd4ec92588c4dc30fc783de2405b302173afa5c5'
Failed to run command on module: ostree pull tcbuilder:75c6707fdef0a153e55d957cf074c41f08e954dbac7fa1e6c9d881fc41c48760

jeremias.tx · July 7, 2026, 9:21pm

can you provide some insights how I can inspect the state of TCB’s internal OSTree repository?

By default, as TCB works it stores it’s state information into a Docker volume named storage. Using the docker inspect command you can find the file-path location of this volume on your development machine. With that information you can just freely browse the volume and the ostree repository should be located in there.

This volume usually gets reset when you run torizoncore-builder images unpack. So if you want a clean state just unpack your OS image again and then inspect the volume.

Best Regards,
Jeremias

bw908 · July 10, 2026, 1:47pm

OK, this is clearly an SELinux issue.

If I inspect the volume content of the storage archive (particularly, the called out object from inside the container), I get this:

sh-5.1# strings c0a6b36b8b0452f388251eede24b29995da2a755f9a1c03cdcd94c391bfb08.filez  | head
security.selinux
system_u:object_r:container_file_t:s0
...

So SELinux is marking the files in some way that’s incompatible with how TCB passes them around internally between its storage (after reading the archive) and then serving them up. Disabling SELinux entirely (permissive mode seems insufficient, I had to fully disable it) fixed the issue.

TL;DR: TorizonCore builder isn’t compatible with docker on SELinux enabled systems. The issue appeared for me after a distribution upgrade where my distro migrated from AppArmor to SELinux.

jeremias.tx · July 10, 2026, 5:30pm

Thanks for investigating and confirming. I double-checked internally and it seems we did actually document issues with SELinux here: Install TorizonCore Builder | Toradex Developer Center

So I guess it was an already known limitation.

Best Regards,
Jeremias