2014-08-24 18:18:18 +01:00
|
|
|
|
<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>
|
2016-06-01 15:23:32 +01:00
|
|
|
|
# nixos-rebuild switch --repair
|
2014-08-24 18:18:18 +01:00
|
|
|
|
</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>
|
2016-06-01 15:23:32 +01:00
|
|
|
|
# nix-store --verify --check-contents --repair
|
2014-08-24 18:18:18 +01:00
|
|
|
|
</screen>
|
|
|
|
|
|
|
|
|
|
Any corrupt paths will be redownloaded if they’re available in a
|
|
|
|
|
binary cache; otherwise, they cannot be repaired.</para>
|
|
|
|
|
|
2016-06-01 15:23:32 +01:00
|
|
|
|
</section>
|