1RPM-OSTREE(1) rpm-ostree RPM-OSTREE(1)
2
6 rpm-ostree - Hybrid image/package system for host operating system
7 updates
8
10 rpm-ostree {COMMAND} [OPTIONS...]
11
13 rpm-ostree is a hybrid image and package system; as the name suggests,
14 it uses OSTree for the image side, and RPM for the package side. It
15 supports composing RPMs server-side into an OSTree commit (like an
16 image), and clients can replicate that bit-for-bit, with fast
17 incremental updates. Additionally, the hybrid nature comes to the fore
18 with client-side package layering and overrides.
19 On an rpm-ostree managed system, the traditional yum (if installed) and
21 rpm tools operate in a read-only state; the RPM database is stored in
22 /usr/share/rpm which is underneath a read-only bind mount.
23 Instead of live package-by-package upgrades, the underlying OSTree
25 layer replicates a complete filesystem tree from a compose server into
26 a new deployment, available on the next reboot. One benefit of this is
27 that there will always be a previous deployment, available for
28 rollback. This also makes it easier to reliably "queue" an update
29 without destabilizing the running system at all. (Currently though
30 there's an experimental livefs command that supports changing the
31 running filesystem).
32 Note in this "pure replication" model, there is no per-client packaging
34 overhead. Dependency resolution, SELinux labeling, all of the scripts
35 etc. were run on the server side and captured in the OSTree commit.
36
38 cancel
39 Cancel a pending transaction. Exits successfully and does nothing
40 if no transaction is running. Note that it is fully safe to cancel
41 transactions such as upgrade in general.
42 db
44 Gives information pertaining to rpm data within the file system
45 trees within the ostree commits. There are three sub-commands:
46 diff to see how the packages are different between the trees in two
48 revs. If no revs are provided, the booted commit is compared to the
49 pending commit. If only a single rev is provided, the booted commit
50 is compared to that rev. The --format=diff option uses - for
51 removed packages, + for added packages, and finally ! for the old
52 version of an updated package, with a following = for the new
53 version.
54 list to see which packages are within the commit(s) (works like yum
56 list). At least one commit must be specified, but more than one or
57 a range will also work.
58 version to see the rpmdb version of the packages within the commit
60 (works like yum version nogroups). At least one commit must be
61 specified, but more than one or a range will also work.
62 deploy
64 Takes version, branch, or commit ID as an argument, and creates a
65 new deployment using it, setting it up as the default for the next
66 boot. Unlike most other commands, this will automatically fetch and
67 traverse the origin history to find the target. By design, this has
68 no effect on your running filesystem tree. You must reboot for any
69 changes to take effect.
70 --unchanged-exit-77 to exit status 77 to indicate that the system
72 is already on the specified commit. This tristate return model is
73 intended to support idempotency-oriented systems automation tools
74 like Ansible.
75 --reboot or -r to initiate a reboot after the upgrade is prepared.
77 --preview download enough metadata to inspect the RPM diff, but do
79 not actually create a new deployment.
80 --cache-only or -C to perform the operation without trying to
82 download the target tree from the remote nor the latest packages.
83 --download-only to only download the target ostree and layered RPMs
85 without actually performing the deployment. This can be used with a
86 subsequent --cache-only invocation to perform the operation
87 completely offline.
88 install
90 Takes one or more packages as arguments. The packages are fetched
91 from the enabled repositories in /etc/yum.repos.d/ and are
92 overlayed on top of a new deployment. It is also possible to
93 specify a local RPM package that resides on the host. Overlayed
94 packages can later be removed with the uninstall command.
95 rpm-ostree remembers these requests even if a later host update
97 includes those packages already: if the packages are subsequently
98 dropped out again, rpm-ostree will go back to layering them.
99 Note that by default, specifying a package that is already in the
101 base layer is an error unless the --allow-inactive option is
102 provided. This can be useful when anticipating the removal of a
103 base package.
104 --reboot or -r to initiate a reboot after the deployment is
106 prepared.
107 --dry-run or -n to exit after printing the transaction rather than
109 downloading the packages and creating a new deployment.
110 --allow-inactive to allow requests for packages that are already in
112 the base layer.
113 --cache-only or -C to perform the operation without trying to
115 download the latest packages.
116 --download-only to only download the target layered RPMs without
118 actually performing the deployment. This can be used with a
119 subsequent --cache-only invocation to perform the operation
120 completely offline.
121 uninstall
123 Takes one or more packages as arguments. The packages are removed
124 from the set of packages that are currently overlayed. The
125 remaining packages in the set (if any) are fetched from the enabled
126 repositories in /etc/yum.repos.d/ and are overlayed on top of a new
127 deployment.
128 --reboot or -r to initiate a reboot after the deployment is
130 prepared.
131 --dry-run or -n to exit after printing the transaction rather than
133 downloading the packages and creating a new deployment.
134 override
136 remove Remove a package from the base tree. Note that this is
137 similar to layering in that the original base is retained.
138 replace Replace a package in the base tree.
140 reset Undo a remove or replace operation.
142 rebase
144 Switch to a different branch (possibly using a new remote), while
145 preserving all of the state that upgrade does, such as /etc
146 changes, any layered RPM packages, etc.
147 The full syntax is rebase REMOTENAME:BRANCHNAME. Alternatively, you
149 can use the --branch or --remote options mentioned below. With the
150 argument syntax, specifying just BRANCHNAME will reuse the same
151 remote. You may also omit one of REMOTENAME or BRANCHNAME (keeping
152 the colon). In the former case, the branch refers to a local
153 branch; in the latter case, the same branch will be used on a
154 different remote.
155 --branch or -b to to pick a branch name.
157 --remote or -m to to pick a remote name.
159 --cache-only or -C to perform the rebase without trying to download
161 the target tree from the remote nor the latest packages.
162 --download-only to only download the target ostree and layered RPMs
164 without actually performing the deployment. This can be used with a
165 subsequent --cache-only invocation to perform the operation
166 completely offline.
167 rollback
169 OSTree manages an ordered list of bootloader entries, called
170 "deployments". The entry at index 0 is the default bootloader
171 entry. Each entry has a separate /etc, but they all share a single
172 /var. You can use the bootloader to choose between entries by
173 pressing Tab to interrupt startup.
174 This command then changes the default bootloader entry. If the
176 current default is booted, then set the default to the previous
177 entry. Otherwise, make the currently booted tree the default.
178 --reboot or -r to initiate a reboot after rollback is prepared.
180 status
182 Gives information pertaining to the current deployment in use.
183 Lists the names and refspecs of all possible deployments in order,
184 such that the first deployment in the list is the default upon
185 boot. The deployment marked with * is the current booted
186 deployment, and marking with 'r' indicates the most recent upgrade
187 (the newest deployment version).
188 upgrade
190 Download the latest version of the current tree, and deploy it,
191 setting it up as the default for the next boot. By design, this has
192 no effect on your running filesystem tree. You must reboot for any
193 changes to take effect.
194 --unchanged-exit-77 to exit status 77 to indicate that the system
196 is already up to date. This tristate return model is intended to
197 support idempotency-oriented systems automation tools like Ansible.
198 --reboot or -r to initiate a reboot after upgrade is prepared.
200 --allow-downgrade to permit deployment of chronologically older
202 trees.
203 --preview to download only /usr/share/rpm in order to do a
205 package-level diff between the two versions.
206 --check to just check if an upgrade is available, without
208 downloading it or performing a package-level diff. Using this flag
209 will force an update of the RPM metadata from the enabled repos in
210 /etc/yum.repos.d/, if there are any layered packages.
211 --cache-only or -C to perform the upgrade without trying to
213 download the latest tree from the remote nor the latest packages.
214 --download-only to only download the target ostree and layered RPMs
216 without actually performing the deployment. This can be used with a
217 subsequent --cache-only invocation to perform the operation
218 completely offline.
219 override
221 Provides subcommands for overriding (modifying) the base OSTree
222 layer. Such modifications should be done with care and are normally
223 not intended to be long-lasting. For example, one might replace a
224 base package with its older version to avoid a regression.
225 Overrides are automatically carried over during new deployments.
226 The subcommands are:
227 remove to remove base packages.
229 replace to replace base packages. Currently, only local RPM
231 replacements are supported: one must directly provide the RPMs to
232 substitute in.
233 reset to reset previous overrides. Currently, the full NEVRA of the
235 target packages must be specified.
236 refresh-md
238 Download the latest rpm repo metadata if necessary and generate the
239 cache.
240 kargs
242 Without options, display current default kernel arguments. Modify
243 arguments using --append, --replace, --delete, or --editor. This
244 will create a new deployment with the modified kernel arguments.
245 Previous deployments are never changed.
246 By default, modifications are applied to the kernel arguments of
248 the default deployment to get the final arguments. Use
249 --deploy-index or --import-proc-cmdline to instead base them off of
250 a specific deployment or the current boot.
251 cleanup
253 Commands such as upgrade create new deployments, which affect the
254 next boot, and take up additional storage space. In some cases, you
255 may want to undo and clean up these operations. This command
256 supports both removing additional deployments such as the "pending"
257 deployment (the next boot) as well as the default rollback
258 deployment. Use -p/--pending to remove the pending deployment, and
259 -r/--rollback to remove the rollback.
260 The -b/--base option does not affect finished deployments, but will
262 clean up any transient allocated space that may result from
263 interrupted operations. If you want to free up disk space safely,
264 use this option first.
265 The -m/--repomd option cleans up cached RPM repodata and any
267 partially downloaded (but not imported) packages.
268 NOTE: the cleanup will not affect any deployments that have been
270 "pinned" via the ostree admin pin operation.
271 reload
273 Some configuration and state data such as /etc/ostree/remotes.d
274 changes may not be reflected until a daemon reload is invoked. Use
275 this command to initiate a reload.
276 usroverlay
278 Mount a writable overlay filesystem on /usr which is active only
279 for the remainder of the system boot. This is intended for
280 development, testing, and debugging. Changes will not persist
281 across upgrades, or rebooting in general.
282 One important goal of this is to support traditional rpm -Uvh
284 /path/to/rpms or equivalent where changes are applied live.
285 However, an intended future feature for rpm-ostree will be a
286 variant of rpm-ostree override which also supports applying changes
287 live, for the cases which one wants persistence as well.
288 This command is equivalent to ostree admin unlock.
290 initramfs
292 By default, the primary use case mode for rpm-ostree is to
293 replicate an initramfs as part of a base layer. However, some use
294 cases require locally regenerating it to add configuration or
295 drivers. Use rpm-ostree initramfs to inspect the current status.
296 Use --enable to turn on client side initramfs regeneration. A new
298 deployment will be generated, and after reboot, further upgrades
299 will continue regenerating. You must reboot for the new initramfs
300 to take effect.
301 To append additional custom arguments to the initramfs program
303 (currently dracut), use --arg. For example, --arg=-I
304 --arg=/etc/someconfigfile.
305 The --disable option will disable regeneration. You must reboot for
307 the change to take effect.
308 ex
310 This command offers access to experimental features; command line
311 stability is not guaranteed. The available subcommands will be
312 listed by invoking rpm-ostree ex. For example, there is rpm-ostree
313 ex livefs which is an experimental interface for applying changes
314 to the booted deployment.
315
317 compose
318 Entrypoint for tree composition; most typically used on servers to
319 prepare trees for replication by client systems. The tree
320 subcommand processes a treefile, installs packages, and commits the
321 result to an OSTree repository. There are also split commands
322 install, postprocess, and commit.
323
325 rpm-ostreed.conf(5) ostree(1), rpm(8)
326rpm-ostree RPM-OSTREE(1)