Remove Panocrypt from a LUKS device
Panocrypt binding is one removable LUKS unlock path.
Removing it does not decrypt the server. It does not require Panocrypt
software. It does not require Panocrypt to approve anything. You use the same
Linux primitives that own the disk already: LUKS, cryptsetup, and Clevis.
The short version is this: confirm you have another working local unlock path, find the Panocrypt-bound LUKS keyslot, then remove that keyslot.
What removal means
Section titled “What removal means”Panocrypt-managed unlock is a Clevis binding stored in one LUKS keyslot. Your other LUKS keyslots remain yours.
After you remove the Panocrypt-bound slot:
- The disk can stay encrypted.
- Customer-held recovery passphrases and other independent keyslots still work.
- Panocrypt cannot use that removed local binding to help unlock the disk.
- Panocrypt may still retain device records and historical unlock events.
- A running host is not locked, wiped, or changed beyond the local LUKS header update you performed.
This is the practical trust boundary: Panocrypt’s side of the exchange is not enough to unlock a disk after the local Panocrypt-bound LUKS slot is gone.
Before you remove it
Section titled “Before you remove it”Confirm another unlock path works before removing anything.
For a data volume, test your customer-held recovery material:
export LUKS_DEVICE="/dev/disk/by-id/YOUR_DEVICE"
sudo cryptsetup open --test-passphrase "$LUKS_DEVICE"If you store recovery material in a file, use your normal key-file option:
sudo cryptsetup open --test-passphrase \ --key-file /path/to/customer-held-recovery-key "$LUKS_DEVICE"For a root disk, do this during a planned maintenance window. Have provider console, KVM, rescue, or break-glass access ready before reboot tests.
If you want a fresh local keyslot before removal, add one with cryptsetup:
sudo cryptsetup luksAddKey "$LUKS_DEVICE"That new keyslot is local. Panocrypt does not receive the passphrase.
Find the LUKS device
Section titled “Find the LUKS device”For a data volume, use the block device you already opened with LUKS.
For a root disk, identify the encrypted backing device:
findmnt / -o SOURCE,FSTYPEsudo cryptsetup status cryptrootlsblk -fUse the stable device path for the LUKS device when possible, such as a
/dev/disk/by-id/... path.
Find the Panocrypt-bound slot
Section titled “Find the Panocrypt-bound slot”Use Clevis and cryptsetup to inspect the LUKS header:
sudo clevis luks list -d "$LUKS_DEVICE"sudo cryptsetup luksDump "$LUKS_DEVICE" | sed -n '/Keyslots:/,/Tokens:/p'The Clevis output shows the slot used by the network-bound unlock binding. Confirm that the binding points at this device’s Panocrypt unlock URL before removing it.
The output usually looks like a slot number followed by a Clevis tang
configuration. The exact formatting depends on your distro.
Remove the binding
Section titled “Remove the binding”Use your distro’s Clevis tooling to remove the Panocrypt-bound slot:
export PANOCRYPT_SLOT="1"
sudo clevis luks unbind -d "$LUKS_DEVICE" -s "$PANOCRYPT_SLOT"That removes the Clevis binding from the selected LUKS slot. It does not remove your other LUKS keyslots.
If you deliberately want to use raw LUKS tooling instead, cryptsetup luksKillSlot can wipe a specific slot:
sudo cryptsetup luksKillSlot "$LUKS_DEVICE" "$PANOCRYPT_SLOT"The Clevis command is usually the cleaner path because it understands the Clevis metadata associated with the binding.
Verify local control
Section titled “Verify local control”Inspect the device again:
sudo clevis luks list -d "$LUKS_DEVICE"sudo cryptsetup luksDump "$LUKS_DEVICE" | sed -n '/Keyslots:/,/Tokens:/p'Then test your remaining local unlock path again:
sudo cryptsetup open --test-passphrase "$LUKS_DEVICE"For a root disk, rebuild initramfs if your distro copied Clevis binding state into early boot:
sudo update-initramfs -u -k allUse your distro’s equivalent command on dracut-based systems, for example:
sudo dracut -fThen reboot only when you have recovery access available and you are ready to prove the root disk opens through your remaining local path.
Removal result
Section titled “Removal result”Panocrypt does not own the disk. The server can remain encrypted, your local LUKS keyslots can remain in place, and the Panocrypt-managed unlock path can be removed with ordinary Linux tools.
Panocrypt operationalizes unlock policy. LUKS still owns the encrypted volume.