O que posso fazer para reparar com segurança meus pacotes yum após uma atualização incorreta?

Question

Estou executando o amazon linux em uma micro-caixa EC2. Recentemente eu corri sudo yum update --security na esperança de que ele remendasse o Heartbleed. Infelizmente fiquei sem memória durante o processo de atualização e alguns pacotes não foram corrigidos com sucesso. Eu tentei corrigir isso reiniciando, em seguida, executando sudo yum clean then sudo yum update como mostrado no pastebin abaixo, mas os problemas de dependência ainda existem.

Como posso consertar isso sem quebrar mais nada?

Aqui está um recorte da saída do yum:

Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.i686
Error: initscripts conflicts with util-linux-ng-2.17.2-13.17.amzn1.x86_64
Error: Package: glibc-devel-2.12-1.107.43.amzn1.x86_64 (@amzn-main)
           Requires: glibc-headers = 2.12-1.107.43.amzn1
           Removing: glibc-headers-2.12-1.107.43.amzn1.x86_64 (@amzn-main)
               glibc-headers = 2.12-1.107.43.amzn1
           Updated By: glibc-headers-2.17-36.81.amzn1.x86_64 (amzn-updates)
               glibc-headers = 2.17-36.81.amzn1
           Available: glibc-headers-2.17-36.80.amzn1.x86_64 (amzn-main)
               glibc-headers = 2.17-36.80.amzn1

Este é o log completo do console: link

    

Answer 1

Reinstale o RPMS com falha

Eu vi esse problema acontecer quando algo falha durante a transação do RPM. O banco de dados RPM pode ficar fora de sincronia com o sistema. Como resultado, o que o sistema realmente possui e o que o RPM acha que está instalado varia.

DICA: Antes de fazer isso, crie uma imagem AMI para que você possa recuperar facilmente se as coisas falharem completamente.

Você pode usar rpm -qa --last para obter uma listagem dos RPMs instalados recentemente.

Em seguida, recrie o banco de dados rpm, rpm --rebuilddb .

Você pode usar yum reinstall para reinstalar qualquer pacote que fizesse parte das transações com falha.

Isso também deve detectar quaisquer problemas de dependência e tentar corrigi-los.

Em alguns casos, tive de resolver manualmente os conflitos baixando o rpm yum download e usando rpm para fazer a instalação.

Se você precisar reverter para a instalação manual usando rpm , mantenha notas detalhadas, especialmente quando a glibc estiver envolvida.

Recomendação

É altamente recomendável que você implante operações na AWS de uma maneira que você possa facilmente criar uma nova instância do EC2 e não se preocupar com esses problemas. Se você usa volumes dedicados do EBS para seus dados e armazena seus arquivos de configuração em outro lugar, muitas vezes você pode criar uma nova instância e voltar a operar mais rápido do que depurar um problema de RPM como este. Quando temos problemas com o EC2 como esse, geralmente implantamos uma nova instância de nossa AMI personalizada, remapeamos IPs e concluímos isso. Se necessário, podemos fazer a análise da causa-raiz nos sistemas com falha / corrompidos sem afetar as operações de produção.