Merge pull request #14293 from keur/systemctl_with_dependencies

[thirdparty/systemd.git] / docs / AUTOMATIC_BOOT_ASSESSMENT.md

diff --git a/docs/AUTOMATIC_BOOT_ASSESSMENT.md b/docs/AUTOMATIC_BOOT_ASSESSMENT.md
index 0909d88b5cac007f83df7740b4b08ca94948c21f..aff203b5906e215c25b858509a2376c8d60835a4 100644 (file)
--- a/docs/AUTOMATIC_BOOT_ASSESSMENT.md
+++ b/docs/AUTOMATIC_BOOT_ASSESSMENT.md
@@ -1,3 +1,9 @@
+---
+title: Automatic Boot Assessment
+category: Booting
+layout: default
+---
+
 # Automatic Boot Assessment
 
 systemd provides support for automatically reverting back to the previous
@@ -32,7 +38,7 @@ components:
 * The
   [`systemd-boot-check-no-failures.service(8)`](https://www.freedesktop.org/software/systemd/man/systemd-boot-check-no-failures.service.html)
   service is a simple health check tool that determines whether the boot
-  completed successfuly. When enabled it becomes an indirect dependency of
+  completed successfully. When enabled it becomes an indirect dependency of
   `systemd-bless-boot.service` (by means of `boot-complete.target`, see
   below), ensuring that the boot will not be considered successful if there are
   any failed services.
@@ -50,7 +56,7 @@ components:
   script can optionally create boot loader entries that carry an initial boot
   counter (the initial counter is configurable in `/etc/kernel/tries`).
 
-# Details
+## Details
 
 The boot counting data `systemd-boot` and `systemd-bless-boot.service`
 manage is stored in the name of the boot loader entries. If a boot loader entry
@@ -93,13 +99,13 @@ Here's an example walkthrough of how this all fits together.
    see the `+1-2` tag, and rename the file to
    `4.14.11-300.fc27.x86_64+0-3.conf` and boot it.
 
-6. If this boot also fails, on the next boot the boot loader will see the the
+6. If this boot also fails, on the next boot the boot loader will see the
    tag `+0-3`, i.e. the counter reached zero. At this point the entry will be
    considered "bad", and ordered to the end of the list of entries. The next
    newest boot entry is now tried, i.e. the system automatically reverted back
    to an earlier version.
 
-The above describes the walkthrough when the selected boot entry continously
+The above describes the walkthrough when the selected boot entry continuously
 fails. Let's have a look at an alternative ending to this walkthrough. In this
 scenario the first 4 steps are the same as above:
 
@@ -143,7 +149,7 @@ scenario the first 4 steps are the same as above:
 12. On the following boot (and all subsequent boots after that) the entry is
     now seen with boot counting turned off, no further renaming takes place.
 
-# How to adapt this scheme to other setups
+## How to adapt this scheme to other setups
 
 Of the stack described above many components may be replaced or augmented. Here
 are a couple of recommendations.
@@ -174,7 +180,7 @@ are a couple of recommendations.
    wrap them in a unit and order them after `boot-complete.target`, pulling it
    in.
 
-# FAQ
+## FAQ
 
 1. *Why do you use file renames to store the counter? Why not a regular file?*
    — Mainly two reasons: it's relatively likely that renames can be implemented