Update order dependency not respected

Technical Support
,
1

Hello,

we’ve noticed that when updating the base OS and the application package at the same time, the order is not applied correctly.

Installed base OS was Torizon 6.6.0 with custom modifications and application package (docker compose) 1.2.1.
We wanted to update to application package v1.2.3, which requires Torizon OS 6.7.0.

When selecting both updates (application package and base OS) at the same time in the web UI, the update process first installs the new application stack and then fails the entire update because the new docker-compose.yml cannot run on the old base OS.

The application stack has only base OS 6.7.0 listed as compatibility.

Is this a known bug or is there a checkbox which we are missing to apply the updates in the correct order?

Have a nice weekend,
Christoph

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello Christoph,

Based on the context provided, it seems that the issue you’re experiencing is related to the update dependency management system not respecting the required order of updates. Specifically, the application package is being updated before the base OS, which leads to compatibility issues since the application package version 1.2.3 requires Torizon OS 6.7.0.

This appears to be a critical issue, and the context suggests that it might be a flaw in the update process. Unfortunately, the context does not provide information about a specific checkbox or setting that can enforce the correct order of updates. It would be advisable to check the documentation or contact Toradex support to see if there are any updates or settings that address this issue.

If this is a known bug, it should be addressed in future updates, and it would be beneficial to report this to Toradex if it hasn’t been already.

Have a nice weekend,
[Your Name]

Please, also check if these links can help you solve your problem:

Building Container with torizon/debian:3-bookworm failed.

3

Greetings @christoph,

I assume based off what you said with doing an OS and application update at the same time you are trying to make use of what we call “synchronous updates”: Torizon Updates Technical Overview | Toradex Developer Center

As detailed in the link I just shared, what you described shouldn’t occur. The new containers should not be started till after the reboot into the new OS version. As a test I did a synchronous update on my own device to double-check the order of operations.

After doing the update but before the reboot I see the following:

torizon@apalis-imx8-06738453:~$ docker images
REPOSITORY                  TAG          IMAGE ID       CREATED        SIZE
torizon/weston-vivante      3            2a3f78a6e6cf   8 weeks ago    512MB
torizonextras/eros-server   arm64-prod   b60eba05d538   4 months ago   213MB
torizonextras/eros-view     imx8-prod    2822dec61bd2   4 months ago   291MB
torizon@apalis-imx8-06738453:~$ docker ps -a
CONTAINER ID   IMAGE                       COMMAND                  CREATED          STATUS          PORTS                                       NAMES
c465efb12e45   torizonextras/eros-view     "./erosView"             18 minutes ago   Up 18 minutes                                               torizon-eros-view-1
cb67155ed42e   torizonextras/eros-server   "node out/lib/index.…"   18 minutes ago   Up 18 minutes   0.0.0.0:3030->3030/tcp, :::3030->3030/tcp   torizon-eros-server-1

As seen we have the old container still running eros-view & eros-server. The new container image has been pulled weston-vivante, but it’s not running yet, which is expected since the device hasn’t rebooted yet and we are still on the old OS version.

Now after the reboot, we should be in the new OS version. Checking the state of the containers we see:

torizon@apalis-imx8-06738453:~$ docker images
REPOSITORY               TAG       IMAGE ID       CREATED       SIZE
torizon/weston-vivante   3         2a3f78a6e6cf   8 weeks ago   512MB
torizon@apalis-imx8-06738453:~$ docker ps -a
CONTAINER ID   IMAGE                      COMMAND                  CREATED          STATUS          PORTS     NAMES
ed9fbea78608   torizon/weston-vivante:3   "/usr/bin/entry.sh -…"   54 seconds ago   Up 52 seconds             torizon-weston-1

Now the new container is running and the old container images have been cleaned from the system.

That said, there is one possibility I can think of that would result in what you observed where the new containers are started on the old OS version. If the Aktualizr update client is restarted before the reboot happens, then it will think a reboot has occurred and will try to start the new containers.

Normally a reboot is requested during a synchronous update so it can be finished. But if you disabled the automatic reboot mechanism then, Aktualizr will restart after some time. Or, if for some reason it takes a long time for the reboot to happen on your system this could result in a similar thing.

So now I have some questions for you:

  • Did you disable the automatic reboot for updates on your devices?
    • If no, then do you observe your system even reboot at all automatically during the update?
  • Can you share the Aktualizr logs showing the entire update process on your device?

Best Regards,
Jeremias

4

Hi @jeremias.tx

the logfiles on the two devices I’ve seen this are already overwritten. I’ve to setup my own test device again and get back to you during the course of the week.

5

Please do let us know. As I said, the behavior you described should not be happening in normal circumstances. It would be good to know whether this is a possible general bug, or maybe some niche behavior that depends on other variables in your system.

I’ve to setup my own test device again and get back to you during the course of the week.

Just to understand. Are you setting up a test because the issue does not happen reliably all the time? In other words does the issue only occur sometimes on your devices?

Best Regards,
Jeremias

6

I’ve to setup my own test device again and get back to you during the course of the week.

Just to understand. Are you setting up a test because the issue does not happen reliably all the time? In other words does the issue only occur sometimes on your devices?

I’ve observed this behavior on customer devices which I cannot roll back and forth. Hence, I will use my own testing device for these tests.

7

Okay, well I’ll await the result of your tests then.

Other than the logs, it would be good to know whether the issue does occur on your devices 100% of the time or not.

Best Regards,
Jeremias