diff options
Diffstat (limited to 'nixos/doc/manual/development')
5 files changed, 42 insertions, 5 deletions
diff --git a/nixos/doc/manual/development/activation-script.section.md b/nixos/doc/manual/development/activation-script.section.md index 1aee252fddea1..c339258c6dc48 100644 --- a/nixos/doc/manual/development/activation-script.section.md +++ b/nixos/doc/manual/development/activation-script.section.md @@ -34,7 +34,7 @@ read which is set to `dry-activate` when a dry activation is done. An activation script can write to special files instructing `switch-to-configuration` to restart/reload units. The script will take these -requests into account and will incorperate the unit configuration as described +requests into account and will incorporate the unit configuration as described above. This means that the activation script will "fake" a modified unit file and `switch-to-configuration` will act accordingly. By doing so, configuration like [systemd.services.\<name\>.restartIfChanged](#opt-systemd.services) is @@ -49,7 +49,7 @@ dry activation being `/run/nixos/dry-activation-restart-list` and `/run/nixos/dry-activation-reload-list`. Those files can contain newline-separated lists of unit names where duplicates are being ignored. These files are not create automatically and activation scripts must take the -possiblility into account that they have to create them first. +possibility into account that they have to create them first. ## NixOS snippets {#sec-activation-script-nixos-snippets} diff --git a/nixos/doc/manual/development/bootspec.chapter.md b/nixos/doc/manual/development/bootspec.chapter.md new file mode 100644 index 0000000000000..96c12f24e7f1f --- /dev/null +++ b/nixos/doc/manual/development/bootspec.chapter.md @@ -0,0 +1,36 @@ +# Experimental feature: Bootspec {#sec-experimental-bootspec} + +Bootspec is a experimental feature, introduced in the [RFC-0125 proposal](https://github.com/NixOS/rfcs/pull/125), the reference implementation can be found [there](https://github.com/NixOS/nixpkgs/pull/172237) in order to standardize bootloader support +and advanced boot workflows such as SecureBoot and potentially more. + +You can enable the creation of bootspec documents through [`boot.bootspec.enable = true`](options.html#opt-boot.bootspec.enable), which will prompt a warning until [RFC-0125](https://github.com/NixOS/rfcs/pull/125) is officially merged. + +## Schema {#sec-experimental-bootspec-schema} + +The bootspec schema is versioned and validated against [a CUE schema file](https://cuelang.org/) which should considered as the source of truth for your applications. + +You will find the current version [here](../../../modules/system/activation/bootspec.cue). + +## Extensions mechanism {#sec-experimental-bootspec-extensions} + +Bootspec cannot account for all usecases. + +For this purpose, Bootspec offers a generic extension facility [`boot.bootspec.extensions`](options.html#opt-boot.bootspec.extensions) which can be used to inject any data needed for your usecases. + +An example for SecureBoot is to get the Nix store path to `/etc/os-release` in order to bake it into a unified kernel image: + +```nix +{ config, lib, ... }: { + boot.bootspec.extensions = { + "org.secureboot.osRelease" = config.environment.etc."os-release".source; + }; +} +``` + +To reduce incompatibility and prevent names from clashing between applications, it is **highly recommended** to use a unique namespace for your extensions. + +## External bootloaders {#sec-experimental-bootspec-external-bootloaders} + +It is possible to enable your own bootloader through [`boot.loader.external.installHook`](options.html#opt-boot.loader.external.installHook) which can wrap an existing bootloader. + +Currently, there is no good story to compose existing bootloaders to enrich their features, e.g. SecureBoot, etc. It will be necessary to reimplement or reuse existing parts. diff --git a/nixos/doc/manual/development/development.xml b/nixos/doc/manual/development/development.xml index 624ee3931659b..949468c9021df 100644 --- a/nixos/doc/manual/development/development.xml +++ b/nixos/doc/manual/development/development.xml @@ -12,6 +12,7 @@ <xi:include href="../from_md/development/sources.chapter.xml" /> <xi:include href="../from_md/development/writing-modules.chapter.xml" /> <xi:include href="../from_md/development/building-parts.chapter.xml" /> + <xi:include href="../from_md/development/bootspec.chapter.xml" /> <xi:include href="../from_md/development/what-happens-during-a-system-switch.chapter.xml" /> <xi:include href="../from_md/development/writing-documentation.chapter.xml" /> <xi:include href="../from_md/development/nixos-tests.chapter.xml" /> diff --git a/nixos/doc/manual/development/option-types.section.md b/nixos/doc/manual/development/option-types.section.md index 40b4d78b250e2..e398d6c30cceb 100644 --- a/nixos/doc/manual/development/option-types.section.md +++ b/nixos/doc/manual/development/option-types.section.md @@ -345,7 +345,7 @@ that are handled like a separate module. It takes a parameter *`o`*, that should be a set, or a function returning a set with an `options` key defining the sub-options. Submodule option definitions are type-checked accordingly to the `options` declarations. -Of course, you can nest submodule option definitons for even higher +Of course, you can nest submodule option definitions for even higher modularity. The option set can be defined directly diff --git a/nixos/doc/manual/development/writing-nixos-tests.section.md b/nixos/doc/manual/development/writing-nixos-tests.section.md index 2efe52b9883c2..f3edea3e70477 100644 --- a/nixos/doc/manual/development/writing-nixos-tests.section.md +++ b/nixos/doc/manual/development/writing-nixos-tests.section.md @@ -298,7 +298,7 @@ The following methods are available on machine objects: : Wait until the supplied regular expressions match a line of the serial console output. This method is useful when OCR is not - possibile or accurate enough. + possible or accurate enough. `wait_for_window` @@ -351,7 +351,7 @@ This applies to `systemctl`, `get_unit_info`, `wait_for_unit`, `start_job` and `stop_job`. For faster dev cycles it\'s also possible to disable the code-linters -(this shouldn\'t be commited though): +(this shouldn\'t be committed though): ```nix { |