Add 'infra/libkookie/' from commit 'd661aa56a8843e991261510c1bb28fdc2f6975ae'

git-subtree-dir: infra/libkookie
git-subtree-mainline: 49f735974dd103039ddc4cb576bb76555164a9e7
git-subtree-split: d661aa56a8843e991261510c1bb28fdc2f6975ae

1 files changed, 36 insertions, 0 deletions

diff --git a/infra/libkookie/nixpkgs/nixos/doc/manual/administration/store-corruption.xml b/infra/libkookie/nixpkgs/nixos/doc/manual/administration/store-corruption.xml
new file mode 100644
index 000000000000..b9d11152d5e1
--- /dev/null
+++ b/infra/libkookie/nixpkgs/nixos/doc/manual/administration/store-corruption.xml
@@ -0,0 +1,36 @@
+<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>
+<prompt># </prompt>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>
+<prompt># </prompt>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>