Fix yetus errors and remove deprecated documentation

README.md

@@ -243,7 +243,7 @@ from containerd - use that instead).
 Once in a container you can run the usual xl commands to start VMs and
 interact with Xen.
 
-#### Exitting
+#### Exiting
 
 To exit out of the QEMU environment, press `Ctrl-A + C` to reach the QEMU console, then `q` to quit.
 
@@ -271,7 +271,7 @@ make run CONF_PART=/path/to/partition
 
 Note that the directory must exist to be mounted; if not, it will be ignored. The most common use case is a config directory output on the run of [adam](https://github.com/zededa/adam).
 
-While running everything on your laptop with QEMU could be fun, nothing beats real hardware. The most cost-effective option, not surprisingly, is ARM. We recommend two popular board [HiKey](http://www.lenovator.com/product/90.html) and [Raspberry Pi 4](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/). The biggest difference between the two is that on Raspberry Pi (since it doesn't have any built-in flash storage) you won't be able to utlize EVE's installer and you'll have to build a live image. With HiKey you can use a standard EVE's installer. The steps to do both are outlined below:
+While running everything on your laptop with QEMU could be fun, nothing beats real hardware. The most cost-effective option, not surprisingly, is ARM. We recommend two popular board [HiKey](http://www.lenovator.com/product/90.html) and [Raspberry Pi 4](https://www.raspberrypi.org/products/raspberry-pi-4-model-b/). The biggest difference between the two is that on Raspberry Pi (since it doesn't have any built-in flash storage) you won't be able to utilize EVE's installer and you'll have to build a live image. With HiKey you can use a standard EVE's installer. The steps to do both are outlined below:
 
 ## How to use on a Raspberry Pi 4 ARM board
 
@@ -515,7 +515,7 @@ You may be wondering why do we have a container-based architecture for a Xen-cen
 1. Set up the filesystem root using [containerd](https://containerd.io)
 1. Launch the domU using Xen via `xl`
 
-In addition to that, while we plan to build a fully disagregated system (with even device drivers running in their separate domains) right now we are just getting started and having containers as a first step towards full disagreagation seems like a very convenient stepping stone.
+In addition to that, while we plan to build a fully disaggregated system (with even device drivers running in their separate domains) right now we are just getting started and having containers as a first step towards full disaggregation seems like a very convenient stepping stone.
 
 Let us know what you think by filing GitHub [issues](https://github.com/lf-edge/eve/issues/new/choose), and feel free to send us pull requests if something doesn't quite work.
 

docs/BOOTING.md

@@ -10,7 +10,7 @@ the following firmware implementations:
 * generic [UEFI firmware](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface) on both x86 and ARM
 * legacy [PC BIOS](https://en.wikipedia.org/wiki/BIOS) on x86 and in the virtualized environments with support for nested virtualization (such as on Google Compute Platform)
 * open source [Coreboot](https://en.wikipedia.org/wiki/Coreboot) via the legacy PC BIOS payload
-* board specific [u-boot](https://en.wikipedia.org/wiki/Das_U-Boot) firmware (such as on Raspbery Pi ARM platform)
+* board specific [u-boot](https://en.wikipedia.org/wiki/Das_U-Boot) firmware (such as on Raspberry Pi ARM platform)
 
 EVE has standardized on GRUB as a bootloader that has to run in all of the initial environments,
 although in the future we may provide direct, custom implementations that would be natively integrated
@@ -202,7 +202,7 @@ about how the first MBR partition needs to look like in order for Raspberry Pi t
 EVE to use hybrid MBR/GPT partitioning scheme and advertise the `EFI System` partition as the first MBR partition visible
 to Raspberry Pi (note that strictly speaking this goes against best practices of how protective MBR should looks like,
 since the recommendation is for the first MBR partition to always be of the type protective MBR). Fortunately, at least
-both UEFI and Raspbery Pi agree on the filesystem for the first partition: FAT.
+both UEFI and Raspberry Pi agree on the filesystem for the first partition: FAT.
 
 To put it all together, for Raspberry Pi we use `EFI System` AKA MBR #1 partition to store the following artifacts (in addition
 to EFI/BOOT folder):

docs/BUILD.md

@@ -388,10 +388,9 @@ The following custom packages are used:
 
 #### Custom Live Packages
 
-* kernel: EVE uses its own custom kernel package, rather than one of the standard linuxkit ones. This is primarily due to kernel modules and drivers, especially on arm, as well as Xen requirements.
+* kernel: EVE uses its own custom kernel (taken from [eve-kernel](https://github.com/lf-edge/eve-kernel) project), rather than one of the standard linuxkit ones. This is primarily due to kernel modules and drivers, especially on arm, as well as Xen requirements.
 * `init` packages:
   * `lfedge/eve-grub` - CoreOS inspired GRUB required to enable CoreOS-style dual partition upgrades. See [UPSTREAMING.md](./UPSTREAMING.md#grub) for a more detailed discussion of what is unique in this grub.
-  * `lfedge/eve-devices-trees` - device trees for all the ARM platforms that EVE supports.
   * `lfedge/eve-fw` - various firmware required for device drivers.
   * `lfedge/eve-xen` - a single Xen binary required to boot EVE.
   * `lfedge/eve-gpt-tools` - ChromiumOS inspired tools and sgdisk required to enable CoreOS-style dual partition upgrades. See [UPSTREAMING.md](./UPSTREAMING.md#grub) for a more detailed discussion of what is unique in these versions of the gpt tools.
@@ -402,11 +401,10 @@ The following custom packages are used:
   * `lfedge/eve-wwan` - WWAN drivers and software. 5G/LTE/3G/2G. See [wwan/README.md](../pkg/wwan/README.md) for detailed documentation.
   * `lfedge/eve-wlan` - WLAN drivers and software. Currently a glorified wrapper around wpa_supplicant.
   * `lfedge/eve-guacd` - [Apache Guacamole service](http://guacamole.apache.org/) that provides console and VDI services to running VMs and containers.
-  * `lfedge/eve-zedctr` - a "catch-all" package for EVE tools; see below.
 
 #### Custom Installer Packages
 
-* kernel: EVE uses its own custom kernel package, rather than one of the standard linuxkit ones. Technically, the installer could use a standard linux kernel from [linuxkit/kernel](https://github.com/linuxkit/kernel). However, while _installing_ has few special requirements, _booting_ the live system _does_ have requirements, including proper xen support and appropriate device drivers functioning. Rather than having the install function, only to have the live boot fail because of driver, module or xen issues, we boot the installer with the exact same kernel as the live system, allowing it to serve double-duty as both an installer and a verifier.
+* kernel: EVE uses its own custom kernel (taken from [eve-kernel](https://github.com/lf-edge/eve-kernel) project), rather than one of the standard linuxkit ones. This is primarily due to kernel modules and drivers, especially on arm, as well as Xen requirements.
 * `init` packages:
   * `lfedge/eve-grub` - CoreOS inspired GRUB required to enable CoreOS-style dual partition upgrades.
   * `lfedge/eve-devices-trees` - device trees for all the ARM platforms that EVE supports.
@@ -416,10 +414,6 @@ The following custom packages are used:
   * `lfedge/eve-rngd` - custom EVE rngd package, rather than the standard linuxkit one. This micro-fork accommodates the [following hack](https://github.com/lf-edge/eve/blob/master/pkg/rngd/cmd/rngd/rng_linux_arm64.go) which provides some semblance of seeding randomness on ARM. Without this HiKey board won't boot.
   * `lfedge/eve-mkimage-raw-efi` - custom EVE version of `mkimage-raw-efi` to create an ext4 image, used to make the correct filesystems on the target install disk.
 
-#### zedctr
-
-The package `lfedge/eve-zedctr` is a "catch-all" package, composed of many different packages that would go into `services` separately. Its source is [pkg/zedctr](../pkg/zedctr), and is comprised of many different services.
-
 #### pillar
 
 The package `pillar` contains, unsurprisingly, the `pillar` services that are responsible for managing the various components and deployments of a running EVE system. Its source is [pkg/pillar](../pkg/pillar). We need to start breaking this monolith down at some point, but for now everything sits in the same container.

docs/CUSTOM-BUILD.md

@@ -35,13 +35,6 @@ make pkg/<package>
 
 For example, `make pkg/edgeview` or `make pkg/guacd`.
 
-Some packages require special treatment in the form of extra steps after build. Those should be invoked with their dedicated targets.
-As of this writing, only `pkg/kernel` is subject to this special treatment, and should be invoked as:
-
-```sh
-make kernel
-```
-
 The `make` command will use linuxkit to build an OCI image based on the contents of the directory, e.g. `pkg/guacd`. The tag
 on the image is based on the [git tree hash](https://git-scm.com/docs/git-ls-tree) of the directory.
 

docs/DEPLOYMENT.md

@@ -223,7 +223,7 @@ At the end of its run, the installer process will shut down the edge node and it
 on the USB stick's INVENTORY partition which is named identical to the soft serial number. Using that
 soft serial number then allows you to onboard your new EVE-OS edge node to its controller.
 
-### Deploying EVE-OS on SBCs (including older Raspbery Pi models) and running live
+### Deploying EVE-OS on SBCs (including older Raspberry Pi models) and running live
 
 A lot of single-board computers (SBCs), including older models of Raspberry Pi, don't have any kind
 of built-in storage devices. They rely on microSD cards that can be put in

docs/EVE-IMAGE-SOURCES.md

@@ -650,7 +650,7 @@ license="GPL-2.0-or-later"
 depends_dev="linux-headers"
 makedepends="$depends_dev libnftnl-dev bison flex autoconf automake"
 subpackages="ip6tables $pkgname-doc $pkgname-dev $pkgname-openrc ip6tables-openrc:ip6tables_openrc"
-provides="ebtables" # for backards compat
+provides="ebtables" # for backwards compat
 replaces="ebtables"
 source="https://www.netfilter.org/projects/iptables/files/iptables-$pkgver.tar.bz2
     use-sh-iptables-apply.patch

docs/README.md

@@ -361,7 +361,7 @@ Parent cgroup (/sys/fs/cgroup/<subsystems>/)
 ```
 
 Memory and CPU limits of `eve`, `eve/services` and `eve/containerd` cgroups can be changed via
-`hv_dom0_*`, `hv_eve_*` and `hv_ctrd_*` respectively in `/config/grup.cfg`.
+`hv_dom0_*`, `hv_eve_*` and `hv_ctrd_*` respectively in `/config/grub.cfg`.
 
 Example:
 

docs/WIRELESS.md

@@ -273,7 +273,7 @@ to behave as follows:
 #### Radio silence indication
 
 When radio silence is temporarily imposed, the device status indicator (by default the disk LED)
-will repeat a patter of blinking 5 times in a row. The pattern is the same regardless of what state
+will repeat a pattern of blinking 5 times in a row. The pattern is the same regardless of what state
 the device was in before the radio silence was imposed.
 More information about the node state indication using LED can be found [here](LED-INDICATION.md).
 

pkg/apparmor/etc/apparmor/parser.conf

@@ -1,7 +1,7 @@
 # parser.conf is a global AppArmor config file for the apparmor_parser
 #
 # It can be used to specify the default options for the parser, which
-# can then be overriden by options passed on the command line.
+# can then be overridden by options passed on the command line.
 #
 # Leading whitespace is ignored and lines that begin with # are treated
 # as comments.

pkg/mkimage-raw-efi/make-raw

@@ -474,7 +474,7 @@ if [ ${EMBED_BOOT_START:-0} -gt 0 -a ${EMBED_BOOT_SIZE:-0} -gt 0 -a -f "$GRUB_IM
 else
   # ...if we're NOT adding ourselves to an existing GPT - assume we own protective MBR
   # as well and can adjust it accordingly to maximize our chances of booting on something
-  # like Raspbery Pi (which is pretty strict about how the first entry in the MBR partition
+  # like Raspberry Pi (which is pretty strict about how the first entry in the MBR partition
   # table needs to look like)
   adjust_protective_mbr
 fi

pkg/pillar/containerd/containerd.go

@@ -405,7 +405,7 @@ func (client *Client) CtrListContainerIds(ctx context.Context) ([]string, error)
 	return res, nil
 }
 
-// CtrListContainer returns a list of containerd.Container ibjects
+// CtrListContainer returns a list of containerd.Container objects
 func (client *Client) CtrListContainer(ctx context.Context) ([]containerd.Container, error) {
 	if err := client.verifyCtr(ctx, true); err != nil {
 		return nil, fmt.Errorf("CtrListContainer: exception while verifying ctrd client: %s", err.Error())

pkg/pillar/docs/domainmgr.md

@@ -17,7 +17,7 @@ Domain Manager interacts with the Cloud controller (e.g. zedcloud) indirectly us
 - DomainConfig from controller is fed to domainmgr. This contains the configuration information about a DomU instance. DomainConfig is defined in `pillar/types/domainmgrtypes.go`
 - DomainStatus is fed from `domainmgr` to controller. This contains the operational information about a DomU instance. DomainStatus is defined in `pillar/types/domainmgrtypes.go`
 - DomainMetric with CPU and memory metrics for the host (dom0) and the applications
-- PhysicalIOAdapterList specifes the set of physical I/O adapters which can potentially be used for adapter assignment.
+- PhysicalIOAdapterList specifies the set of physical I/O adapters which can potentially be used for adapter assignment.
 
 zedmanager publishes DomainConfig and subscribes to DomainStatus, while zedagent publishes PhysicalIOAdapterList and subscribes to DomainMetric.
 

pkg/pillar/types/wwan.go

@@ -407,7 +407,7 @@ const (
 	WwanOpModeRadioOff WwanOpMode = "radio-off"
 	// WwanOpModeOffline : modem is offline
 	WwanOpModeOffline WwanOpMode = "offline"
-	// WwanOpModeUnrecognized : unrecongized operating mode
+	// WwanOpModeUnrecognized : unrecognized operating mode
 	WwanOpModeUnrecognized WwanOpMode = "unrecognized"
 )
 

pkg/uefi/Dockerfile

@@ -24,7 +24,7 @@ FROM build AS build-arm64-versions
 ENV EDK_VERSION edk2-stable202208
 ENV EDK_COMMIT ba0e0e4c6a174b71b18ccd6e47319cc45878893c
 
-# FIXME: we should be building Raspbery Pi 4 UEFI implementations
+# FIXME: we should be building Raspberry Pi 4 UEFI implementations
 COPY rpi /rpi
 
 FROM build AS build-amd64-versions