<appendix xmlns="http://docbook.org/ns/docbook"
          xmlns:xlink="http://www.w3.org/1999/xlink">

<title>Troubleshooting</title>


<para>This section provides solutions for some common problems.</para>


<section><title>Berkeley DB: <quote>Cannot allocate memory</quote></title>

<para>Symptom: Nix operations (in particular the
<command>nix-store</command> operations <option>--gc</option>,
<option>--verify</option>, and <option>--clear-substitutes</option> —
the latter being called by <command>nix-channel --update</command>)
failing:

<screen>
$ nix-store --verify
error: Db::del: Cannot allocate memory</screen>

</para>

<para>Possible solution: make sure that no Nix processes are running,
then do:

<screen>
$ cd /nix/var/nix/db
$ rm __db.00*</screen>

</para>

</section>


<section><title>Berkeley DB gives weird error messages</title>

<para>Symptom: you get error messages such as

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

or other weird Berkeley DB errors, and they don’t away (i.e.,
automatic recovery doesn’t work).  This may be the case after a system crash.</para>

<para>Solution: first try to run <command>db_recover</command> and
then <link linkend='refsec-nix-store-verify'><command>nix-store
--verify</command></link>:

<screen>
$ db_recover -h /nix/var/nix/db
$ nix-store --verify</screen>

(Make sure that you have the right version of
<command>db_recover</command>, namely, Berkeley DB 4.4 for Nix 0.10,
and 4.5 for Nix 0.11.)</para>

<para>If that doesn’t work, it’s time to bring out the big guns:

<screen>
$ cd /nix/var/nix
$ cp -pr db db-backup  <lineannotation>(making a backup just in case)</lineannotation>
$ cd db
$ rm __db.* log*  <lineannotation>(removing the Berkeley DB environment)</lineannotation>
$ mkdir tmp
$ for i in *; do db_dump $i | (cd tmp &amp;&amp; db_load $i); done 
<lineannotation>(ignore error messages about non-database files like “reserved”)</lineannotation>
$ mv tmp/* .
$ nix-store --verify</screen>

</para>

</section>



<section><title>Collisions in <command>nix-env</command></title>

<para>Symptom: when installing or upgrading, you get an error message such as

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

</para>

<para>The cause is that two installed packages in the user environment
have overlapping filenames (e.g.,
<filename>xml/dtd/docbook/calstblx.dtd</filename>.  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 <literal>docbook-xml</literal>, so
<command>nix-env -i</command> will try to install both.  The default
user environment builder has no way to way to resolve such conflicts,
so it just gives up.</para>

<para>Solution: remove one of the offending packages from the user
environment (if already installed) using <command>nix-env
-e</command>, or specify exactly which version should be installed
(e.g., <literal>nix-env -i docbook-xml-4.2</literal>).</para>

<para>Alternatively, you can modify the user environment builder
script (in
<filename><replaceable>prefix</replaceable>/share/nix/corepkgs/buildenv/builder.pl</filename>)
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.</para>

</section>


<section><title><quote>Too many links</quote> error in the Nix
store</title>


<para>Symptom: when building something, you get an error message such as

<screen>
...
<literal>mkdir: cannot create directory `/nix/store/<replaceable>name</replaceable>': Too many links</literal></screen>

</para>

<para>This is usually because you have more than 32,000 subdirectories
in <filename>/nix/store</filename>, as can be seen using <command>ls
-l</command>:

<screen>
$ ls -l /nix/store
drwxrwxrwt 32000 nix nix 4620288 Sep 8 15:08 store</screen>

The <literal>ext2</literal> file system is limited to a inode link
count of 32,000 (each subdirectory increasing the count by one).
Furthermore, the <literal>st_nlink</literal> field of the
<function>stat</function> system call is a 16-bit value.</para>

<para>This only happens on very large Nix installations (such as build
machines).</para>

<para>Quick solution: run the garbage collector.</para>

<para>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 <literal>st_nlink</literal> limit, but
ReiserFS lies to the kernel by reporting a link count of 1 if it
exceeds the limit.)</para>

</section>
  


</appendix>