# (SOLVED) dmcrypt no longer mounts encrypted partition

## Cadex

For some reason, dmcrypt has stopped successfully mounting an encrypted partition on startup. This is a little server I hadn't rebooted for several months and I've only just realized the problem, so I don't even have a clue when the problem started or what may have originally caused the problem.

This is the relevant section of my /etc/conf.d/dmcrypt

```
target=data

source='/dev/sdb2'

key='/etc/encrypted_data_key.gpg:gpg'

```

(rest of file is commented out)

At startup, I get the expected pinentry screen, but after entering the passphrase and a little pause, I'm getting the error "no key available with this passphrase".

Here's a section of my /var/log/rc.log file:

```
rc boot logging started at Wed Jan 20 11:30:07 2016

 * Setting system clock using the hardware clock [UTC] ...

 [ ok ]

 * Autoloaded 0 module(s)

 * Setting up dm-crypt mappings ...

 *   data using:   open /dev/sdb2 data ...

Kein Schlüssel mit dieser Passphrase verfügbar. (=no key available with this passphrase)

Kein Schlüssel mit dieser Passphrase verfügbar. (=no key available with this passphrase)

 * failure running cryptsetup

 [ !! ]

 * Failed to setup dm-crypt devices

 [ !! ]

 * ERROR: dmcrypt failed to start

```

After cancelling setting up the dmcrypt mappings, I can login to the system. If I then try to setup the dmcrypt-mapping manually using the following command, it works fine:

```
gpg --decrypt /etc/encrypted_data_key.gpg 2>/dev/null | cryptsetup luksOpen /dev/sdb2 data
```

At first I thought it might have to do with my keymap not already being loaded when the pinentry prompt appears during startup, but a short test suggests that the problem lies probably rather somewhere else.

Any idea what the problem might be?Last edited by Cadex on Thu Jan 21, 2016 7:44 pm; edited 1 time in total

----------

## toralf

Because it works later I bet that either a kernel module or a depended services is not loaded respectively started.

----------

## Cadex

 *toralf wrote:*   

> Because it works later I bet that either a kernel module or a depended services is not loaded respectively started.

 

Hi toralf, thanks a lot for trying to help!

I think I can rule that out, for there's an important piece of information that I completely forgot to mention.

While I can later on successfully set up the dmcrypt-luks mapping using the following command:

```
gpg --decrypt /etc/encrypted_data_key.gpg 2>/dev/null | cryptsetup luksOpen /dev/sdb2 data
```

it does NOT work if instead I simply run the init script:

```
/etc/init.d/dmcrypt start
```

In that case I get the same "no key available with this passphrase" error.

So the problem is probably rather somewhere in the init script /etc/init.d/dmcrypt or the configuration file /etc/conf.d/dmcrypt, right?

----------

## toralf

indeed - and it 99.99% of all cases it is the conf.d file

----------

## Cadex

As I just realized that the problem is either in the config file or the init file, I came up with the idea of putting a little "echo" line in the init.d file that would print the actual command being executed by the init-file.

it is:

```
gpg -q -d /etc/encrypted_data_key.gpg 2>/dev/null | cryptsetup --key-file -   open /dev/sdb2 data
```

and after running two variations of that command manually, I now know what appears to be the problem:

--key-file -

With "--key-file -" I get the "no key available with this passphrase" error, as soon as I remove that part, it works fine! So now I already know a temporary solution for the problem.

I find it hard to understand what the real problem is here though - for according to the manfile, "--key-file -" pretty much just means "read the key from stdin". So it seams like simply piping the passphrase into cryptsetup (I got that command from an old gentoo Wiki page) is treated slightly different than specifiying "--key-file -" instead, right?

EDIT: I should have simply looked at the bugtracker: Bug 548040 appears to be the same problem.

So thanks again, toralf. Even though you could not directly point me to the actual problem, somehow you greatly helped me narrowing the problem down myself!   :Smile: 

----------

## frostschutz

the difference is that without --keyfile-, cryptsetup stops reading at a newline character.

so if you have a key of random data and the first byte happens to be a newline, if it only works without --keyfile-, the key you actually have is an empty string.

or if there is a newline anywhere in your key, your actual key will be a lot shorter than what you expect it to be.

you should check that out.

----------

## Cadex

Yes, the problem really was my GPG-encoded key having a newline character (luckily, at the very end). I recreated the GPG file without the newline character and now the original init script works fine.

Thanks to both of you!   :Smile: 

----------

