Início / unix / Perguntas / 442154
Accepted
wizzwizz4
Asked: 2018-05-07 09:32:32 +0800 CST

/var/lib/dpkg/ desapareceu após fsck

  • 772

Todos os aptcomandos -like falharam ao criar o arquivo de bloqueio, porque /var/lib/dpkg/não existe. Além disso, /lost+found/tem conteúdo:

pi@pi-top:~ $ sudo ls -al /lost+found/
total 102456
drwx------ 11 root root      16384 Apr  3 16:26 .
drwxr-xr-x 23 root root       4096 May  5 17:00 ..
-rw-------  1 root root  104857600 Apr  3 16:30 #29025
lrwxrwxrwx  1 root root          9 Mar 29 10:05 #87867 -> /run/lock
lrwxrwxrwx  1 root root          4 Mar 29 10:05 #87868 -> /run
drwxr-xr-x  2 root root       4096 May  5 10:35 #89863
drwxr-xr-x 12 root root       4096 Apr  3 16:41 #89864
drwxr-xr-x 44 root root       4096 Apr  3 16:30 #89865
drwxrwsr-x  2 root staff      4096 Mar 12 14:03 #89866
drwxr-xr-x  6 root root       4096 May  5 16:30 #89867
drwxrwsr-x  2 root mail       4096 Mar 29 10:05 #89868
drwxr-xr-x  2 root root       4096 Mar 29 10:05 #89869
drwxr-xr-x  5 root root       4096 Mar 29 10:32 #89870
drwxrwxrwt  3 root root       4096 May  5 16:31 #89871

Muitos /var/lib/também estão faltando, embora o sistema não esteja apresentando nenhum outro sintoma. É possível recuperar o sistema (ou pelo menos dpkg)? Em caso afirmativo, como?

dpkg system-recovery

1 respostas

  1. Best Answer

    Sinto muito, mas neste estágio, provavelmente é melhor restaurar a partir de um backup limpo. Quando fsckcoloca tantos diretórios em /lost+found, isso é um sinal de que houve muita corrupção. É bem possível que haja mais corrupção, mas como está no conteúdo do arquivo e não nos metadados, o fsck não tem como saber.

    Ao restaurar de um backup, certifique-se de que seja um backup limpo . A corrupção pode ter começado antes de ser detectada.

    A única maneira de identificar quais lost+foundsão os arquivos é olhar para eles e descobrir. Não há uma maneira sistemática. Se houvesse um, o fsck o faria.

    Olhando para o conteúdo que você mostra para /lost+found, parece que o /vardiretório foi danificado. Você pode tentar repará-lo criando /vare movendo as entradas apropriadas /lost+foundpara /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 (propriedade e alvos de links simbólicos). Você pode descobrir mais observando o conteúdo do diretório. Compare com uma instalação de sistema existente (de preferência a mesma distribuição ou pelo menos algo próximo, mas a arquitetura do processador não importa).

    /var/libpode ser #89865porque tende a ter muitos subdiretórios, mas isso é apenas um palpite. Pode ser de outra parte do sistema.

    Não foque na recuperação /var/lib/dpkge ignore o resto. 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 o 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, provavelmente continuará corrompendo seus dados.

    • 5

relate perguntas