Skip to content

Image-based operating systems

Image-based operating systems

An image-based operating system is built and distributed as a complete, read-only filesystem image rather than assembled piece by piece from individual packages on each target machine. AutoSD uses this model to deliver a predictable, tamperproof, and atomically updatable platform for automotive workloads.

How image-based systems differ from package-based systems

Traditional RHEL-like distributions such as CentOS Stream or Fedora Workstation follow a package-based model. A package manager (dnf) installs, upgrades, and removes individual pre-built binaries (RPM packages) directly on the running system. Each machine can drift into a unique state depending on which packages were installed, when they were updated, and what configuration changes were applied.

An image-based system takes a different approach:

Characteristic Package-based Image-based
Unit of deployment Individual RPM packages Complete filesystem image
System identity Defined by installed package set; can vary per machine Defined by the image; every machine running the same image is identical
Mutability Root filesystem is writable; any file can be changed at runtime Core OS (/usr) is read-only; only designated directories (/var, /tmp) are writable and some are writable but non-persistant (/etc in AutoSD)
Update mechanism Package manager resolves dependencies and modifies files in place; an unexpected reboot during an update can leave the system in a partially updated, undefined state Entire image is downloaded and staged atomically next to the running system without affecting it; an interrupted update leaves the current system intact. The system reboots into the new version only when staging is complete
Rollback Difficult; requires tracking every changed file Built in; the previous image remains available for reboot
Reproducibility Harder to guarantee; depends on repository state at install time High; the same image produces the same system every time

For automotive and embedded use cases, the image-based model provides stronger guarantees around consistency, reliability, and security.

How AutoSD compares to traditional automotive and embedded systems

Conventional automotive and embedded platforms typically use a real-time operating system (RTOS) or a purpose-built Board Support Package (BSP) provided by a silicon vendor. These systems differ significantly from AutoSD's approach:

Characteristic Traditional automotive / embedded AutoSD (RHEL-like image-based)
OS base Vendor-specific RTOS or Yocto/OpenEmbedded BSP CentOS-based Linux with kernel-automotive
Build system Toolchain rebuilding the whole image from sources (e.g. Yocto BitBake or buildroot) Container-native build with Automotive Image Builder (aib) leveraging pre-built binaries (RPMs)
Update mechanism Partition-based A/B with raw block writes, or full reflash OSTree-based A/B with content-addressed deduplication
Package ecosystem Minimal; vendor-curated libraries, few upstream packages Full RPM ecosystem; thousands of packages from CentOS and Fedora communities
Application model Statically linked binaries or vendor middleware (AUTOSAR, adaptive AUTOSAR) Statically linked binaries or middleware, as well as containerized applications managed by Podman and systemd
Hardware abstraction Tight coupling to specific SoC and BSP Upstream kernel drivers with standardized hardware enablement
Developer tooling Proprietary IDEs and SDKs tied to the BSP vendor Standard Linux tools (podman, systemd, dnf, gdb)
Update granularity Entire partition or firmware blob File-level deltas; only changed content is downloaded
Key advantages of the AutoSD approach
  • No cross-compilation required: AutoSD images are built natively inside containers using aib, eliminating the complexity of cross-toolchains and sysroot management.
  • Standard package management at build time: Image contents are defined declaratively in a manifest and assembled from RPM packages, giving access to the full CentOS and Fedora package ecosystem rather than a vendor-curated subset.
  • Container-native lifecycle: Applications ship as OCI containers and can be updated independently of the OS.
  • Efficient over-the-air updates: OSTree's content-addressed storage means updates transmit only the changed files, not an entire partition image. This reduces bandwidth consumption compared to partition-based A/B schemes.
  • Consistent developer experience: Developers work with familiar Linux tools and workflows rather than learning vendor-specific toolchains for each hardware target.
OSTree: the foundation of image-based AutoSD

OSTree (also known as libostree) is the technology that makes AutoSD an image-based operating system. OSTree works like a version control system for filesystem trees. Each version of the operating system is stored as a commit in a content-addressed object store, similar to how Git stores source code history.

How OSTree manages the filesystem

When an AutoSD system boots, OSTree assembles the root filesystem from a specific commit in its local repository:

  • Content-addressed storage: Every file is identified by its checksum. Identical files across different commits are stored only once, saving disk space.
  • Immutable /usr: The core operating system lives under /usr and is mounted read-only. System binaries, libraries, and default configuration cannot be modified at runtime.
  • Writable state directories: /var holds persistent runtime data that survives updates and reboots. /etc is writable at runtime but, in AutoSD, is regenerated from the image on each boot; persistent configuration changes must be managed through the image build process or applied via mechanisms that run at boot time.
  • Atomic updates: A new OS version is written alongside the current one. The system switches to the new version on reboot. If the update fails, the previous version remains intact and bootable.
Software-based A/B deployments

OSTree maintains multiple deployments simultaneously. AutoSD uses this capability for an A/B update model:

  1. The running system uses deployment A.
  2. An update writes a new deployment B to disk alongside A.
  3. The system reboots into deployment B.
  4. If deployment B fails health checks, the system can roll back to deployment A without downloading anything.

Because deployments share the same content-addressed object store, storing two or more versions uses only as much additional disk space as the files that actually changed between versions. This filesystem-based A/B model is more space-efficient than partition-based A/B schemes that duplicate entire partitions.

bootc: container-native OS management

bootc is the layer that sits on top of OSTree in AutoSD 10. It brings container workflows to operating system management. With bootc, the OS image is packaged as a standard OCI (Open Container Initiative) container image. This means you can build, store, and distribute operating system images using the same container registries and tooling that you use for application containers.

How bootc works with OSTree

bootc does not replace OSTree. Instead, it uses OSTree internally while providing a container-native interface:

  1. Build: Automotive Image Builder produces a bootc container image that packages the full OS (kernel, packages, configuration) into an OCI container.
  2. Distribute: Push the container image to a standard container registry (for example, Quay.io or a private registry).
  3. Deploy: Flash the container image to a device as a disk image, or pull it onto a running system.
  4. Update: On a running system, bootc update pulls the latest version of the container image from the registry, extracts it into a new OSTree deployment, and stages a reboot.
  5. Switch: bootc switch changes the OS source to a completely different container image, enabling migration between image variants.
Benefits of the bootc model
  • Familiar tooling: Use podman, skopeo, and container registries to manage OS images alongside application containers.
  • Unified pipeline: Build and test the OS image in CI/CD pipelines using standard container ecosystem tooling, e.g. container registries for storage and distribution, container-focused CI workflow, or container audit mechanisms.
  • Over-the-air updates: Push a new image tag to a registry and devices pull the update automatically, downloading only the changed layers.
  • Separation of concerns: The OS image and application containers have independent lifecycles. You can update the OS without redeploying applications, and vice versa.
How the pieces fit together in AutoSD

The following diagram shows how these technologies relate in an AutoSD system:

Automotive Image Builder (aib)
        |
        | produces
        v
OCI container image (bootc image)
        |
        |--- push to ---> Container registry (distribution + OTA updates)
        |
        | convert (aib to-disk-image)
        v
Disk image (raw / qcow2)
        |
        | flash to device
        v
Running AutoSD system
        |
        |--- bootc update ---> pulls new image from registry
        |--- OSTree ----------> manages deployments, rollback, deduplication
        |--- composefs -------> verifies filesystem integrity (tamperproof)

In this architecture:

  • Automotive Image Builder creates the bootc container image from a declarative manifest.
  • Container registries store and distribute OS images using standard OCI protocols.
  • bootc manages the update lifecycle on running systems.
  • OSTree handles the underlying filesystem versioning, atomic deployment, and deduplication.
  • composefs provides cryptographic verification of the filesystem to ensure tamperproof operation.
Next steps