我在使用加密 Luks 卷时遇到了一些奇怪的事情，希望有人能帮我解开这个谜团。让我来告诉你答案。
在安装我的操作系统（原版 Arch（顺便说一下））时，我使用 cryptestup 和 luks v2 设置了一个加密的根分区（/boot未加密）。前几天一切都运行正常，没有问题。然后有一天重启后它突然不再接受我的密码了。
No key available with this passphrase就是我得到的全部。所以我首先检查的显然是我的键盘布局是否有问题。启动实时 Manjaro ISO 以使用以下命令在其中安装卷，这样我就可以看到我的密码（这样就不会输错）：
echo [mypassword] | cryptsetup open --test-passphrase /dev/nvme0n1p2
并尝试了以下方法，以防万一
echo [mypassword] | cryptsetup luksOpen --test-passphrase /dev/nvme0n1p2
但无济于事。break=premount启动时使用检查键盘布局，也没有问题。所以此时我认为我没问题了，因为我没有头文件备份（认为当前的头文件已损坏），但在绝望的最后努力下，我尝试再次启动，这次一切正常？
立即继续创建头文件备份。通过运行以下命令验证它是否完整
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
并将标题保存在加密卷之外。
直到今天我才再次遇到这个问题，在启动过程中我再次收到该No key available with this passphrase消息。好吧，然后启动到我的实时 ISO 并尝试在那里安装卷，不起作用。然后我从存储它们的位置复制标题并尝试打开它们，但也不起作用。甚至运行了使我的密码不可能被弄乱的命令：
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
为了排除我对密码的选择性遗忘，我尝试在另一台机器上打开头文件，没有问题。同时，在我的主机上，我仍然收到错误。
所以我决定基本上发送该命令，运行
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
一旦前一个步骤完成，就会立即打开。奇怪的是，我现在观察到打开头文件的成功率约为 1/5。大多数时候我会连续多次失败，但有时我也会连续 2 或 3 次成功。
这让我觉得非常奇怪，因为上面的命令使得输入错误或记错密码成为不可能。传递给头文件的字符串始终是相同的。此外，正如我提到的，这不是一个持续存在的问题，因为从我第一次观察到这个问题到今天，有好几个星期我都可以重新启动并输入密码而没有任何问题。
然后，我尝试对加密分区进行同样的操作，也观察到了大约 1/5 的成功率。然后我决定重新启动，No key available ...在输入密码时收到两次消息，并在第三次尝试时成功启动。
如果你已经读到这里，恭喜你。我希望你没有像我一样在读这篇文章时发疯。
就目前情况而言，我根本不担心丢失数据，因为 a）我备份了所有重要数据，并且 b）我总是可以在另一台设备上解密我的驱动器（我想是的，哈哈），但我仍然希望对我所目睹的奇怪行为有一个解释，并且可能有一个解决方案，因为至少它给我带来了潜在的烦恼，让我无法随时启动。
我甚至考虑过一些古怪的东西，比如宇宙背景辐射，或其他电磁场源，如果你们都不能提出更好的理论，那么我想我必须通过将我的塔移到与可以无故障解密标头的机器相同的房间来测试它。
最大的问题是这个问题似乎是随机发生的，因为我还没有找到可靠的方法来重现它。如果你能帮助我，我将不胜感激！
最后：这个问题似乎不受额外重启/关机的影响，因为我没有观察到打开头文件/卷的可靠性有任何改善。似乎唯一影响它的是时间（明天可能就好了）。我没有检查清除 CMOS，因为如果可以避免的话，我不想丢失我的 BIOS 配置。