docs: initial auto-updates and rollbacks pages (#14)

This adds two initial pages on OS updates, covering:
 * auto-updates
 * manual rollbacks

modules/ROOT/nav.adoc

@@ -1,5 +1,9 @@
 * User guides
-** xref:getting-started.adoc[Getting Started]
+** xref:getting-started.adoc[Getting started]
 ** xref:faq.adoc[FAQ]
+** OS updates
+*** xref:auto-updates.adoc[Auto-updates]
+** Troubleshooting
+*** xref:manual-rollbacks.adoc[Manual rollbacks]
 * Reference pages
 ** xref:platforms.adoc[Platforms]

modules/ROOT/pages/auto-updates.adoc

@@ -0,0 +1,20 @@
+= Auto-updates
+
+Fedora CoreOS provides atomic updates and rollbacks via https://ostree.readthedocs.io/en/latest/[OSTree] deployments.
+
+By default, the OS performs continuous auto-updates via two components:
+
+ * https://github.com/coreos/rpm-ostree[rpm-ostree] handles multiple on-disk OSTree deployments, and it can switch between them at boot-time.
+ * https://github.com/coreos/zincati[Zincati] continuously checks for OS updates and applies them via rpm-ostree.
+
+== OS-update finalization
+
+In order to finalize an OS update, a machine needs to perform a reboot.
+As this is an invasive action which may cause service disruption, Zincati allows the cluster administrator to control when nodes are allowed to reboot in order to finalize updates.
+
+The following finalization strategies are available:
+
+ * immediately reboot to apply an update, as soon as it is downloaded and staged locally
+ * use an external lock-manager to reboot a fleet of machines in a coordinated way
+
+For further documentation on how to configure updates finalization, check Zincati documentation on https://github.com/coreos/zincati/blob/master/docs/usage/updates-strategy.md[updates strategy].

modules/ROOT/pages/manual-rollbacks.adoc

@@ -0,0 +1,12 @@
+= Manual rollbacks
+
+In case of a misbehaving OS update, it is possible to temporarily or permanently switch back to the previous working OS version.
+This is a manual operation which requires human intervention and console access.
+
+Upon updates, the previous OS deployment is kept on disk so that it can be used as a fallback if something goes wrong.
+
+In order to temporarily boot into the previous OS deployment, hold down `Shift` during OS bootup and select the relevant OS entry in the bootloader menu.
+The default boot configuration is not affected by this action, and the next reboot will select again the updated OS.
+
+In order to permanently revert to the previous OS deployment, login to the target node and run `rpm-ostree rollback -r`.
+This operation will update boot-loader configuration, marking the previous OS deployment as the default one and immediately rebooting into it.