On 09/21/2017 06:28 PM, Jerry Lowry wrote: > If that's what you _really_ did, I'm pretty sure it can't have worked. > The newline notwithstanding, whitespace still matters, and there is no > --verify parameter (you probably meant to use --verify-passphrase). > > Yes, I did you verify-passphrase, just a typo! > > So, from the replies that I have gotten it sounds like there are two different camp ( groups) that are doing something with cryptsetup. Isn't that a duplication of effort? Ok, because you tried to hijack other thread and reply out of list privately, I'll try to explain it here: The systemd-cryptsetup uses libcryptsetup to activate devices. So the cryptsetup code is there only once, but systemd decides to "own" and parse /etc/crypttab with own tool - that's OK, crypttab was always owned by init and not by cryptsetup. For your journald log: I am not sure what the invalid parameter means, it could be bug but without additional debug log we cannot say. (systemd should enable better log, it is easy) Anyway, my guess is that you used keyfile in plain mode - then it is used directly as a key, hash parameter does not apply. If there is not enough data for key, it must fail. If you are configuring it with cryptsetup directly, you definitely should see this warning: WARNING: The --hash parameter is being ignored in plain mode with keyfile specified. (Or you have pretty old cryptsetup.) Anyway, if you cannot use LUKS (you should because it solves exactly these issues) then 1) generate keyfile form /dev/urandom, be sure it is at least of the size of encryption key (usually 32 bytes). (dd if=/dev/urandom of=/dir/file bs=1 count=32) 2) use this as keyfile, do not specify hash: cryptsetup --key-file=/dir/file create testcui /dev/sdb 3) then use the same keyfile in crypttab. it should work. m. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
