Torizon as a layer on Debian?

Technical Support
, , ,
1

I watched a recent webinar and it appeared in one chart that Torizon can now be a layer that can exist on top of Debian, Docker, or Yocto? The diagram seemed confusing as I’ve never seen Debian as a compatible base.

We have a tightly-coupled firmware-to-hardware application for our custom instruments built on a standard Debian 11 (Bullseye) distribution while using the the Toradex Debian kernel source code with customizations (Colibri iMX7 and iMX6).

We provide tar.gz update packages and a custom install script for app updates. Can Torizon integrate with this base Debian environment without requiring us to “containerize” all our firmware?

Prior efforts to containerize our firmware just resulted in several confusing and poorly documented exceptions in the container boundaries which we find uncomfortable since we have no idea what additional security issues these exceptions can expose.

Some basic things like allowing the user to set the system clock and timezone are not even exposed in a container as something that can be done (the last time I tried to use Torizon containers) – but we have a graphical interface in our firmware to allow the end user to set the clock and timezone. Another example would be setting the IP networking parameters.

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!

Thank you for your question about Torizon OS. Torizon OS is designed as a minimal Embedded Linux image that operates on top of Toradex Linux BSPs. It is not intended to be installed as a layer on an existing Debian system.

Torizon OS is specifically architected to:

  1. Utilize container-based application development as its primary approach.
  2. Exclude software package management in the base system.
  3. Offer a read-only root filesystem to enhance security and prevent system file corruption.

Given your use case with a custom Debian 11 system, Torizon OS would not integrate directly with your existing setup, as it is designed to function as a complete operating system rather than an additional layer. The containerization approach is a fundamental aspect of Torizon’s architecture.

For system configurations such as clock, timezone, and networking, these can be managed from within containers, though they require specific configurations and permissions. Network management, for instance, can be handled by running Network Manager inside a container with the appropriate access.

If you need more detailed information about any specific aspect of Torizon OS, feel free to ask!

Best regards,
Toradex AI Assistant

3

What is Toradex Slim Debian then?

“Toradex provides a set of lightweight, Debian-based Docker container images for Torizon, derived from the Debian Slim Image variant of the current Debian stable release.”

We would just need the “console” container with access to system features such as starting daemons at boot time, setting the clock/timezone, setting IP params, and accessing all system devices including our custom display interface/framebuffer, gpio, and spi-dev.

Then we’d need to install various packages such as the gcc/g++ compiler and dev packages such as:

bc
bison
build-essential
ca-certificates
flex
git
libcairo2-dev
libfl-dev
libfreetype-dev
libjansson-dev
libts-dev
nano
neofetch
netbase
wget
curl
lighttpd
netcat-traditional
python-is-python2
sudo

Presently we just use Visual Code Remote SSH from our PC to develop, compile, and debug on the device itself. Would that development model work in a Torizon container?

4

Greetings @mmccullotn,

Let me try to clarify and clear up what I can here.

I watched a recent webinar and it appeared in one chart that Torizon can now be a layer that can exist on top of Debian, Docker, or Yocto? The diagram seemed confusing as I’ve never seen Debian as a compatible base.

First of all, I’m not sure what diagram you’re referring to here. Would be helpful if you could clarify this so we’re on the same page.

Next it’s important to make sure we’re talking about the same thing when we say “Torizon”.

  • There’s Torizon OS, the full Yocto-built OS image that we distribute.
  • There’s Torizon Cloud our cloud update solution.

Based on the context of your post, it sounds like you’re talking more about running integrating the cloud solution on your devices, correct?

Now what the Webinar might have been referring to regarding Debian compatibility is this: GitHub - torizon/torizon-plugin-installer: Installation script for installing the Torizon software stack on apt-based distributions.

In short, this is a install script that can be run on apt-based systems. The script will install the client-side essentials for the device to interact with Torizon Cloud. Keep in mind this doesn’t fully replicate what we have on Torizon OS. It installs the update client and container support, but it doesn’t add OSTree since this isn’t supported in Debian.

That said, you don’t sound very keen on the container aspect with regards to updating your application. However, the use of containers is not strictly required when using Torizon. We have a Torizon OS Yocto Reference Minimal Image: Torizon OS Yocto Reference Minimal Image Technical Overview | Toradex Developer Center

This is basically Torizon OS but without the container aspects. This means of course you’re building and adding your application onto the host OS as is done traditionally. Though you’re not using Yocto correct? As you have a custom Debian build.

On that note if you use the install script to get the update client on your Debian system you could use what we call Subsystem updates: Subsystem Updates Overview | Toradex Developer Center

This let’s you define your own update logic for whatever generic update you want to perform. So in theory you could create an update script that handles your tar.gz based update packages. This way you don’t have to deliver your applications via container.

Some basic things like allowing the user to set the system clock and timezone are not even exposed in a container as something that can be done

Just to touch on this point, it should be possible to work with the host system’s time from a container as seen in the following other threads:

Let me know if this helped, I don’t want to dump too much info at once here.

Best Regards,
Jeremias

5

Hi @mmccullotn,

Just wanted to check in, and see if you’re still working on this or had further questions.

Best Regards,
Jeremias