fix(dankserver): mount /mnt/entropy from its LUKS mapper at boot

The crypttab entry named the md RAID array UUID (61bd6eaf-...) where a luks
entry takes the LUKS container UUID (cd86c728-...), so
systemd-cryptsetup@entropy.service could never produce /dev/mapper/entropy and
the fstab entry could not resolve either; the volume only appeared when a
desktop session let udisks2 unlock it, which kept the broken boot path hidden
for a year. The keyfile was wrong as well: 27 bytes, i.e. the 26-character
passphrase plus a trailing newline, and cryptsetup hashes the file whole.

Records the host config as dankserver/host/{crypttab,fstab} (the dankclaw/host
precedent), rewrites the Entropy Volume page to own the chain, the UUID law and
the keyfile contract, and comments out the now-unmountable /dev/md0 line.

Proven on the host: /etc/{crypttab,fstab} byte-identical to the repo copies,
reboot into 7.0.0-42-generic mounts /mnt/entropy from /dev/mapper/entropy, all
12 containers returned, frank-archon back to 141 t/s (was 6.7 t/s on a wedged
amdgpu queue). ./tests/run.sh: ALL TESTS PASSED (749).

dankserver/host/crypttab

@@ -0,0 +1 @@
+entropy	UUID=cd86c728-459e-4f3a-bcc2-41ecf84685ec	/etc/entropy	nofail,luks

dankserver/host/fstab

@@ -0,0 +1,18 @@
+# /etc/fstab: static file system information.
+#
+# Use 'blkid' to print the universally unique identifier for a
+# device; this may be used with UUID= as a more robust way to name devices
+# that works even if disks are added and removed. See fstab(5).
+#
+# <file system> <mount point>   <type>  <options>       <dump>  <pass>
+# / was on /dev/nvme0n1p2 during curtin installation
+/dev/disk/by-uuid/4f3731d2-fb7b-48e7-a79f-0e33cb8a4162 / ext4 defaults 0 1
+# /boot/efi was on /dev/nvme0n1p1 during curtin installation
+/dev/disk/by-uuid/183C-442D /boot/efi vfat defaults 0 1
+#/dev/disk/by-label/archive-one /mnt/archive-one auto nosuid,nodev,nofail,x-gvfs-show 0 0
+#/dev/disk/by-label/archive-two /mnt/archive-two auto nosuid,nodev,nofail,x-gvfs-show 0 0
+# /dev/md0 is a LUKS container, not a filesystem; its ext4 is mounted via
+# /dev/mapper/entropy on the next line. Mounting /dev/md0 directly fails.
+#/dev/md0 /mnt/md0 ext4 auto,nofail,nosuid,nodev 0 0 
+/dev/mapper/entropy /mnt/entropy ext4 auto,nosuid,nofail,nodev,x-gvfs-show 0 0
+/swapfile none swap sw 0 0

serverAppConfigs-docs/Dankserver/Entropy Volume.md

@@ -1,51 +1,68 @@
 ---
 type: reference
-description: "The Dankserver entropy volume is a RAID-backed LUKS filesystem mounted at"
+description: "Dankserver's /mnt/entropy volume: the LUKS/array chain, the crypttab + fstab boot path, and the containers bound to it"
 tags:
   - dankserver
-timestamp: 2026-08-28
+timestamp: 2026-10-31
 ---
 
 # Entropy Volume
 
-The Dankserver entropy volume is a RAID-backed LUKS filesystem mounted at
-`/mnt/entropy`. The command-line helper reuses the host's desktop-integrated
-`udisks2`, `crypttab`, and `fstab` configuration; it does not store or handle
-the passphrase itself.
+`/mnt/entropy` is the ext4 filesystem on the LUKS container holding `/dev/md0`
+(RAID6, seven disks). The media stack's data lives there, so the mount is a boot
+dependency for those containers rather than a convenience.
 
-## Command-line mount
-
-```bash
-/home/dank/serverAppConfigs/scripts/mount-entropy.sh
-```
-
-Run it as the normal desktop user (`dank`), not from a root shell. `udisksctl`
-will securely prompt for the LUKS passphrase. `sudo mount /mnt/entropy` then
-uses the existing `/etc/fstab` entry, preserving its options:
+## Chain
 
 ```text
-nosuid,nodev
+/dev/md0                     <- mdadm (its mdadm.conf ARRAY is what makes md0 exist at boot)
+  -> LUKS UUID=cd86c728-459e-4f3a-bcc2-41ecf84685ec   keyfile: /etc/entropy
+     -> /dev/mapper/entropy  <- systemd-cryptsetup@entropy.service
+        -> ext4 at /mnt/entropy  <- mnt-entropy.mount, from /etc/fstab
 ```
 
-The existing mountpoint is owned by `dank:dankserver` with mode `0755`; the
-helper deliberately does not run `chmod` or `chown`, so it cannot silently
-change those permissions.
+## Files that own it
 
-## Device path
+| Repo file | Installs to | Produces at boot |
+|---|---|---|
+| `dankserver/host/crypttab` | `/etc/crypttab` | `systemd-cryptsetup@entropy.service` → `/dev/mapper/entropy` |
+| `dankserver/host/fstab` | `/etc/fstab` | `mnt-entropy.mount` (mountpoint `dank:dankserver`, `0755`) |
 
-The current storage chain is:
+Deploy a change by copying the file onto the host, then
+`systemctl daemon-reload && update-initramfs -u`. The initramfs step is not
+optional: the cryptsetup hook bakes `/etc/crypttab` into the initrd, and the
+array is unlocked there, before the real root mounts. `scripts/mount-entropy.sh`
+(`udisksctl unlock` + `mount`) stays as the manual path for a volume that was
+never unlocked; on a correct boot it is redundant.
 
-```text
-/dev/md0 -> LUKS UUID cd86c728-459e-4f3a-bcc2-41ecf84685ec
-         -> ext4 label entropy
-         -> /mnt/entropy
-```
+## Law
 
-The helper checks that `/dev/md0` exists and exits successfully if the volume
-is already mounted. It is intentionally specific to this host and volume:
-that avoids accidentally unlocking or mounting a different disk.
+**`crypttab`'s device field takes the LUKS UUID, never the md array UUID.**
+`blkid` prints both on adjacent lines for a RAID-backed container, and the file
+shipped since 2025 carried the array UUID (`61bd6eaf-…`) where the LUKS container
+is `cd86c728-…`. The generator produced a perfectly valid unit pointing at a
+device that never appears, so the mapper came into existence only through a
+desktop `udisks2` session — the volume looked mounted on every login while every
+boot failed to mount it. The matching `fstab` line named the same wrong UUID
+directly instead of the mapper.
 
-## Related
+**A LUKS keyfile is hashed whole, so a trailing newline is a different
+passphrase.** The shipped `/etc/entropy` was 27 bytes — 26 characters plus `\n` —
+and `cryptsetup` rejected it even after the UUID was corrected. Keyfiles stay
+`0600` with no trailing newline; prove it with
+`cryptsetup open --test-passphrase --key-file /etc/entropy UUID=…` *before*
+relying on it for a boot.
 
-- [[Storage Policy]]
-- [[Dankserver Stack]]
+**Prove a mount fix with the artifacts systemd generates, not with a live
+mount.** The regenerated `systemd-cryptsetup@entropy.service` naming the right
+device, `findmnt /mnt/entropy` sourcing `/dev/mapper/entropy`, and a matching
+checksum between the repo copy and the host copy are the evidence. A mount that
+exists because someone logged in proves nothing about the boot path — that
+exactly describes the year this bug survived.
+
+## Consumers
+
+`jellyfin`, `copyparty`, and `plex` bind paths under `/mnt/entropy`; with the
+volume absent they start `active (healthy)` against empty directories, which is
+how a missing 91 TiB volume hides. See [[Dankserver Stack]] for the stack and
+[[Storage Policy]] for what may be written here.

serverAppConfigs-docs/index.md

@@ -48,7 +48,7 @@ is a locator: one row, one clause, no numbers.
 | [[Calibre-Web]] | Calibre-Web is a web application that browses, reads, and downloads eBooks from an existing Calibre library database. |
 | [[Copyparty]] | Copyparty is a lightweight file server and media streamer that runs as a single Python binary. |
 | [[Dankserver Stack]] | Service inventory and routing overview for the media and library host. |
-| [[Entropy Volume]] | The Dankserver entropy volume is a RAID-backed LUKS filesystem mounted at |
+| [[Entropy Volume]] | Dankserver's /mnt/entropy volume: the LUKS/array chain, the crypttab + fstab boot path, and the containers bound to it |
 | [[Jellyfin]] | Jellyfin on Dankserver: quadlet unit, overlay metadata view, provider keys, ports, access, transcode status. |
 | [[mariadb]] | The MariaDB backend for RomM: quadlet unit, network alias, env-file secret handling, and the backup path. |
 | [[Media Audiobook Relayout]] | Re-filing /mnt/entropy/Audiobooks by Plex's chapter rows: narrator shelves, no renumbering, the refusals. |