keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

docs: Add apply-live

Browse Source 
Continuing the more docs momentum.
This commit is contained in:
Colin Walters 2021-03-11 16:35:02 +00:00
parent 5f17bc5c87
commit 4a29454ee6
1 changed files with 72 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
docs/apply-live.md Normal file
View File

@ -0,0 +1,72 @@
---
nav_order: 6
---
# Architecture of apply-live
{: .no_toc }
1. TOC
{:toc}
## Copying into an "underlay"
As noted in the architecture doc, everything in rpm-ostree is oriented
around creating and managing hardlinked complete bootable filesystem trees.
In this flow then, `rpm-ostree install --apply-live strace` will first
create a new pending deployment, run sanity tests on it, prepare it to be booted, etc.
However, the first time `apply-live` is invoked, we create an `overlayfs`
mount over `/usr`. It's mounted `ro` from the perspective of the rest
of the system, but rpm-ostree can write to it.
## Package and filesystem diffs
When `apply-live` is invoked, rpm-ostree computes the diff between
the source and target OSTree commit for `/usr`. If this is the *first* `apply-live`,
the source commit is the booted commit. For subsequent invocations,
it will be based on the current live commit.
We also compute a package-level diff; this is how `apply-live`
currently distinguishes between pure package additions versus upgrades.
## Copying data for /usr
Per the core OSTree model, almost everything we care about is in `/usr`.
So the first step is to apply the diff to the transient writable `overlayfs`.
One downside is that that this diff will take extra memory and disk space
proportional to its size.
## Updating /etc
The second aspect we need to take care of is `/etc`. Normally, the libostree
core handles the `/etc` merge during shutdown as part of `ostree-finalize-staged.service`,
but we need to do it now in order to ensure that we get new config files
(or remove ones).
Note that the changes in `/etc` are persistent, live-applied changes there are
also hence not updated transactionally. It is hence possible for configuration
files to "leak" from partially applied live updates.
## Updating /var
Normally, libostree core never touches `/var`. Today rpm-ostree generates
`systemd-tmpfiles` snippets for RPM packages which contain directories in
`/var`. In a regular update, these will hence be generated at boot
time by `systemd-tmpfiles-setup.service`.
But here, we need to do this live. So rpm-ostree directly starts a
transient systemd unit running `systemd-tmpfiles`.
## Tracking live state
Because the `overlayfs` is transient (goes away on reboot), the `apply-live`
operation also writes its state into the transient `/run` directory, specifically
a stamp file is stored at `/run/ostree/deployment-state/$deployid/`.
Currently, there is also a persistent ostree ref `rpmostree/live-apply` for
the current live commit. Eventually the goal is that libostree itself would
gain direct awareness of live apply, and we wouldn't write a persistent ref.