1 files changed, 10 insertions, 10 deletions

diff --git a/docs/ROOT_STORAGE_DAEMONS.md b/docs/ROOT_STORAGE_DAEMONS.md
index 3b19ea79d1..2d17f3f2dc 100644
--- a/docs/ROOT_STORAGE_DAEMONS.md
+++ b/docs/ROOT_STORAGE_DAEMONS.md
@@ -22,16 +22,16 @@ is not.
 ## A Bit of Background
 
 When complex storage technologies are used as backing for the root file system
-this needs to be set up by the initial RAM file system (initrd), i.e. on Fedora
-by Dracut. In newer systemd versions tear-down of the root file system backing
-is also done by the initrd: after terminating all remaining running processes
-and unmounting all file systems it can (which means excluding the root fs)
-systemd will jump back into the initrd code allowing it to unmount the final
-file systems (and its storage backing) that could not be unmounted as long as
-the OS was still running from the main root file system. The initrd' job is to
-detach/unmount the root fs, i.e. inverting the exact commands it used to set
-them up in the first place. This is not only cleaner, but also allows for the
-first time arbitrary complex stacks of storage technology.
+this needs to be set up by the initrd, i.e. on Fedora by Dracut. In newer
+systemd versions tear-down of the root file system backing is also done by the
+initrd: after terminating all remaining running processes and unmounting all
+file systems it can (which means excluding the root fs) systemd will jump back
+into the initrd code allowing it to unmount the final file systems (and its
+storage backing) that could not be unmounted as long as the OS was still
+running from the main root file system. The initrd' job is to detach/unmount
+the root fs, i.e. inverting the exact commands it used to set them up in the
+first place. This is not only cleaner, but also allows for the first time
+arbitrary complex stacks of storage technology.
 
 Previous attempts to handle root file system setups with complex storage as
 backing usually tried to maintain the root storage with program code stored on