Frank
2406641bc6
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).
3.1 KiB
type, description, tags, timestamp
| type | description | tags | timestamp | |
|---|---|---|---|---|
| reference | Dankserver's /mnt/entropy volume: the LUKS/array chain, the crypttab + fstab boot path, and the containers bound to it |
|
2026-10-31 |
Entropy Volume
/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.
Chain
/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
Files that own it
| 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) |
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.
Law
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.
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.
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.