Additional arguments passed to each module in addition to ones like lib, config, and pkgs, modulesPath.

This option is also available to all submodules. Submodules do not inherit args from their parent module, nor do they provide args to their parent module or sibling submodules. The sole exception to this is the argument name which is provided by parent modules to a submodule and contains the attribute name the submodule is bound to, or a unique generated name if it is not bound to an attribute.

Some arguments are already passed by default, of which the following cannot be changed with this option:

• lib: The nixpkgs library.

• config: The results of all options after merging the values from all modules together.

• options: The options declared in all modules.

• specialArgs: The specialArgs argument passed to evalModules.

• All attributes of specialArgs

  Whereas option values can generally depend on other option values thanks to laziness, this does not apply to imports, which must be computed statically before anything else.

  For this reason, callers of the module system can provide specialArgs which are available during import resolution.

  For NixOS, specialArgs includes modulesPath, which allows you to import extra modules from the nixpkgs package tree without having to somehow make the module aware of the location of the nixpkgs or NixOS directories.

  { modulesPath, ... }: {
    imports = [
      (modulesPath + "/profiles/minimal.nix")
    ];
  }
  

For NixOS, the default value for this option includes at least this argument:

• pkgs: The nixpkgs package set according to the nixpkgs.pkgs option.

The kernel console loglevel. All Kernel Messages with a log level smaller than this setting will be printed to the console.

Size limit for the /dev/shm tmpfs. Look at mount(8), tmpfs size option, for the accepted syntax.

Size limit for the /dev tmpfs. Look at mount(8), tmpfs size option, for the accepted syntax.

A list of additional packages supplying kernel modules.

List of available backends.

Executable that stage 2 will hand off to as PID 1.

Extra files required by the init system, passed directly to environment.etc and uses the same syntax.

Whether this /etc file should be generated. This option allows specific /etc files to be disabled.

GID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

Group name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a gid instead. Otherwise this option takes precedence over gid.

If set to something else than symlink, the file is copied instead of symlinked, with the given file mode.

Path of the source file.

Name of symlink (relative to /etc). Defaults to the attribute name.

Text of the file.

UID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

User name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a uid instead. Otherwise this option takes precedence over uid.

Name of the init backend used after stage-2 activation.

Packages which are required for the backend to function.

Function which takes config.micros.services as an input and outputs files to be appended to environment.etc.

Extra features offered by the init backend, e.g. dependency management

Init backend used after stage-2 activation has completed.

Executable that stage 2 will hand off to as PID 1.

Extra files required by the init system, passed directly to environment.etc and uses the same syntax.

Whether this /etc file should be generated. This option allows specific /etc files to be disabled.

GID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

Group name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a gid instead. Otherwise this option takes precedence over gid.

If set to something else than symlink, the file is copied instead of symlinked, with the given file mode.

Path of the source file.

Name of symlink (relative to /etc). Defaults to the attribute name.

Text of the file.

UID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

User name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a uid instead. Otherwise this option takes precedence over uid.

Name of the init backend used after stage-2 activation.

Packages which are required for the backend to function.

Function which takes config.micros.services as an input and outputs files to be appended to environment.etc.

Extra features offered by the init backend, e.g. dependency management

Executable that stage 2 will hand off to as PID 1.

PATH value used by stage 2 before handing off to the init backend.

Whether the initrd can be built even though modules listed in boot.initrd.kernelModules or boot.initrd.availableKernelModules are missing from the kernel. This is useful when combining configurations that include a lot of modules, such as hardware.enableAllHardware, with kernels that don't provide as many modules as typical NixOS kernels.

Note that enabling this is discouraged. Instead, try disabling individual modules by setting e.g. boot.initrd.availableKernelModules.foo = lib.mkForce false;

The set of kernel modules in the initial ramdisk used during the boot process. This set must include all modules necessary for mounting the root device. That is, it should include modules for the physical device (e.g., SCSI drivers) and for the file system (e.g., ext3). The set specified here is automatically closed under the module dependency relation, i.e., all dependencies of the modules list here are included automatically. The modules listed here are available in the initrd, but are only loaded on demand (e.g., the ext3 module is loaded automatically when an ext3 filesystem is mounted, and modules for PCI devices are loaded when they match the PCI ID of a device in your system). To force a module to be loaded, include it in boot.initrd.kernelModules.

This can either be a list of modules, or an attrset. In an attrset, names that are set to true represent modules that will be included. Note that setting these names to false does not prevent the module from being loaded. For that, use boot.blacklistedKernelModules.

The compressor to use on the initrd image. May be any of:

• The name of one of the predefined compressors, see pkgs/build-support/kernel/initrd-compressor-meta.nix for the definitions.
• A function which, given the nixpkgs package set, returns the path to a compressor tool, e.g. pkgs: "${pkgs.pigz}/bin/pigz"
• (not recommended, because it does not work when cross-compiling) the full path to a compressor tool, e.g. "${pkgs.pigz}/bin/pigz"

The given program should read data from stdin and write it to stdout compressed.

Arguments to pass to the compressor for the initrd image, or null to use the compressor's defaults.

Whether to enable initrd.

This option, if set, adds a collection of default kernel modules to boot.initrd.availableKernelModules and boot.initrd.kernelModules.

Set of modules that are always loaded by the initrd.

This can either be a list of modules, or an attrset. In an attrset, names that are set to true represent modules that will be included. Note that setting these names to false does not prevent the module from being loaded. For that, use boot.blacklistedKernelModules.

Whether the image is a container.

Whether to enable the Linux kernel. This is useful for systemd-like containers which do not require a kernel.

Provides a custom seed for the RANDSTRUCT security option of the Linux kernel. Note that RANDSTRUCT is only enabled in NixOS hardened kernels. Using a custom seed requires building the kernel and dependent packages locally, since this customization happens at build time.

Runtime parameters of the Linux kernel, as set by sysctl(8). Note that sysctl parameters names must be enclosed in quotes (e.g. "vm.swappiness" instead of vm.swappiness). The value of each parameter may be a string, integer, boolean, or null (signifying the option will not appear at all).

The maximum receive socket buffer size in bytes. In case of conflicting values, the highest will be used.

The maximum send socket buffer size in bytes. In case of conflicting values, the highest will be used.

The set of kernel modules to be loaded in the second stage of the boot process. Note that modules that are needed to mount the root file system should be added to boot.initrd.availableKernelModules or boot.initrd.kernelModules.

This can either be a list of modules, or an attrset. In an attrset, names that are set to true represent modules that will be included. Note that setting these names to false does not prevent the module from being loaded. For that, use boot.blacklistedKernelModules.

This option allows you to override the Linux kernel used by NixOS. Since things like external kernel module packages are tied to the kernel you're using, it also overrides those. This option is a function that takes Nixpkgs as an argument (as a convenience), and returns an attribute set containing at the very least an attribute kernel. Additional attributes may be needed depending on your configuration. For instance, if you use the NVIDIA X driver, then it also needs to contain an attribute nvidia_x11.

Please note that we strictly support kernel versions that are maintained by the Linux developers only. More information on the availability of kernel versions is documented in the Linux section of the manual.

Parameters added to the kernel command line.

A list of additional patches to apply to the kernel.

Every item should be an attribute set with the following attributes:

{
  name = "foo";                 # descriptive name, required

  patch = ./foo.patch;          # path or derivation that contains the patch source
                                # (required, but can be null if only config changes
                                # are needed)

  structuredExtraConfig = {     # attrset of extra configuration parameters without the CONFIG_ prefix
    FOO = lib.kernel.yes;       # (optional)
  };                            # values should generally be lib.kernel.yes,
                                # lib.kernel.no or lib.kernel.module

  features = {                  # attrset of extra "features" the kernel is considered to have
    foo = true;                 # (may be checked by other NixOS modules, optional)
  };

  extraConfig = "FOO y";        # extra configuration options in string form without the CONFIG_ prefix
                                # (optional, multiple lines allowed to specify multiple options)
                                # (deprecated, use structuredExtraConfig instead)
}

There's a small set of existing kernel patches in Nixpkgs, available as pkgs.kernelPatches, that follow this format and can be used directly.

Size limit for the /run tmpfs. Look at mount(8), tmpfs size option, for the accepted syntax.

List of paths that should be mounted before this one. This filesystem's device and mountPoint are always checked and do not need to be included explicitly. If a path is added to this list, any other filesystem whose mount point is a parent of the path will be mounted before this filesystem. The paths do not need to actually be the mountPoint of some other filesystem.

Location of the device.

Whether to enable the filesystem mount.

Type of the file system.

Location of the mounted file system.

Whether to mount filesystem in Stage 1

Options used to mount the file system.

UUID of the stratis pool that the fs is located in

Names of supported filesystem types, or an attribute set of file system types and their state. The set form may be used together with lib.mkForce to explicitly disable support for specific filesystems, e.g. to disable ZFS with an unsupported kernel.

(Deprecated) This option, if set, activates the VESA 800x600 video mode on boot and disables kernel modesetting. It is equivalent to specifying [ "vga=0x317" "nomodeset" ] in the boot.kernelParams option. This option is deprecated as of 2020: Xorg now works better with modesetting, and you might want a different VESA vga setting, anyway.

The shell executable that is linked system-wide to /bin/sh.

Set of files that have to be linked in /etc.

Whether this /etc file should be generated. This option allows specific /etc files to be disabled.

GID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

Group name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a gid instead. Otherwise this option takes precedence over gid.

If set to something else than symlink, the file is copied instead of symlinked, with the given file mode.

Path of the source file.

Name of symlink (relative to /etc). Defaults to the attribute name.

Text of the file.

UID of created file. Only takes effect when the file is copied (that is, the mode is not 'symlink').

User name of file owner.

Only takes effect when the file is copied (that is, the mode is not symlink).

When services.userborn.enable, this option has no effect. You have to assign a uid instead. Otherwise this option takes precedence over uid.

Shell script code called during global environment initialisation after all variables and profileVariables have been set. This code is assumed to be shell-independent, which means you should stick to pure sh without sh word split.

List of additional package outputs to be symlinked into /run/current-system/sw.

Shell fragments to be run after the system environment has been created.

This should only be used for things that need to modify the internals of the environment, e.g. generating MIME caches. The environment being built can be accessed at $out.

List of directories to be symlinked in /run/current-system/sw

The set of packages that appear in /run/current-system/sw.

These packages are automatically available to all users, and are automatically updated every time you rebuild the system configuration. (The latter is the main difference with installing them in the default profile, /nix/var/nix/profiles/default.

The file systems to be mounted. It must include an entry for the root directory (mountPoint = "/"). Each entry in the list is an attribute set with the following fields: mountPoint, device, fsType (a file system type recognised by mount; defaults to "auto"), and options (the mount options passed to mount using the -o flag; defaults to [ "defaults" ]).

Instead of specifying device, you can also specify a volume label (label) for file systems that support it, such as ext2/ext3 (see mke2fs -L).

If the device does not currently contain a filesystem (as determined by blkid), then automatically format it with the filesystem type specified in fsType. Use with caution.

If set, the filesystem is grown to its maximum size before being mounted. (This is typically the size of the containing partition.) This is currently only supported for ext2/3/4 filesystems that are mounted during early boot.

List of paths that should be mounted before this one. This filesystem's device and mountPoint are always checked and do not need to be included explicitly. If a path is added to this list, any other filesystem whose mount point is a parent of the path will be mounted before this filesystem. The paths do not need to actually be the mountPoint of some other filesystem.

Location of the device.

Whether to enable the filesystem mount.

Type of the file system.

Label of the device (if any).

Location of the mounted file system.

Whether to mount filesystem in Stage 1

Disable running fsck on this filesystem.

Options used to mount the file system.

UUID of the stratis pool that the fs is located in

Firmware packages

This option allows modules to define helper functions, constants, etc.

List of maintainers of each module. This option should be defined at most once per module.

The option value is not a list of maintainers, but an attribute set that maps module file names to lists of maintainers.

List of team maintainers of each module. This option should be defined at most once per module.

Init-backend-agnostic service definitions.

Optional shell fragment available to init backends that support service configuration files.

Other services to depend on. If they are not running, start them prior to starting this service.

Whether to enable Whether to enable this service. .

Optional shell script run by init backends that support service exit hooks.

Service name used by the selected init backend.

Whether to start automatically after boot

Shell script used to start the service.

Whether this service should be supervised continuously or run once.

Whether to enable DHCP globally. This is overrided by individual interface settings. Defaults to true

Whether to use DHCP nameservers over configured ones. Defaults to false.

Whether to respond to incoming ICMPv4 echo requests ("pings"). ICMPv6 pings are always allowed because the larger address space of IPv6 makes network scanning much less effective.

Range of open TCP ports.

List of open TCP ports.

Range of open UDP ports.

List of open UDP ports.

Whether to auto-load connection-tracking helpers. See the description at networking.firewall.connectionTrackingModules

(needs kernel 3.5+)

Performs a reverse path filter test on a packet. If a reply to the packet would not be sent via the same interface that the packet arrived on, it is refused.

If using asymmetric routing or other complicated routing, set this option to loose mode or disable it and setup your own counter-measures.

This option can be either true (or "strict"), "loose" (only drop the packet if the source address is not reachable via any interface) or false.

List of connection-tracking helpers that are auto-loaded. The complete list of possible values is given in the example.

As helpers can pose as a security risk, it is advised to set this to an empty list and disable the setting networking.firewall.autoLoadConntrackHelpers unless you know what you are doing. Connection tracking is disabled by default.

Loading of helpers is recommended to be done through the CT target. More info: <https://home.regit.org/netfilter-en/secure-use-of-helpers/>

Whether to enable firewall.

Additional nftables rules to be appended to the forward-allow chain.

This option only works with the nftables based firewall.

Additional nftables rules to be appended to the input-allow chain.

This option only works with the nftables based firewall.

Additional nftables rules to be appended to the rpfilter-allow chain.

This option only works with the nftables based firewall.

Enable filtering in IP forwarding.

This option only works with the nftables based firewall.

Interface-specific open ports.

Range of open TCP ports.

List of open TCP ports.

Range of open UDP ports.

List of open UDP ports.

Whether to log rejected or dropped incoming connections. Note: The logs are found in the kernel logs, i.e. dmesg or journalctl -k.

Whether to log all rejected or dropped incoming packets. This tends to give a lot of log messages, so it's mostly useful for debugging. Note: The logs are found in the kernel logs, i.e. dmesg or journalctl -k.

If networking.firewall.logRefusedPackets and this option are enabled, then only log packets specifically directed at this machine, i.e., not broadcasts or multicasts.

Logs dropped packets failing the reverse path filter test if the option networking.firewall.checkReversePath is enabled.

If pings are allowed, this allows setting rate limits on them.

For the iptables based firewall, it should be set like "--limit 1/minute --limit-burst 5".

For the nftables based firewall, it should be set like "2/second" or "1/minute burst 5 packets".

If set, refused packets are rejected rather than dropped (ignored). This means that an ICMP "port unreachable" error message is sent back to the client (or a TCP RST packet in case of an existing connection). Rejecting packets makes port scanning somewhat easier.

Traffic coming in from these interfaces will be accepted unconditionally. Traffic from the loopback (lo) interface will always be accepted.

The 32-bit host ID of the machine, formatted as 8 hexadecimal characters.

You should try to make this ID unique among your machines. You can generate a random 32-bit ID using the following commands:

head -c 8 /etc/machine-id

(this derives it from the machine-id that systemd generates) or

head -c4 /dev/urandom | od -A none -t x4

The primary use case is to ensure when using ZFS that a pool isn't imported accidentally on a wrong machine.

The name of the machine. Leave it empty if you want to obtain it from a DHCP server (if using DHCP). The hostname must be a valid DNS label (see RFC 1035 section 2.3.1: "Preferred name syntax", RFC 1123 section 2.1: "Host Names and Numbers") and as such must not contain the domain part. This means that the hostname must start with a letter or digit, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. The maximum length is 63 characters. Additionally it is recommended to only use lower-case characters. If (e.g. for legacy reasons) a FQDN is required as the Linux kernel network node hostname (uname --nodename) the option boot.kernel.sysctl."kernel.hostname" can be used as a workaround (but the 64 character limit still applies).

WARNING: Do not use underscores (_) or you may run into unexpected issues.

The list of interfaces to configure. By default, all network interfaces detected on startup are brought up with DHCP. Use this to manually configure interfaces and set static IPs.

Whether to use DHCP for the interface. When null (default), DHCP is used if ipv4 has no manually configured addresses.

Whether to enable the interface. This determines if the interface will have an entry in the /etc/network/interfaces file.

IPV4 address given to the interface, with the subnet mask. Given as "x.x.x.x/xx".

IPV4 address used as the network gateway. Given as "x.x.x.x".

IPV6 address given to the interface, with the subnet mask.

IPV6 address used as the network gateway.

Name of the interface. This is used in the /etc/network/interfaces file and needs to be set to a valid network interface, e.g. eth0, ens1p0, wlp2s0, etc.

Whether to use SLAAC for configuring IPV6 on the interface. When null (default), SLAAC is used if ipv6 has no manually configured addresses.

The list of nameservers used. This can be overrided by DHCP. Defaults to cloudflare DNS (1.1.1.1, 1.0.0.1).

Run nft check on the ruleset to spot syntax errors during build. Because this is executed in a sandbox, the check might fail if it requires access to any environmental factors or paths outside the Nix store. To circumvent this, the ruleset file can be edited using the preCheckRuleset option to work in the sandbox environment.

Set of paths that should be intercepted and rewritten while checking the ruleset using pkgs.buildPackages.libredirect.

Whether to enable nftables and use nftables based firewall if enabled. nftables is a Linux-based packet filtering framework intended to replace frameworks like iptables.

Note that if you have Docker enabled you will not be able to use nftables without intervention. Docker uses iptables internally to setup NAT for containers. This module disables the ip_tables kernel module, however Docker automatically loads the module. Please see <https://github.com/NixOS/nixpkgs/issues/24318#issuecomment-289216273> for more information.

There are other programs that use iptables internally too, such as libvirt. For information on how the two firewalls interact, see <https://wiki.nftables.org/wiki-nftables/index.php/Troubleshooting#Question_4._How_do_nftables_and_iptables_interact_when_used_on_the_same_system.3F>.

Extra deletion commands to be run on every firewall start, reload and after stopping the firewall.

Use builtins.readFile rather than include to handle networking.nftables.rulesetFile. It is useful when you want to apply networking.nftables.preCheckRuleset to networking.nftables.rulesetFile.

Whether to enable flushing the entire ruleset on each reload.

This script gets run before the ruleset is checked. It can be used to create additional files needed for the ruleset check to work, or modify the ruleset for cases the build environment cannot cover.

The ruleset to be used with nftables. Should be in a format that can be loaded using "/bin/nft -f". The ruleset is updated atomically. Note that if the tables should be cleaned first, either:

• networking.nftables.flushRuleset = true; needs to be set (flushes all tables)
• networking.nftables.extraDeletions needs to be set
• or networking.nftables.tables can be used, which will clean up the table automatically

The ruleset file to be used with nftables. Should be in a format that can be loaded using "nft -f". The ruleset is updated atomically.

Tables to be added to ruleset. Tables will be added together with delete statements to clean up the table before every update.

The table content.

Enable this table.

Table family.

Table name.

The set of NTP servers from which to synchronise.

Whether to enable Nix.

Disabling Nix makes the system hard to modify and the Nix programs and configuration will not be made available by NixOS itself.

The default Nix expression search path, used by the Nix evaluator to look up paths enclosed in angle brackets (e.g. <nixpkgs>).

This option specifies the Nix package instance to use throughout the system.

A system-wide flake registry.

Whether the from reference needs to match exactly. If set, a from reference like nixpkgs does not match with a reference like nixpkgs/nixos-20.03.

The flake input from is rewritten to.

The flake reference to be rewritten.

The flake reference from is rewritten to.

Specifies the platform on which NixOS should be built. By default, NixOS is built on the system where it runs, but you can change where it's built. Setting this option will cause NixOS to be cross-compiled.

For instance, if you're doing distributed multi-platform deployment, or if you're building machines, you can set this to match your development system and/or build farm.

Ignored when nixpkgs.pkgs is set.

Global configuration for Nixpkgs. The complete list of Nixpkgs configuration options is in the Nixpkgs manual section on global configuration.

Ignored when nixpkgs.pkgs is set.

Systems with a recently generated hardware-configuration.nix may instead specify only nixpkgs.buildPlatform, or fall back to removing the nixpkgs.hostPlatform line from the generated config.

Specifies the platform for which NixOS should be built. Specify this only if it is different from nixpkgs.localSystem, the platform on which NixOS should be built. In other words, specify this to cross-compile NixOS. Otherwise it should be set as null, the default. See its description in the Nixpkgs manual for more details.

Ignored when nixpkgs.pkgs or hostPlatform is set.

Whether to pin nixpkgs in the system-wide flake registry (/etc/nix/registry.json) to the store path of the sources of nixpkgs used to build the NixOS system.

This is on by default for NixOS configurations built with flakes.

This option makes nix run nixpkgs#hello reuse dependencies from the system, avoid refetching nixpkgs, and have a consistent result every time.

Note that this option makes the NixOS closure depend on the nixpkgs sources, which may add undesired closure size if the system will not have any nix commands run on it.

Whether to set NIX_PATH to include nixpkgs=flake:nixpkgs such that <nixpkgs> lookups receive the version of nixpkgs that the system was built with, in concert with nixpkgs.flake.setFlakeRegistry.

This is on by default for NixOS configurations built with flakes.

This makes nix-build '<nixpkgs>' -A hello work out of the box on flake systems.

Note that this option makes the NixOS closure depend on the nixpkgs sources, which may add undesired closure size if the system will not have any nix commands run on it.

The path to the nixpkgs sources used to build the system. This is automatically set up to be the store path of the nixpkgs flake used to build the system if using nixpkgs.lib.nixosSystem, and is otherwise null by default.

This can also be optionally set if the NixOS system is not built with a flake but still uses pinned sources: set this to the store path for the nixpkgs sources used to build the system, as may be obtained by builtins.fetchTarball, for example.

Note: the name of the store path must be "source" due to <https://github.com/NixOS/nix/issues/7075>.

Specifies the platform where the NixOS configuration will run.

To cross-compile, set also nixpkgs.buildPlatform.

Ignored when nixpkgs.pkgs is set.

Systems with a recently generated hardware-configuration.nix do not need to specify this option, unless cross-compiling, in which case you should set only nixpkgs.buildPlatform.

If this is somehow not feasible, you may fall back to removing the nixpkgs.hostPlatform line from the generated config and use the old options.

Specifies the platform on which NixOS should be built. When nixpkgs.crossSystem is unset, it also specifies the platform for which NixOS should be built. If this option is unset, it defaults to the platform type of the machine where evaluation happens. Specifying this option is useful when doing distributed multi-platform deployment, or when building virtual machines. See its description in the Nixpkgs manual for more details.

Ignored when nixpkgs.pkgs or hostPlatform is set.

List of overlays to apply to Nixpkgs. This option allows modifying the Nixpkgs package set accessed through the pkgs module argument.

For details, see the Overlays chapter in the Nixpkgs manual.

If the nixpkgs.pkgs option is set, overlays specified using nixpkgs.overlays will be applied after the overlays that were already included in nixpkgs.pkgs.

If set, the pkgs argument to all NixOS modules is the value of this option, extended with nixpkgs.overlays, if that is also set. Either nixpkgs.crossSystem or nixpkgs.localSystem will be used in an assertion to check that the NixOS and Nixpkgs architectures match. Any other options in nixpkgs.*, notably config, will be ignored.

If unset, the pkgs argument to all NixOS modules is determined as shown in the default value for this option.

The default value imports the Nixpkgs source files relative to the location of this NixOS module, because NixOS and Nixpkgs are distributed together for consistency, so the nixos in the default value is in fact a relative path. The config, overlays, localSystem, and crossSystem come from this option's siblings.

This option can be used by applications like NixOps to increase the performance of evaluation, or to create packages that depend on a container that should be built with the exact same evaluation of Nixpkgs, for example. Applications like this should set their default value using lib.mkDefault, so user-provided configuration can override it without using lib.

Note that using a distinct version of Nixpkgs with NixOS may be an unexpected source of problems. Use this option with care.

This option does not need to be specified for NixOS configurations with a recently generated hardware-configuration.nix.

Specifies the Nix platform type on which NixOS should be built. It is better to specify nixpkgs.localSystem instead.

{
  nixpkgs.system = ..;
}

is the same as

{
  nixpkgs.localSystem.system = ..;
}

See nixpkgs.localSystem for more information.

Ignored when nixpkgs.pkgs, nixpkgs.localSystem or nixpkgs.hostPlatform is set.

Package to use as the runit executable

Runit's initial start script

Runit's main service runner script

Runit shutdown script

Whether to enable PAM.

This option effectively allows adding setuid/setgid bits, capabilities, changing file ownership and permissions of a program without directly modifying it. This works by creating a wrapper program in a directory (not configurable), which is then added to the shell PATH.

A comma-separated list of capability clauses to be given to the wrapper program. The format for capability clauses is described in the “TEXTUAL REPRESENTATION” section of the cap_from_text(3) manual page. For a list of capabilities supported by the system, check the capabilities(7) manual page.

Whether to enable the wrapper.

The group of the wrapper program.

The owner of the wrapper program.

The permissions of the wrapper program. The format is that of a symbolic or numeric file mode understood by chmod.

The name of the wrapper program. Defaults to the attribute name.

Whether to add the setgid bit the wrapper program.

Whether to add the setuid bit the wrapper program.

The absolute path to the program to be wrapped.

Whether to enable Enable chronyd time server.

The chrony package to use.

Whether to enable getty.

Terminal to start getty in

Whether to enable Enable mdevd device manager.

Whether to enable nix-daemon.

The nix package to use.

Whether to enable rngd.

The rng-tools package to use.

Specify the rules for which files to read on the host.

These are paths relative to the host root file system or home directories and they are subject to certain token expansion rules. See AuthorizedKeysFile in man sshd_config for details.

Whether to enable sshd.

MicrOS can automatically generate SSH host keys. This option specifies the path, type and size of each key. See ssh-keygen(1) for supported types and sizes.

The openssh package to use.

A set of shell script fragments that are executed when a NixOS system configuration is activated. Examples are updating /etc, creating accounts, and so on. Since these are executed every time you boot the system or run nixos-rebuild, it's important that they are idempotent and fast.

Attribute set of derivations used to set up the system.

OCI compatible image.

Mount /etc as an overlayfs instead of generating it via a perl script.

Note: This is currently experimental. Only enable this option if you're confident that you can recover your system if it breaks.

Whether to mount /etc mutably (i.e. read-write) or immutably (i.e. read-only).

If this is false, only the immutable lowerdir is mounted. If it is true, a writable upperdir is mounted on top.

Whether to enable Enable syslog daemon.

Contents of /etc/syslog.conf file

Flags passed to syslog executable.

Syslog daemon to use for system logging. Defaults to busybox's syslog implementation. If the option is set to a derivation, lib.getExe is used to get the executable file. If the option is set to a string, it is executed directly.

The name of the system used in the system.build.toplevel derivation.

That derivation has the following name: "nixos-system-${config.system.name}-${config.system.nixos.label}"

Attrset of users.

Account group ID

Account home directory

Account Username

User-wide package list

Hashed account password

Account login shell

Account User ID

Specify the number of cores the guest is permitted to use. The number can be higher than the available cores on the host system.

When using the SLiRP user networking (default), this option allows to forward ports to/from the host/guest.

Controls the direction in which the ports are mapped:

• "host" means traffic from the host ports is forwarded to the given guest port.
• "guest" means traffic from the guest ports is forwarded to the given host port.

The IPv4 address on the guest VLAN.

The guest port to be mapped.

The IPv4 address of the host.

The host port to be mapped.

The protocol to forward.

The memory size in megabytes of the virtual machine.

Networking-related command-line options that should be passed to qemu. The default is to use userspace networking (SLiRP). See the QEMU Wiki on Networking for details.

If you override this option, be advised to keep ${QEMU_NET_OPTS:+,$QEMU_NET_OPTS} (as seen in the example) to keep the default runtime behaviour.