diff --git a/www/docs/bakery/devices/raspberry-pi.md b/www/docs/bakery/devices/raspberry-pi.md index 2cd5945..cccb99b 100644 --- a/www/docs/bakery/devices/raspberry-pi.md +++ b/www/docs/bakery/devices/raspberry-pi.md @@ -16,7 +16,7 @@ Here is an overview over all the supported Raspberry Pi models: [^1]: Requires the U-Boot boot flow. -**⚠️ Please also read the remarks for the respective boards bellow.** +**⚠️ Please also read the remarks for the respective boards below.** Raspberry Pi OS releases based on Debian Bullseye and Bookworm are supported. diff --git a/www/docs/bakery/index.md b/www/docs/bakery/index.md index 4c2ce65..45bce25 100644 --- a/www/docs/bakery/index.md +++ b/www/docs/bakery/index.md @@ -2,7 +2,9 @@ _Rugix Bakery_ is a flexible, user-friendly build system for bespoke Linux distributions. It enables you to build customized variants of binary distributions, such as [Debian](https://debian.org/) and [Alpine Linux](https://alpinelinux.org/), or to build distributions entirely from source, leveraging industry standards like the [Yocto Project](https://www.yoctoproject.org/). While inherently flexible and not tied to any specific distribution, Rugix Bakery ships with ready-to-use integrations for Debian, Alpine Linux, Raspberry Pi OS, and the Yocto Project's Poky reference distribution. -Typically, Rugix Bakery is used to build _full system images_ and Rugix Ctrl _update bundles_ for OTA system updates. System images generally contain a complete Linux root filesystem, a Linux kernel, and other, additional files required for booting a system. For [supported devices](/devices), Rugix Bakery can build bootable images that are ready to be flashed onto a device out of the box. Rugix Bakery allows you to declare multiple system images and other _build artifacts_[^1], while partially sharing build configurations and outputs between them. This feature is particularly useful when building different variants of an image for different devices that share a common base. +Typically, Rugix Bakery is used to build _full system images_ and Rugix Ctrl _update bundles_ for OTA system updates. System images generally contain a complete Linux root filesystem, a Linux kernel, and other, additional files required for booting a system. For [supported devices](/devices), Rugix Bakery can build bootable images that are ready to be flashed onto a device out of the box. Rugix Bakery allows you to declare multiple system images and other _build artifacts_[^build-artifacts], while partially sharing build configurations and outputs between them. This feature is particularly useful when building different variants of an image for different devices that share a common base. + +[^build-artifacts]: For example, individual filesystems, documentation, or a _software bill of materials_ (SBOM). ## Setup and Installation @@ -30,14 +32,19 @@ If you run `./run-bakery help` you should get usage instructions for Rugix Baker The shell script will also pin your project to a specific major version of Rugix Bakery thereby preventing breaking changes from breaking your build. By setting the `RUGIX_BAKERY_IMAGE` environment variable you can also pin Rugix Bakery to a specific Docker image. This adds an additional layer of protection against breaking changes and of security should the Rugix Bakery repository be compromised. For production setups, it is therefore recommended to always pin Rugix Bakery to a specific Docker image. -Rugix Bakery currently requires the container to run in privileged mode such that `chroot` and bind mounts are available within the container. These are required to run tools inside an environment that looks like the final system. In the future, we plan to leverage Linux user namespaces to isolate the build and the system from the host without requiring elevated privileges. +Rugix Bakery currently requires the container to run in privileged mode such that `chroot` and bind mounts are available within the container. These are required to run tools inside an environment that looks like the final system. In the future, we plan to leverage Linux user namespaces to isolate the build and the system from the host without requiring elevated privileges.[^privileges] + +[^privileges]: Existing tools use different approaches to set up an environment that looks like the final system without requiring privileges. For instance, Yocto uses a tool called [Pseudo](https://git.yoctoproject.org/pseudo/about/) (an alternative to the better-known tool [Fakeroot](https://manpages.debian.org/bookworm/pseudo/fakeroot.1.en.html)), to intercepts calls to system APIs via `LD_PRELOAD` and thereby fake a root environment. This approach has limitations, for instance, it does not work with statically-linked binaries and also does not allow starting services binding sockets to ports below 1024. Rugix Bakery strives to provide a container-like environment by using Linux namespaces and process isolation which does not suffer from the same limitations as existing approaches and thereby mimics a real system more closely. ## Build Process: High-Level Introduction Before we get into further details, let’s first look at Rugix Bakery’s build process from a high-level perspective. -The build process revolves around two key concepts: _layers_ and _recipes_. A _layer_ consists of the _build outputs_ of a specific stage of the build process. Typically, a layer provides a root filesystem and a kernel for a system. Layers can be built on top of each other, thereby reusing and extending an existing root filesystem as well as any other build outputs that are part of the previous layer. In that regard, layers are akin to image layers in Docker.[^2] A _recipe_ describes additions and modifications to be made to a layer. A layer is then built by applying the recipes specified in the layer's build configuration, optionally using a _parent layer_ as a base. +The build process revolves around two key concepts: _layers_ and _recipes_. A _layer_ consists of the _build outputs_ of a specific stage of the build process. Typically, a layer provides a root filesystem and a kernel for a system. Layers can be built on top of each other, thereby reusing and extending an existing root filesystem as well as any other build outputs that are part of the previous layer. In that regard, layers are akin to image layers in Docker.[^yocto-layers] A _recipe_ describes additions and modifications to be made to a layer. A layer is then built by applying the recipes specified in the layer's build configuration, optionally using a _parent layer_ as a base. + +[^yocto-layers]: If you are coming from Yocto, Rugix Bakery layers are distinct from Yocto layers in that they contain actual _build outputs_ while Yocto layers add or modify _build metadata and configurations_ used by the build system. + Here is a summary of the core concepts of the build process: @@ -50,7 +57,7 @@ Here is a summary of the core concepts of the build process: Rugix Bakery implements a build process that generates build artifacts from layers created by executing recipes. **Example: Two Device Variants.** -Assume you have an application that you want to integrate into a Debian-based system and then deploy to two different device variants. In Rugix Bakery, you would define a layer for your application building upon a Debian parent layer. The device-specific modifications will then be realized by a layer per device variant using the application layer as a parent. Finally Rugix Bakery will generate a full system image for initial provisioning and a Rugix Ctrl update bundle for each variant, respectively. The figure bellow shows the corresponding build tree with the final build artifacts at the bottom. +Assume you have an application that you want to integrate into a Debian-based system and then deploy to two different device variants. In Rugix Bakery, you would define a layer for your application building upon a Debian parent layer. The device-specific modifications will then be realized by a layer per device variant using the application layer as a parent. Finally Rugix Bakery will generate a full system image for initial provisioning and a Rugix Ctrl update bundle for each variant, respectively. The figure below shows the corresponding build tree with the final build artifacts at the bottom.

```mermaid @@ -75,10 +82,6 @@ If you are using Rugix Bakery with Yocto, then the entire Yocto build for a give ::: **Building from Source.** -While Rugix Bakery can be used to build applications from source as part of the build process, its primary use case is to assemble pre-built components into a full system. It is completely fine to use Rugix Bakery as a final phase of a larger build pipeline, building binaries and other parts of your application with external tools and then injecting them into a Rugix Bakery build. While building everything from source in a coherent system like Yocto has some advantages, it also introduces a lot of complexity and overhead that may not be worthwhile for every project.[^3] Rugix Bakery's central strength lies in its ability to exploit the stability, familiarity, and the maintenance effort that goes into proven binary distributions like Debian, thereby lowering the entry barrier and required resources to build rock-solid software distributions for embedded and IoT devices, or anywhere a custom Linux OS is needed. - - -[^1]: For example, individual filesystems, documentation, or a _software bill of materials_ (SBOM). -[^2]: If you are coming from Yocto, Rugix Bakery layers are distinct from Yocto layers in that they contain actual _build outputs_ while Yocto layers add or modify _build metadata and configurations_ used by the build system. -[^3]: Often, reproducibility, license compliance, and fine-grained control of compile-time options are cited as reasons for using Yocto over Debian, however, (1) not only can [most Debian packages be built 100% reproducibly](https://tests.reproducible-builds.org/debian/reproducible.html) but [Debian snapshots](https://snapshot.debian.org/) dating back to 2005 also provide a way to build Debian-based systems fully reproducibly, (2) all Debian packages come with license information that can be used to generate an SBOM and ensure compliance, and (3) the exact sources for all Debian packages are available and can be used to build custom variants of these packages, e.g., with fine-tuned compile-time options. That being said there are many other good reasons for using Yocto, e.g., when you are using a device for which the manufacturer provides a board support package but no support for a binary distribution like Debian. Whether or not the advantages of Yocto are worth the added complexity and required engineering resources should be evaluated based on the requirements of a project. +While Rugix Bakery can be used to build applications from source as part of the build process, its primary use case is to assemble pre-built components into a full system. It is completely fine to use Rugix Bakery as a final phase of a larger build pipeline, building binaries and other parts of your application with external tools and then injecting them into a Rugix Bakery build. While building everything from source in a coherent system like Yocto has some advantages, it also introduces a lot of complexity and overhead that may not be worthwhile for every project.[^yocto-reasons] Rugix Bakery's central strength lies in its ability to exploit the stability, familiarity, and the maintenance effort that goes into proven binary distributions like Debian, thereby lowering the entry barrier and required resources to build rock-solid software distributions for embedded and IoT devices, or anywhere a custom Linux OS is needed. +[^yocto-reasons]: Often, reproducibility, license compliance, and fine-grained control of compile-time options are cited as reasons for using Yocto over Debian, however, (1) not only can [most Debian packages be built 100% reproducibly](https://tests.reproducible-builds.org/debian/reproducible.html) but [Debian snapshots](https://snapshot.debian.org/) dating back to 2005 also provide a way to build Debian-based systems fully reproducibly, (2) all Debian packages come with license information that can be used to generate an SBOM and ensure compliance, and (3) the exact sources for all Debian packages are available and can be used to build custom variants of these packages, e.g., with fine-tuned compile-time options. That being said there are many other good reasons for using Yocto, e.g., when you are using a device for which the manufacturer provides a board support package but no support for a binary distribution like Debian. Whether or not the advantages of Yocto are worth the added complexity and required engineering resources should be evaluated based on the requirements of a project. diff --git a/www/docs/bakery/layers.mdx b/www/docs/bakery/layers.mdx index fa317ed..7136e1d 100644 --- a/www/docs/bakery/layers.mdx +++ b/www/docs/bakery/layers.mdx @@ -81,7 +81,7 @@ url = "https://downloads.raspberrypi.com/raspios_lite_arm64/images/raspios_lite_ Rugix Bakery can download images and TAR archives from HTTP URLs and create layers from them. This is useful if one wants to take an existing system image as a basis, e.g., when building a customized variant of Raspberry Pi OS. In addition to HTTP URLs, file URLs starting with `file://` are also supported. These URLs are resolved relative to the project directory. :::tip -You can use this to import a root filesystem built with an external tool, e.g., [Buildroot](https://buildroot.org/). +You can use this to import a root filesystem built with an external tool, e.g., [Buildroot](https://buildroot.org/) or [Yocto](https://www.yoctoproject.org/). ::: Note that imported layers must not specify any recipes. Customizations are applied by using them as a parent. @@ -92,13 +92,15 @@ Note that imported layers must not specify any recipes. Customizations are appli Recipes may depend on other recipes and as such will pull in their dependencies automatically when specified in the `recipes` list of a layer. To avoid that, e.g., when you want to replace some recipe with a local variant, you can exclude certain recipes from a layer. To this end, you can provide a list of recipes to exclude via the `exclude` property. -## Layer Configuration +## Configuration Reference -For reference, here is the complete schema for project configuration files: +For reference, here is the complete schema for layer configuration files: }}/> +You will find the most recent version of this schema [on GitHub](https://github.com/silitics/rugix/blob/main/schemas/rugix-bakery-layer.schema.json). + [^1]: The layer should be fully reproducible, however, Rugix Bakery does currently not support building images reproducibly. We will add this functionality in the future such that images can be reproduced bit-by-bit. \ No newline at end of file diff --git a/www/docs/bakery/projects.mdx b/www/docs/bakery/projects.mdx index 388689c..419e631 100644 --- a/www/docs/bakery/projects.mdx +++ b/www/docs/bakery/projects.mdx @@ -46,8 +46,6 @@ architecture = "arm64" The `#:schema` directive is used to specify a [JSON Schema](https://json-schema.org/) for the TOML file. Rugix Bakery comes with JSON Schemas for all its configuration files, enabling easy validation and autocompletion in modern IDEs. -#### Configuration Reference - For reference, here is the complete schema for project configuration files: ` in the `recipes` directory. +As part of the build process, recipes perform the actual work, creating and modifying build outputs. Each recipe consists of a sequence of _steps_ to be executed. Recipes are defined by directories in the `recipes` directory. Each recipe gets its own directory with a _recipe configuration_ file `recipe.toml` and a `steps` subdirectory defining the individual steps to be executed. The configuration file may specify a *description*, a *priority*, *dependencies* of the recipe, and *parameters*. -At the top-level of the layer configuration, the recipes to enable are specified as a list: +Here is the configuration of the [`core/ssh`](https://github.com/silitics/rugpi/blob/main/bakery/repositories/core/recipes/ssh) recipe as an example: -```toml title=".toml" -recipes = [...] -``` -To exclude specific recipes, use the `exclude` directive: +```toml title="recipes/hello-world/recipe.toml" +#:schema https://raw.githubusercontent.com/silitics/rugix/refs/tags/v0.8.0/schemas/rugix-bakery-layer.schema.json -```toml -exclude = [...] +description = "enabling SSH" +priority = 80_000 +dependencies = ["pkg-update"] + +[parameters] +root_authorized_keys = { default = "" } ``` -A recipe describes modifications to be done to the system. -Rugpi Bakery comes with a set of [core recipes](https://github.com/silitics/rugpi/tree/main/bakery/repositories/core/recipes) which you can use. +The `ssh` recipe depends on the [`pkg-update` recipe](https://github.com/silitics/rugpi/tree/main/bakery/repositories/core/recipes/pkg-update)[^pkg-update-ref] from Rugix Bakery's `core` repository. The `pkg-update` recipe will update the package lists of the distribution (Debian or Alpine), which is required to be able to install SSH. It will also later remove the package lists from the build, as they are unnecessary at runtime. The configuration further defines a parameter, `root_authorized_keys`, with an empty _default value_. The steps of the recipe use this parameter to install public keys for SSH access. + +[^pkg-update-ref]: The recipe is referenced as `pkg-update` and not `core/pkg-update` here because the `ssh` is itself in `core`. + +Recipes are always applied in the order of their priority (higher means earlier). In particular, this means that dependencies may be applied _after_ recipes that depend on them, if they have a lower priority. Note that priorities can also be negative. -Each recipe has its own directory with a `recipe.toml` configuration file. -Recipes may have a `description`, a `priority`, and `dependencies`. -Checkout the builtin recipes for examples. -Recipes are always applied in the order of their priority. -In particular, `dependencies` are not guaranteed to be applied before the recipes that depend on them. +Check out the set of [core recipes](https://github.com/silitics/rugpi/tree/main/bakery/repositories/core/recipes) for examples. -### Parameters -Recipes can have _parameters_. -Parameters are defined in the `parameters` section of `recipe.toml`: +## Parameters + +The parameters of a recipe are defined in the `parameters` section of its configuration. Every parameter has a name and an optional default value. Here is an example for how to define parameters with and without default values: ```toml [parameters] @@ -43,17 +44,22 @@ parameter_name = { default = "a default value" } other_parameter = {} # Required parameter without a default value. ``` -They are exposed to steps (see bellow) in environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. +Parameter values are provided by layer configurations in the `parameters` section. For the details, we refer back to the [layers section](./layers.mdx) of this documentation. Layer configurations must provide values for all parameters that do not have a default. + +Parameter values are exposed to a recipe's steps (see below) via environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. + +:::tip +Avoid hard-coding configuration values in your recipes and use parameters instead. +::: -Parameters are set as part of the layer configuration. -### Steps +## Steps -A step is defined by a file in the `steps` directory of the recipe. -The filename must start with an integer followed by a `-` and the _step kind_. -The integer indicates the position of the step in the recipe, e.g., `00` to `99`. +Each recipe consists of a sequence of steps to be executed. Each step is defined by a file in the `steps` directory of a recipe. The names of the files in that directory must start with an integer followed by a `-` and a _step kind_. The integer indicates the position of the step in the recipe, e.g., `00` to `99`. Currently, Rugix Bakery supports three kinds of steps. -There are three kinds of steps. +#### `packages` + +Steps of the kind `packages` can be used to provide lists of packages to install: ```plain title="XX-packages" a @@ -62,36 +68,68 @@ of packages ``` +Rugix Bakery supports APT (Debian) and APK (Alpine) and will automatically select the correct package manager for a given system. The step filenames can also be suffixed with `.apt` and `.apk` to provide different package lists for APT and APK. + +#### `run` + +Steps of the kind `run` can be used to run scripts on the host/within the build environment: + ```bash title="XX-run.*" #!/usr/bin/env bash echo "This runs on the host system." ``` +These scripts are not limited to bash and can have an arbitrary file extension, e.g., `.py` for Python scripts. They must have a shebang (first line starting with `#!`) and must have the executable bit set (`chmod +x`). + +Rugix Bakery exposes multiple environment variables that can be used in such scripts. You will find more details below. + +:::note +When using `run` steps, you have to be a bit careful to not modify the build environment itself. For instance, when you install files or packages into the build environment, then they may persist and affect later steps.[^run-isolation] +::: + +[^run-isolation]: We plan to provide better isolation for `run` steps in the future. + +You can use `run` steps to perform all kinds of tasks. For instance, the [`yocto-build` recipe of the Yocto template](https://github.com/silitics/rugpi/tree/main/bakery/templates/yocto-grub-efi/recipes/yocto-build) sets up a temporary Python virtual environment to install [KAS](https://github.com/siemens/kas) and will then run an entire Yocto build via KAS. + +#### `install` + +Steps of the kind `install` can be used to run scripts inside the system being built: + + ```bash title="XXX-install.*" #!/usr/bin/env bash echo "This runs via chroot in the system being built." ``` -Note that `run` and `install` are not limited to Bash scripts. +Rugix Bakery will set up a semi-isolated environment (similar to a container) that mimics the system being built. It will then run the script inside that environment as the `root` user. The same considerations as for `run` steps apply analogously. -You can also use `XX-packages.apk` and and `XX-packages.apt` to install different packages depending on whether the recipe is used to build an Alpine Linux or Debian based system. +:::tip +You can use `install` steps to customize a system in the same way you normally would when you set up a system and perform customizations manually via a local shell. For instance, you can install packages or enable certain system services. Note that services will not run when executing a `run` step, you can, however, [start them as part of the step](./advanced/services.md). +::: ### Environment Variables -When running steps, the following environment variables are set. +Rugix Bakery will expose the following environment variables when running steps: -- `RUGPI_ARCH`: The architecture of the build (`arm64` or `armhf`). -- `RUGPI_ROOT_DIR`: The directory of the root filesystem. -- `RUGPI_PROJECT_DIR`: The directory of the Rugpi Bakery project. -- `RUGPI_BUNDLE_DIR`: The directory of the Rugpi Bundle being built. -- `RECIPE_DIR`: The directory of the recipe which is applied. -- `RECIPE_STEP_PATH`: The path of the step being executed. +- `RUGPI_ARCH`: Architecture of the build (`arm64` or `armhf`). +- `RUGPI_ROOT_DIR`: Directory of the root filesystem. +- `RUGPI_PROJECT_DIR`: Directory of the Rugpi Bakery project. +- `RUGPI_BUNDLE_DIR`: Directory of the layer being built. +- `RUGIX_CACHE_DIR`: Directory for global caching. +- `RECIPE_DIR`: Directory of the recipe which is applied. +- `RECIPE_STEP_PATH`: Path of the step being executed. + +In addition, the recipe parameters are exposed as explained above. ## Configuration Reference +For reference, here is the complete schema for recipe configuration files: + }}/> + +You will find the most recent version of this schema [on GitHub](https://github.com/silitics/rugix/blob/main/schemas/rugix-bakery-recipe.schema.json). diff --git a/www/docs/ctrl/over-the-air-updates.md b/www/docs/ctrl/over-the-air-updates.md index 9ad24d6..5c34164 100644 --- a/www/docs/ctrl/over-the-air-updates.md +++ b/www/docs/ctrl/over-the-air-updates.md @@ -103,7 +103,7 @@ To prevent breaking the system, it is impossible to make the cold set the defaul Committing an update is up to the concrete update workflow of the application. If you want to automatically commit the hot set during the boot process, you may enable the `rugpi-auto-commit` recipe. -Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see bellow). +Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see below). [^3]: Using the `rugpi-ctrl` command line tool. diff --git a/www/versioned_docs/version-0.6/guide/over-the-air-updates.md b/www/versioned_docs/version-0.6/guide/over-the-air-updates.md index 85c445b..ab71378 100644 --- a/www/versioned_docs/version-0.6/guide/over-the-air-updates.md +++ b/www/versioned_docs/version-0.6/guide/over-the-air-updates.md @@ -103,7 +103,7 @@ To prevent breaking the system, it is impossible to make the cold set the defaul Committing an update is up to the concrete update workflow of the application. If you want to automatically commit the hot set during the boot process, you may enable the `rugpi-auto-commit` recipe. -Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see bellow). +Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see below). [^3]: Using the `rugpi-ctrl` command line tool. diff --git a/www/versioned_docs/version-0.6/guide/supported-boards.md b/www/versioned_docs/version-0.6/guide/supported-boards.md index a417448..8b22020 100644 --- a/www/versioned_docs/version-0.6/guide/supported-boards.md +++ b/www/versioned_docs/version-0.6/guide/supported-boards.md @@ -18,7 +18,7 @@ Here is an overview over all the supported Raspberry Pi models: [^1]: Requires the U-Boot boot flow. -**⚠️ Please also read the remarks for the respective boards bellow.** +**⚠️ Please also read the remarks for the respective boards below.** Raspberry Pi OS releases based on Debian Bullseye and Bookworm are supported. @@ -38,7 +38,7 @@ Make sure that the binaries you install are compatible with the `armv6l` archite ### Raspberry Pi 5 If you are using the quick-start template, please use the `tryboot` image. -The `pi4` image is not compatible with Raspberry Pi 5 as it includes a bootloader update for Raspberry Pi 4 (see bellow). +The `pi4` image is not compatible with Raspberry Pi 5 as it includes a bootloader update for Raspberry Pi 4 (see below). Updating the bootloader is not necessary for Raspberry Pi 5, as it already comes with the `tryboot` feature out-of-the-box. ### Raspberry Pi 4 and Compute Module 4 diff --git a/www/versioned_docs/version-0.6/guide/system-customization.md b/www/versioned_docs/version-0.6/guide/system-customization.md index fefff85..2e3e9ab 100644 --- a/www/versioned_docs/version-0.6/guide/system-customization.md +++ b/www/versioned_docs/version-0.6/guide/system-customization.md @@ -66,7 +66,7 @@ parameter_name = { default = "a default value" } other_parameter = {} # Required parameter without a default value. ``` -They are exposed to steps (see bellow) in environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. +They are exposed to steps (see below) in environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. ### Steps diff --git a/www/versioned_docs/version-0.7.5/advanced/raspberry-pi.md b/www/versioned_docs/version-0.7.5/advanced/raspberry-pi.md index 2cd5945..cccb99b 100644 --- a/www/versioned_docs/version-0.7.5/advanced/raspberry-pi.md +++ b/www/versioned_docs/version-0.7.5/advanced/raspberry-pi.md @@ -16,7 +16,7 @@ Here is an overview over all the supported Raspberry Pi models: [^1]: Requires the U-Boot boot flow. -**⚠️ Please also read the remarks for the respective boards bellow.** +**⚠️ Please also read the remarks for the respective boards below.** Raspberry Pi OS releases based on Debian Bullseye and Bookworm are supported. diff --git a/www/versioned_docs/version-0.7.5/guide/over-the-air-updates.md b/www/versioned_docs/version-0.7.5/guide/over-the-air-updates.md index 9ad24d6..5c34164 100644 --- a/www/versioned_docs/version-0.7.5/guide/over-the-air-updates.md +++ b/www/versioned_docs/version-0.7.5/guide/over-the-air-updates.md @@ -103,7 +103,7 @@ To prevent breaking the system, it is impossible to make the cold set the defaul Committing an update is up to the concrete update workflow of the application. If you want to automatically commit the hot set during the boot process, you may enable the `rugpi-auto-commit` recipe. -Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see bellow). +Note that this recipe installs an equally named Systemd service which will also commit an old version if booted into with the rollback feature (see below). [^3]: Using the `rugpi-ctrl` command line tool. diff --git a/www/versioned_docs/version-0.7.5/guide/system-customization.md b/www/versioned_docs/version-0.7.5/guide/system-customization.md index d6bf5e1..ea30bde 100644 --- a/www/versioned_docs/version-0.7.5/guide/system-customization.md +++ b/www/versioned_docs/version-0.7.5/guide/system-customization.md @@ -89,7 +89,7 @@ parameter_name = { default = "a default value" } other_parameter = {} # Required parameter without a default value. ``` -They are exposed to steps (see bellow) in environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. +They are exposed to steps (see below) in environment variables of the form `RECIPE_PARAM_`. So, in case of our example, `RECIPE_PARAM_PARAMETER_NAME` and `RECIPE_PARAM_OTHER_PARAMETER`. Parameters are set as part of the layer configuration.