Howto make encrypted volumes not fail boot when passphrase is not given

Question

When setting up some encrypted partitions on my debian squeeze machine, all was so easy. I followed some howto and used cryptsetup to create the encrypted partitions now holding /home and /srv. The system itself (root mounting point and boot) have not been encrypted.

Behavior on boot was:

• The system asks for the passphrases of the encrypted partitions.
• If entered correctly, system booted up and the partitions were mounted as stated in fstab.
• If omitted or entered false for three times, the system booted up anyway in multiuser mode and the partitions could be manually unlocked and mounted later.

After doing some updates and upgrades - now it is a Jessie - the behavior changed. If the passphrases are omitted or not given correctly, the system boots to "emergency mode" asking for the root password.

I tried some google on that, but anything I found, did not change this. You have to enter the passphrases correctly or booting fails. As the machine usually operates in a remote place having no one around knowing enough of a non-Windows environment, this is not desired.

:# uname -a

Linux cypher 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) i686 GNU/Linux

:# cat /etc/fstab

UUID=3c3fb5a8-ec8c-49d4-a36c-d3a39d321f49 /  ext3          user_xattr,errors=remount-ro 0  1
/dev/mapper/sda3_crypt  /home                ext4          usrquota,grpquota,user_xattr 0  2
/dev/mapper/sda4_crypt  /srv                 ext4          usrquota,grpquota,user_xattr 0  2
/dev/sda2               none                 swap          sw                           0  0
/dev/sr0                /media/cdrom0        udf,iso9660   user,noauto                  0  0

:# cat /etc/crypttab

sda3_crypt UUID=a89934ba-d90c-415d-b021-05be84995e8b none nofail
sda4_crypt UUID=4134177b-5622-4cef-9844-c83efad8d029 none nofail

On experimenting with different options in crypttab, I've always done a

update-initramfs -u -k all

before attempting the next boot. I don't even know if this is necessary.

I don't know what I have to do to accomplish the "old" behavior and would be happy, if someone could tell me, what I am looking for.

---

To address StackAbstraction's comment: The unencrypted swap partition is the result of a recent error. At first it was encrypted. For some unknown reason it suddenly refused to be unlocked which led to a failed boot. After reformatting and setting up the encryption all should have been fine - but it wasnt. At any boot I got a message about a "missing LVM" and I had to boot from rescue to get into the system again.

I was not able to resolve this and as the reason for encryption is more designed to protect the stored data if the physical device is stolen from the server room it didn't seem to be that high risk. This is also the reason for not protecting the root partition. The data to protect is stored exclusively on the encrypted partitions.

The comment, though, didn't point to the given question. I'm currently aware of the potential risks of not encrypted swap and root partition. I don't see how switching to a volume group would solve the problem of boot failure if the passwords are not given except maybe that passwords for volume groups are not requested upon boot (which would not be the desired behavior) - I don't know if this would be true.

Answer 1

Try adding the nobootwait flags to the fstab entries of encrypted partitions.

Answer 2

Actually there is also a nofail option for fstab so one should do both let cryptab fail on decrypting and then let fstab fail on mount.

/dev/mapper/sda3_crypt  /home  ext4  usrquota,grpquota,user_xattr,nofail 0  2
/dev/mapper/sda4_crypt  /srv   ext4  usrquota,grpquota,user_xattr,nofail 0  2