1 files changed, 0 insertions, 34 deletions
diff --git a/nixpkgs/nixos/doc/manual/from_md/administration/store-corruption.section.xml b/nixpkgs/nixos/doc/manual/from_md/administration/store-corruption.section.xml
deleted file mode 100644
index 9ed572d484dc..000000000000
--- a/nixpkgs/nixos/doc/manual/from_md/administration/store-corruption.section.xml
+++ /dev/null
@@ -1,34 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" 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
-    <literal>sync</literal> 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
-  </para>
-  <programlisting>
-# nixos-rebuild switch --repair
-</programlisting>
-  <para>
-    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:
-  </para>
-  <programlisting>
-# nix-store --verify --check-contents --repair
-</programlisting>
-  <para>
-    Any corrupt paths will be redownloaded if they’re available in a
-    binary cache; otherwise, they cannot be repaired.
-  </para>
-</section>