clevis-systemd doesn't do anything

Bug #1778731 reported by Ross Kramer
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
clevis (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Description: Ubuntu 18.04 LTS
Release: 18.04

clevis-systemd:
  Installed: 8-1
  Candidate: 8-1
  Version table:
 *** 8-1 500
        500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status

What I expected to happen: enabling clevis-systemd with the expectation that it would decrypt local LUKSV1 disks on boot.

What actually happened:

I've gotten as far as partitioning (not using LVM here), encrypting, binding it to a tang server following below procedure:

apt-get install clevis clevis-systemd clevis-dracut clevis-luks

Set up the disk

echo '<TEMPPASS>'| cryptsetup --verbose luksFormat /dev/xvdc1

clevis bind luks -f -k- -d /dev/xvdc1 tang '{"url":"http://<IP>:<PORT>","thp":"<KEY>"}' <<< "<TEMPPASS>"

Get rid of the temporary passkey

echo "<TEMPPASS>" | cryptsetup luksRemoveKey /dev/xvdc1

Verify that we can use clevis to unlock the device

clevis luks unlock -d /dev/xvdc1 -n testluksvol

Device unlocks. Then I format it and verify it can mount.

mkfs.ext4 /dev/mapper/testluksvol

mount /dev/mapper/testluksvol /testluksvol

I add the entries to /etc/fstab using _netdev as the directions said:

/dev/mapper/testluksvol /testluksvol ext4 defaults,_netdev 0 2

Add the entry to /etc/crypttab, also with _netdev, though I didn't think Ubuntu crypttab supported that since it isn't in the crypttab manpage, but this seems to be the only documented method.

testluksvol UUID=<DEVICE UUID> none _netdev

Finally, enable clevis-luks-askpass.path

systemctl enable clevis-luks-askpass.path

Reboot... and the device doesn't decrypt or mount. It sits for a bit running a job for the device before finally giving up and finishing the boot.

Here's the errors I found in the logs:

Jun 22 23:06:22 ubuntu03 systemd[1]: dev-disk-by\x2duuid-72ebf50e\x2dc3de\x2d468a\x2d89c3\x2defc869757a51.device: Job dev-disk-by\x2duuid-72ebf50e\x2dc3de\x2d468a\x2d89c3\x2defc86975
7a51.device/start timed out.
Jun 22 23:06:22 ubuntu03 systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-72ebf50e\x2dc3de\x2d468a\x2d89c3\x2defc869757a51.device.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for Cryptography Setup for testluksvol.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for dev-mapper-testluksvol.device.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for /testluksvol.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for Remote File Systems.
Jun 22 23:06:22 ubuntu03 systemd[1]: remote-fs.target: Job remote-fs.target/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: testluksvol.mount: Job testluksvol.mount/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for File System Check on /dev/mapper/testluksvol.
Jun 22 23:06:22 ubuntu03 systemd[1]: <email address hidden>: Job <email address hidden>/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: dev-mapper-testluksvol.device: Job dev-mapper-testluksvol.device/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: Dependency failed for Local Encrypted Volumes.
Jun 22 23:06:22 ubuntu03 systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: <email address hidden>: Job <email address hidden>/start failed with result 'dependency'.
Jun 22 23:06:22 ubuntu03 systemd[1]: dev-disk-by\x2duuid-72ebf50e\x2dc3de\x2d468a\x2d89c3\x2defc869757a51.device: Job dev-disk-by\x2duuid-72ebf50e\x2dc3de\x2d468a\x2d89c3\x2defc86975
7a51.device/start failed with result 'timeout'.

18.04 has support for using NBDE via clevis & tang but it doesn't seem to work for just decrypting secondary disks.

Revision history for this message
Markus Ueberall (ueberall) wrote :

This looks to be identical to what Ross Kramer described here: https://ubuntuforums.org/showthread.php?t=2395010 -- if so, can this be closed because the underlying cause was a wrong UUID?

dann frazier (dannf)
Changed in clevis (Ubuntu):
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for clevis (Ubuntu) because there has been no activity for 60 days.]

Changed in clevis (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.