kasploosh.com

Debian jessie, systemd, and plain encryption

2015-10-03

Garbled Data

Garbled Data

I upgraded a Debian jessie system and, upon rebooting, systemd failed to bring up a crypt disk which uses a key file and plain encryption. I searched around for the answer, found one, and am posting it here in case anyone else runs into the problem.

More Details About the Problem

This system had a simple crypt disk that was loaded at boot. The encryption is unlocked via a key file on the main file system. The configuration for this simple disk was like this:

(/etc/crypttab) volume_name /dev/sda1 /etc/key_file cipher=blah,hash=plain,size=256

The above configuration worked day after day. On 2015-10-03 I updated the system after a long period of no updates. When I rebooted, the crypt disk was not loaded, and systemd gave error messages like this:

[FAILED] Failed to start Cryptography Setup for volume_name. See ’systemctl status systemd-cryptsetup@volume_name.service’ for details. [DEPEND] Dependency failed for Encrypted Volumes. [DEPEND] Dependency failed for dev-mapper-volume_name.device.

I was given a maintenance console, and I did the status command that was suggested. This gave me output like this:

systemd[1]: Starting Cryptography Setup for volume_name... systemd-cryptsetup[pid]: crypt_load() failed on device /dev/sda1. systemd-cryptsetup[pid]: Failed to activate: Invalid argument systemd[1]: systemd-cryptsetup@volume_name.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: Failed to start Cryptography Setup for volume_name. systemd[1]: systemd-cryptsetup@volume_name.service: Unit entered failed state. systemd[1]: systemd-cryptsetup@volume_name.service: Failed with result: 'exit-code'.

I also noticed that it was no problem for me to start the crypt volumes manually, using cryptsetup-start volume_name.

Research

Hmm... the error messages say “invalid argument”. So I scrutinized the file /etc/crypttab to see if it contained anything that looked like an invalid argument. No, it looked like it was the configuration that worked hundreds of times before. And besides, I was able to start the volumes manually. Must be a problem with systemd.

Next I did an internet search for the problem. I found two articles where users had the same problem. These two articles:

Solution

You can read the workaround in the links above. Or I will repeat it here in case it helps anyone.

My non-working configuration was like this:

(/etc/crypttab) volume_name /dev/sda1 /etc/key_file cipher=blah,hash=plain,size=256

The workaround configuration is like this:

(/etc/crypttab) volume_name /dev/sda1 /etc/key_file plain,cipher=blah,hash=plain,size=256

The only thing that changed was the addition of 'plain,' to the list of options.

From reading the github issue, it seems that in the past systemd would try the plain method of decrypting a device, if other methods fail. But now one must specifically state that the device uses plain encryption.

Also, I can’t tell if this systemd behavior is the new way to do things, or if it is just a growing pain. Is this solution a workaround, or a new requirement for plain encryption?

14657.59398