Optionally mount encrypted filesystem at boot

anne · 2014-01-13 03:56:57

I have an encrypted filesystem which I'd like to optionally mount during boot, that is, mount at boot if I'm available at the console to enter the password. If not (that is, if the system reboots for some reason while I'm not there), I want the system to come up anyway, and I'll log in later and bring up the encrypted device. I almost have this working, but not quite.

The (dm-crypt with LUKS) encrypted device works fine, and I have it in /etc/crypttab as:

crypt     /dev/mapper/VGbig-LVcrypt  none     luks,timeout=15s,nofail

The ext4 filesystem on it mounts correctly; its fstab entry is:

LABEL=crypt  /disks/crypt    ext4 rw,relatime,data=ordered,nofail 0 0

(Hmm, note to self, make that "0 2"; we should fsck.)

My problem is that I cannot enter the password during the boot sequence. First, the password prompt appears buried among the other boot messages, but that's an annoyance, not a show-stopper. Next, when I start typing the password anyway, I do see asterisks appear, but before I finish typing the (somewhat long) passphrase, the screen clears and gives me a login prompt. (This happens much sooner than the 15-second timeout I requested in crypttab.) Here's a journal extract showing some of what happens:

Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[...]
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Expecting device dev-mapper-VGbig\x2dLVcrypt.device...
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Expecting device dev-mapper-crypt.device...
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Starting Encrypted Volumes.
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Reached target Encrypted Volumes.
[...]
Jan 12 20:02:26 archie.porcupine.montreal.qc.ca systemd[1]: Expecting device dev-disk-by\x2dlabel-crypt.device...
[...]
Jan 12 20:02:28 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/mapper/VGbig-LVcrypt.
Jan 12 20:02:28 archie.porcupine.montreal.qc.ca systemd[1]: Starting Cryptography Setup for crypt...
[...]
Jan 12 20:02:28 archie.porcupine.montreal.qc.ca systemd[1]: Starting Dispatch Password Requests to Console...
Jan 12 20:02:28 archie.porcupine.montreal.qc.ca systemd[1]: Started Dispatch Password Requests to Console.
[...]
Jan 12 20:02:32 archie.porcupine.montreal.qc.ca systemd[1]: Starting Multi-User System.
Jan 12 20:02:32 archie.porcupine.montreal.qc.ca systemd[1]: Reached target Multi-User System.
Jan 12 20:02:32 archie.porcupine.montreal.qc.ca systemd[1]: Starting Graphical Interface.
Jan 12 20:02:32 archie.porcupine.montreal.qc.ca systemd[1]: Reached target Graphical Interface.
[...]
Jan 12 20:02:35 archie.porcupine.montreal.qc.ca systemd[1]: Stopped Dispatch Password Requests to Console.
Jan 12 20:02:35 archie.porcupine.montreal.qc.ca systemd[1]: Started Forward Password Requests to Wall.

I think the above is where the password asking program gets the console taken out from under it.

Then, 15 seconds after "Starting Cryptography Setup for crypt", sure enough it times out:

Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd-cryptsetup[295]: Timed out
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd-cryptsetup[295]: Failed to query password: Timer expired
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: systemd-cryptsetup@crypt.service: main process exited, code=exited, status=1/FAILURE
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Failed to start Cryptography Setup for crypt.
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Dependency failed for dev-mapper-crypt.device.
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Unit systemd-cryptsetup@crypt.service entered failed state.
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca login[330]: pam_unix(login:session): session opened for user anne by LOGIN(uid=0)
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Starting user-1043.slice.
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Created slice user-1043.slice.
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Expecting device dev-mapper-crypt.device...
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Starting Cryptography Setup for crypt...
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Starting User Manager for 1043...
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca systemd[1]: Starting Session 1 of user anne.
[...]
Jan 12 20:02:43 archie.porcupine.montreal.qc.ca login[330]: LOGIN ON tty1 BY anne

Then it times out again (second attempt) just as I'm logging in:

Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd-cryptsetup[401]: Timed out
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd-cryptsetup[401]: Failed to query password: Timer expired
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd[1]: systemd-cryptsetup@crypt.service: main process exited, code=exited, status=1/FAILURE
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd[1]: Failed to start Cryptography Setup for crypt.
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd[1]: Dependency failed for dev-mapper-crypt.device.
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd[1]: Unit systemd-cryptsetup@crypt.service entered failed state.
Jan 12 20:02:58 archie.porcupine.montreal.qc.ca systemd-journal[174]: Forwarding to syslog missed 149 messages.
Jan 12 20:03:56 archie.porcupine.montreal.qc.ca systemd[1]: Job dev-disk-by\x2dlabel-crypt.device/start timed out.
Jan 12 20:03:56 archie.porcupine.montreal.qc.ca systemd[1]: Timed out waiting for device dev-disk-by\x2dlabel-crypt.device.
Jan 12 20:03:56 archie.porcupine.montreal.qc.ca systemd[1]: Dependency failed for /disks/crypt.
Jan 12 20:03:56 archie.porcupine.montreal.qc.ca systemd[1]: Startup finished in 3.085s (kernel) + 1min 30.365s (userspace) = 1min 46.472s.

Now I become root and issue "cryptsetup open"; as soon as that completes successfully, the system notices the device and mounts the filesystem:

Jan 12 20:04:24 archie.porcupine.montreal.qc.ca sudo[420]: anne : TTY=tty1 ; PWD=/disks/plain/local/bin ; USER=root ; COMMAND=/bin/bash
Jan 12 20:04:24 archie.porcupine.montreal.qc.ca sudo[420]: pam_unix(sudo:session): session opened for user root by anne(uid=0)
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/disk/by-uuid/5db80b86-fe18-4855-ab0e-4d073ab08d7b.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/disk/by-label/crypt.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/disk/by-id/dm-uuid-CRYPT-LUKS1-72f18c946a924ec7bb7ee3d6ae59f41f-crypt.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/disk/by-id/dm-name-crypt.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /dev/dm-4.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Found device /sys/devices/virtual/block/dm-4.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Mounting /disks/crypt...
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Starting Cryptography Setup for crypt...
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd-cryptsetup[457]: Volume crypt already active.
Jan 12 20:04:53 archie.porcupine.montreal.qc.ca systemd[1]: Started Cryptography Setup for crypt.
Jan 12 20:04:54 archie.porcupine.montreal.qc.ca systemd[1]: Mounted /disks/crypt.
Jan 12 20:04:54 archie.porcupine.montreal.qc.ca kernel: EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: data=ordered

So... is there any way for me to "clear" the boot sequence on either side of this get-password-and-open-device operation, that is, if possible, let everything else that's in progress finish writing to the screen before issuing the password prompt, then wait until that operation completes (either successfully or not) before continuing with the boot sequence?

Or, if that's too much to ask, is there any way to delay whatever's "stealing" the console device until the Cryptography Setup has succeeded or failed, or at worst, delay it for some set period of time?

I suspect that getting a bit creative with the dependency definitions in the systemd units might do the trick, but I'm still coming up to speed on systemd, and I'm really hoping to get this working before I acquire too many more gray hairs over this. Ideas, anyone?

Anne.

vanquish · 2014-01-13 18:41:05

1.)

Or, if that's too much to ask, is there any way to delay whatever's "stealing" the console device until the Cryptography Setup has succeeded or failed, or at worst, delay it for some set period of time?

If you are setting up a 15 sec. timer for lvm you can do this for any other device too. As long as cryptsetup is waiting for any input the boot process is interrupted. If there is no timer set the boot process will wait for eternity. What is your second device? Is there any timer too?

2.) For mouting "optionally":
I don't know if there is an option available within cryptsetup. I guess no. The simpliest way is just hitting the enter button tree times (standard tries). you can modify this value: "tries=1". --> Password will be asked only one times. 0 will be endless asking! The best way in my opinion is to write your unlock script for your special device e. g. into your .bash_login file.

Please enclose your whole fstab/crypttab next time. Nobody is getting any information about the failed device.

anne · 2014-01-14 02:10:27

vanquish wrote:

1.)
Or, if that's too much to ask, is there any way to delay whatever's "stealing" the console device until the Cryptography Setup has succeeded or failed, or at worst, delay it for some set period of time?
If you are setting up a 15 sec. timer for lvm you can do this for any other device too. As long as cryptsetup is waiting for any input the boot process is interrupted. If there is no timer set the boot process will wait for eternity. What is your second device? Is there any timer too?

The 15 second timeout is set in /etc/crypttab, as I showed, and applies to the cryptography set-up for opening the "crypt" device. It means I have (or I should have!) 15 seconds to enter the password for decryption. It has nothing to do with LVM.

It's not the case that the boot process is interrupted while cryptsetup is waiting for input. Actually, it was interrupted to some extent before I added the "nofail" option into crypttab, but I need the "nofail" there to allow the boot to continue even if opening the crypt device fails. I just wish it would wait for the cryptsetup to fail (or succeed!) before continuing with the boot.

I'm not sure what you mean by my second device.

2.) For mouting "optionally":
I don't know if there is an option available within cryptsetup. I guess no.

That turns out not to be the case. Both crypttab and fstab have "nofail" options.

The simpliest way is just hitting the enter button tree times (standard tries).

... which rather defeats the purpose of things still working when I'm not there to hit enter. ;-)

The best way in my opinion is to write your unlock script for your special device e. g. into your .bash_login file.

But that doesn't apply here; this filesystem is systemwide, not restricted to just my user.

Please enclose your whole fstab/crypttab next time. Nobody is getting any information about the failed device.

There is no failed device. You saw my entire crypttab, and the rest of the fstab is unrelated to this problem; everything else mounts fine. All devices work.
The only problem is that I don't have time to enter the decryption password during the boot sequence, so I have to open the crypt device manually after logging in.

I hope that this clarifies things.

Anne.

kocsv · 2016-04-26 09:52:42

Hello Anne,

did you find a solution? Currently I have the same problem and always have to manually mount the partitions after boot.

Greetings

WorMzy · 2016-04-26 09:55:38

Anne hasn't been on the forums for two years, so you are unlikely to get a response. Please open a new topic about your issue and link back to this one if it is still relevant.

https://wiki.archlinux.org/index.php/Fo … bumping.22

Closing.

Arch Linux

#1 2014-01-13 03:56:57

Optionally mount encrypted filesystem at boot

#2 2014-01-13 18:41:05

Re: Optionally mount encrypted filesystem at boot

#3 2014-01-14 02:10:27

Re: Optionally mount encrypted filesystem at boot

#4 2016-04-26 09:52:42

Re: Optionally mount encrypted filesystem at boot

#5 2016-04-26 09:55:38

Re: Optionally mount encrypted filesystem at boot

Board footer