Build Configuration Options
Configuration variables in meta-updater
Here, we provide reference documentation on how to configure meta-updater. Below are the variables that you can set in your local.conf
to control the finer points of your build process.
Option | Description |
---|---|
|
OSTree branch name. Defaults to |
|
Path to your OSTree repository. Defaults to |
|
OS deployment name on your target device. For more information about deployments and osnames see the OSTree documentation. Defaults to "poky". |
|
Message attached to OSTree commit. Empty by default. |
|
Commit subject used by OSTree. Defaults to |
|
Set this to '1' to update summary of OSTree repository on each commit. '0' by default. |
|
Set this to '1' to include devicetree(s) to boot |
|
Set this to '1' to automatically fetch the last version of the garage tools installed by the aktualizr-native. Otherwise use the fixed version specified in the recipe. |
|
Target name used in the Uptane metadata. Defaults to |
|
Sets the |
|
Use this option to have the metadata expire after a fixed date and time. Specify the time as a UTC instant like in the following example: GARAGE_TARGET_EXPIRES = "2018-01-01T00:01:00Z" More detail is available in the metadata expiry page. |
|
Use this option to have the metadata expire after an elapsed period of time. Specify the number of years, months and days like in the following example: GARAGE_TARGET_EXPIRE_AFTER = "1Y3M5D" More detail is available in the metadata expiry page. |
|
The initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such a proxy. |
|
When set, your ostree commit will be pushed to a remote repo as a bitbake step. This should be the path to a zipped credentials file in the format accepted by garage-push. |
|
When set to '1' (default value), deploys credentials to the built image. Override it in |
|
Which provisioning method to use. Valid options are |
|
Extensions to aktualizr. The only valid options are |
|
A file containing JSON configuration for secondaries. It will be installed into |
|
A custom hardware ID that will be written to the aktualizr config. Defaults to MACHINE if not set. |
|
The base device tree to use with the kernel. Used together with FIT images. You can change it, and the device tree will also be changed after the update. |
|
A whitespace-separated list of used device tree overlays for FIT image. This list is OSTree-updateable as well. |
|
Extra configuration fragments for FIT image. |
|
Controls maximum resource usage of the aktualizr service, when |
|
Sets polling interval for aktualizr to check for updates if aktualizr-polling-interval is included in the image. |
Custom aktualizr versions
You can override the version of aktualizr included in your image. This requires that the version you wish to run is pushed to the aktualizr github repo. You can then use these settings in your local.conf
to simplify the development process:
Option | Effect |
---|---|
|
Build the latest head (by default, using the master branch) of Aktualizr |
|
Build |
|
Build the specified revision of Aktualizr. Note that both of these need to be set. This can be used in conjunction with |
|
Use with |
Overriding target version
Warning: overriding target version is a dangerous operation, make sure you understand this section completely before doing it.
Every time you build an image with SOTA_PACKED_CREDENTIALS
set, a new entry in your Uptane metadata is created and you can see it in the OTA Garage UI if you’re using one. Normally this version will be equal to OSTree hash of your root file system. If you want it to be different though you can override is using one of two methods:
-
Set
GARAGE_TARGET_VERSION
variable in yourlocal.conf
. -
Write a recipe or a bbclass to write the desired version to
${STAGING_DATADIR_NATIVE}/target_version
. An example of such bbclass can be found inclasses/target_version_example.bbclass
.
Please note that [target name, target version] pairs are expected to be unique in the system. If you build a new target with the same target version as a previously built one, the old package will be overwritten on the update server. It can have unpredictable effect on devices that have this version installed, and it is not guaranteed that information will be reported correctly for such devices or that you will be able to update them (we’re doing our best though). The easiest way to avoid problems is to make sure that your overriding version is as unique as an OSTree commit hash.