nixpkgs/nixos/doc/manual/from_md/development/bootspec.chapter.xml
Naïm Favier 07cb3bf3cc
nixos/doc: bump Pandoc
Update the pinned channel in `md-to-db`, which bumps the Pandoc version,
which fixes https://github.com/NixOS/nixpkgs/issues/125511 maybe.
2022-12-27 17:23:25 +01:00

74 lines
3.0 KiB
XML

<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-experimental-bootspec">
<title>Experimental feature: Bootspec</title>
<para>
Bootspec is a experimental feature, introduced in the
<link xlink:href="https://github.com/NixOS/rfcs/pull/125">RFC-0125
proposal</link>, the reference implementation can be found
<link xlink:href="https://github.com/NixOS/nixpkgs/pull/172237">there</link>
in order to standardize bootloader support and advanced boot
workflows such as SecureBoot and potentially more.
</para>
<para>
You can enable the creation of bootspec documents through
<link xlink:href="options.html#opt-boot.bootspec.enable"><literal>boot.bootspec.enable = true</literal></link>,
which will prompt a warning until
<link xlink:href="https://github.com/NixOS/rfcs/pull/125">RFC-0125</link>
is officially merged.
</para>
<section xml:id="sec-experimental-bootspec-schema">
<title>Schema</title>
<para>
The bootspec schema is versioned and validated against
<link xlink:href="https://cuelang.org/">a CUE schema file</link>
which should considered as the source of truth for your
applications.
</para>
<para>
You will find the current version
<link xlink:href="../../../modules/system/activation/bootspec.cue">here</link>.
</para>
</section>
<section xml:id="sec-experimental-bootspec-extensions">
<title>Extensions mechanism</title>
<para>
Bootspec cannot account for all usecases.
</para>
<para>
For this purpose, Bootspec offers a generic extension facility
<link xlink:href="options.html#opt-boot.bootspec.extensions"><literal>boot.bootspec.extensions</literal></link>
which can be used to inject any data needed for your usecases.
</para>
<para>
An example for SecureBoot is to get the Nix store path to
<literal>/etc/os-release</literal> in order to bake it into a
unified kernel image:
</para>
<programlisting language="nix">
{ config, lib, ... }: {
boot.bootspec.extensions = {
&quot;org.secureboot.osRelease&quot; = config.environment.etc.&quot;os-release&quot;.source;
};
}
</programlisting>
<para>
To reduce incompatibility and prevent names from clashing between
applications, it is <emphasis role="strong">highly
recommended</emphasis> to use a unique namespace for your
extensions.
</para>
</section>
<section xml:id="sec-experimental-bootspec-external-bootloaders">
<title>External bootloaders</title>
<para>
It is possible to enable your own bootloader through
<link xlink:href="options.html#opt-boot.loader.external.installHook"><literal>boot.loader.external.installHook</literal></link>
which can wrap an existing bootloader.
</para>
<para>
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.
</para>
</section>
</chapter>