Export translations

Settings

Group

Language

Format

Export for off-line translation

Export in native format

Export in CSV format

<languages/>
<div lang="en" dir="ltr" class="mw-content-ltr">
Frequently asked questions and common newcomer trouble should be put here so that we can point to this page instead of answering the same question over and over again.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
http://unix.stackexchange.com/questions/tagged/nixos can also be used for questions.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Why is there a new wiki? What is with nixos.wiki? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The old wiki at nixos.wiki has several problems:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* Many components (mediawiki, php, icu) are severely outdated.
** MediaWiki 1.29 (EOL 2018), now 1.35 (EOL 2023-12)
** PHP 7.3.33 (EOL 2021-12)
** ICU 64.2
* Cloudflare DDOS protection makes wiki edits fail sometimes.
* There is no WYSIWYG editor.
* The wiki infrastructure, which was supposed to be made public after launch, never ended-up being made public.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
We tried to address these issues multiple times over multiple years across multiple channels (email, matrix). We never got a direct answer. The last point of contact was made through zimbatm representing the NixOS foundation, asking the maintainer about possible cooperation on a new wiki. The answer was no. With the old wiki deteriorating and the maintainer unresponsive, forking the content into a new wiki remained the only way forward.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also see:
* https://wiki.nixos.org/wiki/User:Winny/WikiRisks
* https://greasyfork.org/en/scripts/495011-redirect-to-wiki-nixos-org (trivial userscript to redirect nixos.wiki links here)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Why is Nix written in C++ rather than a functional language like Haskell? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Mainly because Nix is intended to be lightweight, easy to learn, and portable (zero dependencies).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How to keep build-time dependencies around / be able to rebuild while being offline? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix"># /etc/nixos/configuration.nix
{ config, pkgs, lib, ... }:
{
  nix.settings = {
    keep-outputs = true;
    keep-derivations = true;
    # See https://nixos.org/manual/nix/stable/command-ref/conf-file.html
    # for a complete list of Nix configuration options.
  };
}</syntaxhighlight>
Check 'man configuration.nix' for these options. Rebuild for these options to take effect:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>
List all store paths that form the system closure and realise them:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
nix-store -qR $(nix-instantiate '<nixpkgs/nixos>' -A system) | xargs nix-store -r
warning: you did not specify `--add-root'; the result might be removed by the garbage collector
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<build output and list of successfully realised paths>
</syntaxhighlight>
Repeat for your user and further profiles:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-store -qR ~/.nix-profile | xargs nix-store -r</syntaxhighlight>
The warning can be ignored for profiles that are listed/linked in ''/nix/var/nix/profiles/'' or one of its subdirectories.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Consult man pages of nix-store and nix-instantiate for further information.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Why <hash>-<name> instead of <name>-<hash>? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For the rare cases where we have to dig into the /nix/store it is more practical to keep in mind the first few letters at the beginning than finding a package by name. 
Ie, you can uniquely identify almost any storepath with just the first 4-5 characters of the hash.
(Rather than having to type out the full package name, then 4-5 characters of the hash.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Also, since the initial part is all of the same length, visually parsing a list of packages is easier.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you still wonder why, run <code>ls -1 /nix/store | sort -R -t - -k 2 | less</code> in your shell. ''(? unclear)''
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is what might happen if you don't garbage collect frequently, or if you are testing compilation variants:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
q0yi2nr8i60gm2zap46ryysydd2nhzhp-automake-1.11.1/
vbi4vwwidvd6kklq2kc0kx3nniwa3acl-automake-1.11.1/
wjgzir57hcbzrq3mcgxiwkyiqss3r4aq-automake-1.11.1/
1ch5549xnck37gg2w5fh1jgk6lkpq5mc-nixos-build-vms/
4cmjlxknzlvcdmfwj0ih0ggqsj5q73hb-nixos-build-vms/
7fv4kwi5wwwzd11ili3qwg28xrj8rxw2-nixos-build-vms/
8jij13smq9kdlqv96hm7y8xmbh2c54iy-nixos-build-vms/
j714mv53xi2j4ab4g2i08knqr137fd6l-nixos-build-vms/
xvs7y09jf7j48p6l0p87iypgpq470jqw-nixos-build-vms/
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I've updated my channel and something is broken, how can I rollback to an earlier channel? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
View the available generations of your channel:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
nix-env --list-generations -p /nix/var/nix/profiles/per-user/root/channels
18   2014-04-17 09:16:28
19   2014-06-13 10:31:24 
20   2014-08-12 19:09:20   (current)
</syntaxhighlight>
To rollback to the previous generation:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
nix-env --rollback -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 19
</syntaxhighlight>
To switch to a particular generation:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">
nix-env --switch-generation 18 -p /nix/var/nix/profiles/per-user/root/channels
switching from generation 20 to 18
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I'm working on a new package, how can I build it without adding it to nixpkgs? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; callPackage ./mypackage.nix { }'</syntaxhighlight>
You can replace callPackage with callPackage_i686 to build the 32-bit version of your package on a 64-bit system if you want to test that.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How can I compile a package with debugging symbols included? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
To build a package with -Og and -g, and without stripping debug symbols use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build -E 'with import <nixpkgs> { }; enableDebugging fooPackage'</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See also [[Debug Symbols]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How can I force a rebuild from source even without modifying the nix expression? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
As root you can run nix-build with the --check flag:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-build --check -A ncdu</syntaxhighlight>
== How can I manage software with nix-env like with configuration.nix? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
There are many ways, one is the following:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<ol style="list-style-type: decimal;">
<li><p>Create a meta package called ''userPackages'' your ''~/.config/nixpkgs/config.nix'' file with the packages you would like to have in your environment:</p>
<syntaxhighlight lang="nix">
with (import <nixpkgs> {});
{
  packageOverrides = pkgs: with pkgs; {
    userPackages = buildEnv {
      inherit ((import <nixpkgs/nixos> {}).config.system.path)
      pathsToLink ignoreCollisions postBuild;
      extraOutputsToInstall = [ "man" ];
      name = "user-packages";
      paths = [ vim git wget ];
    };
  };
}
</syntaxhighlight></li>
<li><p>Install all specified packages using this command:</p>
<syntaxhighlight lang="bash">nix-env -iA userPackages -f '<nixpkgs>'</syntaxhighlight></li></ol>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Now you can add and remove packages from the paths list and rerun nix-env to update your user local packages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Another way is using [[Home Manager]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I've downloaded a binary, but I can't run it, what can I do? ==
Binaries normally do not work out of the box when you download them because they normally just assume that libraries can be found in hardcoded paths such as <code>/lib</code>. However this assumption is incorrect on NixOS systems due to the inner workings of <code>nix</code> - there is no default path, everything gets set to the corresponding version on compile time.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you are new to packaging proprietary software you should check out the [[Packaging Binaries|Packaging Binaries Tutorial]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you are in a hurry and just want to get shit running, continue reading:<br />
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can use [https://github.com/Mic92/nix-ld nix-ld] to run compiled binaries. For example, if your binary needs zlib and openssl:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
programs.nix-ld = {
  enable = true;
  libraries = [ pkgs.zlib pkgs.openssl ];
};</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Log out and back in to apply the environment variables it sets, and you can then directly run the binary.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you don't want to configure the list of libraries manually, a quick and dirty way to run nearly any precompiled binary is the following:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
programs.nix-ld = {
  enable = true;
  libraries = pkgs.steam-run.fhsenv.args.multiPkgs pkgs;
};</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This uses the libraries that are used by [[Steam]] to simulate a traditional Linux FHS environment to run games in. It's a [https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/games/steam/fhsenv.nix big list] that usually contains all the libraries your binary needs to run.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Another possibility is to use [https://nixos.org/patchelf.html patchelf] to set the library path and dynamic linker appropriately, since compiled binaries have hard-coded interpreter and require certain dynamic libraries.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
# mybinaryprogram.nix
with import <nixpkgs> {}; 
stdenv.mkDerivation rec {
  name = "somename";
  buildInputs = [ makeWrapper ];
  buildPhase = "true";
  libPath = lib.makeLibraryPath with xlibs;[ libXrandr libXinerama libXcursor ];
  unpackPhase = "true";
  installPhase = ''
    mkdir -p $out/bin
    cp ${./mybinaryprogram} $out/bin/mybinaryprogram
  '';
  postFixup = ''
    patchelf \
      --set-interpreter "$(cat $NIX_CC/nix-support/dynamic-linker)" \
      --set-rpath "${libPath}" \
      $out/bin/mybinaryprogram
  '';
}</syntaxhighlight>
This can be built with:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-build mybinaryprogram.nix</syntaxhighlight>
And run with:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">./result/bin/mybinaryprogram</syntaxhighlight>
Another possibility is using a FHS-compatible Sandbox with [https://nixos.org/nixpkgs/manual/#sec-fhs-environments buildFHSUserEnv]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
# fhsUser.nix
{ pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSUserEnv {
  name = "example-env";
  targetPkgs = pkgs: with pkgs; [
    coreutils
  ];
  multiPkgs = pkgs: with pkgs; [
    zlib
    xorg.libXxf86vm
    curl
    openal
    openssl_1_0_2
    xorg.libXext
    xorg.libX11
    xorg.libXrandr
    mesa_glu
  ];
  runScript = "bash";
}).env</syntaxhighlight>
the sandbox can be entered with
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-shell fhsUser.nix</syntaxhighlight>
<br>
If your target application can't find shared libraries inside buildFHSUserEnv, you may run [https://github.com/lexleogryfon/de-generate nix-de-generate] for target application inside FHS, which will generate newenv.nix file, an nix-expression of buildFHSUserEnv with resolved dependencies for shared libraries.
== What are channels and how do they get updated? ==
{{main|Channel branches}}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
[https://github.com/NixOS/nixpkgs Nixpkgs] is the git repository containing all packages and NixOS modules/expressions. Installing packages directly from Nixpkgs master branch is possible but a bit risky as git commits are merged into master before being heavily tested. That's where channels are useful.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
A "channel" is a name for the latest "verified" git commits in Nixpkgs. Each channel has a different definition of what "verified" means. Each time a new git commit is verified, the channel declaring this verification gets updated. Contrary to an user of the git master branch, a channel user will benefit both from verified commits and binary packages from the binary cache.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Channels are reified as git branches in the [https://github.com/NixOS/nixpkgs nixpkgs repository] and as disk images in the [https://nixos.org/channels/ channels webpage]. There are several channels, each with its own use case and verification phase:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* '''nixos-unstable'''
** '''description''' Use this when you want the latest package and module versions while still benefiting from the binary cache. You can use this channel on non-NixOS systems. This channel corresponds to NixOS’s main development branch, and may thus see radical changes between channel updates. This channel is not recommended for production systems.
** '''definition''' this channel is updated depending on [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release.nix release.nix] and [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-lib.nix release-lib.nix]
* '''nixos-unstable-small'''
** '''description''' This channel is identical to <code>nixos-unstable</code> described above, except that this channel contains fewer binary packages. This means the channel gets updated faster than <code>nixos-unstable</code> (for instance, when a critical security patch is committed to NixOS’s source tree). However, the binary cache may contain less binary packages and thus using this channel may require building more packages from source than <code>nixos-unstable</code>. This channel is mostly intended for server environments and as such contains few GUI applications.
** '''definition''' this channel is updated depending on [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-small.nix release-small.nix] and [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-lib.nix release-lib.nix]
* '''nixos-YY.MM''' (where '''YY''' is a 2-digit year and '''MM''' is a 2-digit month, such as [https://nixos.org/channels/nixos-15.09/ ''nixos-17.03''])
** '''description''' These channels are called '''stable''' and only get conservative bug fixes and package upgrades. For instance, a channel update may cause the Linux kernel on your system to be upgraded from 3.4.66 to 3.4.67 (a minor bug fix), but not from 3.4.x to 3.11.x (a major change that has the potential to break things). Stable channels are generally maintained until the next stable branch is created.
** '''definition''' this channel is updated depending on [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release.nix release.nix] and [https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/release-lib.nix release-lib.nix]
* '''nixos-YY.MM-small''' (where '''YY''' is a 2-digit year and '''MM''' is a 2-digit month, such as [https://nixos.org/channels/nixos-15.09-small/ nixos-15.09-small])
** '''description''' The difference between <code>nixos-YY.MM-small</code> and <code>nixos-YY.MM</code> is the same as the one between <code>nixos-unstable-small</code> and <code>nixos-unstable</code> (see above)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Channel update works as follows:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
# Each channel has a particular job at '''hydra.nixos.org''' which must succeed:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* For NixOS: the trunk-combined [http://hydra.nixos.org/job/nixos/trunk-combined/tested tested] job, which contains some automated NixOS tests.
* For nixos-small: the unstable-small [http://hydra.nixos.org/job/nixos/unstable-small/tested tested] job.
* For nixpkgs: the trunk [http://hydra.nixos.org/job/nixpkgs/trunk/unstable unstable] job, which contains some critical release packages.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<ol start="2" style="list-style-type: decimal;">
<li>Once the job succeeds at a particular nixpkgs commit, '''cache.nixos.org''' will download binaries from '''hydra.nixos.org'''.</li>
<li>Once the above download completes, the channel updates.</li></ol>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can checkout the nixpkgs git and reset it to a particular commit of a channel. This will not affect your access to the binary cache.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How do I know where's nixpkgs channel located and at which commit? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
First <code>echo $NIX_PATH</code> to see where nix looks for the expressions. Note that nix-env uses ''~/.nix-defexpr'' regardless of ''$NIX_PATH''.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you want to know where <nixpkgs> is located:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-instantiate --find-file nixpkgs</syntaxhighlight>
To know the commit, open the .version-suffix file in the nixpkgs location. The hash after the dot is the git commit.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Nixpkgs branches ==
Branches on the nixpkgs repo have a relationship with channels, but that relationship is not 1:1.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Some branches are reified as channels (e.g. the <code>nixos-XX.YY</code> branches, or <code>nix(os|pkgs)-unstable</code>), whereas others are the starting point for those branches (e.g. the <code>master</code> or <code>release-XX.YY</code> branches). For example:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
* When a change in master needs to be backported to the current NixOS release, it is cherry-picked into the current <code>release-XX.YY</code> branch
* [[Channel branches#Channel_update_process|Hydra]] picks up this change, runs tests, and if those tests pass, updates the corresponding <code>nixos-XX.YY</code> branch, which is then reified as a channel.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
So in short, the <code>relase-XX.YY</code> branches have not been run through Hydra yet, whereas the <code>nixos-XX.YY</code> ones have.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== There's an updated version for $software on nixpkgs but not in channels, how can I use it? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You can jump the queue and use <code>nix-shell</code> with a <code>NIX_PATH</code> pointing to a tarball of the channel to get a shell for that software. Some building may occur. This will not work for system services.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="command">
NIX_PATH=nixpkgs=https://github.com/NixOS/nixpkgs/archive/release-17.09.tar.gz nix-shell -p $software
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How do I install a specific version of a package for build reproducibility etc.? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[FAQ/Pinning Nixpkgs]] and [[How to fetch Nixpkgs with an empty NIX PATH]]. Find the version of nixpkgs with the package version you want and pin nixpkgs to that. However, be aware that the pinning of a package of another nixpkgs version results in a much larger package size as not only the package itself but all dependencies (down to libc) have older versions.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
if you just want the old version of the single package but with new dependencies it is often easier to copy the package description into your scope and add it to your <code>configuration.nix</code> via: <code> mypackage-old = pkgs.callPackage ./mypackage-old.nix {};</code>.You can try to build the package as described in [[FAQ#I.27m_working_on_a_new_package.2C_how_can_I_build_it_without_adding_it_to_nixpkgs.3F|the FAQ: building a single derivation]].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== An error occurs while fetching sources from an url, how do I fix it? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
First try to update the local nixpkgs expressions with <code>nix-channel --update</code> (these describe where to download sources from and how to build them). Try your build again and the url might have already been correctly updated for the package in question. You can also subscribe the unstable channel (which includes the most up-to-date expressions) with <code>nix-channel --add http://nixos.org/channels/nixpkgs-unstable</code>, update and try the build again.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If that fails you can update the url in the nix expression yourself. [https://nixos.org/wiki/FAQ#How_do_I_know_where.27s_nixpkgs_channel_located_and_at_which_commit.3F Navigate to your channel's expressions] and find the package in one of the subdirectories. Edit the respective ''default.nix'' file by altering the ''url'' and ''sha256''. You can use <code>nix-prefetch-url url</code> to get the SHA-256 hash of source distributions.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If the shell complains that you do not have write privileges for the file system, you will have to enable them.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
start a new shell with a private mount namespace (Linux-only)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo unshare -m bash</syntaxhighlight>
remount the filesystem with write privileges (as root)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">mount -o remount,rw /nix/store</syntaxhighlight>
update the file
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nano <PATH_TO_PACKAGE>/default.nix</syntaxhighlight>
exit to shell where /nix/store is still mounted read-only
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">exit</syntaxhighlight>
Be sure to [https://github.com/NixOS/nixpkgs/issues report the incorrect url] or [https://github.com/NixOS/nixpkgs/pulls fix it yourself].
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How do I know the sha256 to use with fetchgit, fetchsvn, fetchbzr or fetchcvs? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Install <code>nix-prefetch-scripts</code> and use the corresponding nix prefetch helper.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For instance to get the checksum of a git repository use:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-prefetch-git https://git.zx2c4.com/password-store</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Or, use <code>lib.fakeHash</code> as the fetcher's hash argument, and attempt to build; Nix will tell you the actual and expected hash's mismatch, and you may copy the actual hash.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== Should I use http://hydra.nixos.org/ as a binary cache? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
No. As of 2017, all build artifacts are directly pushed to http://cache.nixos.org/ and are available there, therefore setting http://hydra.nixos.org/ as a binary cache no longer serves any function.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I'm trying to install NixOS but my WiFi isn't working and I don't have an ethernet port ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Most phones will allow you to share your WiFi connection over USB. On Android you can enable this setting via ''Settings'' > ''Wireless &amp; Networks'' / More ... > ''Tethering &amp; portable hotspot'' > ''USB tethering''. This should be enough to allow you to install NixOS, and then fix your WiFi. iPhones only let you tether using your data connection rather than WiFi.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It is also possible to build a custom NixOS installation ISO containing all the dependencies needed for an offline installation, but the default installation ISOs require internet connectivity.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
For connecting to your WiFi, see [[NixOS_Installation_Guide#Wireless]]
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How can I disable the binary cache and build everything locally? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Set the binary caches to an empty list: <code>nix.binaryCaches = [];</code> in <code>configuration.nix</code> or pass ad-hoc <code>--option binary-caches <nowiki>''</nowiki></code> as parameter to nix-build or its wrappers.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This is also useful to make simple configuration changes in NixOS (ex.: network related), when no network connectivity is available:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch --option binary-caches ''</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How do I enable sandboxed builds on non-NixOS? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Two options have to be added to make sandboxed builds work on Nix, ''build-use-sandbox'' and ''build-sandbox-paths'':
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
# /etc/nix/nix.conf
build-use-sandbox = true
build-sandbox-paths = $(nix-store -qR $(nix-build '<nixpkgs>' -A bash) | xargs echo /bin/sh=$(nix-build '<nixpkgs>' -A bash)/bin/bash)
</syntaxhighlight>
On NixOS set the following in ''configuration.nix'':
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
nix.settings.sandbox = true;
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
See [[Nix package manager#Sandbox_builds]] for more details.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== How can I install a package from unstable while remaining on the stable channel? ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you simply want to run a ''nix-shell'' with a package from unstable, you can run a command like the following:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nix-shell -I nixpkgs=channel:nixpkgs-unstable -p somepackage</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
It is possible to have multiple nix-channels simultaneously. To add the unstable channel with the specifier ''unstable'',
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable</syntaxhighlight>
After updating the channel
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">sudo nix-channel --update nixos-unstable</syntaxhighlight>
queries via <code>nix-env</code> will show packages from both ''stable'' and ''unstable''. Use this to install unstable packages into your user environment. The following snippet shows how this can be done in ''configuration.nix''.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="nix">
{ config, pkgs, ... }:
let
  unstable = import <nixos-unstable> {};
in {
  environment.systemPackages = [ unstable.PACKAGE_NAME ];
}
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
This only changes what version of <code>PACKAGE_NAME</code> is available on <code>$PATH</code>. If the package you want to take from unstable is installed through a NixOS module, you must use [[overlays]]:
<syntaxhighlight lang="nix">
{ config, pkgs, ... }:
let
  unstable = import <nixos-unstable> {};
in {
  nixpkgs.overlays = [
    (self: super: {
       PACKAGE_NAME = unstable.PACKAGE_NAME;
    })
  ];
}
</syntaxhighlight>
Note that this will rebuild all packages depending on the overlaid package, which may be a lot. Some modules offer a <code>services.foo.package</code> to change the actual derivation used by the module without and overlay, and without recompiling dependencies ([https://nixos.org/manual/nixos/stable/options.html#opt-services.gvfs.package example]).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If you want to install unfree packages from unstable you need to also set allowUnfree by replacing the import statment above with:
<syntaxhighlight lang="nix">
import <nixos-unstable> { config = { allowUnfree = true; }; }
</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I'm unable to connect my USB HDD | External HDD is failing to mount automatically ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
'''Note:''' If you're using a kernel with at least version 5.6, you don't need to explicitly add this.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
exfat is not supported in NixOS by default - since there are legality issues still with exFAT filesystem.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">su nano /etc/nixos/configuration.nix</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Add this line to your configuration file.
<syntaxhighlight lang="bash">boot.extraModulePackages = [ config.boot.kernelPackages.exfat-nofuse ];</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
After saving the file rebuild NixOS:
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Restart NixOS.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== What is the origin of the name "Nix" ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
The name <code>Nix</code> comes from the Dutch word [https://en.wiktionary.org/wiki/nix niks] which means ''nothing''. It reflects the fact that Nix derivations do not have access to anything that has not been explicitly declared as an input.<ref>Eelco Dolstra et al. “Nix: A Safe and Policy-Free System for Software Deployment.” LiSA (2004), https://pdfs.semanticscholar.org/5fd8/8f89bd8738816e62808a1b7fb12d3ab14a2f.pdf</ref>
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== What does it mean to say that NixOS is "immutable" ==
Immutability is a property of data, in general, which means that the data cannot be modified after it is created. In the context of an operating system, it really means that certain parts of the system have this property. In the case of Nix and NixOS, that includes the Nix store, where files can be created but not modified after the time they are created. It does not apply to every part of the operating system, in that users can still modify their own files in their home directory, for example.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== I'm getting ‘infinite recursion’ errors when trying to do something clever with <code>imports</code> ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
Evaluating the <code>imports</code> attribute of a NixOS module (such as configuration.nix) is a prerequisite for evaluating just about everything else, so trying anything clever with <code>imports</code> is a common source of infinite recursion (because the evaluator can't determine the values of packages and options without knowing what is imported, and can't determine what is imported without knowing the values of packages or options).
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
You should not try to conditionally import other modules based on other values. Make your imports unconditional, and make the modules that you're importing have conditional ''behavior'' based on the values of options.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
If it helps, think of <code>imports</code> as akin to an <code>#include</code> directive in C.
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
(Note that none of this applies to the [https://nix.dev/manual/nix/stable/language/builtins#builtins-import <code>import</code> built-in Nix language function], which is its own thing.)
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
{{:FAQ/Libraries}}
{{:FAQ/nix-env -iA}}
{{:FAQ/stateVersion}}
{{:FAQ/notfound}}
{{:FAQ/unfree}}

</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
== References ==
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
[[Category:Cookbook]]
</div>