This section provides solutions for some common problems.

Symptom: Nix operations (in particular the nix-store operations --gc, --verify, and --clear-substitutes — the latter being called by nix-channel --update) failing: $ nix-store --verify error: Db::del: Cannot allocate memory Possible solution: make sure that no Nix processes are running, then do: $ cd /nix/var/nix/db $ rm __db.00*

Symptom: you get error messages such as Berkeley DB message: Finding last valid log LSN: file: 1 offset 28 Berkeley DB error: file validpaths (meta pgno = 0) has LSN [483][34721]. Berkeley DB error: end of log is [1][28] Berkeley DB error: /nix/var/nix/db/validpaths: unexpected file type or format or other weird Berkeley DB errors, and they don’t go away (i.e., automatic recovery doesn’t work). This may be the case after a system crash. Solution: first try to run db_recover and then nix-store --verify: $ db_recover -h /nix/var/nix/db $ nix-store --verify (Make sure that you have the right version of db_recover, namely, Berkeley DB 4.4 for Nix 0.10, and 4.5 for Nix 0.11.) If that doesn’t work, it’s time to bring out the big guns: $ cd /nix/var/nix $ cp -pr db db-backup (making a backup just in case) $ cd db $ rm __db.* log* (removing the Berkeley DB environment) $ mkdir tmp $ for i in *; do db_dump $i | (cd tmp && db_load $i); done (ignore error messages about non-database files like “reserved”) $ mv tmp/* . $ nix-store --verify

Symptom: when installing or upgrading, you get an error message such as $ nix-env -i docbook-xml ... adding /nix/store/s5hyxgm62gk2...-docbook-xml-4.2 collission between `/nix/store/s5hyxgm62gk2...-docbook-xml-4.2/xml/dtd/docbook/calstblx.dtd' and `/nix/store/06h377hr4b33...-docbook-xml-4.3/xml/dtd/docbook/calstblx.dtd' at /nix/store/...-builder.pl line 62. The cause is that two installed packages in the user environment have overlapping filenames (e.g., xml/dtd/docbook/calstblx.dtd. This usually happens when you accidentally try to install two versions of the same package. For instance, in the example above, the Nix Packages collection contains two versions of docbook-xml, so nix-env -i will try to install both. The default user environment builder has no way to way to resolve such conflicts, so it just gives up. Solution: remove one of the offending packages from the user environment (if already installed) using nix-env -e, or specify exactly which version should be installed (e.g., nix-env -i docbook-xml-4.2). Alternatively, you can modify the user environment builder script (in prefix/share/nix/corepkgs/buildenv/builder.pl) to implement some conflict resolution policy. E.g., the script could be modified to rename conflicting file names, or to pick one over the other.

Symptom: when building something, you get an error message such as ... mkdir: cannot create directory `/nix/store/name': Too many links This is usually because you have more than 32,000 subdirectories in /nix/store, as can be seen using ls -l: $ ls -l /nix/store drwxrwxrwt 32000 nix nix 4620288 Sep 8 15:08 store The ext2 file system is limited to a inode link count of 32,000 (each subdirectory increasing the count by one). Furthermore, the st_nlink field of the stat system call is a 16-bit value. This only happens on very large Nix installations (such as build machines). Quick solution: run the garbage collector. Real solution: put the Nix store on a file system that supports more than 32,000 subdirectories per directory, such as ReiserFS. (This doesn’t solve the st_nlink limit, but ReiserFS lies to the kernel by reporting a link count of 1 if it exceeds the limit.)