All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <gmazyland@gmail.com>
To: Jerry Lowry <jlowry@edt.com>, dm-crypt@saout.de
Subject: Re: [dm-crypt] problems mounting encrypted drive on reboot
Date: Fri, 29 Sep 2017 19:37:12 +0200	[thread overview]
Message-ID: <0c9d8daf-27cf-95d9-3fc1-e6eba7cd76a2@gmail.com> (raw)
In-Reply-To: <02dbebc7-17ed-057d-fac0-6e51485eb357@edt.com>



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.

      parent reply	other threads:[~2017-09-29 17:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20 22:38 [dm-crypt] problems mounting encrypted drive on reboot Jerry Lowry
2017-09-20 22:53 ` Arno Wagner
2017-09-20 22:59   ` Jerry Lowry
2017-09-21  7:27     ` Ondrej Kozina
2017-09-21  7:25 ` Michael Kjörling
2017-09-21 16:28   ` Jerry Lowry
2017-09-21 16:49     ` Arno Wagner
2017-09-29 17:37     ` Milan Broz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c9d8daf-27cf-95d9-3fc1-e6eba7cd76a2@gmail.com \
    --to=gmazyland@gmail.com \
    --cc=dm-crypt@saout.de \
    --cc=jlowry@edt.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.