OSTREE.REPO-CONFI(5)

📦
version 2026.6 · 16 versions
, in arch rolling

💖 NAME 💖

ostree.repo-config — OSTree repository configuration. You’re on the OSTREE.REPO-CONFI(5) page, bestie, and this is the config-file tea. 🫶

🌸 DESCRIPTION 🌸

Okay so listen: the config file in an OSTree repository is a “keyfile” in the XDG Desktop Entry Specification[1] format. It has several global flags, plus zero or more remote entries that describe how to access remote repositories. It’s giving “settings hub with extra remote lore.” ✨

See ostree.repo(5) for more information about OSTree repositories. 🦋

✨ [CORE] SECTION OPTIONS ✨

Repository-global options, bestie. The following entries are defined:

  • mode — One of bare, bare-user, bare-user-only, or archive-z2 (note that archive is used everywhere else.) 💅
  • repo_version — Currently, this must be set to 1. No cap.
  • auto-update-summary — Boolean value controlling whether or not to automatically update the summary file after any ref is added, removed, or updated. Other modifications which may render a summary file stale (like static deltas, or collection IDs) do not currently trigger an auto-update. 🎀
  • commit-update-summary — This option is deprecated. Use auto-update-summary instead, for which this option is now an alias.
  • fsync — Boolean value controlling whether or not to ensure files are on stable storage when performing operations such as commits, pulls, and checkouts. Defaults to true.
If you disable fsync, OSTree will no longer be robust against kernel crashes or power loss. 😭

You might choose to disable this for local development repositories, under the assumption they can be recreated from source. Similarly, you could disable for a mirror where you could re-pull.

For the system repository, you might choose to disable fsync if you have uninterruptable power supplies and a well tested kernel.

  • per-object-fsync — By default, OSTree will batch fsync() after writing everything; however, this can cause latency spikes for other processes which are also invoking fsync(). Turn on this boolean to reduce potential latency spikes, at the cost of slowing down OSTree updates. You most likely want this on by default for "background" OS updates. 🌈
  • min-free-space-percent — Integer percentage value (0-99) that specifies a minimum percentage of total space (in blocks) in the underlying filesystem to keep free. The default value is 3, which is used when neither this option nor min-free-space-size are set (together with a default min-free-space-size of 1GB; the smaller of the two is enforced).

If min-free-space-size is set to a non-zero value, the smaller of the two limits is used. Note that, min-free-space-percent is not enforced on metadata objects. It is assumed that metadata objects are relatively small in size compared to content objects and thus kept outside the scope of this option. 🍓

  • min-free-space-size — Value (in power-of-2 MB, GB or TB) that specifies a minimum space in the underlying filesystem to keep free. Examples of acceptable values: 500MB (524 288 000 bytes), 1GB (1 073 741 824 bytes), 1TB (1 099 511 627 776 bytes).

If this option is set to a non-zero value, and min-free-space-percent is also set, the smaller of the two limits is used. When neither option is set, the default is 1GB (capped at 3% of total filesystem size). Note that, min-free-space-size is not enforced on metadata objects. It is assumed that metadata objects are relatively small in size compared to content objects and thus kept outside the scope of this option. 💖

  • add-remotes-config-dir — Boolean value controlling whether new remotes will be added in the remotes configuration directory. Defaults to true for system ostree repositories. When this is false, remotes will be added in the repository's config file.

This only applies to repositories that use a remotes configuration directory such as system ostree repositories, which use /etc/ostree/remotes.d. Non-system repositories do not use a remotes configuration directory unless one is specified when the repository is opened. 🧚

  • payload-link-threshold — An integer value that specifies a minimum file size for creating a payload link. By default it is disabled. 🔥
  • collection-id — A reverse DNS domain name under your control, which enables peer to peer distribution of refs in this repository. See the --collection-id section in ostree-init(1). 👑
  • locking — Boolean value controlling whether or not OSTree does repository locking internally. This uses file locks and is hence for multiple process exclusion (e.g. Flatpak and OSTree writing to the same repository separately). This is enabled by default since 2018.5. 🎀
  • lock-timeout-secs — Integer value controlling the number of seconds to block while attempting to acquire a lock (see above). A value of -1 means block indefinitely. The default value is 300. This timeout is now regarded as a mistake; because it's likely to cause flakes. It's recommended to set it to -1, and have timeouts at a higher application level if desired. 💀
  • default-repo-finders — Semicolon separated default list of finders (sources for refs) to use when pulling. This can be used to disable pulling from mounted filesystems, peers on the local network, or the Internet. However note that it only applies when a set of finders isn't explicitly specified, either by a consumer of libostree API or on the command line. Possible values: config, lan, and mount (or any combination thereof). If unset, this defaults to config;mount; (since the LAN finder is costly). 🦋
  • no-deltas-in-summary — Boolean value controlling whether OSTree should skip putting an index of available deltas in the summary file. Defaults to false.

Since 2020.7 OSTree can use delta indexes outside the summary file, making the summary file smaller (especially for larger repositories). However by default we still create the index in the summary file to make older clients work. If you know all clients will be 2020.7 later you can enable this to save network bandwidth. ✨

  • sign-verify-deltas — A boolean value, defaults to false. When true, applying a signed static delta with ostree static-delta apply-offline requires a key to be supplied, and fails with Key is mandatory to check delta signature when none is.

This option cannot require a delta to be signed. It is consulted only after a delta has been found to carry a signature, so an unsigned delta is applied whatever this is set to. It also has no effect on ostree pull, which cannot consume signed deltas at all; see ostree-static-delta(1). 🫶

🌸 [REMOTE "NAME"] SECTION OPTIONS 🌸

okay bestie, this section is literally the whole personality of a remote repo — it's where you tell OSTree where the remote lives and how to talk to it 💖 The NAME in the header is whatever you called the remote, and everything below is the tea.

  • url — mandatory, no skips 🙅‍♀️ This declares the URL where OSTree grabs the metadata and the content for this remote. There's also contenturl if you wanna split those up, and the supported schemes are listed further down (iykyk, they're in the URL/CONTENTURL bit).
  • contenturl — declares the URL for pulling content specifically (so: filez, static delta parts). When you set this, url gets demoted to metadata-only duty: summary, static delta "superblocks". Teamwork 💅
  • branches — a list of strings, and it's literally just the default branches to fetch from this remote when you do a pull and don't ask for anything specific. The pre-selected faves ✨
  • proxy — a string value; if you give it one, it should be a URL for an HTTP proxy to use when hitting up this repo. Networking but make it ~through a middleman~ 🫶
  • gpg-verify — a boolean, defaults to true. Controls whether OSTree makes commits be signed by a known GPG key. More deets live in the ostree(1) manual under GPG. Yes, it's on by default — it's giving protective bestie energy 🔥
  • gpg-verify-summary — a boolean, defaults to false. Controls whether OSTree checks that the summary is signed by a known GPG key. Again: ostree(1) manual, under GPG. 📖
  • sign-verify — the non-GPG glow-up ✨ Controls whether OSTree requires commits to be signed by a known key using one of the non-GPG signature engines (currently ed25519). If it's unset, empty, or set to a boolean-false value (false or 0), no such verification happens at all. Periodt.

A boolean-true value enables every compiled-in signature engine. Keys are optional in that case: an engine with no verification-<engine> option set for the remote is still enabled, and falls back to the system-wide key storage. Any other value gets read as a semicolon-delimited list of engine names — and then keys for each named engine become mandatory rather than optional, and a commit is accepted if any one of the named engines finds a valid signature for it. Picky but fair 💅

Public keys come from the companion options verification-<engine>-key (holds an inline key) and verification-<engine>-file (holds a path to a file of keys) — for example verification-ed25519-file. And fun fact: ostree remote add --sign-verify=ed25519=file:/path/to/key writes this option and the matching companion together. Two birds, one command 🐦🐦

🚨 This setting is independent of gpg-verify, which defaults to true. So if you only enable sign-verify, GPG verification stays enabled too — and a pull against a remote with no GPG signatures fails with GPG verification enabled, but no signatures found until you also set gpg-verify to false. No cap, this trips people up.
  • sign-verify-summary — same energy as sign-verify, but for the summary: it controls whether the summary must carry a valid signature. If it's unset or empty, the summary is not verified. 🙈
  • tls-permissive — a boolean, defaults to false. By default, server TLS certificates get checked against the system certificate store. Set this variable and literally any certificate will be accepted. Fun and also terrifying, use wisely 😭
  • tls-client-cert-path — path to the file for the client-side certificate, presented when making requests to this repository. Hi, it's me, I'm the client 🫶
  • tls-client-key-path — path to the file containing the client-side certificate key, also presented when making requests to this repository. The matching set 💜
  • tls-ca-path — path to a file containing trusted anchors, used instead of the system CA database. Mutual trust era 🤝
  • http2 — a boolean, defaults to true. By default libostree uses HTTP2; set this to false to disable it. May be useful to work around broken servers — sometimes the tech is just not slaying 💀
  • unconfigured-state — if set, pulls from this remote will fail with the text you configured. Intended for OS vendors who have a subscription process to access content. Paywall, but make it ostree 🎀
  • custom-backend — if set, pulls from this remote via libostree will fail with an error that mentions the value. Recommended to make it a software identifier token (e.g. "examplecorp-fetcher"), not freeform text ("ExampleCorp Fetcher" — nope, not that). Intended for higher level software that wants to fetch ostree commits via some other mechanism while still reusing the core libostree infrastructure around e.g. signatures. Fancy ✨

🎀 [SYSROOT] SECTION OPTIONS 🎀

These are the options for the sysroot — the thing that contains the OSTree repository, deployments, and stateroots. The following entries are defined:

  • readonly — a boolean. If true, then the /sysroot mount point is mounted read-only. Fair warning bestie: this is a legacy repository configuration, and the equivalent option in ostree/prepare-root.conf should be used instead — see ostree-prepare-root(1) 🫡
  • bootloader — configures the bootloader OSTree uses when deploying the sysroot. It can take the values bootloader=none, bootloader=auto, bootloader=grub2, bootloader=syslinux, bootloader=uboot or bootloader=zipl. Default is auto.
    • If none, OSTree generates only BLS (Boot Loader Specification) fragments in sysroot/boot/loader/entries/ for the deployment.
    • If auto, then in addition to generating BLS fragments, OSTree dynamically checks whether grub2, uboot, and syslinux bootloaders exist. If one of them is found, OSTree generates a config for that bootloader. Like, grub2-mkconfig is run in the grub2 case. Detective mode 🔍
    • A specific bootloader type can also be explicitly requested by choosing grub2, syslinux, uboot or zipl. Main character energy, you pick 👑
  • boot-counting-tries — integer value controlling the max number of boot attempts. The boot counting data lives in the name of the boot loader entry. A boot loader entry file name may contain a plus (+) followed by a number. That may optionally be followed by a minus (-) followed by a second number. The dot (.) and file name suffix (conf or efi) must immediately follow. More details in The Boot Loader Specification[2] — it's a whole thing, go read it 🧚
  • bls-append-except-default — a semicolon separated string list of key-value pairs. For example: bls-append-except-default=key1=value1;key2=value2. These key-value pairs get injected into the generated BLS fragments of the non-default deployments. In other words: the BLS fragment of the default deployment is unaffected by bls-append-except-default. Default deployment stays unbothered, as it should 💅
  • bootprefix — a boolean; defaults to false. If set to true, the bootloader entries generated will include /boot as a prefix. Heads up: this will likely be turned on by default in the future, so like… get used to it 👀

🧪 [EX-INTEGRITY] SECTION OPTIONS 🧪

The ex- prefix here signifies experimental options — read the room, they're in beta 😌 The ex-integrity section contains options related to system integrity. Info about experimental options is canonically found in upstream tracking issues. That's where the lore lives 📚

📁 /ETC/OSTREE/REMOTES.D 📁

In addition to the /ostree/repo/config file, remotes may also be specified in /etc/ostree/remotes.d. The remote configuration file must end in .conf; files whose name does not end in .conf will be ignored. No .conf, no entry, no exceptions 🚫

🌈 REPOSITORY URL/CONTENTURL 🌈

Originally, OSTree had just a url option for remotes. Since then, the contenturl option was introduced — glow-up moment 💖 Both of these support file, http, and https schemes.

Additionally, both of these can be prefixed with the string mirrorlist=, which tells the client that the target url is a "mirrorlist" format — that's a plain text file of newline-separated URLs. Earlier URLs get precedence. First come, first served, literally 👑

🚨 Note that currently, the tls-ca-path and tls-client-cert-path options apply to every HTTP request, even when contenturl and/or mirrorlist are in use. This may change in the future to only apply to metadata (i.e. url, not contenturl) fetches. Future tea, not current tea 🍵

🔐 PER-REMOTE GPG KEYRINGS AND VERIFICATION 🔐

OSTree supports a per-remote GPG keyring, as well as a gpgkeypath option. For more information see ostree(1), in the section GPG verification. Yes, more reading, but it's important reading, bestie 📖💜

🍪 PER-REMOTE HTTP COOKIES 🍪

Some content providers may want to control access to remote repositories via HTTP cookies. The ostree remote add-cookie and ostree remote delete-cookie commands will update a per-remote lookaside cookie jar, named $remotename.cookies.txt. Cookies but for repos, obsessed 🍪✨

👀 SEE ALSO 👀

ostree(1), ostree.repo(5)

📝 NOTES 📝

  1. XDG Desktop Entry Specification http://standards.freedesktop.org/desktop-entry-spec/latest/
  2. The Boot Loader Specification https://uapi-group.org/specifications/specs/boot_loader_specification/#boot-counting

and that's the whole page, bestie!! 🎉 you read the entire OSTREE.REPO-CONFI(5) manual page from OSTree — that's the source, and the date is baked into the footer — you're officially a repo-config scholar now 👑💖 go forth and configure responsibly 🦋

📦 where this page comes from