Eu tenho um laptop rodando Maverick (muito feliz até ontem), com um SSD Patriot Torx; Criptografia LUKS de toda a partição; um volume físico lvm em cima disso; depois, home e root em ext4 volumes lógicos em cima disso.
Quando tentei inicializá-lo ontem, ele reclamou que não era possível montar o sistema de arquivos raiz. Rodando fsck, basicamente todo inode parece estar errado. Os sistemas de arquivos doméstico e raiz mostram problemas semelhantes. Verificar um superbloco de backup não ajuda.
e2fsck 1.41.12 (17-May-2010)
lithe_root was not cleanly unmounted, check forced.
Resize inode not valid. Recreate? no
Pass 1: Checking inodes, blocks, and sizes
Root inode is not a directory. Clear? no
Root inode has dtime set (probably due to old mke2fs). Fix? no
Inode 2 is in use, but has dtime set. Fix? no
Inode 2 has a extra size (4730) which is invalid
Fix? no
Inode 2 has compression flag set on filesystem without compression support. Clear? no
Inode 2 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
HTREE directory inode 2 has an invalid root node.
Clear HTree index? no
Inode 2, i_size is 9581392125871137995, should be 0. Fix? no
Inode 2, i_blocks is 40456527802719, should be 0. Fix? no
Reserved inode 3 (<The ACL index inode>) has invalid mode. Clear? no
Inode 3 has compression flag set on filesystem without compression support. Clear? no
Inode 3 has INDEX_FL flag set but is not a directory.
Clear HTree index? no
....
Executando strings em todos os sistemas de arquivos, eu vejo que existem nomes de arquivos e dados do usuário lá. Eu tenho backups suficientemente bons (touch madeira) que não vale a pena rastejar para puxar arquivos individuais, embora eu possa salvar uma imagem do disco não criptografado antes de reconstruir, apenas no caso.
smartctl não mostra nenhum erro, nem o log do kernel. Executar um modo de gravação badblocks no swap lv também não encontra problemas. Então o disco pode estar falhando, mas não de maneira óbvia.
Neste momento eu sou basicamente, como eles dizem, fscked? Voltar para reinstalar, talvez executando badblocks sobre o disco e, em seguida, restaurando de backup? Nem parece haver dados suficientes para apresentar um bug significativo ...
Não me lembro de que esta máquina caiu da última vez que a usei.
Neste ponto, suspeito que um erro ou a corrupção da memória fizeram com que ele escrevesse lixo nos discos quando ele estava sendo executado pela última vez, ou algum tipo de modo de falha sutil para o SSD.
O que você acha que teria causado isso? Há mais alguma coisa que você tentaria?
Parece que seu primeiro superbloco está corrompido. Existem muitas cópias do superbloco, já que é a parte mais crítica do sistema de arquivos. Você pode tentar e2fsck com a opção -b para verificar se uma cópia diferente do superbloco tem as informações corretas. Verifique e2fsck (8) para obter mais informações sobre a opção -b e como determinar superblocos.
IIRC, existe apenas uma cópia do diretório raiz, então se ele foi danificado, ele terá que ser recriado, vazio. Os diretórios originalmente sob o diretório raiz aparecerão em / lost + found e você terá que realocá-los de lá.
As tabelas de inodes são espalhadas pela partição. É improvável que você perca todos eles. Os que são recuperáveis, se seus arquivos não puderem ser realocados para seus diretórios originais, eles também terminarão em / lost + found.
Eu já vi isso antes. É algo a ver com o Ubuntu 10.10. Eu olharia ao redor do rastreador de bugs como foi publicado algumas vezes. Para ter certeza, tire um instantâneo do disco, limpe-o e solte-o em um sistema secundário para ver se o bug se repete (para excluir o disco - o provável culpado).
Tags ssd ext4 fsck linux corruption