table of contents
RPM-OSTREE(1) | rpm-ostree | RPM-OSTREE(1) |
NAME¶
rpm-ostree - Hybrid image/package system for host operating system updates
SYNOPSIS¶
rpm-ostree {COMMAND} [OPTIONS...]
DESCRIPTION¶
rpm-ostree is a hybrid image and package system; as the name suggests, it uses OSTree for the image side, and RPM for the package side. It supports composing RPMs server-side into an OSTree commit (like an image), and clients can replicate that bit-for-bit, with fast incremental updates. Additionally, the hybrid nature comes to the fore with client-side package layering and overrides.
On an rpm-ostree managed system, the traditional yum (if installed) and rpm tools operate in a read-only state; the RPM database is stored in /usr/share/rpm which is underneath a read-only bind mount.
Instead of live package-by-package upgrades, the underlying OSTree layer replicates a complete filesystem tree from a compose server into a new deployment, available on the next reboot. One benefit of this is that there will always be a previous deployment, available for rollback. This also makes it easier to reliably "queue" an update without destabilizing the running system at all. (Currently though there's an experimental livefs command that supports changing the running filesystem).
Note in this "pure replication" model, there is no per-client packaging overhead. Dependency resolution, SELinux labeling, all of the scripts etc. were run on the server side and captured in the OSTree commit.
CLIENT SIDE COMMANDS¶
cancel
db
diff to see how the packages are different between the trees in two revs. If no revs are provided, the booted commit is compared to the pending commit. If only a single rev is provided, the booted commit is compared to that rev. The --format=diff option uses - for removed packages, + for added packages, and finally ! for the old version of an updated package, with a following = for the new version.
list to see which packages are within the commit(s) (works like yum list). At least one commit must be specified, but more than one or a range will also work.
version to see the rpmdb version of the packages within the commit (works like yum version nogroups). At least one commit must be specified, but more than one or a range will also work.
deploy
This will also queue an update for any layered packages.
--unchanged-exit-77 to exit status 77 to indicate that the system is already on the specified commit. This tristate return model is intended to support idempotency-oriented systems automation tools like Ansible.
--reboot or -r to initiate a reboot after the upgrade is prepared.
--preview download enough metadata to inspect the RPM diff, but do not actually create a new deployment.
--cache-only or -C to perform the operation without trying to download the target tree from the remote nor the latest packages.
--download-only to only download the target ostree and layered RPMs without actually performing the deployment. This can be used with a subsequent --cache-only invocation to perform the operation completely offline.
install
If this is the first time a machine-local change is made, note that this will change rpm-ostree to operate in full hybrid mode. Concretely, rpm-ostree will also start fetching all enabled rpm-md (yum) repositories and use those for package updates every time rpm-ostree upgrade is invoked, as well as during other operations such as rebase.
rpm-ostree remembers these requests even if a later host update includes those packages already: if the packages are subsequently dropped out again, rpm-ostree will go back to layering them.
Note that by default, specifying a package that is already in the base layer is an error unless the --allow-inactive option is provided. This can be useful when anticipating the removal of a base package.
--idempotent to do nothing if a package request is already present instead of erroring out.
--reboot or -r to initiate a reboot after the deployment is prepared.
--dry-run or -n to exit after printing the transaction rather than downloading the packages and creating a new deployment.
--allow-inactive to allow requests for packages that are already in the base layer.
--cache-only or -C to perform the operation without trying to download the latest packages.
--download-only to only download the target layered RPMs without actually performing the deployment. This can be used with a subsequent --cache-only invocation to perform the operation completely offline.
--apply-live will perform a subsequent apply-live operation to apply changes to the booted deployment.
uninstall
--reboot or -r to initiate a reboot after the deployment is prepared.
--dry-run or -n to exit after printing the transaction rather than downloading the packages and creating a new deployment.
rebase
The full syntax is rebase REMOTENAME:BRANCHNAME. Alternatively, you can use the --branch or --remote options mentioned below. With the argument syntax, specifying just BRANCHNAME will reuse the same remote. You may also omit one of REMOTENAME or BRANCHNAME (keeping the colon). In the former case, the branch refers to a local branch; in the latter case, the same branch will be used on a different remote.
This will also queue an update for any layered packages.
--branch or -b to pick a branch name.
--remote or -m to pick a remote name.
--cache-only or -C to perform the rebase without trying to download the target tree from the remote nor the latest packages.
--download-only to only download the target ostree and layered RPMs without actually performing the deployment. This can be used with a subsequent --cache-only invocation to perform the operation completely offline.
rollback
This command then changes the default bootloader entry. If the current default is booted, then set the default to the previous entry. Otherwise, make the currently booted tree the default.
--reboot or -r to initiate a reboot after rollback is prepared.
status
upgrade
--unchanged-exit-77 to exit status 77 to indicate that the system is already up to date. This tristate return model is intended to support idempotency-oriented systems automation tools like Ansible.
--reboot or -r to initiate a reboot after upgrade is prepared.
--allow-downgrade to permit deployment of chronologically older trees.
--preview to download only /usr/share/rpm in order to do a package-level diff between the two versions.
--check to just check if an upgrade is available, without downloading it or performing a package-level diff. Using this flag will force an update of the RPM metadata from the enabled repos in /etc/yum.repos.d/, if there are any layered packages.
--cache-only or -C to perform the upgrade without trying to download the latest tree from the remote nor the latest packages.
--download-only to only download the target ostree and layered RPMs without actually performing the deployment. This can be used with a subsequent --cache-only invocation to perform the operation completely offline.
override
remove to remove base packages.
replace to replace base packages. Requires explicitly specifying a set of RPMs to install via HTTP or local file paths. On Fedora systems, it is also supported to pull from the Fedora Koji/Bodhi systems. For example, rpm-ostree override replace https://objstore.int.example.com/hotfixes/kernel.rpm, rpm-ostree override replace ./podman.rpm, rpm-ostree override replace https://bodhi.fedoraproject.org/updates/FEDORA-2020-XXXXXXX or rpm-ostree override replace https://koji.fedoraproject.org/koji/buildinfo?buildID=XXXXXXX
reset to reset previous overrides. Currently, the full NEVRA of the target packages must be specified.
refresh-md
kargs
--editor to use an editor to modify the kernel arguments.
--append to append a kernel argument. For example, --append=panic=1.
--append-if-missing to append a kernel argument if it is not present.
--delete to delete a kernel argument. For example, --delete=panic=1.
--delete-if-present to delete a kernel argument if it is already present. For example, --delete-if-present=panic=1.
--replace to replace an existing kernel argument, it allows you to pass a KEY=VALUE. Also, it supports "KEY=VALUE=NEWVALUE" to replace the value of an argumnet only if one value exist for that argument. For example, --replace=panic=1. or --replace=panic=1=0.
--unchanged-exit-77 to exit status 77 to indicate that the kernel arguments have not changed.
By default, modifications are applied to the kernel arguments of the default deployment to get the final arguments. Use --deploy-index or --import-proc-cmdline to instead base them off of a specific deployment or the current boot.
cleanup
The -b/--base option does not affect finished deployments, but will clean up any transient allocated space that may result from interrupted operations. If you want to free up disk space safely, use this option first.
The -m/--repomd option cleans up cached RPM repodata and any partially downloaded (but not imported) packages.
NOTE: the cleanup will not affect any deployments that have been "pinned" via the ostree admin pin operation.
reload
usroverlay
One important goal of this is to support traditional rpm -Uvh /path/to/rpms or equivalent where changes are applied live. However, an intended future feature for rpm-ostree will be a variant of rpm-ostree override which also supports applying changes live, for the cases which one wants persistence as well.
This command is equivalent to ostree admin unlock.
initramfs
Use --enable to turn on client side initramfs regeneration. A new deployment will be generated, and after reboot, further upgrades will continue regenerating. You must reboot for the new initramfs to take effect.
To append additional custom arguments to the initramfs program (currently dracut), use --arg. For example, --arg=-I --arg=/etc/someconfigfile.
The --disable option will disable regeneration. You must reboot for the change to take effect.
ex
ex apply-live
Given a target OSTree commit (defaults to the pending deployment), create a transient overlayfs filesystem for /usr, and synchronize the changes to the booted filesystem tree. By default, to ensure safety, only package additions are allowed.
--reset to reset the filesystem tree to the booted commit.
--target may be used to target an arbitrary OSTree commit. This is an advanced feature, exposed mainly for testing.
--allow-replacement enables live updates and removals for existing packages.
Example 1. Install postgresql live
$ rpm-ostree install postgresql-server $ rpm-ostree ex apply-live $ systemctl start postgresql # Some setup required
Currently, this just synchronizes the filesystem; no systemd units are restarted for example.
A major implicit benefit of the overlayfs approach is that if something goes wrong in the middle of a apply-live operation, a system reboot will implicitly remove the overlay, restoring the system to the pristine deployment state.
ex initramfs-etc
Add configuration (/etc) files into the initramfs without regenerating the entire initramfs. This is useful to be able to configure services backing the root block device as well as early-boot services like systemd and journald.
Use --track to start tracking a specific file. Can be specified multiple times. A new deployment will be generated. Use --untrack or --untrack-all to stop tracking files.
When there are tracked files, any future created deployment (e.g. when doing an upgrade) will ensure that they are synced. You can additionally use --force-sync to simply generate a new deployment with the latest versions of tracked files without upgrading.
SERVER SIDE COMMANDS¶
compose
SEE ALSO¶
rpm-ostree |