Skip to main content

EmberRTOS (Standard)

EmberRTOS (Standard) is the general-purpose variant of EmberRTOS, Fireball Industries' own Linux distribution for the EmberNet edge. It runs a general-purpose kernel and is the right choice for the majority of edge nodes: container hosts, protocol gateways, telemetry collectors, and anything that does not have a hard real-time deadline. For workloads that must hit a deadline, use EmberRTOS RT instead. Everything on this page applies to both.

The immutable foundation​

EmberRTOS is an immutable operating system. The root filesystem is mounted read-only, and the running system cannot be changed in place. This is what keeps a fleet of edge devices identical and predictable: there is no configuration drift, no half-applied update, and no "works on that one box" mystery state.

Changes are made transactionally. Instead of modifying the live system, EmberRTOS creates a new filesystem snapshot, applies the change there, and switches to it on the next reboot. Every update is therefore atomic (all-or-nothing) and reversible.

Updating the system​

Package and system changes go through transactional-update, which prepares a new snapshot without touching the running system:

# Install a package into the next snapshot
sudo transactional-update pkg install <package>

# Apply all available updates into a new snapshot
sudo transactional-update up

# Open a shell in the new snapshot to make several changes at once
sudo transactional-update shell

None of these affect the running system until you reboot into the new snapshot. In normal operation you do not run these by hand. EmberRTOS updates itself automatically (see below).

Automatic updates and reboots​

EmberRTOS applies updates in the background on a timer and then reboots into the new snapshot inside a controlled maintenance window:

# View / set the maintenance window and reboot strategy
rebootmgrctl status
rebootmgrctl set-strategy best-effort

The default best-effort strategy uses the configured maintenance window if one is set, and otherwise reboots as soon as the update is staged. This lets a fleet stay current with zero manual intervention while confining disruption to approved times.

Rollback​

Because every change is a snapshot, recovering from a bad update is a rollback, not a repair:

# List snapshots
sudo snapper list

# Roll back to the previous (or a specific) snapshot, then reboot
sudo transactional-update rollback <number>

If a staged update fails to boot, EmberRTOS returns to the last known-good snapshot automatically.

First-boot configuration​

EmberRTOS is provisioned on its first boot from a configuration medium: a disk, USB stick, or config drive whose filesystem is labeled combustion. The system reads a /combustion/script from it and runs that script inside a transactional shell before the node comes up for real.

A minimal first-boot script looks like this:

#!/bin/bash
# combustion: network
# set the hostname, install packages, enable services, apply branding, etc.
echo "emberrtos-node" > /etc/hostname
systemctl enable sshd firewalld chronyd cockpit.socket

The # combustion: network line brings up networking (DHCP by default) so the script can pull packages and register with EmberNet. This is how a stock image becomes a fully branded, enrolled EmberRTOS node on first power-on, with no rip-and-replace and no manual install steps.

What's included​

EmberRTOS ships a deliberately minimal host with the pieces edge operation needs:

  • A container runtime, so EmberNet workloads run as containers on top of the immutable host.
  • A web management console (cockpit.socket) for lights-out administration.
  • A host firewall, enabled by default.
  • Time synchronization, which is critical for correlated telemetry and for certificates.
  • SELinux, enabled in enforcing mode for mandatory access control.

Security posture​

  • Read-only root eliminates a large class of runtime tampering and persistence techniques.
  • SELinux enforces mandatory access control on top of standard Linux permissions.
  • The firewall is on by default with no inbound ports beyond what a node needs; EmberNet's zero-trust networking removes the need for exposed management ports.
  • Every OS change is an auditable, reversible snapshot.

Standard vs. RT: which do I deploy?​

Choose EmberRTOS (Standard) unless the node runs a workload with a hard timing requirement. Choose EmberRTOS RT when the node performs motion control, safety functions, high-rate deterministic I/O, or any control loop that must respond within a bounded worst-case time. Both variants are the same OS with the same operations model; only the kernel differs.

Next steps​