Мой компьютер завис на долгое время, и я нажал кнопку сброса. После перезагрузки все ПЯТЬ файловых систем, зашифрованных luks (LUKS 1), больше не открываются. Я получаю сообщение «Нет доступного ключа с этой парольной фразой». Я уверен, что использую правильный пароль. Я использую один и тот же пароль для всех файловых систем в течение многих лет. У меня есть резервные копии для всех этих томов, кроме одного, поэтому я хотел бы проанализировать свои варианты для него. Я пробовал «cryptsetup isLuks» и «cryptsetup luksDump» для всех файловых систем, и все они успешны, я имею в виду, что это разделы Luks, и я могу сбросить их заголовки и увидеть их слоты. Однако при исследовании я нашел похожие случаи, когда люди говорят, что их заголовки были повреждены без возможности восстановления. Я не знаю, как это определить. Как мне это сделать? Спасибо за любую информацию.
решение1
Я нашел эту страницу:
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
Также эта страница:
А точнее,
«Вы можете довольно быстро определить, есть ли шанс на восстановление. Запустите «hexedit -s /dev/sdx» и найдите шестнадцатеричную строку «4C 55 4B 53 BA BE» в начале сектора. (Это строка ASCII «LUKS», за которой следуют шестнадцатеричные байты 0xBA и 0xBE.) Если вы не найдете ее в пределах первых нескольких мегабайт диска, заголовок LUKS исчез».
Все пять файловых систем, которые отказываются открываться, имеют эту строку в заголовках, так что все они, похоже, не повреждены. Теперь, почему все они не открываются, это отдельный вопрос, и я подозреваю, что я никогда не узнаю, что произошло.
решение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>
Похожие случаи могут быть похожими, а могут и не быть.
Что касается других и вашего исследования, тех, на которые вы ссылались выше, не было ясно, что вы делали, когда ваш компьютер завис, и, таким образом, это был последний раз, когда вы могли получить доступ к дискам. Напротив, две ссылки включают две разные причины, по которым их отдельные зашифрованные LUKS диски стали недоступными, одна из которых связана сHPAнеправильная конфигурация, а другой произошел после обновления ядра, которое повлияло только на /homeтом, а не на /rootобъем, и на самом деле может быть вызванопроблема обрезки/выброса.
Возможно, можно найти более похожую проблему, основанную на широком объяснении.здесь, где они даже начали рассматривать возможность того, что космические лучи заставляют биты переключаться где-то, и это может быть полезным чтением для тех, кто хочет еще раз проверить, исследовали ли они все другие варианты.
Поскольку на основе предоставленной информации неясно, содержат ли эти «файловые системы»*, как вы их называете, вашу операционную систему или просто «контент», как мы выразимся в общих чертах, было бы полезно узнать, зависает ли ваша система при попытке загрузки, если один из зашифрованных томов/разделов LUKS является вашим загрузочным диском, а пароль не работает, или если вы просто пытаетесь получить доступ к этим 5 устройствам из терминала и/или из графического интерфейса (и на какой версии Linux), что выдает вам эту повторяющуюся ошибку? В таком случае, может быть небольшая надежда на последнее.
*В качестве пояснения, «файловая система» будет относиться к тому, как и где хранятся данные, поэтому файловая система обычно будет относиться к таким форматам, как 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иvgdisplayУзнать больше.
И, исследуя другие возможности
К сожалению, при шифровании LUKS1 контрольные суммы не были реализованы по ряду причин, о которых вы можете узнать изэта презентацияесли хотите. В противном случае, это просто означает, что единственная «контрольная сумма» в LUKS — это та, которая сообщает вам, что нет соответствующего слота ключа, и подразумевает, что он поврежден.
Однако было отмечено, что вы сказали, что все 5 файловых систем не будут открываться, и ссылаетесь на них как на тома, поэтому неясно, находятся ли они все на одном диске и является ли это SSD-диском или нет, в таком случаеСканирование памяти и хранилищаСледующим предложением будет привод.
Наконец, чтобы убедиться, вы ответили cryptsetup« sudoда»?
Вы также можете попробовать
- Используя функцию восстановления в графическом интерфейсе gparted, найденную относительно таблиц разделов и т.п.
- Сканирую его с помощью
ddrescue - Убедитесь, что не включена блокировка заглавных букв или цифр (знаю, это глупо, но это просто вежливое напоминание).
- Попробуйте некоторые из предложенных ответовздесь
- если перед зависанием компьютера было обновление, попробуйте откатиться к предыдущей версии
- Попробуйте добавить пароль в другой слот для ключей.
Примечание
Предполагалось, что вы попытались открыть зашифрованные тома LUKS в терминале с помощью sudo, поскольку не было упомянуто ни конкретной системы, ни графического интерфейса, ни процесса загрузки.