Skip to content

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.

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.

Confirm another unlock path works before removing anything.

For a data volume, test your customer-held recovery material:

Terminal window
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:

Terminal window
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:

Terminal window
sudo cryptsetup luksAddKey "$LUKS_DEVICE"

That new keyslot is local. Panocrypt does not receive the passphrase.

For a data volume, use the block device you already opened with LUKS.

For a root disk, identify the encrypted backing device:

Terminal window
findmnt / -o SOURCE,FSTYPE
sudo cryptsetup status cryptroot
lsblk -f

Use the stable device path for the LUKS device when possible, such as a /dev/disk/by-id/... path.

Use Clevis and cryptsetup to inspect the LUKS header:

Terminal window
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.

Use your distro’s Clevis tooling to remove the Panocrypt-bound slot:

Terminal window
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:

Terminal window
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.

Inspect the device again:

Terminal window
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:

Terminal window
sudo cryptsetup open --test-passphrase "$LUKS_DEVICE"

For a root disk, rebuild initramfs if your distro copied Clevis binding state into early boot:

Terminal window
sudo update-initramfs -u -k all

Use your distro’s equivalent command on dracut-based systems, for example:

Terminal window
sudo dracut -f

Then reboot only when you have recovery access available and you are ready to prove the root disk opens through your remaining local path.

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.