Skip to content

Embedding containerized applications in the QM partition

Embedding containerized applications in the QM partition

The AutoSD architecture isolates non-critical (QM) applications from critical applications. This isolation mechanism is the QM software partition. In this architecture, the QM partition is an imageless container that uses a subsection of the host filesystem as its root filesystem. This means that you must place your applications in one of two locations:

  • Copy critical applications to /etc/containers/systemd
  • Copy non-critical applications to /etc/containers/systemd inside the QM partition, which is mounted at /usr/lib/qm/. The resulting path for QM applications is /usr/lib/qm/rootfs/etc/containers/systemd.

To configure the placement of applications in the QM partition, create a new qm stage in your manifest file, and configure QM-specific operations in the QM partition.

All QM-level containerized applications belong in the QM partition inside the qm stage. Create a content section in the the qm stage and define the source URL, tag, and name of the container image.

You can view a complete example manifest for QM container configuration in the demos/container_qm/container_qm.aib.yml file.

Prerequisites

  • Podman
  • automotive-image-builder

  • One or more container images available from a local or remote registry.

    Note

    Installing container images from local storage is appropriate only for development and experimental purposes.

Procedure

  1. Include the qm stage in your manifest to initialize the QM partition. Add content and container_images sections to the qm stage so that you can define the container images that you want to install:

    YAML title="Automotive Image Builder manifest (container_images)" --8<-- "demos/container_qm/container_qm.aib.yml:19:31"

    Note

    To install a container image from local storage, set the containers-transport: containers-storage parameter.

  2. Optional. If you have container configuration files that you want to copy to the image, use the add_files section within the content section. For example, copy the example radio.container and engine.container files to the image:

    YAML title="Automotive Image Builder manifest (add_files)" --8<-- "demos/quadlet_radio_engine/quadlet_radio_engine.aib.yml:6:6" --8<-- "demos/quadlet_radio_engine/quadlet_radio_engine.aib.yml:25:29"

    Note

    The source_path: option resolves a relative path. In this example, the container configuration files are in the ../demos directory.

Boot-time container verification

The auto-boot-check service can validate the QM container configuration on every boot. When container_checksum is set in the qm section of your manifest, the service computes a SHA256 hash of the QM container's canonicalized OCI runtime configuration and compares it against the expected value. A mismatch indicates that the container configuration has been altered.

For the default QM container, AIB includes pre-computed checksums for each supported QM RPM version and architecture. You only need to set container_checksum manually when you customize the QM container configuration.

To obtain the checksum for a customized QM container:

  1. Build and boot an image without container_checksum set.

  2. On the running system, run:

    console $ auto-boot-check-tool container-checksum qm

  3. Copy the hex digest from the output into your manifest. Use only the raw hex string without a sha256: prefix:

    yaml title="Example container_checksum configuration" qm: container_checksum: "<hex-digest>" # raw hex only, no sha256: prefix content: container_images: - source: registry.example.com/my-app tag: latest name: localhost/my-app

  4. Rebuild the image with container_checksum set.

Note

The checksum is derived from the OCI runtime configuration, not from the container image digest. The runtime configuration only exists after the QM container has been created on a running system.

For more information about the boot-time verification service, see the auto-boot-check source repository.

Next steps

Now that you have included your containerized application in your Automotive Image Builder manifest, you can build your AutoSD image. For more information, see Building an image from a custom manifest.