You are not logged in.
Pages: 1
Hi,
I just setup a system with an encrypted root partition which is automatically unlocked at boot by a keyfile, which is stored on /boot (I'm aware that this defeats the main purpose of encryption).
My /etc/crypttab file looks like this:
sda2_crypt UUID=186b2415-a31f-41d1-9c6a-5c745e4d2faf /dev/disk/by-uuid/f41f8341-ec7d-425c-8c69-fb586c0c5850:/keyfile luks,discard,keyscript=/lib/cryptsetup/scripts/passdev
My /etc/fstab file looks like this:
UUID=f41f8341-ec7d-425c-8c69-fb586c0c5850 /boot ext2 defaults 0 2
/dev/mapper/sda2_crypt / ext4 errors=remount-ro 0 1
During boot I get an error message stating that "a start job is running for dev-disk-by uuid" and I have to wait 90 seconds until boot resumes. In the log file (/var/log/syslog) I found this particular entry:
systemd[1]: dev-disk-by\x2duuid-f41f8341\x2dec7d\x2d425c\x2d8c69\x2dfb586c0c5850:-keyfile.device: Job dev-disk-by\x2duuid-f41f8341\x2dec7d\x2d425c\x2d8c69\x2dfb586c0c5850:-keyfile.device/start timed out.
The way I understand this is that systemd is trying to mount my keyfile as a device (but it's just a file?). Does anyone know how to fix this, so that systemd doesn't try to mount or start it?
Offline
I'm facing the same issue on a Debian system, I agree it's probably an error parsing the keyfile option in crypttab, but I managed to work around it.
I have a slightly more convoluted setup:
- Key file for my root partition exists on a USB key, this is configured in /etc/crypttab in order for the initramfs configuration to hook it all up.
This part is the same as your setup, and I worked around it by disabling the post-root systemd's cryptsetup generator, using "luks.crypttab=no" as described here: https://www.freedesktop.org/software/sy … rator.html
- Then I added an additional partition/filesystem and wanted to keep the key on the root filesystem, with a regular filesystem path for the keydev option in /etc/crypttab
This completely broke my boot process, due to the cryptsetup generator being disabled, so I removed that kernel argument and got the 90 second timeout back.
I tried the "noauto" option in crypttab for my root device (since root was already unlocked and mounted at this point), but it had no effect.
I then tried "luks.cryptsetup=no" with "luks.uuid=..." to whitelist the extra partition, but this still failed, in a weird way - the cryptsetup generator still was looking for the keyfile argument (with the full filesystem path appended to the .device, which is the broken bit) to my boot line in crypttab, and trying to wait for it as a device. Perhaps it wasn't matching the UUID specified on the kernel command line to the correct crypttab line, but 1. the boot device it was matching was specified with a UUID, which obviously didn't match, and 2. I tried changing the extra partition's line in crypttab to select it by UUID, and it still failed in the same way.
I was finally able to work around it by deleting the line in /etc/crypttab for my extra partition, and specifying the whole crypttab configuration using kernel command line arguments:
luks.crypttab=no luks.name=<uuid>=<unlocked device name> luks.key=<uuid>=/path/to/key
Offline
Pages: 1