Description of problem:
(This issue was found in CentOS 8.2, but seems like it must apply to RHEL also.)

Using Clevis at boot time to automatically unlock a non-root crypttab partition was working in 8.1, but failed in 8.2. There is no communication with the Tang server during boot.


Version-Release number of selected component (if applicable):
clevis-systemd-11-9.el8.x86_64


How reproducible:
Always.


Steps to Reproduce:
1. /etc/crypttab for non-root partition with entry of the form:
data1 /dev/vda5 none _netdev,timeout=60s

where /dev/vda5 is a luks1 partition.
Note the use of a device name in the second field, not UUID=.

2. Use clevis to bind this partition to a tang server for automatic unlock at boot time. In 8.1, this used: "systemctl enable clevis-luks-askpass.path".
In 8.2, this was replaced by a device-specific instance of the form clevis-luks-askpass.

3. Reboot.

Actual results:
No communication with Tang server at boot, partition is not unlocked.

Expected results:
Partition unlocked at boot.

Additional info:
/usr/libexec/clevis-luks-askpass sets the variable $d from the line:
  Id=cryptsetup:/
in /run/systemd/ask-password/ask.*
By experiment, this line comes from the second field in the /etc/crypttab file. If you use a device name in that file, the line
is of the form:
  Id=cryptsetup:/dev/vda5

In 8.2, clevis-luks-askpass compares this against the $device_uuid argument that was passed to the script instance via -l:
  [[ -n "${device_uuid}" ]] && [[ "${d}" != *"${device_uuid}"* ]] && continue

This will never match if you specified the device name in crypttab. Changing the crypttab file to use the UUID works.

Perhaps it would be fine to document that the UUID form is required.