summary refs log tree commit diff
path: root/nixos/doc/manual/administration/store-corruption.xml
blob: 9f567042b727e956c860d8190cf392fb0b09f76f (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<section xmlns="http://docbook.org/ns/docbook"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xmlns:xi="http://www.w3.org/2001/XInclude"
        version="5.0"
        xml:id="sec-nix-store-corruption">

<title>Nix Store Corruption</title>

<para>After a system crash, it’s possible for files in the Nix store
to become corrupted.  (For instance, the Ext4 file system has the
tendency to replace un-synced files with zero bytes.)  NixOS tries
hard to prevent this from happening: it performs a
<command>sync</command> before switching to a new configuration, and
Nix’s database is fully transactional.  If corruption still occurs,
you may be able to fix it automatically.</para>

<para>If the corruption is in a path in the closure of the NixOS
system configuration, you can fix it by doing

<screen>
# nixos-rebuild switch --repair
</screen>

This will cause Nix to check every path in the closure, and if its
cryptographic hash differs from the hash recorded in Nix’s database,
the path is rebuilt or redownloaded.</para>

<para>You can also scan the entire Nix store for corrupt paths:

<screen>
# nix-store --verify --check-contents --repair
</screen>

Any corrupt paths will be redownloaded if they’re available in a
binary cache; otherwise, they cannot be repaired.</para>

</section>