Meu computador congelou por um longo tempo e apertei o botão reset. Após a reinicialização, todos os sistemas de arquivos criptografados com CINCO luks (LUKS 1) não serão mais abertos. A mensagem que recebo é "Nenhuma chave disponível com esta senha". Tenho certeza de que estou usando a senha correta. Há anos uso a mesma senha para todos os sistemas de arquivos. Tenho backups para todos esses volumes, exceto um, então gostaria de analisar minhas opções. Eu tentei 'cryptsetup isLuks' e 'cryptsetup luksDump' em todos os sistemas de arquivos e todos eles foram bem-sucedidos, quero dizer, são partições Luks e posso despejar seus cabeçalhos e ver seus slots. No entanto, em pesquisas, encontrei casos semelhantes em que as pessoas dizem que seus cabeçotes foram danificados sem possibilidade de reparo. Não sei como identificar isso. Como faço isso? Obrigado por qualquer informação.
Responder1
Encontrei esta página:
https://bbs.archlinux.org/viewtopic.php?pid=1846810#p1846810
Também esta página:
Mais especificamente,
"Você pode dizer rapidamente se há alguma chance de recuperação. Execute "hexedit -s /dev/sdx" e procure pela string hexadecimal "4C 55 4B 53 BA BE" no início de um setor. (Essa é a string ASCII "LUKS" seguido pelos bytes hexadecimais 0xBA e 0xBE.) Se você não encontrar isso nos primeiros megabytes do disco, o cabeçalho LUKS desapareceu.
Todos os cinco sistemas de arquivos que se recusam a abrir têm essa string intacta em seus cabeçalhos, de modo que todos parecem não estar danificados. Agora, por que todos eles não abrem é uma questão separada e suspeito que nunca descobrirei o que aconteceu.
Responder2
Resposta fornecida para a posteridade.
Como saber se o seu cabeçalho LUKS está corrompido?
A resposta curta à sua pergunta é que ele informará que está corrompido quando você tentar desbloqueá-lo ou o sistema congela ao tentar inserir a senha, se for a partição de inicialização. Mas, no seu caso, ocorre apenas um erro sobre a chave não estar "disponível com esta senha", o que é um pouco estranho.
Visto que você já descobriu, hexedit -s <device>você também pode tentar executar dmsetup info <device_name>]depois de tentar inserir a senha e ver que tipo de estado é relatado, as tabelas são relatadas como presentes, etc.Página de manual para DMsetuppara mais informações.
Ou tente dmsetup table --showkeys <device or header file>ver se ele reconhecerá o slot de chave.
Métodos adicionais de verificação do cabeçalho LUKS
Além de usar o cryptsetup luksHeaderBackup <device> --header-backup-file <file>para criar um backup de cabeçalho (mesmo que não abra, pois luksDumpnão relata nenhuma corrupção), você também pode tentar fazer um backup deles e depois tentar restaurá-los a partir desses backups para ver se isso cryptsetupacontecerá. permitem restaurar o cabeçalho dessa maneira. Além do método mencionado, você também pode usar ddcomo alternativa para criar um "backup" do cabeçalho:
root@system:# dd if=<device> of=<Luksheader_filename> bs=512 count=4097
Além de usar hexeditpara verificar o cabeçalho, você também pode usar o comando fileou stringsno arquivo que acabou de criar acima, ou até mesmo executar luksDumpo comando no próprio arquivo, substituindo o nome do dispositivo pelo caminho e nome do arquivo.
root@system:# file <Luksheader_filename>
root@system:# strings <Luksheader_filename> | grep -i luks LUKS
root@system:# cryptsetup luksDump <Luksheader_filename>
Casos semelhantes podem ou não ser tão semelhantes
Em termos dos outros e da sua pesquisa, os que você linkou acima, não ficou claro o que você estava fazendo quando o computador congelou e, portanto, seria a última vez que você conseguiria acessar as unidades. Em contraste, dois links envolvem duas razões diferentes para que suas unidades individuais criptografadas por LUKS se tornem inacessíveis, uma delas relacionada a umHPAconfiguração incorreta e a outra foi após uma atualização do kernel que afetou apenas o /homevolume e não o /rootvolume, e pode na verdade ser devido a umproblema de cortar/descartar.
Talvez um problema de ocorrência mais semelhante com base na explicação ampla possa ser encontradoaqui, onde eles até começaram a considerar a possibilidade de um raio cósmico forçar uma mudança de bit em algum lugar e pode ser uma boa leitura para alguém que queira verificar novamente se explorou todas as outras opções.
Como não está claro com base nas informações fornecidas, se esses "sistemas de arquivos"* como você os chama, retêm seu sistema operacional ou apenas "conteúdo", como colocaremos de forma ampla, ajudaria saber se o seu sistema congela ao tentar para inicializar se um dos volumes/partições criptografados LUKS for sua unidade de inicialização e a senha não funcionar ou se você estiver apenas tentando acessar esses 5 dispositivos a partir do terminal e/ou de uma GUI (e em que tipo de Linux ) que dá aquele erro repetido? Nesse caso, pode haver alguma esperança com o último.
*Como ponto de esclarecimento, "sistema de arquivos" se referiria a como e onde os dados são armazenados, portanto, o sistema de arquivos geralmente se referirá a formatos como ext3, ext4, NTFS, etc., enquanto LUKS é uma especificação de criptografia de disco. Portanto, não nos dá nenhuma ideia sobre qual o papel desses 5 'sistemas de arquivos' LUKS (presumivelmente volumes como você mencionou) desempenham como parte do seu sistema.
Possível problema sem cabeçalho
A questão era sobre como identificar e/ou determinar um cabeçalho LUKS corrompido. No entanto, sem um backup de qualquer um dos cabeçalhos, não haveria uma versão não corrompida do cabeçalho para o OP comparar. Como pode estar mais claro agora que a situação aplicável é incerta e provavelmente diferente dos exemplos vinculados, pode valer a pena tentar:
Verificando se é um problema de LVM usando
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)
Veja a página de manual paralvscaneexibição vgaprender mais.
E, explorando outras possibilidades
Infelizmente, com a criptografia LUKS1, as somas de verificação não foram implementadas por vários motivos, que você pode aprender comesta apresentaçãose desejado. Caso contrário, isso significa apenas que a única "soma de verificação" no LUKS é aquela que informa que não há slot de chave correspondente e implica que ele está corrompido.
No entanto, foi notado que você disse que todos os 5 sistemas de arquivos não abririam e se referiria a todos eles como volumes, então não está claro se está tudo em um disco e se é ou não uma unidade SSD ou não, nesse caso, umVerificação de memória e armazenamentoda unidade seria a próxima sugestão.
Finalmente, com certeza, você respondeu cryptsetupsim sudo?
Você também pode tentar
- Usando o recurso de recuperação na GUI do gparted encontrado em relação às tabelas de partição e outros enfeites
- Fazendo uma varredura com
ddrescue - Certifique-se de que o Caps Lock ou o Number Lock não estejam ativados (bobo, eu sei, mas apenas um lembrete gentil)
- Experimente algumas das respostas sugeridasaqui
- se houve uma atualização antes do computador travar, tente reverter para uma versão anterior
- Tente adicionar uma senha em outro keylot
Nota
Foi assumido que você tentou abrir os volumes criptografados LUKS dentro de um terminal e com sudo, já que nenhum sistema ou GUI específico foi mencionado, nem menção a um processo de inicialização.