Fix typos and small errors throughout the documentation

docs/BIOS-FIRMWARE.md

@@ -54,7 +54,7 @@ can be not. For example, on a popular Raspberry Pi 4 ARM board there are at leas
 
 EVE helps managing layers #2 and #3 and leaves #1 to the operator. In general,
 as long as firmware can be derived from u-boot -- EVE can manage it by carrying
-all the extra firmware blobs in its UEFI compliant exfat partiotion (UEFI doesn't
+all the extra firmware blobs in its UEFI compliant exfat partition (UEFI doesn't
 mind if extra files are present in that partition).
 
 On ARM boards EVE leverages u-boot to provide UEFI environment and fill out SMBIOS

docs/BOOTING.md

@@ -44,7 +44,7 @@ Since artifacts #2-#5 are physically embedded inside of the rootfs image (artifa
 
 All the logic of locating the right boot artifacts can been seen in [grub.cfg](../pkg/eve/installer/grub.cfg) and [ipxe.cfg](../pkg/eve/installer/ipxe.efi.cfg). All the cpio artifacts are loaded together and contribute files to the initial initramfs filesystem that the kernel will see. All of this is pretty vanilla Linux kernel boot flow, except for:
 
-* order of the cpio artifacts matters: if you have a file with the same name in two artifacts the actual content of that file will be taken from the later cpio artifacat (think of it as kernel doing sequence of `cpio -i` operations with root filesystem as a target)
+* order of the cpio artifacts matters: if you have a file with the same name in two artifacts the actual content of that file will be taken from the later cpio artifact (think of it as kernel doing sequence of `cpio -i` operations with root filesystem as a target)
 * if rootfs was loaded in memory it will also appear in the initramfs filesystem under the fixed name `/initrd.image`. This kind of a trick is pretty unique to EVE and it comes at a price of Linux kernel sticking ALL of the cpio bits into that file (artifacts #5-#7) not just rootfs image. Therefore we have to search for where rootfs image actually begins in that file to pass that offset to a `losetup`.
 
 Finally, once all the required boot artifacts have been made available in the initial initramfs, EVE leverages Alpine's ability to create an overlayfs-based stacked rootfilesystem by specifying [overlaytmpfs kernel option](https://gitlab.alpinelinux.org/alpine/mkinitfs/-/blob/master/initramfs-init.in) (look for `KOPT_overlaytmpfs` in the initramfs-init.in source to understand how it works). This is how EVE tweaks the content of the final rootfs to have additional files (e.g. the content of the installer container image appearing under `/containers/onboot/003-installer`).

docs/BUILD.md

@@ -603,7 +603,7 @@ Similarly, a `pkg/` may be sourced from another package which, in turn, has a sp
 FROM lfedge/eve-xen-tools@sha256:4a6d0bcfc33a3096398b4daa0931f9583c674358eeb47241e0df5f96e24c0110 as xentools
 ```
 
-The Dockerfile mentioned above is not checked into the repository, but instead generated from a teampled by a parse-pkgs script.
+The Dockerfile mentioned above is not checked into the repository, but instead generated from a template by a parse-pkgs script.
 
 The purpose of [parse-pkgs](../parse-pkgs.sh) is to collect the actual hashes of the latest version of every relevant package and either report them to stdout or modify a template file à la sed.
 

docs/DEBUGGING.md

@@ -30,7 +30,7 @@ eve enter pillar
 /opt/dlv --headless --listen :2345 attach "$(pgrep zedbox)"
 ```
 
-In a different termianl
+In a different terminal
 
 ```bash
 ❯ dlv connect :2348

docs/ECOS.md

@@ -91,7 +91,7 @@ As part of a regular config that EVE receives from its controller, each ECO gets
         * dsId
         * siginfo
 
-EVE periodically pulls the configuration from the controller. The configuration specifies the desired end state. EVE implements "eventual consistentency" model. To reach the desired state from the current state of the system, EVE computes the required operations to be performed. EVE then executes those operations. At the end of each operation, EVE reports the state of the system back to the controller.
+EVE periodically pulls the configuration from the controller. The configuration specifies the desired end state. EVE implements "eventual consistency" model. To reach the desired state from the current state of the system, EVE computes the required operations to be performed. EVE then executes those operations. At the end of each operation, EVE reports the state of the system back to the controller.
 
 The picture below provides simplified view of states and transitions for an ECO.
 
@@ -117,7 +117,7 @@ The picture below provides simplified view of states and transitions for an ECO.
 The controller drives the ECO state transitions via the configuration. These state transitions are described below. Due to the eventual consistency model, a new configuration may result in zero or more state transitions for a given ECO.
 
 * Prepare an ECO
-  * The ECI(s) is transfer'ed to EVE's storage area and resources required for the ECO are reserved.
+  * The ECI(s) is transferred to EVE's storage area and resources required for the ECO are reserved.
   * EVE performs the operations to "prepare an ECO" for each entry in the array of ECO's in the new configuration and not present in older configuration.
 
 * Start an ECO

docs/HARDWARE-MODEL.md

@@ -47,7 +47,7 @@ If and only if you have a debug version of EVE-OS booted with the KVM hypervisor
 
 Note that the script does not take photos of the front and back, nor find the product URL, hence the output must be edited. The less obvious but more critical manual work includes:
 
-- The script looks for controllers on the PCI bus but has no visibility to which controllers are connected to which external physical ports. This is a an issue in particular for USB ports where one controller can be connected to multiple physical ports, but there can also be multiple USB controllers perhaps with some of them having no external physical ports. On a device with multiple USB controllers manual testing is needed to determine which controller is connected to which external USB ports.
+- The script looks for controllers on the PCI bus but has no visibility to which controllers are connected to which external physical ports. This is an issue in particular for USB ports where one controller can be connected to multiple physical ports, but there can also be multiple USB controllers perhaps with some of them having no external physical ports. On a device with multiple USB controllers manual testing is needed to determine which controller is connected to which external USB ports.
 - A cellular modem (if available) is typically connected via a USB controller, but it might not be visible (not plugged in or software not yet initializing it) when you run the script. ```lsusb``` and ```lspci``` can help finding those.
 - If there are unknown controllers/functions on the PCI bus which share an IOMMU group with a known controller/function, the script is conservative and will mark the known as not assignable by setting assigngrp to empty. More about that below.
 

docs/README.md

@@ -97,7 +97,7 @@ our goals we put forward a [few guiding principles](SECURITY.md).
 ## EVE Controller
 
 Each Edge Node with EVE running on it can participate in sophisticated
-[Edge Computing scenarious](https://www.zdnet.com/article/10-scenarios-where-edge-computing-can-bring-new-value/)
+[Edge Computing scenarios](https://www.zdnet.com/article/10-scenarios-where-edge-computing-can-bring-new-value/)
 ranging from simple [data collection](https://blog.equinix.com/blog/2017/11/29/how-iot-data-collection-and-aggregation-with-local-event-processing-work/)
 all the way to [Edge Analytics and AI](https://www.datanami.com/2019/02/04/exploring-artificial-intelligence-at-the-edge/).
 While EVE provides an incredible amount of functionality to support these use
@@ -266,7 +266,7 @@ absolutely no reason of ever being written to past initial installation process.
 
 P3 is a scratch space. Unlike CONFIG and EFI System partition, P3 can be wiped out
 and re-created without affecting much of edge node behaviour. The content of CONFIG
-and EFI System has to be preserved at all costs. Corrupting those parititions will
+and EFI System has to be preserved at all costs. Corrupting those partitions will
 result in an edge node that needs to be re-installed (technically IMGA and IMGB
 should be protected as well, but since they are always treated as read-only corrupting
 them is much harder).

docs/ZFS.md

@@ -19,14 +19,14 @@ it's data, furthermore it knows better what to cache.
 `recordsize=16k` - is a sweet spot between constantly having sub-blocks
 updates, and good compression ratio.
 
-`compression=zstd` - is a less cpu intencive algorithm, with not too big
+`compression=zstd` - is a less cpu intensive algorithm, with not too big
 compromise on compression ratio
 
 `redundant_metadata=most` - will reduce the number of copies of the
 indirect blocks at the higher levels. This can greatly cut the amount
 of data that must be written, resulting in better performance.
 
-Multiple tunabels to better regulate how fast ZFS can accept
+Multiple tunables to better regulate how fast ZFS can accept
 requests. This along helped mediate maximum latency on parallel access
 with small ARC: