+++ This bug was initially created as a clone of Bug #1824414 +++ Description ------------- Before the NBDE playbook completes the binding to tang server procedure, if any failures occurs, then users prefers to run cleanup to fix previously created setup. But this procedure, also removes the keyslot 0, where the initial passphrase is removed Version ------- RHHI-V 1.8 RHVH 4.4 gluster-ansible-infra-1.0.4-8 How reproducible ----------------- Always Steps to reproduce ------------------- 1. Update the ansible inventory file for NBDE 2. Run the playbook with incorrect disks 3. Run the cleanup playbook Actual results --------------- keyslot 0 is getting removed, as part of clevis-luks-unbind Expected results ----------------- clevis-luks-unbind should be used on root disk only when clevis-luks-list returns values --- Additional comment from RHEL Program Management on 2020-04-16 07:35:47 UTC --- This bug is automatically being proposed for RHHI-V 1.8 release at Red Hat Hyperconverged Infrastructure for Virtualization product, by setting the release flag 'rhiv‑1.8' to '?'. If this bug should be proposed for a different release, please manually change the proposed release flag.
Only the slots containing the Clevis needs to be removed. This information can be obtained from clevis-luks-list command [root@ ~]# clevis-luks-list -d /dev/sda2 2: tang '{"url":"http://dhcp35-220.lab.eng.blr.redhat.com:7500"}' 3: tang '{"url":"http://dhcp35-114.lab.eng.blr.redhat.com"}' In this case, the values that needs to used are 2 and 3. clevis-luks-unbind -d /dev/sda2 -s 2 clevis-luks-unbind -d /dev/sda2 -s 3 No other slots should be used, because, the other keyslots may have key information pertaining to other keys
Tested with gluster-ansible-roles-1.0.5-12.el8rhgs 1. Start NBDE playbook with incorrect disks 2. When the NBDE setup fails, perform cleanup 3. Check for the keyslots on the root disk. Root disk has that slot0 preserved.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2020:2575