···159 "/run/opengl-driver/share/vulkan/icd.d/radeon_icd.x86_64.json";
160```
1610000000000000000000000000000000000162## Common issues {#sec-gpu-accel-common-issues}
163164### User permissions {#sec-gpu-accel-common-issues-permissions}
···159 "/run/opengl-driver/share/vulkan/icd.d/radeon_icd.x86_64.json";
160```
161162+## VA-API {#sec-gpu-accel-va-api}
163+164+[VA-API (Video Acceleration API)](https://www.intel.com/content/www/us/en/developer/articles/technical/linuxmedia-vaapi.html)
165+is an open-source library and API specification, which provides access to
166+graphics hardware acceleration capabilities for video processing.
167+168+VA-API drivers are loaded by `libva`. The version in nixpkgs is built to search
169+the opengl driver path, so drivers can be installed in
170+[](#opt-hardware.opengl.extraPackages).
171+172+VA-API can be tested using:
173+174+```ShellSession
175+$ nix-shell -p libva-utils --run vainfo
176+```
177+178+### Intel {#sec-gpu-accel-va-api-intel}
179+180+Modern Intel GPUs use the iHD driver, which can be installed with:
181+182+```nix
183+hardware.opengl.extraPackages = [
184+ intel-media-driver
185+];
186+```
187+188+Older Intel GPUs use the i965 driver, which can be installed with:
189+190+```nix
191+hardware.opengl.extraPackages = [
192+ vaapiIntel
193+];
194+```
195+196## Common issues {#sec-gpu-accel-common-issues}
197198### User permissions {#sec-gpu-accel-common-issues-permissions}
+36
nixos/doc/manual/development/bootspec.chapter.md
···000000000000000000000000000000000000
···1+# Experimental feature: Bootspec {#sec-experimental-bootspec}
2+3+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
4+and advanced boot workflows such as SecureBoot and potentially more.
5+6+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.
7+8+## Schema {#sec-experimental-bootspec-schema}
9+10+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.
11+12+You will find the current version [here](../../../modules/system/activation/bootspec.cue).
13+14+## Extensions mechanism {#sec-experimental-bootspec-extensions}
15+16+Bootspec cannot account for all usecases.
17+18+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.
19+20+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:
21+22+```nix
23+{ config, lib, ... }: {
24+ boot.bootspec.extensions = {
25+ "org.secureboot.osRelease" = config.environment.etc."os-release".source;
26+ };
27+}
28+```
29+30+To reduce incompatibility and prevent names from clashing between applications, it is **highly recommended** to use a unique namespace for your extensions.
31+32+## External bootloaders {#sec-experimental-bootspec-external-bootloaders}
33+34+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.
35+36+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.
···180</programlisting>
181 </section>
182 </section>
183+ <section xml:id="sec-gpu-accel-va-api">
184+ <title>VA-API</title>
185+ <para>
186+ <link xlink:href="https://www.intel.com/content/www/us/en/developer/articles/technical/linuxmedia-vaapi.html">VA-API
187+ (Video Acceleration API)</link> is an open-source library and API
188+ specification, which provides access to graphics hardware
189+ acceleration capabilities for video processing.
190+ </para>
191+ <para>
192+ VA-API drivers are loaded by <literal>libva</literal>. The version
193+ in nixpkgs is built to search the opengl driver path, so drivers
194+ can be installed in
195+ <xref linkend="opt-hardware.opengl.extraPackages" />.
196+ </para>
197+ <para>
198+ VA-API can be tested using:
199+ </para>
200+ <programlisting>
201+$ nix-shell -p libva-utils --run vainfo
202+</programlisting>
203+ <section xml:id="sec-gpu-accel-va-api-intel">
204+ <title>Intel</title>
205+ <para>
206+ Modern Intel GPUs use the iHD driver, which can be installed
207+ with:
208+ </para>
209+ <programlisting language="bash">
210+hardware.opengl.extraPackages = [
211+ intel-media-driver
212+];
213+</programlisting>
214+ <para>
215+ Older Intel GPUs use the i965 driver, which can be installed
216+ with:
217+ </para>
218+ <programlisting language="bash">
219+hardware.opengl.extraPackages = [
220+ vaapiIntel
221+];
222+</programlisting>
223+ </section>
224+ </section>
225 <section xml:id="sec-gpu-accel-common-issues">
226 <title>Common issues</title>
227 <section xml:id="sec-gpu-accel-common-issues-permissions">
···1+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-experimental-bootspec">
2+ <title>Experimental feature: Bootspec</title>
3+ <para>
4+ Bootspec is a experimental feature, introduced in the
5+ <link xlink:href="https://github.com/NixOS/rfcs/pull/125">RFC-0125
6+ proposal</link>, the reference implementation can be found
7+ <link xlink:href="https://github.com/NixOS/nixpkgs/pull/172237">there</link>
8+ in order to standardize bootloader support and advanced boot
9+ workflows such as SecureBoot and potentially more.
10+ </para>
11+ <para>
12+ You can enable the creation of bootspec documents through
13+ <link xlink:href="options.html#opt-boot.bootspec.enable"><literal>boot.bootspec.enable = true</literal></link>,
14+ which will prompt a warning until
15+ <link xlink:href="https://github.com/NixOS/rfcs/pull/125">RFC-0125</link>
16+ is officially merged.
17+ </para>
18+ <section xml:id="sec-experimental-bootspec-schema">
19+ <title>Schema</title>
20+ <para>
21+ The bootspec schema is versioned and validated against
22+ <link xlink:href="https://cuelang.org/">a CUE schema file</link>
23+ which should considered as the source of truth for your
24+ applications.
25+ </para>
26+ <para>
27+ You will find the current version
28+ <link xlink:href="../../../modules/system/activation/bootspec.cue">here</link>.
29+ </para>
30+ </section>
31+ <section xml:id="sec-experimental-bootspec-extensions">
32+ <title>Extensions mechanism</title>
33+ <para>
34+ Bootspec cannot account for all usecases.
35+ </para>
36+ <para>
37+ For this purpose, Bootspec offers a generic extension facility
38+ <link xlink:href="options.html#opt-boot.bootspec.extensions"><literal>boot.bootspec.extensions</literal></link>
39+ which can be used to inject any data needed for your usecases.
40+ </para>
41+ <para>
42+ An example for SecureBoot is to get the Nix store path to
43+ <literal>/etc/os-release</literal> in order to bake it into a
44+ unified kernel image:
45+ </para>
46+ <programlisting language="bash">
47+{ config, lib, ... }: {
48+ boot.bootspec.extensions = {
49+ "org.secureboot.osRelease" = config.environment.etc."os-release".source;
50+ };
51+}
52+</programlisting>
53+ <para>
54+ To reduce incompatibility and prevent names from clashing between
55+ applications, it is <emphasis role="strong">highly
56+ recommended</emphasis> to use a unique namespace for your
57+ extensions.
58+ </para>
59+ </section>
60+ <section xml:id="sec-experimental-bootspec-external-bootloaders">
61+ <title>External bootloaders</title>
62+ <para>
63+ It is possible to enable your own bootloader through
64+ <link xlink:href="options.html#opt-boot.loader.external.installHook"><literal>boot.loader.external.installHook</literal></link>
65+ which can wrap an existing bootloader.
66+ </para>
67+ <para>
68+ Currently, there is no good story to compose existing bootloaders
69+ to enrich their features, e.g. SecureBoot, etc. It will be
70+ necessary to reimplement or reuse existing parts.
71+ </para>
72+ </section>
73+</chapter>
···1+# Note that these schemas are defined by RFC-0125.
2+# This document is considered a stable API, and is depended upon by external tooling.
3+# Changes to the structure of the document, or the semantics of the values should go through an RFC.
4+#
5+# See: https://github.com/NixOS/rfcs/pull/125
6+{ config
7+, pkgs
8+, lib
9+, ...
10+}:
11+let
12+ cfg = config.boot.bootspec;
13+ children = lib.mapAttrs (childName: childConfig: childConfig.configuration.system.build.toplevel) config.specialisation;
14+ schemas = {
15+ v1 = rec {
16+ filename = "boot.json";
17+ json =
18+ pkgs.writeText filename
19+ (builtins.toJSON
20+ {
21+ v1 = {
22+ kernel = "${config.boot.kernelPackages.kernel}/${config.system.boot.loader.kernelFile}";
23+ kernelParams = config.boot.kernelParams;
24+ initrd = "${config.system.build.initialRamdisk}/${config.system.boot.loader.initrdFile}";
25+ initrdSecrets = "${config.system.build.initialRamdiskSecretAppender}/bin/append-initrd-secrets";
26+ label = "NixOS ${config.system.nixos.codeName} ${config.system.nixos.label} (Linux ${config.boot.kernelPackages.kernel.modDirVersion})";
27+28+ inherit (cfg) extensions;
29+ };
30+ });
31+32+ generator =
33+ let
34+ # NOTE: Be careful to not introduce excess newlines at the end of the
35+ # injectors, as that may affect the pipes and redirects.
36+37+ # Inject toplevel and init into the bootspec.
38+ # This can only be done here because we *cannot* depend on $out
39+ # referring to the toplevel, except by living in the toplevel itself.
40+ toplevelInjector = lib.escapeShellArgs [
41+ "${pkgs.jq}/bin/jq"
42+ ''
43+ .v1.toplevel = $toplevel |
44+ .v1.init = $init
45+ ''
46+ "--sort-keys"
47+ "--arg" "toplevel" "${placeholder "out"}"
48+ "--arg" "init" "${placeholder "out"}/init"
49+ ] + " < ${json}";
50+51+ # We slurp all specialisations and inject them as values, such that
52+ # `.specialisations.${name}` embeds the specialisation's bootspec
53+ # document.
54+ specialisationInjector =
55+ let
56+ specialisationLoader = (lib.mapAttrsToList
57+ (childName: childToplevel: lib.escapeShellArgs [ "--slurpfile" childName "${childToplevel}/bootspec/${filename}" ])
58+ children);
59+ in
60+ lib.escapeShellArgs [
61+ "${pkgs.jq}/bin/jq"
62+ "--sort-keys"
63+ ".v1.specialisation = ($ARGS.named | map_values(. | first | .v1))"
64+ ] + " ${lib.concatStringsSep " " specialisationLoader}";
65+ in
66+ ''
67+ mkdir -p $out/bootspec
68+69+ ${toplevelInjector} | ${specialisationInjector} > $out/bootspec/${filename}
70+ '';
71+72+ validator = pkgs.writeCueValidator ./bootspec.cue {
73+ document = "Document"; # Universal validator for any version as long the schema is correctly set.
74+ };
75+ };
76+ };
77+in
78+{
79+ options.boot.bootspec = {
80+ enable = lib.mkEnableOption (lib.mdDoc "Enable generation of RFC-0125 bootspec in $system/bootspec, e.g. /run/current-system/bootspec");
81+82+ extensions = lib.mkOption {
83+ type = lib.types.attrs;
84+ default = { };
85+ description = lib.mdDoc ''
86+ User-defined data that extends the bootspec document.
87+88+ To reduce incompatibility and prevent names from clashing
89+ between applications, it is **highly recommended** to use a
90+ unique namespace for your extensions.
91+ '';
92+ };
93+94+ # This will be run as a part of the `systemBuilder` in ./top-level.nix. This
95+ # means `$out` points to the output of `config.system.build.toplevel` and can
96+ # be used for a variety of things (though, for now, it's only used to report
97+ # the path of the `toplevel` itself and the `init` executable).
98+ writer = lib.mkOption {
99+ internal = true;
100+ default = schemas.v1.generator;
101+ };
102+103+ validator = lib.mkOption {
104+ internal = true;
105+ default = schemas.v1.validator;
106+ };
107+108+ filename = lib.mkOption {
109+ internal = true;
110+ default = schemas.v1.filename;
111+ };
112+ };
113+114+ config = lib.mkIf (cfg.enable) {
115+ warnings = [
116+ ''RFC-0125 is not merged yet, this is a feature preview of bootspec.
117+ The schema is not definitive and features are not guaranteed to be stable until RFC-0125 is merged.
118+ See:
119+ - https://github.com/NixOS/nixpkgs/pull/172237 to track merge status in nixpkgs.
120+ - https://github.com/NixOS/rfcs/pull/125 to track RFC status.
121+ ''
122+ ];
123+ };
124+}
···1+# External Bootloader Backends {#sec-bootloader-external}
2+3+NixOS has support for several bootloader backends by default: systemd-boot, grub, uboot, etc.
4+The built-in bootloader backend support is generic and supports most use cases.
5+Some users may prefer to create advanced workflows around managing the bootloader and bootable entries.
6+7+You can replace the built-in bootloader support with your own tooling using the "external" bootloader option.
8+9+Imagine you have created a new package called FooBoot.
10+FooBoot provides a program at `${pkgs.fooboot}/bin/fooboot-install` which takes the system closure's path as its only argument and configures the system's bootloader.
11+12+You can enable FooBoot like this:
13+14+```nix
15+{ pkgs, ... }: {
16+ boot.loader.external = {
17+ enable = true;
18+ installHook = "${pkgs.fooboot}/bin/fooboot-install";
19+ };
20+}
21+```
22+23+## Developing Custom Bootloader Backends
24+25+Bootloaders should use [RFC-0125](https://github.com/NixOS/rfcs/pull/125)'s Bootspec format and synthesis tools to identify the key properties for bootable system generations.
26+
···1+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-bootloader-external">
2+ <title>External Bootloader Backends</title>
3+ <para>
4+ NixOS has support for several bootloader backends by default:
5+ systemd-boot, grub, uboot, etc. The built-in bootloader backend
6+ support is generic and supports most use cases. Some users may
7+ prefer to create advanced workflows around managing the bootloader
8+ and bootable entries.
9+ </para>
10+ <para>
11+ You can replace the built-in bootloader support with your own
12+ tooling using the <quote>external</quote> bootloader option.
13+ </para>
14+ <para>
15+ Imagine you have created a new package called FooBoot. FooBoot
16+ provides a program at
17+ <literal>${pkgs.fooboot}/bin/fooboot-install</literal> which takes
18+ the system closure’s path as its only argument and configures the
19+ system’s bootloader.
20+ </para>
21+ <para>
22+ You can enable FooBoot like this:
23+ </para>
24+ <programlisting language="nix">
25+{ pkgs, ... }: {
26+ boot.loader.external = {
27+ enable = true;
28+ installHook = "${pkgs.fooboot}/bin/fooboot-install";
29+ };
30+}
31+</programlisting>
32+ <section xml:id="developing-custom-bootloader-backends">
33+ <title>Developing Custom Bootloader Backends</title>
34+ <para>
35+ Bootloaders should use
36+ <link xlink:href="https://github.com/NixOS/rfcs/pull/125">RFC-0125</link>’s
37+ Bootspec format and synthesis tools to identify the key properties
38+ for bootable system generations.
39+ </para>
40+ </section>
41+</chapter>
···60 # only an issue with the useLLVM stdenv, not the darwin stdenv…
61 # https://github.com/grpc/grpc/issues/26473#issuecomment-860885484
62 useLLVMAndOldCC = (stdenv.hostPlatform.useLLVM or false) && lib.versionOlder stdenv.cc.cc.version "11.0";
63- cxxStandard = if useLLVMAndOldCC then "11" else "17";
0064 in
65 [
66 "-DgRPC_ZLIB_PROVIDER=package"
···60 # only an issue with the useLLVM stdenv, not the darwin stdenv…
61 # https://github.com/grpc/grpc/issues/26473#issuecomment-860885484
62 useLLVMAndOldCC = (stdenv.hostPlatform.useLLVM or false) && lib.versionOlder stdenv.cc.cc.version "11.0";
63+ # With GCC 9 (current aarch64-linux) it fails with c++17 but OK with c++14.
64+ useOldGCC = !(stdenv.hostPlatform.useLLVM or false) && lib.versionOlder stdenv.cc.cc.version "10";
65+ cxxStandard = if useLLVMAndOldCC then "11" else if useOldGCC then "14" else "17";
66 in
67 [
68 "-DgRPC_ZLIB_PROVIDER=package"
···32 perl scripts/config.pl set MBEDTLS_THREADING_PTHREAD # POSIX thread wrapper layer for the threading layer.
33 '';
3435- cmakeFlags = [ "-DUSE_SHARED_MBEDTLS_LIBRARY=on" ];
36- NIX_CFLAGS_COMPILE = lib.optionals stdenv.cc.isGNU [
37- "-Wno-error=format"
38- "-Wno-error=format-truncation"
000039 ];
4041 meta = with lib; {
···32 perl scripts/config.pl set MBEDTLS_THREADING_PTHREAD # POSIX thread wrapper layer for the threading layer.
33 '';
3435+ cmakeFlags = [
36+ "-DUSE_SHARED_MBEDTLS_LIBRARY=on"
37+38+ # Avoid a dependency on jsonschema and jinja2 by not generating source code
39+ # using python. In releases, these generated files are already present in
40+ # the repository and do not need to be regenerated. See:
41+ # https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.3.0 below "Requirement changes".
42+ "-DGEN_FILES=off"
43 ];
4445 meta = with lib; {
···78stdenv.mkDerivation rec {
9 pname = "adguardhome";
10- version = "0.107.20";
11 src = sources.${system} or (throw "Source for ${pname} is not available for ${system}");
1213 installPhase = ''
···78stdenv.mkDerivation rec {
9 pname = "adguardhome";
10+ version = "0.107.21";
11 src = sources.${system} or (throw "Source for ${pname} is not available for ${system}");
1213 installPhase = ''