systemd: Cryptsetup of device in crypttab does not happen - timeout

lasombra · 2016-11-22 11:14:03

I have installed a secondary disk (Sdb1) and formatted with a single luks-encrypted partition.

lsblk -o NAME,UUID
NAME                                          UUID
sda                                           
├─sda2                                        556bf1e4-3730-4da3-8688-0f3c468bf5bb
│ └─luks-556bf1e4-3730-4da3-8688-0f3c468bf5bb jC1V25-7L1I-KG4K-iFr2-7syc-3ORc-5Ye7ji
│   ├─CryptVol-swap                           3a365fa3-de6b-4404-97aa-877c1d8331b6
│   └─CryptVol-root                           78d7fc05-a371-4808-ad4b-82cabba079a9
└─sda1                                        3E22-B7AB
sdb                                           
└─sdb1                                        1d8820b3-346c-424c-aa56-c7a6c4874e86

The luks partition in encrypted with a keyfile which resides in /etc. I can decrypt the partition without problems using cryptsetup open. But I actually want that the device is decrypted and mapped on boot. Therefore I have setup fstab and crypttab as follows:
/etc/crypttab

# <name>       <device>                                     <password>              <options>
home           UUID=1d8820b3-346c-424c-aa56-c7a6c4874e86     /etc/keyfile.enc	    luks,timeout=15

/etc/fstab

# /dev/mapper/home
/dev/mapper/home	/home     	ext4      	rw,relatime,data=ordered	0 2

But this does not work and I get the following error at boot time:

[ TIME ] timeout waiting for device dev-mapper-home.device

I was following https://wiki.archlinux.org/index.php/Dm … n#crypttab and to my understanding it should work as I have set it up.

Last edited by lasombra (2016-11-22 17:13:01)

frostschutz · 2016-11-22 11:23:09

I can decrypt the partition without problems using cryptsetup open.

Using the --key-file=/etc/keyfile.enc option? Sometimes there is confusion if you have newlines in that file and added it the wrong way.

lasombra · 2016-11-22 12:06:56

frostschutz wrote:

I can decrypt the partition without problems using cryptsetup open.
Using the --key-file=/etc/keyfile.enc option? Sometimes there is confusion if you have newlines in that file and added it the wrong way.

Yes here is the command I use:

cryptsetup open --type luks /dev/sdb1 --key-file=/etc/keyfile.enc home

The keyfile was created as follows:

dd bs=512 count=4 if=/dev/urandom of=/etc/keyfile.enc iflag=fullblock

Last edited by lasombra (2016-11-22 12:07:15)

lasombra · 2016-11-22 14:55:35

I tried adding noauto,x-systemd.automount to the fstab but with the same effect, the home partition is not decrypted and therefore not mounted

/dev/mapper/home	/home     	ext4      	 noauto,x-systemd.automount,rw,relatime,data=ordered	0 2

lasombra · 2016-11-22 17:02:00

In the directory /var/run/systemd/generator I can only find the service files which take care of mounting but not of the cryptsetup for home.

lasombra · 2016-11-23 19:53:35

If I check journalctl it tells me

systemd-cryptsetup-generator[272]: Not creating device 'home' because it was not specified on the kernel command line

Do I need to add kernel parameter? As I want to decrypt a non-root device I thought not. Does not make sense to me...

lasombra · 2016-11-25 11:42:22

So when I add luks parameter for the second hard disk the home partition actually is decrypted and mounted

title	Arch Linux (Systemd Cryptdev Alternative)
linux	/vmlinuz-linux
initrd	/initramfs-linux.img
options luks.uuid=556bf1e4-3730-4da3-8688-0f3c468bf5bb luks.uuid=1d8820b3-346c-424c-aa56-c7a6c4874e86 luks.key=/etc/keyfile.enc resume=/dev/mapper/CryptVol-swap root=/dev/mapper/CryptVol-root rw
1d8820b3-346c-424c-aa56-c7a6c4874e86

However, 1) I am always asked for a password for the home partition and 2) I still don't get the point why I should provide luks parameters when I want it shall be read from crypttab

Is this a bug? Current version of systemd is 231-4

Seven.issimo · 2017-02-17 20:58:15

I'm experiencing the same problem described in this thread (so I avoid to open a new one).

I'm trying to install Arch in relative-simple configuration with encrypted partitions,
but I can't get non-root partition(s) unlocked and mounted on boot as if crypttab was just ignored.

System is UEFI capable; disk is GPT partitioned; systemd-boot as chosen bootloader.
Desidered configuration is:

sda
+-sda1 --- to be used in windows (not as OS partition!)
+-sda2     FAT / UEFI   mounted to /boot
+-sda3     LUKS         unlocked to /dev/mapper/arch
| +-arch   ext4         mounted to /
+-sda4     LUKS         unlocked to /dev/mapper/home
  +-home   ext4         mounted to /home

Arch setup went smooth.

When I boot Arch, systemd-boot loads initrd and vmlinux, kernel with systemd-encrypt prompts for password, it opens luks partiton and mounts root (/). It does mount /boot, as listed on /etc/fstab, but it fails mounting 'home' because luks partition wasn't unlocked.

Relevant configuration:

lsblk -f

NAME                                          FSTYPE      LABEL UUID                                 MOUNTPOINT
sda
|-sda1
|-sda2                                        vfat        UEFI  77E0-9445                            /boot
|-sda3                                        crypto_LUKS       632a70ab-b2f3-46ee-95e1-f88b1e44e250
| `-luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 ext4        arch  8dbe352c-0b5e-4e6f-b296-b342b8df0821 /
`-sda4                                        crypto_LUKS       8f9f6801-971a-48ae-9154-70930ca29e23

/etc/crypttab

# crypttab: mappings for encrypted partitions
# <name>       <device>                               <password>     <options>
home    UUID=8f9f6801-971a-48ae-9154-70930ca29e23     none           luks

Also tested with: 2nd param in form PARTUUID or /dev/disk/by-uuid/..., third param as keyfile path or even 'ASK', fourth param empty or not and combinations of them.

/etc/fstab

# UUID=8dbe352c-0b5e-4e6f-b296-b342b8df0821 LABEL=arch
/dev/mapper/arch        /               ext4            rw,noatime      0 1

# UUID=77E0-9445 LABEL=UEFI
UUID=77E0-9445          /boot           vfat            rw,noatime,fmask=0022,dmask=0022,errors=remount-ro      0 2

# UUID=5d35f3e0-01e4-4619-82a9-b40d30659035 LABEL=home
/dev/mapper/home        /home           ext4            rw,noatime       0 2

Hooks in mkinitcpio.conf

HOOKS="base systemd autodetect modconf block sd-vconsole keyboard sd-encrypt filesystems fsck"

/proc/cmdline

initrd=\initramfs-linux.img luks.uuid=632a70ab-b2f3-46ee-95e1-f88b1e44e250 root=/dev/mapper/luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 luks.crypttab=yes

systemd-cryptsetup-generator

~# /usr/lib/systemd/system-generators/systemd-cryptsetup-generator
Not creating device 'home' because it was not specified on the kernel command line.

~# ls /var/run/systemd/generator/**
 /var/run/systemd/generator/-.mount
 /var/run/systemd/generator/boot.mount
 /var/run/systemd/generator/home.mount
'/var/run/systemd/generator/systemd-cryptsetup@luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.service'

/var/run/systemd/generator/cryptsetup.target.requires:
'systemd-cryptsetup@luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.service'

'/var/run/systemd/generator/dev-disk-by\x2duuid-632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.device.wants':
'systemd-cryptsetup@luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.service'

'/var/run/systemd/generator/dev-mapper-luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.device.d':
90-device-timeout.conf

'/var/run/systemd/generator/dev-mapper-luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.device.requires':
'systemd-cryptsetup@luks\x2d632a70ab\x2db2f3\x2d46ee\x2d95e1\x2df88b1e44e250.service'

/var/run/systemd/generator/local-fs.target.requires:
-.mount  boot.mount

/var/run/systemd/generator/local-fs.target.wants:
home.mount  systemd-fsck-root.service

In addition I should mention that, if I manually open sda4 to /dev/mapper/home, it gets automatically mounted.

tl;dr

/etc/crypttab seems to be ingored by systemd despite luks.crypttab=yes

As documented on ArchWiki and here, systemd-cryptsetup-generator should consider LUKS devices listed on /etc/crypttab and open them on boot.
Am I missing something?

PS. Add every LUKS device on kernel command line seems dumb to me.

rdeckard · 2017-02-18 01:44:45

It looks like you're using the "sd-encrypt" hook. Have you tried the "encrypt" hook with the equivalent options as a comparison?

userak · 2017-02-18 09:15:53

I'm facing the similar problem. The home partition which is encypted with luks fail to map at boot time, with the error "device not responding or busy".

Actually Despite of the above error home parition is getting mapped and mounted. I choose to put the name of home partition as "crypt_home" in crypttab file, but it is getting mapped as "home".

You guys should try changing the kernel command line parameter "luks" to "rd.luks" home partition should get mapped, it did in my case. However the bootlogs still shows the same error.

Here is the thread I posted the similar problem"

Last edited by userak (2017-02-18 09:17:41)

Seven.issimo · 2017-02-18 10:10:58

rdeckard wrote:

It looks like you're using the "sd-encrypt" hook. Have you tried the "encrypt" hook with the equivalent options as a comparison?

Encrypt hook works like a charm without messing init command line as I expect since /etc/crypttab exists.

Can I say it's a systemd-encrypt bug?
or do I misunderstood something and I'm missing some configuration?

userak wrote:

You guys should try changing the kernel command line parameter "luks" to "rd.luks" home partition should get mapped, it did in my case. However the bootlogs still shows the same error.

I haven't any luks/rd.luks entry related to 'home' on my kernel command line and I do not want add it. It does not make sense.

Imho, kernel command line is supposed to boot the system from scratch, with no more than basic capabilities, while /etc/crypttab (as like /etc/fstab) complete system configuration.
Imagine a machine (server?) with 10+ luks partitions... what would kernel command line become?

(Although, as I have already tested, this works around the problem)

userak · 2017-02-18 11:57:59

@Seven.issimo

I myself don't have 'home' related entry on the kernel command line. I tried changing the the parameter for the root partition from "luks" to "rd.luks" and it is getting mapped ( It is getting mapped but not with name "crypt_home" that I have specified in crypttab file ).

Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .

Seven.issimo · 2017-02-18 12:22:07

userak wrote:

I myself don't have 'home' related entry on the kernel command line. I tried changing the the parameter for the root partition from "luks" to "rd.luks" and it is getting mapped ( It is getting mapped but not with name "crypt_home" that I have specified in crypttab file ).

Maybe I misunderstood your suggestion.

However my problem is not root-related or mapping name related:
luks.uuid=<uuid> and root=/dev/mapper/luks-<uuid> handle my encrypted root with no issues.

userak wrote:

Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .

That's exactly the point.
That's because boot process (not bootloader) should attempt /etc/crypttab with all its devices and keyfiles (or random keyfile for swap).

userak · 2017-02-18 13:01:04

@Seven.issimo Yeah I think there is some communication gap ... may be I'm not able to explain the scenario properly. English is 3rd language for me.

During boot I'm being asked to enter password only 2 times . One buy the grub to unlock the "boot" parittion and other by the systemd-cryptsetup to unlock "root" partition . I'm not being asked password for "swap" and "home" partions. Which is peculiar since I have not specified any keyfile in "crypttab" file and even then both the partitions are getting mapped somehow and are accessible .

What is going on ?

Did switching to init instead of systemd-boot resolved the problem ?

Last edited by userak (2017-02-18 13:14:13)

userak · 2017-02-18 13:28:28

Seven.issimo wrote:

However my problem is not root-related or mapping name related:
luks.uuid=<uuid> and root=/dev/mapper/luks-<uuid> handle my encrypted root with no issues.

I think, again there is some confusion . specifying root partition with the parameter luks.uuid=<uuid of root partition > fails to mount home paritition . While on specifying the same parameter as rd.luks.uuid=<uuid of root partition> "home" gets mapped somehow.

Following is the quote from this page

Note: If you use luks.* kernel parameters for the rootfs while also using /etc/crypttab for the swap then systemd will complain about "Not creating device 'swap' because it was not specified on the kernel command line.". To fix this issue just use rd.luks.* parameters instead.

Last edited by userak (2017-02-18 13:29:44)

teateawhy · 2017-02-18 13:30:41

I can confirm the problem with crypttab, it seems to be a bug in systemd.
I usually use a keyfile, but in order to test this i replaced the keyfile path in /etc/crypttab with "none". Now systemd asks for a password, but after i typed half of it, it skips over the password entry before i can press enter, and nothing gets done.
What's even worse is that some characters of the password are typed into the console and visible after the password entry is skipped.

userak · 2017-02-18 13:41:13

userak wrote:

Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .

@teateawhy can you confirm the case mentioned in above quote.

teateawhy · 2017-02-18 14:03:33

userak wrote:

userak wrote:
Btw How many times it should ask me to enter password during boot , if I'm not using any password files and "boot" "root" "home" "swap" are separate partitions encrypted with luks .
@teateawhy can you confirm the case mentioned in above quote.

I added a second entry to crypttab as a test, but i can't really confirm or deny this quote, since the the first password entry isn't completed, i can't say what happens after that.

Seven.issimo · 2017-02-18 16:02:21

userak wrote:

Seven.issimo wrote:
However my problem is not root-related or mapping name related:
luks.uuid=<uuid> and root=/dev/mapper/luks-<uuid> handle my encrypted root with no issues.
I think, again there is some confusion . specifying root partition with the parameter luks.uuid=<uuid of root partition > fails to mount home paritition . While on specifying the same parameter as rd.luks.uuid=<uuid of root partition> "home" gets mapped somehow.
Following is the quote from this page
Note: If you use luks.* kernel parameters for the rootfs while also using /etc/crypttab for the swap then systemd will complain about "Not creating device 'swap' because it was not specified on the kernel command line.". To fix this issue just use rd.luks.* parameters instead.

This works!

Thank @userak, I'm really sorry I misunderstood your suggestion. But I can't find any logic in systemd behaviour.

Moreover, imao, ArchWiki is not clear at all on this: it refers to 'rootfs' and 'swap' but, apparently, systemd ignores the entire crypttab if luks.uuid option is specified.

Seven.issimo · 2017-02-18 16:40:39

I'm trying to test teateawhy's issue: I added second entry to /etc/crypttab and removed keyfile for home. This should give me at least 2 prompt (after rootfs one).

I really don't know how but 'home' get opened and mounted without password prompt
Instead I am asked my password for the second partition (as expected).

However, in no case, boot continues without waiting for complete password input.

Screenshot

userak · 2017-02-18 17:35:13

Glad it worked... However there is something more to it ... Try going through the bootlogs with the cmd "journalctl -b" and see if there are any mapping error. The device mapped name problem that I was talking about might be there .. I saw your "crypttab" file you have named the device as "home" so you might not be noticing that problem. Try naming the "home" partion device name to something else in "crypttab" and "fstab" files and see if it still works. It is working in my case.

Last edited by userak (2017-02-18 17:39:53)

Seven.issimo · 2017-02-18 21:30:36

userak wrote:

Glad it worked... However there is something more to it ... Try going through the bootlogs with the cmd "journalctl -b" and see if there are any mapping error. The device mapped name problem that I was talking about might be there .. I saw your "crypttab" file you have named the device as "home" so you might not be noticing that problem. Try naming the "home" partion device name to something else in "crypttab" and "fstab" files and see if it still works. It is working in my case.

I changed my /etc/crypttab to:

# PART=sda4 LABEL=none WAS=home
whatever        UUID=8f9f6801-971a-48ae-9154-70930ca29e23    none     luks

# PART=sda1 LABEL=none WAS=test
disk_123        UUID=9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2    none     luks

* With /etc/fstab untouched (with /dev/mapper/home and /dev/mapper/test)
...boot fails as I could expect. screenshot

* Updating /etc/fstab to reflect crypttab changes, it works and get me to this configuration:

# lsblk -f
NAME                                          FSTYPE      LABEL UUID                                 MOUNTPOINT
sda
|-sda1                                        crypto_LUKS       9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2
| `-disk_123                                  ntfs              5F9F0FFC2E3D2419                     /root/test
|-sda2                                        vfat        UEFI  77E0-9445                            /boot
|-sda3                                        crypto_LUKS       632a70ab-b2f3-46ee-95e1-f88b1e44e250
| `-luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 ext4        arch  8dbe352c-0b5e-4e6f-b296-b342b8df0821 /
`-sda4                                        crypto_LUKS       8f9f6801-971a-48ae-9154-70930ca29e23
  `-whatever                                  ext4        home  5d35f3e0-01e4-4619-82a9-b40d30659035 /home

Still remains my doubts about how 'home' is unlocked without password prompt or keyfile.

With these same /etc/crypttab and /etc/fstab, but with encrypt hook (instead of sd-encrypt one), I'm prompted for three passwords: first one for rootfs, then for 'whatever' (home) and then for disk_123.

Last edited by Seven.issimo (2017-02-20 09:22:56)

damjan · 2017-02-19 23:10:30

A very similar scenario works for me fine, since … 2 year ago at least.

I have root and home luks partitions, root is decrypted from the initramfs - which asks for a password. in /etc on the root partition I have the key file for home, so only one password is needed.

/etc/crypttab:
home UUID=xyz-abc-.... /etc/crypttab.home discard

/etc/fstab:
/dev/mapper/home /home ext4 rw,noatime,data=ordered,discard 0 2

kernel command line is:
cryptdevice=UUID=yyy-ppprrr-xxx:root:allow-discards root=/dev/mapper/root rw elevator=noop quiet

/etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck"

Things to check:
- make sure your initramfs doesn't contain weird things, like old copies of crypttab, other hooks etc
- permissions of /etc/crypttab* are 600

Seven.issimo · 2017-02-20 09:40:39

damjan wrote:

/etc/mkinitcpio.conf:
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck"
Things to check:
- make sure your initramfs doesn't contain weird things, like old copies of crypttab, other hooks etc
- permissions of /etc/crypttab* are 600

Thank @damjan but my (our) problem is not with 'encrypt' hook.
As I mentioned above, it does work like a charm prompting a password each luks device listed in /etc/crypttab.

Issue of "auto-unlocking home" happen with sd-encrypt hook (= systemd-cryptsetup).

And I'm curious to investigate the wierd behavior of systemd-cryptsetup...

userak · 2017-02-20 10:25:35

Seven.issimo wrote:

I changed my /etc/crypttab to:

# PART=sda4 LABEL=none WAS=home
whatever        UUID=8f9f6801-971a-48ae-9154-70930ca29e23    none     luks

# PART=sda1 LABEL=none WAS=test
disk_123        UUID=9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2    none     luks

* With /etc/fstab untouched (with /dev/mapper/home and /dev/mapper/test)
...boot fails as I could expect. screenshot

* Updating /etc/fstab to reflect crypttab changes, it works and get me to this configuration:

# lsblk -f
NAME                                          FSTYPE      LABEL UUID                                 MOUNTPOINT
sda
|-sda1                                        crypto_LUKS       9bd3addc-8c6b-4b92-8acb-c7b6f97fe0c2
| `-disk_123                                  ntfs              5F9F0FFC2E3D2419                     /root/test
|-sda2                                        vfat        UEFI  77E0-9445                            /boot
|-sda3                                        crypto_LUKS       632a70ab-b2f3-46ee-95e1-f88b1e44e250
| `-luks-632a70ab-b2f3-46ee-95e1-f88b1e44e250 ext4        arch  8dbe352c-0b5e-4e6f-b296-b342b8df0821 /
`-sda4                                        crypto_LUKS       8f9f6801-971a-48ae-9154-70930ca29e23
  `-whatever                                  ext4        home  5d35f3e0-01e4-4619-82a9-b40d30659035 /home

Did you tried this with sd-encrypt hooks ... because this problem is unique to systemd-boot and not init boot.

Arch Linux

#1 2016-11-22 11:14:03