This section provides solutions for some common problems. See the Nix bug tracker for a list of currently known issues.

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

It is possible, especially in nix-store --verify or when running the garbage collector, to run out of Berkeley DB locks, like this: $ nix-store --verify checking path existence checking path realisability checking the derivers table checking the references table Berkeley DB error: Lock table is out of available object entries error: Db::get: Cannot allocate memory A workaround is to increase the number of locks that Berkeley DB allocates. (The real solution would be for Nix to not use so many locks.) This can be done by putting the following in the file /nix/var/nix/db/DB_CONFIG: set_lk_max_locks 100000 set_lk_max_lockers 100000 set_lk_max_objects 100000 (Increase these numbers if necessary.) Then make sure that there are no running Nix processes and delete the Berkeley DB environment: $ rm /nix/var/nix/db/__db.* The Berkeley DB environment is automatically recreated with the new limits when you run any Nix command.

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