Parece que os comandos /usr/bin/locale e /usr/bin/gettext estão encontrando algo parecido com um cabeçalho de documento PostScript, e isso está causando alguns erros. Esses erros podem ou não ser a causa dos seus problemas, mas estão interferindo em outras funcionalidades do sistema.
Você tem algo estranho em /etc/default/locale , talvez? Ele deve conter apenas as definições e / ou comentários da variável sh .
O que acontece se você executar locale ? Ele deve exibir suas configurações de localidade atuais e nenhuma mensagem de erro.
Ou se você executar gettext -d coreutils -s "write error" ? Ele deve gerar uma versão traduzida da mensagem "write error", de acordo com as configurações atuais de localidade.
Ou talvez um arquivo PostScript tenha entrado no diretório do catálogo de mensagens? Então este comando pode encontrá-lo:
find /usr/share/locale -type f -exec file {} \+ |grep -E -v 'GNU (gettext )?message catalog'
O comando deve identificar quaisquer arquivos em / usr / share / locale que não sejam arquivos de catálogo de mensagens. Se a saída do comando file também for traduzida, talvez seja necessário prefixar esse comando com LC_ALL=C para ter mensagens temporárias em inglês padrão dos EUA, para que a sequência de pesquisa exclua corretamente os arquivos de catálogo de mensagens da saída.
Descobrimos que seu /usr/bin/locale e aparentemente também /usr/bin/gettext parece ter sido substituído por arquivos PostScript criados pelo ImageMagick. Isto soa como possível corrupção do sistema de arquivos, ou talvez um "oops" com comandos do ImageMagick enquanto rodando como root.
Para reparar seus /usr/bin/locale e /usr/bin/gettext , execute este comando:
apt-get install --reinstall libc-bin gettext-base
Isso reinstalará todos os arquivos do pacote libc-bin e gettext-base sem remover nenhum pacote que dependa deles primeiro. Isso deve corrigir pelo menos algumas de suas mensagens de erro originais. Em seguida, você pode tentar executar dpkg --configure -a novamente para ver se essa foi a verdadeira causa raiz de todo o seu problema ou se ainda há mais a ser corrigido.
A possibilidade de corrupção do sistema de arquivos faz com que eu pense que você deveria verificar dmesg | less output: existe algo parecido com um erro de disco?
Será que smartctl -a /dev/<your system disk device> diz que o disco passa por suas verificações de integridade internas do SMART? O comando gera muita informação, mas a parte importante deve ficar assim:
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Se não disser "PASSED", o seu disco está falhando e deve ser substituído.
Mesmo se smartctl achar que o disco está correto, um backup completo e, em seguida, uma verificação completa do sistema de arquivos pode ser uma boa ideia. Se você precisar de ajuda com a verificação do sistema de arquivos, por favor, abra uma nova pergunta para ela.