ostree Developer Jonathan Lebon jonathan@jlebon.com ostree-state-overlay 8 ostree-state-overlay@.service Set up state overlays ostree-state-overlay@.service Note this feature is currently considered experimental. It may not work correctly and some of its semantics may be subject to change. Positive or negative feedback are both welcome and may be provided at . If using the feature via rpm-ostree, feedback may also be provided at . In some cases, it's useful to be able to have a directory as part of the OSTree commit yet still have this directory be writable client-side. One example is software that ships in /opt. /opt is its own vendor-namespaced alternate file hierarchy which may contain both code and state. With state overlays, it's possible to have the code part baked in the OSTree, but still allowing the directory to be writable so that state can be kept there. Since it's writable, nothing prevents sufficiently privileged code to modify or delete content that comes from the OSTree commit. This is in sharp contrast with content in /usr, and more closely matches a package manager-based distro. Crucially, this state is automatically rebased during upgrades (or more generally, anytime a different OSTree commit is booted). The semantics of the rebase are as follows: any state file or directory that modified OSTree content is deleted, otherwise it is kept and merged onto the new base content (using overlayfs). This mostly matches the semantics of a package manager. To enable this feature, simply instantiate the unit template, using the target path (in escaped systemd path notation) as the instance name. For example, to enable it on /opt: $ systemctl enable --now ostree-state-overlay@opt.service