rewritten: chain, owning files, the UUID law, the keyfile contract
serverAppConfigs-docs/index.md
regenerated with scripts/gen-vault-index.py
Why it was broken
Two defects, both invisible whenever someone was logged in:
crypttab named the wrong UUID. It carried 61bd6eaf-… — the md RAID array UUID — where a luks entry takes the LUKS container UUID (cd86c728-…); blkid prints both on adjacent lines. The generated systemd-cryptsetup@entropy.service pointed at a device that never appears, so /dev/mapper/entropy never existed at boot and the old fstab line (UUID=61bd6eaf-… /mnt/entropy) could not resolve either. udisks2 unlocked the volume on every desktop login, so the volume looked mounted while the boot path stayed broken since 2025-09-14.
The keyfile had a trailing newline./etc/entropy was 27 bytes — a 26-character passphrase plus \n — and cryptsetup hashes the whole file, so the newline is part of the secret. Proven with cryptsetup open --test-passphrase: the 27-byte variant fails, the 26-byte variant unlocks.
Evidence
Host /etc/crypttab and /etc/fstab are byte-identical to the committed copies (sha256 239729205… / 7ee85c3af…).
Rebooted host on 7.0.0-42-generic (the GRUB default; initrds rebuilt for both installed kernels so the corrected crypttab is on the boot path either way): findmnt /mnt/entropy → /dev/mapper/entropy ext4, md0[7/7][UUUUUUU], the stale mnt-md0.mount failure cleared.
All 12 containers returned. frank-archon/health → {"status":"ok","model":"frank-archon","in_flight":0,"queue_cap":32}; a timed completion came back at 141 t/s with draft_n_accepted: 22/26, against 6.7 t/s before the reboot (radiance's own watchdog had logged a wedged amdgpu queue on both ranks — see the endpoint page's Laws).
./tests/run.sh in this worktree → ALL TESTS PASSED (749 assertions); scripts/check-vault-links.py → 122 pages, 0 unresolved links.
Notes
deploy-plan.py maps any dankserver/host/** change to jellyfin + plex (the pre-existing rule for that prefix). Restarting those two after a mount change is the intended behaviour, not a surprise.
scripts/mount-entropy.sh is untouched; the page now describes it as the manual fallback rather than the mount mechanism, since the boot path is the owner.
Unrelated pre-existing breakage observed while verifying, not touched here: nvidia-cdi-refresh.path / nvidia-cdi-refresh.service fail at boot on this AMD-only box (vestigial nvidia-container-toolkit).
## What
`/mnt/entropy` on Dankserver now mounts at boot from its LUKS mapper, and the host's `crypttab` + `fstab` are recorded in the repo for the first time.
| File | Change |
|---|---|
| `dankserver/host/crypttab` | new — `entropy UUID=cd86c728-459e-4f3a-bcc2-41ecf84685ec /etc/entropy nofail,luks` |
| `dankserver/host/fstab` | new — the real `/etc/fstab`, with the entropy entry pointed at `/dev/mapper/entropy` and the dead `/dev/md0 /mnt/md0` line commented out |
| `serverAppConfigs-docs/Dankserver/Entropy Volume.md` | rewritten: chain, owning files, the UUID law, the keyfile contract |
| `serverAppConfigs-docs/index.md` | regenerated with `scripts/gen-vault-index.py` |
## Why it was broken
Two defects, both invisible whenever someone was logged in:
1. **`crypttab` named the wrong UUID.** It carried `61bd6eaf-…` — the *md RAID array* UUID — where a `luks` entry takes the *LUKS container* UUID (`cd86c728-…`); `blkid` prints both on adjacent lines. The generated `systemd-cryptsetup@entropy.service` pointed at a device that never appears, so `/dev/mapper/entropy` never existed at boot and the old `fstab` line (`UUID=61bd6eaf-… /mnt/entropy`) could not resolve either. `udisks2` unlocked the volume on every desktop login, so the volume *looked* mounted while the boot path stayed broken since 2025-09-14.
2. **The keyfile had a trailing newline.** `/etc/entropy` was 27 bytes — a 26-character passphrase plus `\n` — and `cryptsetup` hashes the whole file, so the newline is part of the secret. Proven with `cryptsetup open --test-passphrase`: the 27-byte variant fails, the 26-byte variant unlocks.
## Evidence
- Host `/etc/crypttab` and `/etc/fstab` are byte-identical to the committed copies (`sha256 239729205…` / `7ee85c3af…`).
- Rebooted host on `7.0.0-42-generic` (the GRUB default; initrds rebuilt for both installed kernels so the corrected crypttab is on the boot path either way): `findmnt /mnt/entropy` → `/dev/mapper/entropy ext4`, `md0` `[7/7][UUUUUUU]`, the stale `mnt-md0.mount` failure cleared.
- All 12 containers returned. `frank-archon` `/health` → `{"status":"ok","model":"frank-archon","in_flight":0,"queue_cap":32}`; a timed completion came back at **141 t/s** with `draft_n_accepted: 22/26`, against 6.7 t/s before the reboot (radiance's own watchdog had logged a wedged amdgpu queue on both ranks — see the endpoint page's Laws).
- `./tests/run.sh` in this worktree → `ALL TESTS PASSED` (749 assertions); `scripts/check-vault-links.py` → `122 pages, 0 unresolved links`.
## Notes
- `deploy-plan.py` maps any `dankserver/host/**` change to `jellyfin` + `plex` (the pre-existing rule for that prefix). Restarting those two after a mount change is the intended behaviour, not a surprise.
- `scripts/mount-entropy.sh` is untouched; the page now describes it as the manual fallback rather than the mount mechanism, since the boot path is the owner.
- Unrelated pre-existing breakage observed while verifying, not touched here: `nvidia-cdi-refresh.path` / `nvidia-cdi-refresh.service` fail at boot on this AMD-only box (vestigial nvidia-container-toolkit).
---
cwd: /home/blank/.omp/wt/wt-20261030-205906-6d1fc1f · session: 01a1901c-6ed7-74f4-a0bb-7fe51fa081c3
(build worktree: /home/blank/.omp/wt/wt-20261031-113700-6d1fc1f)
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).
dank
merged commit 132805a25a into main2026-10-31 12:04:09 -07:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
What
/mnt/entropyon Dankserver now mounts at boot from its LUKS mapper, and the host'scrypttab+fstabare recorded in the repo for the first time.dankserver/host/crypttabentropy UUID=cd86c728-459e-4f3a-bcc2-41ecf84685ec /etc/entropy nofail,luksdankserver/host/fstab/etc/fstab, with the entropy entry pointed at/dev/mapper/entropyand the dead/dev/md0 /mnt/md0line commented outserverAppConfigs-docs/Dankserver/Entropy Volume.mdserverAppConfigs-docs/index.mdscripts/gen-vault-index.pyWhy it was broken
Two defects, both invisible whenever someone was logged in:
crypttabnamed the wrong UUID. It carried61bd6eaf-…— the md RAID array UUID — where aluksentry takes the LUKS container UUID (cd86c728-…);blkidprints both on adjacent lines. The generatedsystemd-cryptsetup@entropy.servicepointed at a device that never appears, so/dev/mapper/entropynever existed at boot and the oldfstabline (UUID=61bd6eaf-… /mnt/entropy) could not resolve either.udisks2unlocked the volume on every desktop login, so the volume looked mounted while the boot path stayed broken since 2025-09-14./etc/entropywas 27 bytes — a 26-character passphrase plus\n— andcryptsetuphashes the whole file, so the newline is part of the secret. Proven withcryptsetup open --test-passphrase: the 27-byte variant fails, the 26-byte variant unlocks.Evidence
/etc/crypttaband/etc/fstabare byte-identical to the committed copies (sha256 239729205…/7ee85c3af…).7.0.0-42-generic(the GRUB default; initrds rebuilt for both installed kernels so the corrected crypttab is on the boot path either way):findmnt /mnt/entropy→/dev/mapper/entropy ext4,md0[7/7][UUUUUUU], the stalemnt-md0.mountfailure cleared.frank-archon/health→{"status":"ok","model":"frank-archon","in_flight":0,"queue_cap":32}; a timed completion came back at 141 t/s withdraft_n_accepted: 22/26, against 6.7 t/s before the reboot (radiance's own watchdog had logged a wedged amdgpu queue on both ranks — see the endpoint page's Laws)../tests/run.shin this worktree →ALL TESTS PASSED(749 assertions);scripts/check-vault-links.py→122 pages, 0 unresolved links.Notes
deploy-plan.pymaps anydankserver/host/**change tojellyfin+plex(the pre-existing rule for that prefix). Restarting those two after a mount change is the intended behaviour, not a surprise.scripts/mount-entropy.shis untouched; the page now describes it as the manual fallback rather than the mount mechanism, since the boot path is the owner.nvidia-cdi-refresh.path/nvidia-cdi-refresh.servicefail at boot on this AMD-only box (vestigial nvidia-container-toolkit).cwd: /home/blank/.omp/wt/wt-20261030-205906-6d1fc1f · session: 01a1901c-6ed7-74f4-a0bb-7fe51fa081c3
(build worktree: /home/blank/.omp/wt/wt-20261031-113700-6d1fc1f)