View Issue Details

IDProjectCategoryView StatusLast Update
0017470CentOS-8-OTHERpublic2020-06-16 23:07
Reporterrgmorris 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0017470: Clevis unlock of /etc/crypttab entries using device names fails in 8.2
DescriptionUsing Clevis at boot time to automatically unlock a non-root crypttab partition was working in 8.1, but fails in 8.2.
There is no communication with the Tang server during boot.
Steps To ReproduceContents of /etc/crypttab:
  data1 /dev/vda5 none _netdev,timeout=60s

Note the use of a device name in the second field, not UUID=.
In CentOS 8.1, I used "systemctl enable clevis-luks-askpass.path" to enable automatic unlock of this partition at boot using a Tang server.
On upgrading to CentOS 8.2, this service was removed and replaced by an instance of the form clevis-luks-askpass@UUID.service,
where UUID is that for /dev/vda5.
This service runs at boot, but fails to unlock the partition. It does not communicate with the Tang server.
Additional Information/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.

This is an upstream RHEL issue.

Meta:
bugs.centos.org doesn't seem to have a "product version" for CentOS 8.2, nor a category for "clevis".
TagsNo tags attached.

Issue History

Date Modified Username Field Change
2020-06-16 22:55 rgmorris New Issue
2020-06-16 23:07 rgmorris Note Added: 0037129