暗号化された Luks ボリュームに関して奇妙な体験をしており、誰かがその原因を解明するのを手伝ってくれることを期待しています。その手順を説明させてください。
OS (バニラ Arch (ちなみに)) をインストールするときに、/bootcryptestup と luks v2 を使用して暗号化されたルート パーティション (暗号化されていないまま) を設定しました。最初の数日間は問題なくすべて正常に動作していました。しかし、ある日再起動すると突然パスフレーズが受け入れられなくなりました。
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を起動してボリュームをマウントしようとしましたが、うまくいきません。次に、保存した場所からヘッダーをコピーして開こうとしましたが、ALSOは動作しませんパスワードを間違えないようにするコマンドも実行しました:
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
パスワードに関する急性選択性健忘症の可能性を排除するために、別のマシンでヘッダー ファイルを開こうとしましたが、問題なく動作しました。一方、メイン マシンでは依然としてエラーが発生します。
そこで私は基本的にコマンドをスパムして実行することにした。
echo [mypassword] | cryptsetup luksOpen --test-passphrase ./luksHeader
前の作業が終わるとすぐに、次の作業を開始します。奇妙なことに、ヘッダー ファイルを開く成功率は約 1/5 です。ほとんどの場合、連続して複数の失敗が発生しますが、2 回または 3 回連続して成功することもあります。
上記のコマンドによりパスワードを誤って入力したり、間違って覚えたりすることが不可能になるのに、これは非常に奇妙に思えました。ヘッダー ファイルに渡されるのは常に同じ文字列でした。さらに、私が述べたように、これは常に発生する問題ではありません。最初にこれを観察できたときから今日までの間に、再起動して問題なくパスフレーズを入力できた週が何週間もありました。
次に、暗号化されたパーティションで同じことを試してみましたが、成功率は約 1/5 でした。その後、再起動することにしました。No key available ...パスワードを入力するときにメッセージが 2 回表示され、3 回目の試行で起動に成功しました。
ここまで読んでくださった方、おめでとうございます。これを読んで私が経験したように気が狂ってしまわないように願っています。
現状では、a) 重要なものはすべてバックアップしており、b) 別のデバイスでドライブをいつでも復号化できるため、データを失うことをまったく心配していません (笑)。しかし、それでも、私が目撃している奇妙な動作についての説明、および、できればその解決策が欲しいです。少なくとも、いつでも好きなときに起動できないのは、私にとっては潜在的な迷惑だからです。
私は宇宙背景放射線や他の電磁場の発生源といった突飛なものも検討しましたが、もし皆さんがもっと良い理論を思いつかないのであれば、ヘッダーを失敗なく解読できるマシンと同じ部屋にタワーを移動してテストする必要があると思います。
大きな問題は、この問題がランダムに発生するようで、確実に再現する方法をまだ見つけられていないことです。その点でもご協力いただければ、大変助かります。
最後に: ヘッダー ファイルやボリュームを開く際の信頼性に改善が見られなかったため、この問題は追加の再起動や電源オフの影響を受けないようです。影響を受けると思われるのは時間だけです (明日はおそらく大丈夫でしょう)。ただし、BIOS 構成が失われるのは避けたいので、CMOS のクリアは確認しませんでした。