- Using higher level build tooling
- Background on managing an OSTree repository
- Generating OSTree commits in a container
- Choosing a base config
rpm-ostree compose tree
- More information
rpm-ostree compose tree was intended to be a “high level” tool, but that didn’t work out very well in practice. Today, you should consider it as a low level tool. For example, most people that want to generate OSTree commits also want to generate bootable disk images, and rpm-ostree has nothing to do with that.
One example higher level tool that takes care of both OSTree commit generation and bootable disk images is coreos-assembler; it is strongly oriented towards “CoreOS-like” systems which include rpm-ostree and Ignition.
Before you get started, it’s recommended to read (at least) these two sections of the OSTree manual:
rpm-ostree compose tree runs well in an unprivileged (or “run as root”) podman container. You can also use other container tools, they are just less frequently tested.
You can also directly install
rpm-ostree on a traditional
yum/rpm based virtual (or physical) machine - it won’t affect your host. However, containers are encouraged.
Currently, rpm-ostree is fairly coupled to the Fedora project. We are open to supporting other distributions however.
Example base rpm-ostree “manifest repositories” are:
This program takes as input a manifest file that describes the target system, and commits the result to an OSTree repository.
The input format is a YAML (or JSON) “treefile”.
If you’re doing this multiple times, it’s strongly recommended to create a cache directory:
# rpm-ostree compose tree --unified-core --cachedir=cache --repo=/srv/repo /path/to/manifest.yaml
This will download RPMs from the referenced repos, and commit the result to the OSTree repository, using the ref named by
Once we have that commit, let’s export it:
# ostree --repo=repo pull-local build-repo exampleos/8/x86_64/stable
You can tell client systems to rebase to it by combining
ostree remote add, and
rpm-ostree rebase on the client side.