# 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

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

Confirm another unlock path works before removing anything.

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

```sh
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:

```sh
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`:

```sh
sudo cryptsetup luksAddKey "$LUKS_DEVICE"
```

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

## 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:

```sh
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.

## Find the Panocrypt-bound slot

Use Clevis and `cryptsetup` to inspect the LUKS header:

```sh
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

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

```sh
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:

```sh
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

Inspect the device again:

```sh
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:

```sh
sudo cryptsetup open --test-passphrase "$LUKS_DEVICE"
```

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

```sh
sudo update-initramfs -u -k all
```

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

```sh
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.

## 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.