Why Is My Clevis Service Inactive After Rebooting Debian?

0
2
Asked By CuriousCat74 On

I'm trying to set up Clevis with my newly installed Debian system. I've installed all the relevant packages like vim, clevis, clevis-luks, clevis-systemd, and clevis-initramfs. The issue I'm running into is that while Clevis successfully encrypts the root disk with LUKS, it's failing to decrypt my data disks after I reboot. My fstab is set up like this:
```
LABEL=DISK1 /mnt/disk1 xfs defaults,_netdev 0 0
LABEL=DISK2 /mnt/disk2 xfs defaults,_netdev 0 0
```
And my crypttab looks like this:
```
disk1 UUID=disk1-uuid none _netdev
disk2 UUID=disk2-uuid none _netdev
```
I've also included the disks in Tang using these commands:
```
clevis luks bind -d /dev/vdb1 sss '{"t":1,"pins":{"tang":[{"url":"http://10.0.10.99"}]}}'
clevis luks bind -d /dev/vdc1 sss '{"t":1,"pins":{"tang":[{"url":"http://10.0.10.99"}]}}'
```
Then I enabled the clevis-luks-askpass.path using:
```
systemctl enable clevis-luks-askpass.path
```
However, after rebooting, the status of clevis-luks-askpass.path shows inactive and it doesn't decrypt the disks. I suspect the service isn't starting up at boot, but I'm not sure what steps to take next. Has anyone else experienced this or know how to fix it?

2 Answers

Answered By LinuxGuru22 On

I have a similar setup on an Ubuntu server, and this is the process I use:
```
apt install -y clevis clevis-luks clevis-initramfs clevis-systemd
clevis luks bind -d /dev/sda3 tang '{"url": "http://10.10.10.10"}'
clevis luks bind -d /dev/sda3 tang '{"url": "http://10.10.10.11"}'
sudo update-initramfs -u -k 'all'
```
Maybe this can help you identify what you might be missing?

DebianNoob -

I tried your approach on Trixie and switched to your method, but it's still not decrypting. The clevis systemd service remains inactive. I never had issues with Buster, which I upgraded to Bullseye.

Answered By TechSavvy99 On

Have you checked the boot logs with `journalctl -b`? It might give you some insight into what's going wrong during startup.

User12345 -

I did check, and the only error was about DISK1 timing out:
```
dev-disk-byx2dlabel-DISK1.device: job dev-disk-byx2dlabel-DISK1.device/start failed with result 'timeout'
timed out waiting for device dev-disk-byx2dlabel-DISK1.device - /dev/disk/by-label/DISK1
```
This causes the dependency for mnt-disk1 to fail too.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.