Only download docker update and apply on next boot

Technical Support
, , ,
1

Dear Toradex Team,

we are using Torizon OTA to update the Docker images on our apalis-imx8 devices. I am looking for a mechanism where the devices only download the update after it has been scheduled, and then apply it when the device is booted the next time.
The reason behind this is that our clients are turning on the device only for a short amount of time, e.g. 2h and then turn it off again. We need to avoid restarting the docker containers while the clients are using it, because this can cause data loss. Therefore, the idea of downloading the update while they are using it and then applying it on next boot.
My first idea was to use the new Consent Mode introduced in Torizon 7.4, but it turns out that it waits with downloading the images until consent is given and then recreates the docker containers immediately after download.
My second idea was to disable the automatic reboot when an OS update is performed and then always schedule a docker update together with an OS update. The idea was that it will wait with applying the new docker images until the OS update is performed, which will happen at next boot. But then I figured out, a few seconds after everything is downloaded and the device did not reboot, aktualizr is restarted which causes the containers to restart as well. I have not managed to prevent systemd from restarting aktualizr yet, but I am working on it.

Can you give me any advice on how to achieve this separation of download and applying the update? Am I on the right track or is there a better way?

Thank you and best regards,

Thorbjörn

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.

I’d be glad to help! Could you let me know which OS and version you are using?

To provide you with the most accurate guidance for implementing your download-and-apply-later update mechanism, I’ll need to understand your specific setup. Please run the tdx-info command on your device to get detailed information about your hardware and software configuration.

You can find more details about this command at: tdx-info documentation

Once I have this information, I can guide you through the available configuration options for Aktualizr and help you achieve the separation between downloading and applying updates that you’re looking for.

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.

3

Hi @ToradexAI

This is the OS I am using:
cat /etc/os-release
ID=torizon
NAME=“Torizon OS”
VERSION=“7.5.0+build.30 (scarthgap)”
VERSION_ID=7.5.0-build.30
VERSION_CODENAME=“scarthgap”
PRETTY_NAME=“Torizon OS 7.5.0+build.30 (scarthgap)”
CPE_NAME=“cpe:/o:openembedded:torizon:7.5.0+build.30”
BUILD_ID=“30”
ANSI_COLOR=“1;34”
VARIANT=“Docker”

And this is the output of txd-info
Software summary

Bootloader: U-Boot
Kernel version: 6.6.119-7.5.0-ge5c5595adb06 #1-Torizon SMP PREEMPT Mon Jan 5 09:23:13 UTC 2026
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/355a9292db51ac073efe0f4bd0d04594b90533e9a5a643f6338ca91f7086d93a/0
Distro name: NAME=“Torizon OS”
Distro version: VERSION_ID=7.5.0-build.30
Distro variant: VARIANT=“Docker”
Hostname: n11-AP131

Hardware info

HW model: Toradex Apalis iMX8QM V1.1 on Apalis Evaluation Board
Toradex version: 0037 V1.1C
Serial number: 06852193
Processor arch: aarch64

4

Thank you for providing the detailed system information! Based on your Torizon OS 7.5.0 setup on the Apalis iMX8QM, I can help you implement a download-first, apply-later update mechanism.

Understanding the Challenge

Your use case is quite common in industrial applications where devices have limited uptime windows. The challenge is that Aktualizr’s default behavior applies Docker container updates immediately after download, which would disrupt your clients’ operations (1).

Recommended Approach: Synchronous Updates

The most effective solution for your requirements is to configure synchronous updates by combining OS and Docker container updates. This approach leverages Torizon’s built-in capability to defer container application until the next boot (2).

How Synchronous Updates Work

When both OS and container updates are scheduled together, Torizon OS will (1):

  1. Download both the OS image and Docker images during device operation
  2. Stage the OS update for next boot
  3. Keep the new Docker images downloaded but not applied
  4. Apply both updates simultaneously on the next reboot

Configuration Steps

  1. Disable Automatic Reboot for OS Updates (1):
sudo systemctl stop ostree-pending-reboot.path
sudo systemctl disable ostree-pending-reboot.path
  1. Configure Custom Reboot Command (optional) (1):
    Create /etc/sota/conf.d/21-custom-reboot.toml:
sudo mkdir -p /etc/sota/conf.d/
cat <<EOF | sudo tee /etc/sota/conf.d/21-custom-reboot.toml
[bootloader]
reboot_command = "/path/to/your/custom-reboot-script"
EOF
  1. Restart Aktualizr (3):
sudo systemctl restart aktualizr

Update Scheduling Strategy

When scheduling updates through Torizon Cloud:

  • Always bundle OS updates with Docker container updates
  • This ensures the system treats it as a synchronous update
  • The Docker containers will only be updated after the device reboots into the new OS

Managing the Reboot Timing

Since automatic reboot is disabled, you have full control over when the update is applied:

  • Monitor for pending updates using Aktualizr’s status
  • Schedule the reboot during your maintenance window
  • The device will boot with both the new OS and updated containers

Alternative: Custom Update Orchestration

If you need more granular control, you could also:

  1. Use Aktualizr’s configuration to modify polling intervals (1)
  2. Implement a custom reboot command that checks for your application state
  3. Create a maintenance mode that signals when updates can be applied

This approach gives you the separation you’re looking for: downloads happen during operation, but application is deferred until the controlled reboot timing that works for your clients’ usage patterns.

**

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.

5

Hey @ToradexAI ,
I got it to work, the solution is doing what you suggested and to disable aktualizr from restarting automatically after it is terminated.
To do this, create the file /etc/systemd/system/aktualizr-torizon.service.d/override.conf

[Service]
Restart=on-failure

and reload the config

systemctl daemon-reload

When the next update is installed, it only downloads the docker images and applies them on next boot :slight_smile:

6

Excellent! Thank you for sharing your complete working solution. This is a valuable contribution that combines the configuration approach I suggested with your additional systemd service modification.

Complete Working Solution Summary

Your implementation successfully achieves the download-first, apply-later update mechanism by:

1. Disabling Automatic OS Reboot

As documented in the Aktualizr configuration guide (1):

sudo systemctl stop ostree-pending-reboot.path
sudo systemctl disable ostree-pending-reboot.path

2. Preventing Aktualizr Auto-Restart

Your key addition - modifying the systemd service behavior by creating /etc/systemd/system/aktualizr-torizon.service.d/override.conf:

[Service]
Restart=on-failure

This prevents Aktualizr from automatically restarting after it completes the download, which was causing the immediate container restart you wanted to avoid.

3. Applying Configuration Changes

systemctl daemon-reload

How This Solution Works

With this configuration:

  • Updates are downloaded during device operation without disrupting running containers
  • Aktualizr doesn’t automatically restart after completing the download
  • Container updates are staged and only applied on the next system boot
  • You maintain full control over when the actual update application occurs

This approach perfectly addresses your industrial use case where devices have limited uptime windows and you need to avoid disrupting client operations during their active usage periods.

Your solution demonstrates an effective way to customize Torizon’s update behavior for specialized deployment scenarios while leveraging the built-in OTA capabilities (1).

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.