FAQ/en: Difference between revisions

<languages/>

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.

http://unix.stackexchange.com/questions/tagged/nixos can also be used for questions.

The old wiki at nixos.wiki has several problems:

* The wiki infrastructure, which was supposed to be made public after launch, never ended-up being made public.

Also see:

* https://greasyfork.org/en/scripts/495011-redirect-to-wiki-nixos-org (trivial userscript to redirect nixos.wiki links here)

Mainly because Nix is intended to be lightweight, easy to learn, and portable (zero dependencies).

<syntaxhighlight lang="nix"># /etc/nixos/configuration.nix

   };

}</syntaxhighlight>

Check 'man configuration.nix' for these options. Rebuild for these options to take effect:

<syntaxhighlight lang="bash">nixos-rebuild switch</syntaxhighlight>

List all store paths that form the system closure and realise them:

<build output and list of successfully realised paths>

</syntaxhighlight>

Repeat for your user and further profiles:

<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.

Consult man pages of nix-store and nix-instantiate for further information.

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.  

</syntaxhighlight>

View the available generations of your channel:

20  2014-08-12 19:09:20  (current)

</syntaxhighlight>

To rollback to the previous generation:

switching from generation 20 to 19

</syntaxhighlight>

To switch to a particular generation:

</syntaxhighlight>

<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.

To build a package with -Og and -g, and without stripping debug symbols use:

See also [[Debug Symbols]]

As root you can run nix-build with the --check flag:

<syntaxhighlight lang="bash">sudo nix-build --check -A ncdu</syntaxhighlight>

There are many ways, one is the following:

Another way is using [[Home Manager]].

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.

programs.nix-ld = {

   enable = true;

};</syntaxhighlight>

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.

   '';

}</syntaxhighlight>

This can be built with:

<syntaxhighlight lang="bash">nix-build mybinaryprogram.nix</syntaxhighlight>

And run with:

<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]

   runScript = "bash";

}).env</syntaxhighlight>

the sandbox can be entered with

<syntaxhighlight lang="bash">nix-shell fhsUser.nix</syntaxhighlight>

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.

{{main|Channel branches}}

* 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.

<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>

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.

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''.

<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.

Branches on the nixpkgs repo have a relationship with channels, but that relationship is not 1:1.

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.

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.

</syntaxhighlight>

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.

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]].

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.

If the shell complains that you do not have write privileges for the file system, you will have to enable them.

<syntaxhighlight lang="bash">sudo unshare -m bash</syntaxhighlight>

remount the filesystem with write privileges (as root)

<syntaxhighlight lang="bash">mount -o remount,rw /nix/store</syntaxhighlight>

update the file

<syntaxhighlight lang="bash">nano <PATH_TO_PACKAGE>/default.nix</syntaxhighlight>

exit to shell where /nix/store is still mounted read-only

<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].

Install <code>nix-prefetch-scripts</code> and use the corresponding nix prefetch helper.

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.

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.

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.  

For connecting to your WiFi, see [[NixOS_Installation_Guide#Wireless]]

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.

<syntaxhighlight lang="bash">nixos-rebuild switch --option binary-caches ''</syntaxhighlight>

Two options have to be added to make sandboxed builds work on Nix, ''build-use-sandbox'' and ''build-sandbox-paths'':

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'':

See [[Nix package manager#Sandbox_builds]] for more details.

If you simply want to run a ''nix-shell'' with a package from unstable, you can run a command like the following:

<syntaxhighlight lang="bash">sudo nix-channel --add https://nixos.org/channels/nixos-unstable nixos-unstable</syntaxhighlight>

After updating the channel

<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''.

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, ... }:

}

</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]).

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>

'''Note:''' If you're using a kernel with at least version 5.6, you don't need to explicitly add this.

Add this line to your configuration file.

<syntaxhighlight lang="bash">boot.extraModulePackages = [ config.boot.kernelPackages.exfat-nofuse ];</syntaxhighlight>

Restart NixOS.

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>

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.

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).

{{:FAQ/stateVersion}}

{{:FAQ/notfound}}

<!-- Transclude subpages -->