Automotive Image Builder tool¶
Automotive Image Builder is a tool used to create operating system (OS) images from YAML configuration files called manifests. Each manifest defines what to include in the built image, from core OS components to user-specific applications, drivers, and settings.
The Automotive Image Builder manifests are YAML files that define the content and configuration of the OS image. A manifest file can be as simple as the following minimal manifest example:
name: minimal
content:
rpms: []
# Set a password so that you can log in to the system. Setting a
# password is not necessary to build the minimal image, but you
# cannot log in without configuring a password.
auth:
# "password"
root_password: $6$xoLqEUz0cGGJRx01$H3H/bFm0myJPULNMtbSsOFd/2BnHqHkMD92Sfxd.EKM9hXTWSmELG8cf205l6dktomuTcgKGGtGDgtvHVXSWU.
To review available manifest options and configurations, see Automotive Image Builder manifest format.
Options and mechanics¶
The OS image that you deploy on the target hardware consists of AutoSD packages that you assemble into an OS image by using the AutoSD image build
tool, automotive-image-builder.
The Automotive SIG stores source files in public Git repositories, including all of the CentOS Stream or AutoSD source code, SPEC
files, and patches used to build AutoSD. The RPM Package Manager
references this repository to compile AutoSD RPM packages.
Automotive engineering teams can then build those RPM packages into an OS image by using automotive-image-builder, which composes a build configuration specification called a manifest.
The compose operation takes a YAML-based automotive image manifest and a set of options that affect the compose. The result is a precise build instruction that specifies the exact software, including selected packages and container images, to include in the image.
Automotive Image Builder provides two tools for building images:
aib-dev build- Build a traditional, package-based disk image for development and testing. The output is a disk image file (qcow2, raw, or other format).
aib build- Build a bootc container image for production deployments. The output is an
immutable, atomically updatable container image. You can then convert the
container image to a disk image with
aib to-disk-image.
Building a package-based image with aib-dev¶
Use aib-dev build to build a disk image directly from a manifest:
The output format is determined by the file extension. For example, use
.qcow2 for QEMU or .img for a raw disk image.
Building a bootc image with aib¶
Use aib build to build a bootc container image from a manifest:
Convert the container image to a disk image separately:
Alternatively, produce both a bootc container and a disk image in the same command by adding the disk image path as a second output argument:
$ aib build \
--target <target> \
<path-to-manifest>.aib.yml \
localhost/<my-image>:latest \
<my-image>.qcow2
Once a system is running, you can update directly from the bootc container
using bootc switch and bootc update instead of re-flashing a disk image.
For details on pushing images and managing updates, see
Registry-based distribution and
Registry workflows.
Architecture¶
--arch- The hardware architecture to build for (x86_64 or aarch64). If unspecified, the native architecture is used.
Note
You can compose an image for any architecture, but you can only build for the native architecture.
Distributions¶
--distro- Define the package repositories for the distribution you intend to use. The default is
autosd10-sig. View available distributions with theaib list-distrocommand. Available distributions include:
- autosd or autosd10 – AutoSD 10, based on the nightly AutoSD compose
- autosd10-sig – AutoSD 10 with automotive SIG community packages (default)
- autosd10-latest-sig – AutoSD 10 with the latest cs10 and AutoSD repos, plus automotive SIG community packages
- autosd9 – AutoSD 9, based on the nightly AutoSD compose
- autosd9-sig – AutoSD 9 with automotive SIG community packages
- autosd9-latest-sig – AutoSD 9 with the latest cs9 and AutoSD repos, plus automotive SIG community packages
- cs9 – CentOS Stream 9
- eln – Fedora ELN
- f43 – Fedora 43
To extend list-distro with custom distributions, add an ipp.yml in a directory called /some/dir/distro and pass
--include /some/dir to the argument list.
Targets¶
--target- The physical or virtual deployment target for your image. The default value is
qemu. View the available targets with theaib list-targetscommand. Available targets include:
Virtual and cloud targets
- qemu – General virtualized images (default)
- abootqemu – QEMU with Android boot partition instead of GRUB
- abootqemukvm – QEMU with Android boot and KVM-enabled DTB
- aws – Amazon Web Services
- azure – Microsoft Azure
- acrn – ACRN hypervisor
- pc – Generic PC target
- ebbr – Systems compliant with the EBBR specification
Texas Instruments
- am62sk – TI SK-AM62 Evaluation Board
- am69sk – TI SK-AM69 Evaluation Board
- beagleplay – TI BeaglePlay Board
- j784s4evm – TI J784S4XEVM Evaluation Board
- tda4vm_sk – TI SK-TDA4VM Evaluation Board
Qualcomm
- qdrive3 – Qualcomm QDrive3
- ridesx4 – Qualcomm Snapdragon Ride SX 4.0
- ride4_sa8775p_sx – Ride SX 4.0 SA8775P with SCMI-enabled firmware
- ride4_sa8775p_sx_r3 – Ride SX 4.0 SA8775P Rev 3 with SCMI-enabled firmware
- ride4_sa8650p_sx_r3 – Ride SX 4.0 SA8650P Rev 3
NXP
- s32g_vnp_rdb3 – NXP S32G3 Vehicle Networking Reference Design Board
- imx8qxp_mek – i.MX 8QuadXPlus Multisensory Enablement Kit
- ccimx93dvk – ConnectCore i.MX93 Development Kit
Renesas
- rcar_s4 – Renesas R-Car S4
- rcar_s4_can – Renesas R-Car S4 with CAN bus enablement
Other
- rpi4 – Raspberry Pi 4
Additional resources
- For more information about how to build automotive images, see automotive-image-builder.
- Bootc image building – concept overview of the bootc workflow
- Building bootc images – step-by-step bootc build procedure
- Bootc image layering – customizing bootc images with Containerfile layers
- Registry-based distribution – pushing images and enabling over-the-air updates
Next steps
For more information about using the automotive-image-builder tool with build options and manifests
to provision your hardware, see the flashing guide specific to your target hardware: