Markdown linting

Signed-off-by: GitHub <noreply@github.com>

Author: mikehaller

.markdownlint.json

@@ -0,0 +1,6 @@
+{
+    "MD033": false,
+    "MD013": {
+        "line_length": 160
+    }
+}

content/en/docs/device-provisioning/container-management/_index.md

@@ -30,11 +30,13 @@ When one of the cloud connector components, such as leda-contrib-cloud-connector
     - `namespace` is `azure.edge` for Kanto's Azure Cloud Connector
     - `gatewayId` indicates the hostname of the Azure IoT Hub
     - `deviceId` is the identifier for the device, this can either be part of the Azure Connection String or part of the device authentication certificate (CN)
-    - `<tenantId>` is a configuration setting in the cloud connector
+    - `tenantId` is a configuration setting in the cloud connector
 
     > **Note:** You can simulate the cloud connector trigger by issueing the MQTT message manually on command line:
-    
-        mosquitto_pub -t 'edge/thing/response' -m '{"deviceId":"dummy-namespace:dummy-gateway:dummy-device-id","tenantId":"dummy-tenant-id"}'
+
+    ```shell
+    mosquitto_pub -t 'edge/thing/response' -m '{"deviceId":"dummy-namespace:dummy-gateway:dummy-device-id","tenantId":"dummy-tenant-id"}'
+    ```
 
 3. Container Management responds with a list of containers in the topic `e/<tenantId>/<gatewayId>:<deviceId>:edge:containers`
 
@@ -84,6 +86,7 @@ When one of the cloud connector components, such as leda-contrib-cloud-connector
         }
     }
     ```
+
 4. Container Management answers with an additional message for each container in the topic `e/<tenantId>/<gatewayId>:<deviceId>:edge:containers`
 
     ```json

content/en/docs/device-provisioning/self-update/rauc-integration.md

@@ -10,11 +10,13 @@ Leda integrates [RAUC](https://rauc.io/) as a reference implementation and examp
 
 Get the current RAUC boot status:
 
-    rauc status
-
+```shell
+rauc status
+```
 
 Example output:
-```
+
+```shell
 root@qemux86-64:~# rauc status
 === System Info ===
 Compatible:  Eclipse Leda qemu86-64
@@ -40,7 +42,7 @@ x [rootfs.0] (/dev/sda4, ext4, booted)
 
 To manually force the device to boot into another slot, mark the current booted slot as *bad*, mark the other partitions as *active* and perform a reboot:
 
-```
+```shell
 rauc status mark-bad booted
 rauc status mark-active other
 reboot now
@@ -50,14 +52,15 @@ reboot now
 
 By marking both root slots as bad, the bootloader is supposed to boot the rescue system:
 
-```
+```shell
 rauc status mark-bad rootfs.0
 rauc status mark-bad rootfs.1
 reboot now
 ```
 
 Example output of rauc:
-```
+
+```shell
 o [rootfs.1] (/dev/sda5, ext4, inactive)
         bootname: B
         boot status: bad
@@ -78,10 +81,11 @@ The configurations can be customized by applying or patching the following files
 
 ## RAUC System Configuration
 
-The [RAUC System Configuration ](https://rauc.readthedocs.io/en/latest/integration.html#rauc-system-configuration) is the central configuration of the RAUC Update system.
+The [RAUC System Configuration](https://rauc.readthedocs.io/en/latest/integration.html#rauc-system-configuration) is the central configuration of the RAUC Update system.
 
 Example:
-```
+
+```shell
 [system]
 compatible=Eclipse Leda qemu86-64
 bootloader=grub
@@ -120,7 +124,8 @@ The GRUB bootloader has a configuration file which describes which partitions ar
 The configuration also contains **RAUC specific logic and variables required for a proper integration**. Please see the full `grub.cfg` in the source repository and [RAUC Documentation - Integration - GRUB](https://rauc.readthedocs.io/en/latest/integration.html#grub) for details.
 
 Excerpt:
-```
+
+```text
 ...
 
 menuentry "SDV Slot A (OK=$SDV_A_OK TRY=$SDV_A_TRY)" {
@@ -152,8 +157,9 @@ These disk images are machine specific and the structure of the partitions are c
 
 ### Excerpt `qemux86-grub-efi.wks`
 
-*Note: The excerpt is exemplary, please see the sources for a full representation and documentation.* 
-```
+*Note: The excerpt is exemplary, please see the sources for a full representation and documentation.*
+
+```text
 bootloader --ptable gpt
 
 part --fixed-size 50M --source rawcopy --sourceparams="file=efi-boot.vfat" --fstype=vfat --label boot --active

content/en/docs/device-provisioning/self-update/self-update-tutorial.md

@@ -6,31 +6,41 @@ weight: 1
 
 This chapter describes the steps necessary to perform a local (without cloud) self update of the operating system.
 
-![](../self-update-arch.png)
+![Self Update Architecture](../self-update-arch.png)
 
 ## Self-Update using RAUC Update Bundles
 
 - On host: Update bundle `sdv-rauc-bundle-qemux86-64.raucb` is in current folder
 
-  *Note: In the development environment, the update RAUC Update Bundle is located in the BitBake machine-specific output folder, for example `tmp/deploy/images/qemux86-64`*
+  *Note: In the development environment, the update RAUC Update Bundle is located in the BitBake machine-specific output folder
+  Example location is `tmp/deploy/images/qemux86-64`*
+
 - On host: Start a dummy web server for serving the update file
 
-      python3 -m http.server --bind 192.168.7.1
+  ```shell
+  python3 -m http.server --bind 192.168.7.1
+  ```
 
 - On host: open two new terminals - one for monitoring and one for triggering the self-update
 
-   - Terminal 1: To view the progress, watch the MQTT topics `selfupdate/desiredstate` and `selfupdate/desiredstatefeedback`:
+  - Terminal 1: To view the progress, watch the MQTT topics `selfupdate/desiredstate` and `selfupdate/desiredstatefeedback`:
 
-         mosquitto_sub -h 192.168.7.2 -p 1883 -t "selfupdate/#"
+      ```shell
+      mosquitto_sub -h 192.168.7.2 -p 1883 -t "selfupdate/#"
+      ```
 
-   - Terminal 2: Trigger the actual self update process by publishing an MQTT message to `selfupdate/desiredstate`:
+  - Terminal 2: Trigger the actual self update process by publishing an MQTT message to `selfupdate/desiredstate`:
 
-         mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate" -f start-update-example.json
+      ```shell
+      mosquitto_pub -h 192.168.7.2 -p 1883 -t "selfupdate/desiredstate" -f start-update-example.json
+      ```
 
 - Switch to a terminal in the guest
 - On guest: After the self update process completed, check the status:
 
-      rauc status --detailed
+  ```shell
+  rauc status --detailed
+  ```
 
 ## Self-Update Trigger Message
 
@@ -45,6 +55,7 @@ This chapter describes the steps necessary to perform a local (without cloud) se
 1. Initial response message on startup from self update agent in topic `selfupdate/currentstate`, or upon request by sending message to `selfupdate/currentstate/get`
 
       Request:
+
       ```json
       {
             "activityId": "<uuid>",
@@ -53,6 +64,7 @@ This chapter describes the steps necessary to perform a local (without cloud) se
       ```
 
       Response:
+
       ```json
       {
             "activityId": "<uuid>",
@@ -73,7 +85,6 @@ This chapter describes the steps necessary to perform a local (without cloud) se
       }
       ```
 
-
 ### Desired State
 
 1. External trigger to update via desired state on topic `selfupdate/desiredstate`:
@@ -212,4 +223,4 @@ This chapter describes the steps necessary to perform a local (without cloud) se
                   ]
             }
       }
-      ```
+      ```