Me desculpe, mas neste estágio, você provavelmente está melhor restaurando de um backup limpo. Quando fsck
coloca tantos diretórios em /lost+found
, isso é um sinal de que houve muita corrupção. É bem possível que haja mais corrupção, mas porque está no conteúdo do arquivo e não nos metadados, o fsck não tem como saber.
Ao restaurar a partir de um backup, certifique-se de que seja um backup clean . A corrupção pode ter sido iniciada antes de ser detectada.
A única maneira de identificar quais são os arquivos em lost+found
é olhar para eles e descobrir. Não existe um caminho sistemático. Se houvesse um, o fsck faria isso.
Olhando para o conteúdo que você mostra para /lost+found
, parece que o diretório /var
foi danificado. Você pode tentar repará-lo criando /var
e movendo as entradas apropriadas em /lost+found
para /var
.
# Running as root, of course
umask 022
mkdir /var
mv /lost+found/\#87867 /var/lock
mv /lost+found/\#87868 /var/run
mv /lost+found/\#89866 /var/local
mv /lost+found/\#89868 /var/mail
…
Eu descobri as entradas acima dos metadados (metas de propriedade e de links simbólicos). Você pode descobrir mais, olhando para o conteúdo do diretório. Compare com uma instalação de sistema existente (preferencialmente a mesma distribuição ou pelo menos algo próximo, mas a arquitetura do processador não importa).
/var/lib
pode ser #89865
porque tende a ter muitos subdiretórios, mas isso é apenas um palpite. Poderia ser de outra parte do sistema.
Não se concentre em recuperar /var/lib/dpkg
e ignore o restante. A falta de /var/lib/dpkg
é apenas o primeiro sintoma que você notou.
Em um PC, sugiro fazer um teste de RAM (com Memtest86 + que está disponível como um pacote na maioria das distribuições e é instalado por padrão pelo menos no Ubuntu). Em um Raspberry Pi, se seu sistema estiver em um cartão SD, recomendo substituir o cartão SD: os cartões SD são a parte menos confiável do sistema e, se você continuar usando, ele provavelmente continuará corrompendo seus dados.