Confused about change management in toradex ecosystem

I am confused about all the change management solutions in the toradex ecosystem.
And according to the support forum, I am not alone.

As far as i understand there is yocto, where you have to build the whole system yourself.
There is TorizonCore, where you can have docker containers.
If you choose you can have debian with apt.
And there is OStree for deploying.

Did i miss any?

My goal is to minimize the effort, and keep the system up-to-date with security patches.

With Yocto, i have to monitor all packages, and the kernel for any security fix, and rebuild the whole system.
Docker images do not change at all, i think.
Apt would be fine, unless it uses a SNAPSHOT of the debian system. So it is static as well, no security updates.
OStree is only responsible for updating the prduction filesystems, and not for creating a master image, i think.

So I am stuck.
Is there a solution for my problem?

(My ideal solution would be that you support official debian images. And push the changes to debian upstream. (Or to Armbian, or something like this). But any other solution is good for me, if i do not have to rebuild everything on a security patch.)

Apalis iMX6 Dual 1GB IT
Ixora Carrier Board V1.2A

Hi @jsaak !

I will try to answer your questions as well as explain better Toradex’s offers.

Right now, talking about software (OS included here) we have mainly 2 ways of developing a project based on a Toradex SOM:

  • Directly using our Board Support Package (BSP) that is made available as Yocto layers.

    • Here you have the power to do whatever you need/want and you’ll be responsible for maintaining your own distro. We have the reference images (minimal and multimedia) that you can base on to start your own.
    • About security, the BSP layers are maintained by Toradex and you can read more about it on the Embedded Linux Release Matrix | Toradex Developer Center article and articles listed on its Prerequisites section.
    • To develop your application, you will need to come up with your own development environment and maintain it.
    • About updates, you will need to come up with your own update method/strategy (and also infrastructure) to actually deploy the updates to your on-the-field modules.
  • Using Torizon

    • Here you won’t need to “build everything”:
    • Also, we have the Torizon Over-The-Air Update System that really seems to be what you need to deploy the important security updates when you need.
      • Using this, you will be able to update the OS and/or the containerized application independently. Here is where the OStree approach shows its value.
      • Also, we have fleet management and monitoring (and more interesting features upcoming :slight_smile: )

But also, I need to say that there is no silver bullet. Using either directly the BSP or Torizon, you will be able to integrate 3rd party pieces of software and you will need to keep up with security-related news of all the software that your project uses (being 3rd party or not).

Does it help your understanding?

Let me know if you have more questions :slight_smile:

Best regards,

Thank you for your detailed answer!

It seems that you do not have the solution I am looking for.
Maintaining an operating system is no easy task.
Debian does a really good job of that, among others.

I hoped that you use Debian upstream instead of a snapshot.
If you want to make embedded development easy for the customers, I think you should consider it.
Or you can join Armbian, that looks good as well.

Hi @jsaak !

Although we wrote on Debian Containers for Torizon | Toradex Developer Center section that we use Debian snapshots, this information is outdated. Sorry for that. We will fix it.

Since Debian Bullseye was released (Debian -- Debian “bullseye” Release Information), we stopped using snapshots. You can actually check it by:

  • Running our Debian base container:
docker run --rm -it torizon/debian:2-bullseye
  • And taking a look at /etc/apt/sources.list:
   root@cdba698c8f95:/# cat /etc/apt/sources.list
   # deb http://snapshot.debian.org/archive/debian/20210902T000000Z bullseye main
   deb http://deb.debian.org/debian bullseye main
   # deb http://snapshot.debian.org/archive/debian-security/20210902T000000Z bullseye-security main
   deb http://security.debian.org/debian-security bullseye-security main
   # deb http://snapshot.debian.org/archive/debian/20210902T000000Z bullseye-updates main
   deb http://deb.debian.org/debian bullseye-updates main
   deb https://feeds.toradex.com/debian/snapshots/20210909T072507Z testing main non-free

So, currently, if the usage of Debian snapshots is the only concern, should be good to go.

Let me know if there are another concerns.

Best regards,

I am starting to understand what you did:

You build a Yocto kernel with some userspace applications.
Added apt. And you call it Debian.

So the kernel is built and should be maintained with Yocto. Some userspace too, i am guessing. And the rest is managed by apt, using debian repositories.

There is one thing i do not understand:
If I use your torizon/debian:2-bullseye container. And then I run apt upgrade what state will I be in?
How do you recommend I should keep the system up-to-date?
(If i make a new Dockerfile and put $ apt upgrade there, it will result in different filesystems as the security patches are landing to debian repositories. That is why you used a snapshot I am guessing. But now you do not any more. How it is supposed to work?)

Hi @jsaak !

This is not quite right. See:

  • TorizonCore is not Debian-based. You will have a Debian-based system inside the Torizon Containers.
    • Here your system will have 2 main parts:
      • TorizonCore itself with the drivers and Toradex’s BSP. Here you don’t have apt.
      • Torizon Containers, where your application will run and you will use apt only (hopefully) on the Dockerfile.
  • Our BSP is also not Debian-based. We don’t have apt there.

One thing that you must understand is that a container is a lightweight environment to run your application. This means that your application and the container will be built at the same time and you will have an artifact that will run on the target.

Every time you build your container (which uses apt update/upgrade) it will be up-to-date with the latest Debian feeds and you will have a new container ready to deploy on the target. You can choose when you will do this build/deploy cycle. So, when you detect necessary security updates, you can trigger the process.

Here is an excerpt of the Best practices for writing Dockerfiles | Docker Documentation article that explains how Docker uses the layers it creates during the build process.

Docker builds images automatically by reading the instructions from a Dockerfile – a text file that contains all commands, in order, needed to build a given image. A Dockerfile adheres to a specific format and set of instructions which you can find at Dockerfile reference.

A Docker image consists of read-only layers each of which represents a Dockerfile instruction. The layers are stacked and each one is a delta of the changes from the previous layer. Consider this Dockerfile :

FROM ubuntu:18.04
COPY . /app
RUN make /app
CMD python /app/app.py

Each instruction creates one layer:

  • FROM creates a layer from the ubuntu:18.04 Docker image.
  • COPY adds files from your Docker client’s current directory.
  • RUN builds your application with make.
  • CMD specifies what command to run within the container.

When you run an image and generate a container, you add a new writable layer (the “container layer”) on top of the underlying layers. All changes made to the running container, such as writing new files, modifying existing files, and deleting files, are written to this writable container layer.

Best regards,