From 4df0b9903d391b7531e06ca859c46f261335bdc1 Mon Sep 17 00:00:00 2001
From: Bobby Rong <rjl931189261@126.com>
Date: Fri, 2 Jul 2021 10:48:31 +0800
Subject: [PATCH] nixos: nixos/doc/manual/administration/store-corruption.xml
 to CommonMark

---
 .../store-corruption.section.md               | 28 +++++++++++++++
 .../administration/store-corruption.xml       | 36 -------------------
 .../manual/administration/troubleshooting.xml |  2 +-
 .../store-corruption.section.xml              | 34 ++++++++++++++++++
 4 files changed, 63 insertions(+), 37 deletions(-)
 create mode 100644 nixos/doc/manual/administration/store-corruption.section.md
 delete mode 100644 nixos/doc/manual/administration/store-corruption.xml
 create mode 100644 nixos/doc/manual/from_md/administration/store-corruption.section.xml

diff --git a/nixos/doc/manual/administration/store-corruption.section.md b/nixos/doc/manual/administration/store-corruption.section.md
new file mode 100644
index 000000000000..bd8a5772b37c
--- /dev/null
+++ b/nixos/doc/manual/administration/store-corruption.section.md
@@ -0,0 +1,28 @@
+# Nix Store Corruption {#sec-nix-store-corruption}
+
+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 `sync` 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.
+
+If the corruption is in a path in the closure of the NixOS system
+configuration, you can fix it by doing
+
+```ShellSession
+# nixos-rebuild switch --repair
+```
+
+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.
+
+You can also scan the entire Nix store for corrupt paths:
+
+```ShellSession
+# nix-store --verify --check-contents --repair
+```
+
+Any corrupt paths will be redownloaded if they're available in a binary
+cache; otherwise, they cannot be repaired.
diff --git a/nixos/doc/manual/administration/store-corruption.xml b/nixos/doc/manual/administration/store-corruption.xml
deleted file mode 100644
index b9d11152d5e1..000000000000
--- a/nixos/doc/manual/administration/store-corruption.xml
+++ /dev/null
@@ -1,36 +0,0 @@
-<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>
diff --git a/nixos/doc/manual/administration/troubleshooting.xml b/nixos/doc/manual/administration/troubleshooting.xml
index 16cf4f00b26d..218324b299ac 100644
--- a/nixos/doc/manual/administration/troubleshooting.xml
+++ b/nixos/doc/manual/administration/troubleshooting.xml
@@ -11,6 +11,6 @@
  <xi:include href="../from_md/administration/boot-problems.section.xml" />
  <xi:include href="../from_md/administration/maintenance-mode.section.xml" />
  <xi:include href="../from_md/administration/rollback.section.xml" />
- <xi:include href="store-corruption.xml" />
+ <xi:include href="../from_md/administration/store-corruption.section.xml" />
  <xi:include href="network-problems.xml" />
 </chapter>
diff --git a/nixos/doc/manual/from_md/administration/store-corruption.section.xml b/nixos/doc/manual/from_md/administration/store-corruption.section.xml
new file mode 100644
index 000000000000..9ed572d484dc
--- /dev/null
+++ b/nixos/doc/manual/from_md/administration/store-corruption.section.xml
@@ -0,0 +1,34 @@
+<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>