DOC: Proofread files in the /installation directory (#1739)

* Proofread files

Proofread the following files in the /installation directory:
* image.rst
* index.rst
* secure-boot.rst
* update.rst

* Proofread install.rst

Add lastproofread dates to all files edited in this branch

* Fix table in install.rst

Fixed line length lint errors in:
* secure-boot.rst
* update.rst
* image.rst

1 files changed, 48 insertions, 40 deletions

diff --git a/docs/installation/secure-boot.rst b/docs/installation/secure-boot.rst
index b6685039..1dd6713b 100644
--- a/docs/installation/secure-boot.rst
+++ b/docs/installation/secure-boot.rst
@@ -1,12 +1,14 @@
+:lastproofread: 2026-01-26
+
 .. _secure_boot:
 
 ###########
 Secure Boot
 ###########
 
-Initial UEFI secure boot support is available (:vytask:`T861`). We utilize
-``shim`` from Debian 12 (Bookworm) which is properly signed by the UEFI
-SecureBoot key from Microsoft.
+Initial UEFI Secure Boot support is available (:vytask:`T861`). VyOS uses
+``shim`` from Debian 12 (Bookworm), which is properly signed by the UEFI
+Secure Boot key from Microsoft.
 
 .. note:: There is yet no signed version of ``shim`` for VyOS, thus we
    provide no signed image for secure boot yet. If you are interested in
@@ -39,13 +41,13 @@ Installation
 As our version of ``shim`` is not signed by Microsoft we need to enroll the
 previously generated :abbr:`MOK (Machine Owner Key)` to the system.
 
-First of all you will need to disable UEFI secure boot for the installation.
+First, disable UEFI Secure Boot for the installation.
 
 .. figure:: /_static/images/uefi_secureboot_01.png
    :alt: Disable UEFI secure boot
 
-Proceed with the regular VyOS :ref:`installation <permanent_installation>` on
-your system, but instead of the final ``reboot`` we will enroll the
+Proceed with the standard VyOS :ref:`installation <permanent_installation>` on
+your system. Instead of the final ``reboot`` command, enroll the
 :abbr:`MOK (Machine Owner Key)`.
 
 .. code-block:: none
@@ -54,8 +56,8 @@ your system, but instead of the final ``reboot`` we will enroll the
   input password:
   input password again:
 
-The requested ``input password`` can be user chosen and is only needed after
-rebooting the system into MOK Manager to permanently install the keys.
+You can set the ``input password`` to any value you choose. You'll need this
+password after reboot when MOK Manager launches to permanently install the keys.
 
 With the next reboot, MOK Manager will automatically launch
 
@@ -67,7 +69,7 @@ Select ``Enroll MOK``
 .. figure:: /_static/images/uefi_secureboot_03.png
    :alt: Disable UEFI secure boot
 
-You can now view the key to be installed and ``continue`` with the Key installation
+You can now view the key to be installed and continue with key installation.
 
 .. figure:: /_static/images/uefi_secureboot_04.png
    :alt: Disable UEFI secure boot
@@ -75,18 +77,18 @@ You can now view the key to be installed and ``continue`` with the Key installat
 .. figure:: /_static/images/uefi_secureboot_05.png
    :alt: Disable UEFI secure boot
 
-Now you will need the password previously defined
+Now you need to enter the password you defined previously.
 
 .. figure:: /_static/images/uefi_secureboot_06.png
    :alt: Disable UEFI secure boot
 
-Now reboot and re-enable UEFI secure boot.
+Now reboot and re-enable UEFI Secure Boot.
 
 .. figure:: /_static/images/uefi_secureboot_07.png
    :alt: Disable UEFI secure boot
 
-VyOS will now launch in UEFI secure boot mode. This can be double-checked by running
-either one of the commands:
+VyOS will now launch in UEFI Secure Boot mode. You can verify this by running
+one of the following commands:
 
 .. code-block:: none
 
@@ -126,18 +128,17 @@ either one of the commands:
 Image Update
 ************
 
-.. note:: There is yet no signed version of ``shim`` for VyOS, thus we
-   provide no signed image for secure boot yet. If you are interested in
-   secure boot you can build an image on your own.
+.. note:: Currently, there is no signed version of ``shim`` for VyOS. If you
+   want Secure Boot support, you can build a custom image with your own keys.
 
-During image installation you will install your :abbr:`MOK (Machine Owner
-Key)` into the UEFI variables to add trust to this key. After enabling
-secure boot support in UEFI again, you can only boot into your signed image.
+During image installation, you install your :abbr:`MOK (Machine Owner Key)`
+into the UEFI variables to add trust to this key. After you re-enable Secure
+Boot in UEFI, you can only boot into your signed image.
 
-It is no longer possible to boot into a CI generated rolling release as those
-are currently not signed by a trusted party (:vytask:`T861` work in progress).
-This also means that you need to sign all your successor builds you build on
-your own with the exact same key, otherwise you will see:
+You can no longer boot into a CI-generated rolling release because those
+are not signed by a trusted party (:vytask:`T861` work in progress). This
+also means you must sign all successor builds with the same key; otherwise,
+you'll see this error:
 
 .. code-block:: none
 
@@ -148,37 +149,44 @@ your own with the exact same key, otherwise you will see:
 Linux Kernel
 ************
 
-In order to add an additional layer of security that can already be used in nonesecure
-boot images already is ephem,eral key signing of the Linux Kernel modules.
+In addition to Secure Boot support, VyOS uses ephemeral key signing of Linux
+Kernel modules for an extra security layer in both Secure and non-Secure boot
+images.
+
+.. stop_vyoslinter
 
 https://patchwork.kernel.org/project/linux-integrity/patch/20210218220011.67625-5-nayna@linux.ibm.com/
 
-Whenever our CI system builds a Kernel package and the required 3rd party modules,
-we will generate a temporary (ephemeral) public/private key-pair that's used for signing the
-modules. The public key portion is embedded into the Kernel binary to verify the loaded
-modules.
+.. start_vyoslinter
+
+When the CI system builds a Kernel package and required third-party modules,
+it generates a temporary (ephemeral) key pair for signing the modules. The
+public key is embedded in the Kernel binary to verify loaded modules.
 
-After the Kernel CI build completes, the generated key is discarded - meaning we can no londer
-sign additional modules with out key. Our Kernel configuration also contains the option
-``CONFIG_MODULE_SIG_FORCE=y`` which means that we enforce all modules to be signed. If you
-try to load an unsigned module, it will be rejected with the following error:
+After the Kernel CI build completes, the generated key is discarded, meaning
+we can no longer sign additional modules with that key. The Kernel configuration
+also includes the option ``CONFIG_MODULE_SIG_FORCE=y``, which enforces signature
+verification for all modules. If you try to load an unsigned module, you'll
+get this error:
 
-``insmod: ERROR: could not insert module malicious.ko: Key was rejected by service``
+``insmod: ERROR: could not insert module malicious.ko: Key was rejected by
+service``
 
-Thos we close the door to load any malicious stuff after the image was assembled into the
-Kernel as module. You can of course disable this behavior on custom builds.
+This prevents loading any malicious code after the image is assembled into the
+Kernel as a module. You can disable this behavior on custom builds if needed.
 
 ************
 Troubleshoot
 ************
 
-In most of the cases if something goes wrong you will see the following error message
-during system boot:
+In most cases, if something goes wrong during system boot, you'll see this
+error message:
 
 .. code-block:: none
 
   error: bad shim signature
   error: you need to load the kernel first
 
-This means that the Machine Owner Key used to sign the Kernel is not trusted by your
-UEFI. You need to install the MOK via ``install mok`` as stated above.
+This error means the Machine Owner Key used to sign the Kernel is not trusted
+by your UEFI. Install the MOK using the ``install mok`` command as described
+above.