Crypttab encryption key UUID or PARTUUID

Hi. I have a LUKS encrypted disk on Tumbleweed that is mounted (on /data) on boot and currently unlocked by prompting for the password to be entered interactively.

I’m now testing performing the unlock using a key file.

I’ve created the key file and added it to a keyslot for the device.

If I specify the absolute path to the key file in /etc/crypttab it works fine:

data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /boot/efi/data.key

but if I specify a relative path and a device it does not:

data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /data.key:PARTUUID=7a8ef736-65e2-4dfd-ba7a-8c1838aeebf3

or:

data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /data.key:UUID=E1DA-2923

Some info:

mount | grep “/boot/efi”
/dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro)

sudo fdisk -l /dev/sda | grep -E “type|sda1”
Disklabel type: gpt
/dev/sda1 2048 1050623 1048576 512M EFI System

sudo blkid | grep sda1
/dev/sda1: UUID=“E1DA-2923” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“7a8ef736-65e2-4dfd-ba7a-8c1838aeebf3”

find /dev/disk/{by-partuuid,by-uuid} -ls | grep sda1
861 0 lrwxrwxrwx 1 root root 10 Jun 10 16:23 /dev/disk/by-partuuid/7a8ef736-65e2-4dfd-ba7a-8c1838aeebf3 → …/…/sda1
867 0 lrwxrwxrwx 1 root root 10 Jun 10 16:23 /dev/disk/by-uuid/E1DA-2923 → …/…/sda1

Man page references:

man crypttab:

    3. The third field specifies an absolute path to a file with the encryption key. Optionally, the path may be followed by ":" and an /etc/fstab style device specification (e.g. starting with "LABEL=" or similar); in which case the path is taken relative to the specified
       device's file system root. If the field is not present or is "none" or "-", a key file named after the volume to unlock (i.e. the first column of the line), suffixed with .key is automatically loaded from the /etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/
       directories, if present. Otherwise, the password has to be manually entered during system boot. For swap encryption, /dev/urandom may be used as key file, resulting in a randomized key

man fstab:

The first field (fs_spec).
   This field describes the block special device, remote filesystem or filesystem image for loop device to be mounted or swap file or swap device to be enabled.

   For ordinary mounts, it will hold (a link to) a block special device node (as created by mknod(2)) for the device to be mounted, like /dev/cdrom or /dev/sdb7. For NFS mounts, this field is <host>:<dir>, e.g., knuth.aeb.nl:/. For filesystems with no storage, any string can be
   used, and will show up in df(1) output, for example. Typical usage is proc for procfs; mem, none, or tmpfs for tmpfs. Other special filesystems, like udev and sysfs, are typically not listed in fstab.

   LABEL=<label> or UUID=<uuid> may be given instead of a device name. This is the recommended method, as device names are often a coincidence of hardware detection order, and can change when other disks are added or removed. For example, 'LABEL=Boot' or
   'UUID=3e6be9de-8139-11d1-9106-a43f08d823a6'. (Use a filesystem-specific tool like e2label(8), xfs_admin(8), or fatlabel(8) to set LABELs on filesystems).

   It’s also possible to use PARTUUID= and PARTLABEL=. These partitions identifiers are supported for example for GUID Partition Table (GPT).

   See mount(8), blkid(8) or lsblk(8) for more details about device identifiers.

   Note that mount(8) uses UUIDs as strings. The string representation of the UUID should be based on lower case characters. But when specifying the volume ID of FAT or NTFS file systems upper case characters are used (e.g UUID="A40D-85E7" or UUID="61DB7756DB7779B3").

I’m not sure if I’ve misunderstood the man pages, or if I’m not specifying the correct syntax in /etc/crypttab.

Does anyone have this working and, if so, could they point me in the correct direction.

Many thanks in advance.

Why? Your keyfile is on the filesystem that is mounted automatically anyway. There is really no reason to add device specification. Actually, it could well be the reason for the failure (systemd attempts to mount device that is already mounted).

Anyway, the first thing you should do is to check logs.

You do realize that /boot/efi is not encrypted and anyone having physical access to your device can trivially unlock your LUKS partition?

I’m just using /boot/efi/ as the location to test for now.

Next stage is to store the key file on a USB drive.

For now I just wanted to store it on something I knew would be available during boot.

Sorry, should have made that clear.

Then use a test location that is not mounted automatically.

Just to make sure I’ve made myself clear …

The EFI partition on /dev/sda is just where I’m storing the key file to test it can be used to unlock a difference device on boot:

/dev/sda1: UUID=“E1DA-2923” BLOCK_SIZE=“512” TYPE=“vfat” PARTUUID=“7a8ef736-65e2-4dfd-ba7a-8c1838aeebf3”

The device that I want to unlock using that key is a completely separate disk:

/dev/sdc: UUID=“6e2089ea-ec52-4e33-a956-586c63ab54d0” TYPE=“crypto_LUKS”

All I see in the journal is:

Jun 10 16:47:52 desktop systemd[1]: dev-disk-by\x2duuid-efaa722d\x2d7296\x2d4659\x2d8d4a\x2d1d133d42f21a.device: Job dev-disk-by\x2duuid-efaa722d\x2d7296\x2d4659\x2d8d4a\x2d1d133d42f21a.device/start timed out.
Jun 10 16:47:52 desktop systemd[1]: Timed out waiting for device /dev/disk/by-uuid/efaa722d-7296-4659-8d4a-1d133d42f21a.
Jun 10 16:47:52 desktop systemd[1]: Dependency failed for /data.
Jun 10 16:47:52 desktop systemd[1]: Dependency failed for Local File Systems.
Jun 10 16:47:52 desktop systemd[1]: local-fs.target: Job local-fs.target/start failed with result ‘dependency’.
Jun 10 16:47:52 desktop systemd[1]: local-fs.target: Triggering OnFailure= dependencies.
Jun 10 16:47:52 desktop systemd[1]: data.mount: Job data.mount/start failed with result ‘dependency’.
Jun 10 16:47:52 desktop systemd[1]: dev-disk-by\x2duuid-efaa722d\x2d7296\x2d4659\x2d8d4a\x2d1d133d42f21a.device: Job dev-disk-by\x2duuid-efaa722d\x2d7296\x2d4659\x2d8d4a\x2d1d133d42f21a.device/start failed with result ‘timeout’.

The UUID referenced is that of the mapper device created when the disk is unlocked:

/dev/mapper/data: UUID=“efaa722d-7296-4659-8d4a-1d133d42f21a” UUID_SUB=“2f89968a-6a4a-4c1b-ad11-e459319f7f16” BLOCK_SIZE=“4096” TYPE=“btrfs”

Post computer output as preformatted text so it remains readable.

The log lines you posted come tool late and do not contain anything about unlocking your LUKS partition.

Here are the full logs:

/etc/crypttab (fails):
data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /data.key:UUID=E1DA-2923

dmesg:

journalctl:

/etc/crypttab (fails):
data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /data.key:PARTUUID=7a8ef736-65e2-4dfd-ba7a-8c1838aeebf3

dmesg:

journalctl:

/etc/crypttab (works):
data UUID=6e2089ea-ec52-4e33-a956-586c63ab54d0 /boot/efi/data.key

dmesg:

journalctl:

Please next time upload files to https://paste.opensuse.org/

Open bug report as instructed by the Portal:SELinux - openSUSE Wiki

Will do.

Many thanks. I can’t believe I missed such an obvious error! I had just noticed that the systemd-cryptsetup@data.service unit was not being created correctly but had completely overlooked SELinux. I can confirm that, with SELinux disabled, it all works as expected.

You were also correct that using the EFI partition was a bad idea as the system complains that it is already mounted. Moving the key file to the USB drive, and updating the UUID in /etc/crypttab, worked.

Thanks again for the help and advice, I will raise a bug now.

https://bugzilla.opensuse.org/show_bug.cgi?id=1244459