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 @@
-
- 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
-
-# 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:
-
-# 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/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 @@
-
+
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 @@
+
+ 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
+
+
+# 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:
+
+
+# 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.
+
+