我對我的加密 Luks 捲經歷了最奇怪的經歷，希望有人能幫助我闡明它。讓我引導您完成它。
安裝我的作業系統（vanilla 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檢查我的鍵盤佈局來啟動，也沒有問題。所以在這一點上，我以為我是 sol 看到的，因為我沒有標頭備份（認為當前的標頭備份已損壞），但在絕望中我嘗試再次啟動，這一次它工作正常嗎？
立即繼續建立頭備份檔。透過運行驗證其完好無損
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）我總是可以在另一台設備上解密我的驅動器（我認為，哈哈），但我仍然會就像對我所目睹的奇怪行為的解釋，以及可能的解決方案，因為至少它給我帶來了潛在的煩惱，因為我無法隨時啟動。
我甚至考慮過一些奇怪的事情，例如宇宙背景輻射或其他電磁場來源，如果你們中沒有人能提出更好的理論，那麼我想我必須通過將我的塔移到同一個地方來測試它room作為可以無故障解密標頭的機器。
最大的問題是這個問題似乎是隨機發生的，因為我還沒有找到可靠地重現它的方法。如果您能在這方面幫助我，我將不勝感激！
最後：這個問題似乎不受額外的重新啟動/斷電的影響，因為我無法觀察到開啟頭檔/磁碟區的可靠性有任何改進。唯一影響它的似乎是時間（明天可能會好）。不過，我沒有檢查清除 CMOS，因為如果可以避免的話，我不想失去 BIOS 配置。