![LUKS ヘッダーが破損しているかどうかはどうすればわかりますか?](https://rvso.com/image/756787/LUKS%20%E3%83%98%E3%83%83%E3%83%80%E3%83%BC%E3%81%8C%E7%A0%B4%E6%90%8D%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%81%8B%E3%81%A9%E3%81%86%E3%81%8B%E3%81%AF%E3%81%A9%E3%81%86%E3%81%99%E3%82%8C%E3%81%B0%E3%82%8F%E3%81%8B%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B%3F.png)
コンピュータが長時間フリーズしたので、リセット ボタンを押しました。再起動後、5 つの luks 暗号化 (LUKS 1) ファイル システムすべてが開かなくなりました。表示されるメッセージは、「このパスフレーズで使用できるキーはありません」です。正しいパスワードを使用していることは確かです。何年もの間、すべてのファイル システムに同じパスワードを使用しています。1 つを除くすべてのボリュームのバックアップがあるので、そのオプションを分析したいと思います。すべてのファイル システムで「cryptsetup isLuks」と「cryptsetup luksDump」を試しましたが、すべて成功しました。つまり、それらは Luks パーティションであり、ヘッダーをダンプしてスロットを確認できます。ただし、調査したところ、ヘッダーが修復できないほど破損しているという同様のケースが見つかりました。それを特定する方法がわかりません。どうすればいいですか? 情報があれば、よろしくお願いします。
答え1
このページを見つけました:
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
このページも:
すなわち、
「回復の可能性があるかどうかは、かなり早くわかります。「hexedit -s /dev/sdx」を実行し、セクターの先頭で 16 進文字列「4C 55 4B 53 BA BE」を検索します。(これは、ASCII 文字列「LUKS」の後に 16 進バイト 0xBA と 0xBE が続く文字列です。) ディスクの最初の数メガバイト内にそれが見つからない場合、LUKS ヘッダーは失われています。」
開かない 5 つのファイル システムはすべて、ヘッダーにその文字列がそのまま残っているので、破損していないようです。ただし、なぜすべてが開かないのかは別の問題であり、何が起こったのかは永遠にわからないと思います。
答え2
後世のために回答を提供します。
LUKS ヘッダーが破損しているかどうかを知るにはどうすればよいでしょうか?
質問に対する簡単な答えは、ロック解除しようとすると破損していると表示されるか、ブート パーティションの場合はパスフレーズを入力しようとするとシステムがフリーズするということです。しかし、あなたの場合は、キーが「このパスフレーズでは使用できない」というエラーが表示されるだけで、少し奇妙です。
すでに発見したので、パスワードを入力してから実行してみて、どのような状態が報告されるか、テーブルが存在すると報告されるかなどを確認することhexedit -s <device>
もできます。dmsetup info <device_name>]
DMsetup のマニュアルページ詳細については。
または、dmsetup table --showkeys <device or header file>
キースロットが認識されるかどうかを確認してください。
LUKS ヘッダーを確認するための追加方法
ヘッダーのバックアップを作成するために を使用する以外に (破損が報告されないcryptsetup luksHeaderBackup <device> --header-backup-file <file>
ため開かない場合でも)、それらのバックアップを作成し、それらのバックアップから復元して、 でヘッダーを復元できるかどうか確認してみるのもよいでしょう。前述の方法の他に、ヘッダーの「バックアップ」を作成するための代替手段としてを使用することもできます。luksDump
cryptsetup
dd
root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097
hexedit
を使用してヘッダーを検証するだけでなく、上記で作成したファイルに対してコマンドfile
またはコマンドを使用することもできます。また、デバイス名をパスとファイル名に置き換えて、ファイル自体に対して コマンドを実行することもできます。strings
luksDump
root@system:# file <Luksheader_filename>
root@system:# strings <Luksheader_filename> | grep -i luks LUKS
root@system:# cryptsetup luksDump <Luksheader_filename>
類似のケースは似ている場合もあれば、似ていない場合もあります
上記にリンクした他の事例やあなたの調査では、コンピュータがフリーズしたときに何をしていたのかが明らかにされておらず、それがドライブにアクセスできた最後の機会となる。対照的に、2つのリンクでは、それぞれのLUKS暗号化ドライブがアクセス不能になった2つの異なる理由が関係しており、1つはHPA設定ミスと、もう1つはカーネルのアップグレード後に/home
ボリュームにのみ影響し、ボリュームには影響しなかった/root
ため、実際にはトリム/破棄の問題。
おそらく、より広範な説明に基づいて、より類似した問題が見つかるかもしれませんここそこでは、宇宙線がどこかでビットスイッチを強制する可能性さえ考慮し始めており、他のすべての選択肢を検討したかどうかを再確認したい人にとっては良い読み物になるかもしれません。
提供された情報に基づくと、あなたが言及しているこれらの「ファイルシステム」* がオペレーティングシステムを保持しているのか、それとも広義で言えば「コンテンツ」だけを保持しているのかは不明なので、LUKS で暗号化されたボリューム/パーティションの 1 つがブートドライブであり、パスワードが機能しない場合に、ブートしようとするとシステムがフリーズするかどうか、またはターミナルや GUI (およびどのバージョンの Linux) からこれらの 5 つのデバイスにアクセスしようとしているときに繰り返しエラーが発生するかどうかを知ることは役に立ちます。その場合、後者にはわずかな希望があるかもしれません。
*明確にしておくと、「ファイルシステム」はデータの保存方法と場所を指します。したがって、ファイルシステムは通常、ext3、ext4、NTFS などの形式を指しますが、LUKS はディスク暗号化仕様です。したがって、これら 5 つの LUKS「ファイルシステム」(おそらく、おっしゃるとおりボリューム) がシステムの一部としてどのような役割を果たしているかについては、何もわかりません。
ヘッダー以外の問題の可能性
質問は、破損した LUKS ヘッダーを識別および/または判断する方法についてでした。しかし、ヘッダーのバックアップがなければ、OP が比較できる破損していないバージョンのヘッダーはありません。適用される状況は不確実であり、リンクされた例とは異なる可能性が高いことが今では明らかになっているため、試してみる価値があるかもしれません。
LVMの問題かどうかを確認するには
root@system:# lvscan
# or
root@system:# lvdisplay
# To check if you can still identify the LUKS filesystems as volume groups or
# supported LVM block devices.
root@system:# vgdisplay --short
# To find the Volume Group (usually fails if password won't work)
root@system:# lvs -o lv_name,lv_size -S vg_name=[name_of_volumegroup]
# To list the logical volumes identified in the volume group (if it works)
マニュアルページを参照してくださいlvscanそしてvgディスプレイ詳しく知ることができ。
そして、他の可能性を探る
残念ながら、LUKS1暗号化では、いくつかの理由によりチェックサムが実装されていません。その理由は次の通りです。このプレゼンテーション必要であれば。それ以外の場合、LUKS の唯一の「チェックサム」は、一致するキー スロットが存在せず、破損していることを示唆するものになります。
しかし、5つのファイルシステムすべてが開かず、それらをすべてボリュームとして参照するとおっしゃっていたため、すべてが1つのディスク上にあるかどうか、SSDドライブであるかどうかは不明です。その場合、メモリとストレージのスキャンドライブの次の提案になります。
最後に、念のため、はいcryptsetup
と答えましたsudo
か?
あなたも試してみるといいかもしれません
- gpartedのGUIのリカバリ機能を使用してパーティションテーブルなどに関するものを見つけた
- スキャンしてみると
ddrescue
- Caps Lock または Number Lock がオンになっていないことを確認してください (馬鹿げているかもしれませんが、単なる注意喚起です)
- 提案された回答をいくつか試してみてくださいここ
- コンピュータがフリーズする前にアップデートがあった場合は、以前のバージョンにロールバックしてみてください。
- 別のキースロットにパスワードを追加してみてください
サイドノート
特定のシステムや GUI について言及されておらず、ブート プロセスについても言及されていないため、ターミナル内で sudo を使用して LUKS で暗号化されたボリュームを開こうとしたものと想定されます。