Commit 3fff8285 authored by Frédéric Dalleau's avatar Frédéric Dalleau

updates-rollback: More informations on OSTree updates

Mention that OSTree upgrades are atomic
Mention some update metadata examples
Add a link to OSTree atomic upgrade section
Mention special directories used by OSTree
Signed-off-by: default avatarFrédéric Dalleau <frederic.dalleau@collabora.com>
parent 1ae3b09c
......@@ -195,8 +195,9 @@ known working version.
After a tentative update was terminated by a rollback, the update system
will find an update pending. Since it is known that this update has a defect,
a blacklist can be used to prevent this update to be applied again.
In a more generic fashion, some metadata could be attached to updates using an
"update metadata system".
In a more generic fashion, additional metadata could be attached to updates.
For example, the date of the blacklist, the reason why it was blacklisted,
or the remote repository from which it was pulled.
### Factory reset
......@@ -886,7 +887,7 @@ device class, depending on the specific use-case.
## System snapshots and rollback
OSTree makes the term snapshots inexact. The snapshot is the capture
of a state at a specific moment. Since OSTree systems are read only,
of a state at a specific moment. Since OSTree systems are read-only,
the state is the same since it was deployed, until it is
updated. Each of thoses states are referenced by a commit, similar to
git commits.
......@@ -894,6 +895,12 @@ When an upgrade is started a new commit will be retrieved, then deployed.
Once that finishes successfully the update manager will then reboot into
the newly created deployment.
There are a couple exceptions to the read-only rule: in OSTree, `/etc` is writable.
During an upgrade, OSTree will perform a 3-way merge and continue. `/var` is
also writable, but OSTree does not touch its content. Individual components are
responsible for managing upgrade of their data in `/var`. Refer to
[][OSTree deployments] for more informations.
If the upgrade operation fails, the commit is simply not deployed, and the
selection of which deployment to boot into will be done by an atomic operation
that guarantees the new deployment has been successfully selected, or the
......@@ -903,6 +910,12 @@ To avoid insisting on a broken upgrade, the update can be blacklisted.
The usage of hard links greatly reduces the amount of disk space needed
to keep several parallel deployments.
OSTree implements transactional updates by design. The upgrade procedure is
atomic and detects errors to always maintain a consistent state.
Additionally, OSTree provide commands to manually check for the consistency of a
existing deployment.
Refer to [][OSTree atomic upgrades] for more information.
This covers essentially all there is to it, functionality wise; however,
the hard question on this matter is what technologies should be used.
Since OSTree works at the filesystem level, it becomes possible to not rely on
......@@ -1392,6 +1405,10 @@ BTRFS development and
[OSTree]: http://ostree.readthedocs.io
[OSTree atomic upgrades]: https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/#atomic-upgrades
[OSTree deployments]: https://ostree.readthedocs.io/en/latest/manual/deployment/#deployments
[GPT]: http://en.wikipedia.org/wiki/GUID_Partition_Table
[U-Boot]: http://www.denx.de/wiki/U-Boot/WebHome
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment