10. Reference

10.1. System Configuration File

A configuration file located in /etc/rauc/system.conf describes the number and type of available slots. It is used to validate storage locations for update images. Each board type requires its special configuration.

This file is part of the root file system.

Example configuration:

compatible=FooCorp Super BarBazzer





[system] section

A user-defined compatible string that describes the target hardware as specific enough as required to prevent faulty updating systems with the wrong firmware. It will be matched against the compatible string defined in the update manifest.
The bootloader implementation RAUC should use for its slot switching mechanism. Currently supported values (and bootloaders) are barebox, grub, u-boot.
Prefix of the path where bundles and slots will be mounted. Can be overwritten by the command line option --mount. Defaults to /mnt/rauc/.
Only valid when bootloader is set to grub. Specifies the path under which the GRUB environment can be accessed.
This boolean value controls if a freshly installed slot is automatically marked active with respect to the used bootloader. Its default value is true which means that this slot is going to be started the next time the system boots. If the value of this parameter is false the slot has to be activated manually in order to be booted, see section Manually Switch to a Different Slot.

[keyring] section

The keyring section refers to the trusted keyring used for signature verification.

Path to the keyring file in PEM format. Either absolute or relative to the system.conf file.

[autoinstall] section

The auto-install feature allows to configure a path that will be checked upon RAUC service startup. If there is a bundle placed under this specific path, this bundle will be installed automatically without any further interaction.

This feature is useful for automatically updating the slot RAUC currently runs from, like for asymmetric redundancy setups where the update is always performed from a dedicated (recovery) slot.

The full path of the bundle file to check for. If file at path exists, auto-install will be triggered.

[handlers] section

Handlers allow to customize RAUC by placing scripts in the system that RAUC can call for different purposes. All parameters expect pathnames to the script to be executed. Pathnames are either absolute or relative to the system.conf file location.

RAUC passes a set of environment variables to handler scripts. See details about using handlers in Custom Handlers (Interface).


This handler will be called when RAUC starts up, right after loading the system configuration file. It is used for obtaining further information about the individual system RAUC runs on. The handler script must print the information to standard output in form of key value pairs KEY=value. The following variables are supported:

Serial number of the individual board
This handler will be called right before RAUC starts with the installation. This is after RAUC has verified and mounted the bundle, thus you can access bundle content.
This handler will be called after a successful installation. The bundle is still mounted at this moment, thus you could access data in it if required.


When using a full custom installation (see [handler] section) RAUC will not execute any system handler script.

[slot.<slot-class>.<idx>] section

Each slot is identified by a section starting with slot. followed by the slot class name, and a slot number. The <slot-class> name is used in the update manifest to target the correct set of slots. It must not contain any . (dots) as these are used as hierarchical separator.

The slot’s device path.
The type describing the slot. Currently supported values are raw, nand, ubivol, ubifs, ext4, vfat. See table Slot Type for a more detailed list of these different types.
For bootable slots, the name the bootloader uses to identify it. The real meaning of this depends on the bootloader implementation used.
The parent entry is used to bind additional slots to a bootable root file system slot. This is used together with the bootname to identify the set of currently active slots, so that the inactive one can be selected as the update target. The parent slot is referenced using the form <slot-class>.<idx>.
Marks the slot as existing but not updatable. May be used for sanity checking or informative purpose. A readonly slot cannot be a target slot.
If set to true this will bypass the default hash comparison for this slot and force RAUC to unconditionally update it. The default value is false, which means that updating this slot will be skipped if new image’s hash matches hash of installed one.

10.2. Manifest

A valid manifest file must have the file extension .raucm.

compatible=FooCorp Super BarBazzer



[update] section

A user-defined compatible string that must match the compatible string of the system the bundle should be installed on.
A free version field that can be used to provide and track version information. No checks will be performed on this version by RAUC itself, although a handler can use this information to reject updates.
A free-form description field that can be used to provide human-readable bundle information.
A build id that would typically hold the build date or some build information provided by the bundle creation environment. This can help to determine the date and origin of the built bundle.

[hooks] section

Hook script path name, relative to the bundle content.
List of hooks enabled for this bundle.

[handler] section

Handler script path name, relative to the bundle content. Used to fully replace default update process.
Arguments to pass to the handler script, such as args=--verbose

[image.<slot-class>] section

Name of the image file (relative to bundle content).
sha256 of image file. RAUC determines this value automatically when creating a bundle, thus it is not required to set this by hand.
size of image file. RAUC determines this value automatically when creating a bundle, thus it is not required to set this by hand.
List of per-slot hooks enabled for this image.

10.3. Slot Status File

A slot status file is generated by RAUC after having updated a slot. If the slot is writeable for RAUC (because it contains a writable filesystem), it will place a small file named slot.raucs in its root directory, containing the sha256 of the installed image.


10.4. Command Line Tool

  rauc [OPTION...] <COMMAND>

  -c, --conf=FILENAME               config file
  --cert=PEMFILE                    cert file
  --key=PEMFILE                     key file
  --keyring=PEMFILE                 keyring file
  --intermediate=PEMFILE            intermediate CA file name
  --mount=PATH                      mount prefix
  --override-boot-slot=SLOTNAME     override auto-detection of booted slot
  --handler-args=ARGS               extra handler arguments
  -d, --debug                       enable debug output
  --version                         display version
  -h, --help

List of rauc commands:
  bundle        Create a bundle
  resign        Resign an already signed bundle
  checksum      Update a manifest with checksums (and optionally sign it)
  install       Install a bundle
  info          Show file information
  status        Show status

10.5. Custom Handlers (Interface)

Interaction between RAUC and custom handler shell scripts is done using shell variables.

Path to the system configuration file (default path is /etc/rauc/system.conf)
Bootname of the slot the system is currently booted from
Path to mounted update bundle, e.g. /mnt/rauc/bundle
Provides the path prefix that may be used for RAUC mount points
An iterator list to loop over all existing slots. Each item in the list is an integer referencing one of the slots. To get the slot parameters, you have to resolve the per-slot variables (suffixed with <N> placeholder for the respective slot number).
An iterator list similar to RAUC_SLOTS but only containing slots that were selected as target slots by the RAUC target slot selection algorithm. You may use this list for safely installing images into these slots.
The name of slot number <N>, e.g. rootfs.0
The class of slot number <N>, e.g. rootfs
The device path of slot number <N>, e.g. /dev/sda1
The bootloader name of slot number <N>, e.g. system0
The name of slot number <N>, empty if none, otherwise name of parent slot
for i in $RAUC_TARGET_SLOTS; do

10.6. D-Bus API

RAUC provides a D-Bus API that allows other applications to easily communicate with RAUC for installing new firmware.


10.6.1. Methods

Install (IN s source);

10.6.2. Signals

Completed (i result);

10.6.3. Properties

Operation readable s

LastError readable s

Progress readable (isi)

10.6.4. Description

10.6.5. Method Details The Install() Method

Install (IN  s source);

Triggers the installation of a bundle.

IN s source:
Path to bundle to be installed

10.6.6. Signal Details The “Completed” Signal

Completed (i result);

This signal is emitted when an installation completed, either successfully or with an error.

i result:
return code (0 for success)

10.6.7. Property Details The “Operation” Property

Operation  readable   s

Represents the current (global) operation RAUC performs. The “LastError” Property

LastError  readable   s

Holds the last message of the last error that occured. The “Progress” Property

Progress  readable   (isi)

Provides installation progress informations in the form

(percentage, message, nesting depth)

10.7. RAUC’s Basic Update Procedure

Performing an update using the default RAUC mechanism will work as follows:

  1. Startup, read system configuration
  2. Determine slot states
  3. Verify bundle signature (reject if invalid)
  4. Mount bundle (SquashFS)
  5. Parse and verify manifest
  6. Determine target install group
    1. Execute pre install handler (optional)
  7. Verify bundle compatible against system compatible (reject if not matching)
  8. Mark target slots as non-bootable for bootloader
  9. Iterate over each image specified in the manifest
    1. Determine update handler (based on image and slot type)
    2. Try to mount slot and read slot status information
      1. Skip update if new image hash matches hash of installed one
    3. Perform slot update (image copy / mkfs+tar extract / …)
    4. Try to write slot status information
  10. Mark target slots as new primary boot source for the bootloader
    1. Execute post install handler (optional)
  11. Unmount bundle
  12. Terminate successfully if no error occurred