rpm-ostreerpm-ostreeDeveloperJonathanLebonjlebon@redhat.comDeveloperColinWalterswalters@redhat.comrpm-ostree1rpm-ostree
Hybrid image/package system for host operating system updates
rpm-ostreeCOMMANDOPTIONSDescription
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 commandscancel
Cancel a pending transaction. Exits successfully and does
nothing if no transaction is running. Note that it is fully
safe to cancel transactions such as upgrade
in general.
db
Gives information pertaining to rpm data
within the file system trees within the ostree commits.
There are three sub-commands:
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
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
Takes version, branch, or commit ID as an argument, and
creates a new deployment using it, setting it up as the
default for the next boot. Unlike most other commands, this
will automatically fetch and traverse the origin history to
find the target. By design, this has no effect on your
running filesystem tree. You must reboot for any changes to
take effect.
--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.
or -C to
perform the operation without trying to download the target
tree from the remote nor the latest packages.
to only download the target
ostree and layered RPMs without actually performing the
deployment. This can be used with a subsequent
invocation to perform the
operation completely offline.
install
Takes one or more packages as arguments. The packages are
fetched from the enabled repositories in
/etc/yum.repos.d/ and are overlayed on
top of a new deployment. It is also possible to specify a
local RPM package that resides on the host. Overlayed
packages can later be removed with the
uninstall command.
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.
--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.
to allow requests for
packages that are already in the base layer.
or -C to
perform the operation without trying to download the latest
packages.
to only download the target
layered RPMs without actually performing the deployment.
This can be used with a subsequent
invocation to perform the
operation completely offline.
uninstall
Takes one or more packages as arguments. The packages are
removed from the set of packages that are currently
overlayed. The remaining packages in the set (if any) are
fetched from the enabled repositories in
/etc/yum.repos.d/ and are overlayed on
top of a new deployment.
--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.
overrideremove Remove a package from the base
tree. Note that this is similar to layering in that
the original base is retained.
replace Replace a package in the base tree.
reset Undo a remove or
replace operation.
rebase
Switch to a different branch (possibly using a new remote),
while preserving all of the state that upgrade
does, such as /etc changes, any layered RPM
packages, etc.
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.
--branch or -b to
to pick a branch name.
--remote or -m to
to pick a remote name.
or -C to
perform the rebase without trying to download the target
tree from the remote nor the latest packages.
to only download the target
ostree and layered RPMs without actually performing the
deployment. This can be used with a subsequent
invocation to perform the
operation completely offline.
rollback
OSTree manages an ordered list of bootloader entries, called
"deployments". The entry at index 0 is the default
bootloader entry. Each entry has a separate
/etc, but they all share a single
/var. You can use the bootloader to
choose between entries by pressing Tab to interrupt
startup.
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
Gives information pertaining to the current deployment in
use. Lists the names and refspecs of all possible
deployments in order, such that the first deployment in the
list is the default upon boot. The deployment marked with *
is the current booted deployment, and marking with 'r'
indicates the most recent upgrade (the newest deployment
version).
upgrade
Download the latest version of the current tree, and deploy
it, setting it up as the default for the next boot. By
design, this has no effect on your running filesystem tree.
You must reboot for any changes to take effect.
--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.
to download only /usr/share/rpm
in order to do a package-level diff between the two
versions.
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.
or -C to
perform the upgrade without trying to download the latest
tree from the remote nor the latest packages.
to only download the target
ostree and layered RPMs without actually performing the
deployment. This can be used with a subsequent
invocation to perform the
operation completely offline.
override
Provides subcommands for overriding (modifying) the base
OSTree layer. Such modifications should be done with care
and are normally not intended to be long-lasting. For
example, one might replace a base package with its older
version to avoid a regression. Overrides are automatically
carried over during new deployments. The subcommands are:
remove to remove base packages.
replace to replace base packages.
Currently, only local RPM replacements are supported:
one must directly provide the RPMs to substitute in.
reset to reset previous overrides.
Currently, the full NEVRA of the target
packages must be specified.
refresh-md
Download the latest rpm repo metadata if necessary and generate the
cache.
kargs
Without options, display current default kernel arguments. Modify
arguments using ,
, , or
. This will create a new deployment with
the modified kernel arguments. Previous deployments are never
changed.
By default, modifications are applied to the kernel arguments of the
default deployment to get the final arguments. Use
or
to instead base them off of a
specific deployment or the current boot.
cleanup
Commands such as upgrade create new deployments,
which affect the next boot, and take up additional storage space. In
some cases, you may want to undo and clean up these operations. This
command supports both removing additional deployments such as the
"pending" deployment (the next boot) as well as the default rollback
deployment. Use to remove the pending
deployment, and to remove the
rollback.
The 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 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
Some configuration and state data such as
/etc/ostree/remotes.d changes may not be
reflected until a daemon reload is invoked. Use this command to
initiate a reload.
usroverlay
Mount a writable overlay filesystem on /usr which
is active only for the remainder of the system boot. This is
intended for development, testing, and debugging. Changes will not
persist across upgrades, or rebooting in general.
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
By default, the primary use case mode for rpm-ostree is to replicate
an initramfs as part of a base layer. However, some use cases
require locally regenerating it to add configuration or drivers. Use
rpm-ostree initramfs to inspect the current
status.
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
This command offers access to experimental features; command line
stability is not guaranteed. The available subcommands will be listed
by invoking rpm-ostree ex. For example, there is
rpm-ostree ex apply-live which is an experimental
interface for applying changes to the booted deployment.
ex apply-live
Experimental feature; subject to change.
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.
to reset the filesystem tree to the booted commit.
may be used to target an arbitrary OSTree commit. This is an advanced feature, exposed mainly for testing.
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
Experimental feature; subject to change.
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 commandscompose
Entrypoint for tree composition; most typically used on servers to
prepare trees for replication by client systems. The
tree subcommand processes a treefile, installs
packages, and commits the result to an OSTree repository. There are
also split commands install,
postprocess, and commit.
See Alsorpm-ostreed.conf5ostree1,
rpm8