biblioteca corrompida após desligamento forçado

Question

ontem à noite meu laptop executa um desligamento pesado porque minha bateria estava sem carga. Após a reinicialização, o Xorg trava e a solução de problemas é bem difícil. Uma primeira verificação do sistema de arquivos da minha partição ext4 não resulta em erro. Além disso comecei a verificar o relacionado logs e não encontrei nada irregular. Desde que eu usei xdm i eventualmente procurei em /var/log/xdm.log onde eu encontrei a seguinte linha, que eu tinha negligenciado várias vezes antes

/usr/bin/X: symbol lookup error: /usr/lib/libpciaccess.so.0: undefined symbol: gzopen64

Então eu invoquei

apt-get install --reinstall libpciaccess

e depois de uma reinicialização, tudo correu bem novamente.

Eu sei que um desligamento strong pode corromper os dados, porque o cache do disco não pode ser fisicamente escrito por mais tempo. Desde que eu não tenho uma compreensão mais profunda dos sistemas de arquivos internacionais, eu me pergunto por que /usr/lib/libpciaccess.so.0 foi prejudicado pelo desligamento? Particularmente, dado que o sistema só lê a partir de uma biblioteca compartilhada, provavelmente a corrupção é menos provável de acontecer nos setores em que eles estão localizados.

Além disso, gostaria de saber quais sistemas de arquivos são mais resistentes a desligamentos e quais são menos.

Obrigado pelo seu tempo e pelos melhores cumprimentos

    

Answer 1

Não é tanto uma questão do sistema de arquivos "certo", mas como você o usa e como você o monta.

No caso de ext3 e ext4, você pode usar as opções ro , sincronização , dirsync .

Sistemas de arquivos com intent-write-log normalmente são melhores, se os metadados estiverem sendo sincronizados antes da gravação real.

No seu caso, pode ter sido que o cache da biblioteca (/etc/ld.so.cache) estava corrompido - um simples ldconfig poderia ter corrigido o problema.

Às vezes, você precisa forçar uma verificação completa do sistema de arquivos para localizar e corrigir erros. Às vezes você precisa de uma inicialização de recuperação via Netboot ou CD / DVD (imagem) para fazer isso.

fsck -f -y ... - grava a saída em um arquivo de log para revisão posterior.

Depois disso, passe por todos os arquivos / diretórios que foram reportados como bugs e o pacote ainda está ok (em sistemas baseados em rpm: rpm -V ) - o Debian deve ter um mecanismo comparável para determinar qual pacote um arquivo pertence e para verificar a integridade do pacote.