我已经遇到过这个问题几次，但到目前为止我无法可靠地重现这个问题/找到根本原因。我该去哪里？看起来获取hexdump标头可能会有所帮助，所以也许继续拍摄hexdump第一个关键槽区域的快照，直到它再次执行此操作？
症状：
- 重新启动/关闭后，有时第一个密钥槽的密码被拒绝
No key available for this passphrase. - 有时标头备份似乎没有帮助。运行类似的东西
cryptsetup -v --header backupheader.bin open /dev/device test仍然会返回No key...第一个插槽。但是从头备份恢复的五分之一是有效的（同样，有时有效，有时无效）。cryptsetup luksHeaderRestore产生相同的结果。
观察结果：
- 分区本身似乎没问题。
lsblk并且cryptsetup isLuks没有任何异常表现。 cryptsetup luksDump始终有效并显示第一个插槽已启用。- 此后我又添加了一些键，并且这些键始终有效。这是第一个似乎有问题的关键插槽。
- 如果我使用第二个或除第一个之外的任何其他密钥解锁分区，则第一个密钥插槽通常在下次启动时起作用。
环境：
- X1 Carbon Gen 6、Fedora 28