SIMATIC IOT2050 Custom Ubuntu Image with Docker and Telegraf

Overview

The SIMATIC IOT2050 is Siemens' industrial IoT gateway built on the TI ARM64 (Sitara) platform. The device ships in two hardware variants — IOT2050 Basic (1 GB RAM, 4 GB eMMC) and IOT2050 Advanced (2 GB RAM, 16/32 GB eMMC) — and is supported by the open-source meta-iot2050 build layer, which produces a Debian-based Ubuntu ARM64 image using the Isar (Image Creation and Assembly) build framework rather than classic Yocto/BitBake packaging.

This reference covers three production-proven strategies for pre-integrating a metrics stack (Telegraf + InfluxDB + Grafana) and a container runtime (Docker) into a redistributable IOT2050 image so the end customer can flash a single USB stick and run the device with no further shell work:

1. Golden Image — install on hardware, capture the on-disk state, re-flash it as the shipping image.
2. Isar Debian Layer — describe every install step in a reproducible recipe using dpkg-prebuilt and IMAGE_INSTALL_append.
3. First-Boot Service — ship a small bootstrap service that fetches a setup script from a known server and runs it once after the first-boot filesystem resize.

Each method is evaluated against reproducibility, build-cycle time, and operator complexity.

Prerequisites

Method 1: Golden Image (fastest path)

The Golden Image approach is appropriate when reproducibility is secondary to time-to-delivery. You treat one already-flashed IOT2050 as the canonical device, freeze its software state, and re-deploy that exact image to every other unit.

Workflow

1. Flash the upstream iot2050-image-example-ubuntu.wic from meta-iot2050 to the IOT2050 Advanced using the Siemens DP image tool or balenaEtcher.
2. Insert the device, expand the rootfs on first boot, and confirm resize2fs ran cleanly:

df -h /
systemctl is-system-running

3. Install Docker and Telegraf directly on the device as outlined in Section 4.
4. Enable and start the services, validate metrics ingestion, then power down cleanly.
5. Pull the eMMC with dd to a remote host (e.g. dd if=/dev/mmcblk0 | ssh user@host "dd of=iot2050-golden-$(date +%F).img").
6. Shrink the image with pishrink or image-shrink.sh, then re-flash onto other units with the Siemens DP Image tool.

Method 2: Isar Debian Layer (reproducible, recommended)

Method 2 produces a deterministic image by declaring the desired software state inside BitBake/Isar recipes. The build runs in a chroot, but the recipes are themselves plain Debian packaging, so you can ship pre-built .deb files that you have already validated on a running IOT2050.

Layer layout

meta-mycustomer/
├── recipes-app/
│   ├── telegraf/
│   │   └── telegraf_1.27.4.bb
│   ├── prebuilt-deb/
│   │   └── my-setup_1.0.0.bb
│   └── docker-ce/
│       └── docker-ce_24.0.bb
├── recipes-core/
│   └── images/
│       └── iot2050-image-customer.bbappend
└── conf/
    └── layer.conf

conf/layer.conf

BBPATH .= ":${LAYERDIR}"
BBFILE_COLLECTIONS += "mycustomer"
BBFILE_PATTERN_mycustomer = "^${LAYERDIR}/"
BBFILE_PRIORITY_mycustomer = "10"
LAYERSERIES_COMPAT_mycustomer = "kirkstone"
LAYERDEPENDS_mycustomer = "iot2050 isar"

recipes-core/images/iot2050-image-customer.bbappend

inherit image

IMAGE_INSTALL += " \
    telegraf \
    docker-ce \
    my-setup \
    prebuilt-deb-example \
"

IMAGE_INSTALL_append = " curl ca-certificates systemd"

The IMAGE_INSTALL variable is the single source of truth for the runtime package set. The jan/ubuntu branch of meta-iot2050 ships a base recipe at recipes-core/images/iot2050-image-example.bb that you append to rather than fork.

Including a prebuilt .deb with dpkg-prebuilt

Use the dpkg-prebuilt class from Isar to wrap an external Debian package without rebuilding it from source. The following recipe mirrors the pattern in the upstream meta-isar example:

# recipes-app/prebuilt-deb/prebuilt-deb-example_1.0.0.bb
# SPDX-License-Identifier: MIT
inherit dpkg-prebuilt

SRC_URI = "https://artifacts.example.com/debs/example-prebuilt_1.0.0-0_all.deb"
SRC_URI[sha256sum] = "REPLACE_WITH_REAL_SHA256"

PROVIDES += "example-prebuilt"
RPROVIDES_${PN} += "example-prebuilt"

Place the recipe in recipes-app/prebuilt-deb/ and add example-prebuilt to IMAGE_INSTALL. Isar will fetch the deb, place it in the image's apt pool, and install it during image assembly. The build is fully reproducible: every package, every hash, every file is declared in the recipe.

Including systemd-enabled .debs

Isar's image assembly uses a chroot environment, not a running systemd --system instance. A .deb postinst that calls systemctl enable foo.service will fail with Failed to connect to bus during the build. Two robust patterns exist:

1. Ship a systemd unit but enable it via a recipe hook. Drop the unit file under /lib/systemd/system/foo.service from the .deb, and add the unit to a startup symlink from an Isar recipe:

inherit dpkg-prebuilt

do_install_append() {
    install -d ${D}/etc/systemd/system/multi-user.target.wants
    ln -sf /lib/systemd/system/foo.service \
           ${D}/etc/systemd/system/multi-user.target.wants/foo.service
}

2. Use an enable-presets file. Isar honors /lib/systemd/system-preset/ and will enable matching units at first boot through the preset mechanism, which is the same code path used by systemctl preset-all.

# In your .deb, ship:
# /lib/systemd/system-preset/90-customer.preset
enable foo.service
enable bar.service

Method 3: First-Boot Service (most flexible)

This method keeps the image lean and pushes configuration to runtime. A small systemd unit, enabled in the base image, runs once on first boot, fetches a setup script from a known URL, and exits. The setup script can install anything you need — including debs that ship their own systemd units.

Drop-in service file (shipped inside the image)

# /lib/systemd/system/iot2050-firstboot.service
[Unit]
Description=IOT2050 First-Boot Provisioning
ConditionPathExists=/var/lib/iot2050-firstboot.lock
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/iot2050-firstboot.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Bootstrap script (also shipped in the image)

#!/bin/sh
# /usr/local/bin/iot2050-firstboot.sh
set -e
LOCK=/var/lib/iot2050-firstboot.lock
URL="https://setup.example.com/iot2050/setup.sh"
curl -fsSL "$URL" -o /tmp/setup.sh
sh /tmp/setup.sh
touch "$LOCK"
systemctl disable iot2050-firstboot.service

Enable the service from the image recipe

# In your b.bbappend or custom image recipe:
SYSTEMD_SERVICE_${PN} += "iot2050-firstboot.service"
SYSTEMD_AUTO_ENABLE_${PN} = "enable"

Telegraf Configuration

Telegraf collects system, Docker, and (optionally) Modbus/OPC UA metrics and pushes them to InfluxDB, Prometheus, MQTT, or any other supported output. Two integration paths are common on the IOT2050.

Path A — Native Telegraf binary

Use the ubuntu/telegraf image only as a reference for the upstream configuration schema. On the IOT2050 itself, install the binary from InfluxData's apt repo or from a deb prebuilt on your build host:

wget -qO- https://repos.influxdata.com/influxdb.key | gpg --dearmor \
    -o /usr/share/keyrings/influxdb.gpg
echo "deb [signed-by=/usr/share/keyrings/influxdb.gpg] \
    https://repos.influxdata.com/debian bullseye stable" \
    > /etc/apt/sources.list.d/influxdb.list
apt update
apt install -y telegraf=1.27.*

Path B — Telegraf inside Docker

For deployments that already run Docker workloads, run Telegraf as a container with the host's /proc, /sys, and Docker socket mounted read-only:

docker run -d --name=telegraf --restart=always \
  -v /:/host:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /sys:/host/sys:ro \
  -v /proc:/host/proc:ro \
  -v $PWD/telegraf.conf:/etc/telegraf/telegraf.conf:ro \
  telegraf:1.27

telegraf.conf skeleton

[agent]
  interval = "10s"
  flush_interval = "10s"
  hostname = "$HOSTNAME"
  omit_hostname = false

[[inputs.cpu]]
  percpu = true
  totalcpu = true

[[inputs.mem]]

[[inputs.disk]]
  mount_points = ["/"]
  ignore_fs = ["tmpfs", "devtmpfs", "overlay"]

[[inputs.diskio]]

[[inputs.net]]

[[inputs.internal]]

[[inputs.system]]

[[inputs.docker]]
  endpoint = "unix:///var/run/docker.sock"
  container_names = []
  source_tag = true

[[inputs.smart]]
  path = "/usr/sbin/smartctl"
  attributes = ["id", "name", "model"]

[[outputs.influxdb]]
  urls = ["http://127.0.0.1:8086"]
  database = "iot2050"
  retention_policy = ""
  timeout = "5s"
  useragent = "telegraf"

Docker Integration on the IOT2050

The IOT2050 Basic (1 GB RAM) is tight for Docker. The Advanced (2 GB) is the recommended target. Use docker-ce from Docker's official apt repo, not the Debian-packaged docker.io package, to avoid the older containerd shipped with Debian 11.

install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg \
    | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=arm64 signed-by=/etc/apt/keyrings/docker.gpg] \
    https://download.docker.com/linux/ubuntu jammy stable" \
    > /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io \
               docker-buildx-plugin docker-compose-plugin

Building the Image

From the Isar build directory (after source setup-environment build-iot2050 and dropping your meta-mycustomer layer into conf/bblayers.conf):

bitbake iot2050-image-customer

Build artefacts land in build-iot2050/tmp/deploy/images/iot2050/:

Verification

1. Write the image to an SD card or directly to eMMC:

bmaptool copy --bmap iot2050-image-customer-iot2050.wic.bmap \
                iot2050-image-customer-iot2050.wic \
                /dev/sdX

2. Boot the IOT2050, log in over the serial console or SSH (default user root, no password — set one immediately).
3. Confirm the resize completed:

df -h /
lsblk

3. Confirm Docker:

docker version
docker run --rm hello-world

4. Confirm Telegraf is emitting metrics to InfluxDB:

systemctl status telegraf
journalctl -u telegraf -n 50
influx -execute 'SHOW MEASUREMENTS' -database iot2050

5. Confirm the first-boot service did not run twice:

ls -l /var/lib/iot2050-firstboot.lock
systemctl is-enabled iot2050-firstboot.service

Troubleshooting Matrix

Reproducibility and Maintenance Trade-offs

A common hybrid pattern: build the Isar image with a minimal set of packages and the first-boot service skeleton, and let the first-boot service install the application-specific debs. This keeps the image artifact small, the build deterministic, and the per-customer logic in a single versioned file on your artifact server.

Operational Notes

• Reserve at least 200 MB of free eMMC after image install — the IOT2050 firmware updater and apt's downloaded-package cache need headroom.
• Disable the apt-daily.timer and apt-daily-upgrade.timer in production images; they will trigger dpkg runs at random intervals and can collide with your services.
• For OTA updates, use swupdate (already pulled in by meta-iot2050) with a signed CPIO image; do not reflash the full .wic in the field.
• Watch the kernel omap_wdt watchdog — if Telegraf or Docker hangs for > 60 s, the IOT2050 will reboot, which is desirable in a brownout scenario but noisy in logs.