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).
2 lines
75 B
Plaintext
2 lines
75 B
Plaintext
entropy UUID=cd86c728-459e-4f3a-bcc2-41ecf84685ec /etc/entropy nofail,luks
|