More documentation (#1671)

Some minor typos, and updating old links.

Also removed some BIOS mention because it's no longer supported.

Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>

DEVELOPMENT.md

@@ -5,7 +5,7 @@ Some helpful tips and docs for development
 ## Enable video capture on virtualbox (packer, tests)
 
 When building the images with packer or running the tests with virtualbox, there is a possibility of enabling video capture of the machine output for easy troubleshooting.
-This is helful on situations when we cannot access the machine directly like in CI tests.
+This is helpful in situations where we cannot access the machine directly like in CI tests.
 
 This is disabled by default but can be enabled so the output is captured. The CI is prepared to save the resulting artifacts if this is enabled.
 
@@ -35,16 +35,6 @@ The test run is done via ginkgo, test suites are under the `test/installer` dire
 
 The full test workflow for this is as follows:
 
-For bios:
-
- - *(Makefile)* Create a vbox machine
- - *(Makefile)* Set bios
- - *(Makefile)* Set the boot order, so it boots from disk first, then dvd. This works because the initial disk is empty, so it will force booting from dvd on the first boot and allows us to test the installer from ISO.
- - *(Ginkgo)* Run test suite
- - *(Ginkgo)* Reboot. Now because of the boot order, the VM will boot from disk properly as it contains grub
- - *(Ginkgo)* Tests will check to see if whatever was run in the test was correctly (i.e. layout, partitions, config files, etc...)
- - *(Ginkgo)* After each test, the disk partition table is wiped out so the next test will see an empty disk and boot from dvd again.
-
 For efi:
 
 - *(Makefile)* Create a vbox machine
@@ -145,4 +135,4 @@ The following environment variables are available:
  - `REFERENCEID` Name of the repository.yaml that will be downloaded.
  - `DEBUGLOGLEVEL` Set debug log level
 
-Note that this should not be needed to run manually as the ci job can be manually triggered with the above fields pre-filled.
+Note that this should not be needed to run manually as the ci job can be manually triggered with the above fields pre-filled.

docs/content/en/docs/Customizing/login.md

@@ -13,4 +13,4 @@ By default you can login with the user `root` and `cos` in a vanilla Elemental i
 You can change this by overriding `/system/oem/04_accounting.yaml` in the container image if present, or via [cloud-init](../../reference/cloud_init/#stagesstage_idstep_nameusers).
 
 ### Examples
-- [Example accounting file](https://github.com/mudler/c3os/blob/master/files/system/oem/10_accounting.yaml)
+- [Example accounting file](https://github.com/rancher/elemental/blob/main/framework/files/system/oem/04_accounting.yaml)

docs/content/en/docs/Examples/embedded_images.md

@@ -405,7 +405,3 @@ Finally, we start k3s. Note, we could have tweaked that part slightly to provide
        - |
         chmod 600 /etc/systemd/system/k3s.service.env
 ```
-
-## References
-
-You can find the complete example [here](https://github.com/mudler/c3os) where this article was made from.

docs/content/en/docs/Reference/built_with_elemental.md

@@ -25,4 +25,4 @@ Open up an issue or create a PR to get yours added to the list!
 
 | Name      | Description                                                                                                     | Link                                   |
 |-----------|-----------------------------------------------------------------------------------------------------------------|----------------------------------------|
-| c3os      | Immutable OS for Automated (Decentralized) Kubernetes clusters with k3s, for homelab and beyond                 | https://github.com/c3os-io/c3os        |
+| Kairos    | Immutable OS for Automated (Decentralized) Kubernetes clusters with k3s, for homelab and beyond                 | https://github.com/kairos-io/kairos    |

packages/cos/setup.yaml

@@ -20,9 +20,9 @@ stages:
         NAME: ":BRANDING:"
         ID: ":BRANDING:"
         ANSI_COLOR: "0;32"
-        BUG_REPORT_URL: "https://github.com/mudler/cOS/issues"
-        HOME_URL: "https://github.com/mudler/cOS"
-        DOCUMENTATION_URL: "https://github.com/mudler/cOS"
+        BUG_REPORT_URL: "https://github.com/rancher/elemental-toolkit/issues"
+        HOME_URL: "https://github.com/rancher/elemental-toolkit"
+        DOCUMENTATION_URL: "https://github.com/rancher/elemental-toolkit"
         VERSION: ":VERSION:"
         PRETTY_NAME: ":PRETTY_NAME:"
-        GRUB_ENTRY_NAME: "cOS :VERSION:"
+        GRUB_ENTRY_NAME: "cOS :VERSION:"

packages/immutable-rootfs/README.md

@@ -2,7 +2,7 @@ This package ships the `immutable-rootfs` dracut module responsible of mounting
 boot time with the immutable specific setup. The immutability concept refers
 to read only root (`/`) system. To ensure the linux OS is still functional
 certain paths or areas are required to be writable, in those cases an
-ephemeral overlay tmpfs is set in place. Additionaly, the immutable rootfs
+ephemeral overlay tmpfs is set in place. Additionally, the immutable rootfs
 module can also mount a custom list of device blocks with read write
 permissions, those are mostly devoted to store persistent data.
 
@@ -22,7 +22,7 @@ before `initramfs` stage. So immutable rootfs configuration via cloud-init
 using the `/run/cos/cos-layout.env` file is only effective if called in any
 of the `rootfs.before`, `rootfs` or `rootfs.after` cloud-init stages.
 
-## Kernel configuraton paramters
+## Kernel configuration parameters
 
 The immutable rootfs can be configured with the following kernel parameters:
 
@@ -47,7 +47,7 @@ The immutable rootfs can be configured with the following kernel parameters:
   persistent block device labelled `COS_OEM` which is used to keep some
   configuration data (mostly cloud-init files). The immutable rootfs tries
   to mount this device at very early stages of the boot even before applying
-  the immutable rootfs configs. It done this way to enable to configure the
+  the immutable rootfs configs. It's done this way to enable to configure the
   immutable rootfs module within the cloud-init files. As the `COS_OEM` device
   might not be always present the boot process just continues without failing
   after a certain timeout. This option configures such a timeout. Defaults to
@@ -72,7 +72,7 @@ only effective if called in any of the `rootfs.before`, `rootfs` or
 `rootfs.after` cloud-init stages.
 
 
-In the environment file few options are available:
+In the environment file the following options are available:
 
 
 * `VOLUMES=LABEL=<blk_label>:<mountpoint>`: This variable expects a block device
@@ -108,17 +108,17 @@ In the environment file few options are available:
   `PERSISTENT_STATE_TARGET`. By default this variable is empty, which means
   no persistent state area is created or used.
 
-  **Note**: The specified paths needs either to exist or be located in an area 
+  **Note**: The specified paths needs to either exist or be located in an area 
             which is writeable ( for example, inside locations specified with `RW_PATHS`).
-            The dracut module will attempt to create non-existant directories, 
-            but might fail if the mountpoint where are located is read-only.
+            The dracut module will attempt to create nonexistent directories, 
+            but might fail if the mountpoint where they are located is read-only.
 
 * `PERSISTENT_STATE_BIND="true|false"`: When this variable is set to true
   the persistent state paths are bind mounted (instead of using overlayfs)
   after being mirrored with the original content. By default this variable is
   set to `false`.
 
-Note that persistent state are is setup once the ephemeral paths and persistent
+Note that persistent state is setup once the ephemeral paths and persistent
 volumes are mounted. Persistent state paths can't be an already existing mount
 point. If the persistent state requires any of the paths that are part of the
 ephemeral area by default, then `RW_PATHS` needs to be defined to avoid