dank/serverAppConfigs
1
0 Fork 0
Code Issues 4 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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).
This commit is contained in:
Frank committed 2026-10-31 11:56:39 -07:00
1 parent dbcf8a2c35
commit 2406641bc6
4 files changed
+69 -33
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

serverAppConfigs-docs/Dankserver/Entropy Volume.md
+49 -32
View File
@@ -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.