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

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:

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

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

{{main|Channel branches}}

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

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

** '''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)

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

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.

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

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>

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

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