Como solucionar problemas de uma instância do Linux do EC2 que falhou na verificação do status da instância devido a problemas no sistema operacional?

Breve descrição

Sua instância do Linux do EC2 pode falhar na verificação do status da instância pelos seguintes motivos:

• Você atualizou o kernel e o novo kernel não inicializou.
• As entradas do sistema de arquivos em /etc/fstab estão incorretas ou o sistema de arquivos está corrompido.
• Há configurações de rede incorretas na instância.

Resolução

Importante: alguns dos procedimentos a seguir exigem a interrupção da instância. Quando você interrompe uma instância, você perde dados armazenados em volumes de armazenamento de instâncias. Salve um backup dos dados antes de interromper a instância. Diferentemente dos volumes baseados no Amazon Elastic Block Store (Amazon EBS), os volumes de armazenamento de instância são efêmeros e não oferecem suporte à persistência de dados. Para obter mais informações, consulte Início e interrupção de instâncias do Amazon EC2.

O endereço público IPv4 estático que o Amazon EC2 atribuiu automaticamente à instância na inicialização ou no início muda após a interrupção e o início. Para manter um endereço IPv4 público que não muda quando a instância é interrompida, use um endereço IP elástico.

Observação: os métodos a seguir usam exemplos baseados no Amazon Linux 2. No entanto, esses conceitos se aplicam às distribuições Linux em geral. Se você tiver uma distribuição Linux diferente do Amazon Linux 2, os comandos, caminhos e saídas poderão variar.

Usar o console de Série do EC2 para instâncias do Linux

Se você ativou o Console de Série do EC2 para instâncias do Linux, poderá usá-lo para solucionar problemas com tipos de instâncias baseadas em Nitro compatíveis e instâncias bare metal. O console de série ajuda a solucionar problemas de inicialização e de configuração de rede e SSH. O console de série se conecta à sua instância sem precisar de uma conexão de rede em funcionamento. Para acessar o console de série, use o console do Amazon EC2 ou a AWS Command Line Interface (AWS CLI).

Na primeira vez que você usar o console de série do EC2, revise os pré-requisitos e configure o acesso antes de se conectar.

Se sua instância estiver inacessível e você não tiver configurado o acesso ao console de série, consulte a seção Executar a ferramenta EC2Rescue para Linux. Ou, consulte Use uma instância de resgate. Para obter informações sobre como configurar o console de série do EC2 para instâncias do Linux, consulte Configurar o acesso ao Console de Série do EC2.

Observação: se você receber erros ao executar comandos da AWS CLI, consulte Solucionar erros da AWS CLI. Além disso, verifique se você está usando a versão mais recente da AWS CLI.

Executar a ferramenta EC2Rescue para Linux

O EC2Rescue para Linux diagnostica e soluciona problemas automaticamente em sistemas operacionais em instâncias inacessíveis. Para obter mais informações, consulte Como uso o EC2Rescue para Linux para solucionar problemas no nível do sistema operacional?

Use uma instância de resgate para corrigir erros manualmente

1. Inicie uma nova instância do EC2 na nuvem privada virtual (VPC). Use a mesma imagem de máquina da Amazon (AMI) e a mesma zona de disponibilidade da instância danificada. A nova instância se torna sua instância de resgate.

   Ou use uma instância existente. A instância existente deve usar a mesma AMI e estar na mesma zona de disponibilidade da instância danificada.

2. Interrompa a instância comprometida.

3. Desassocie o volume raiz do Amazon EBS (/dev/xvda ou /dev/sda1) da instância comprometida. Anote o nome do dispositivo do seu volume raiz.

4. Anexe o volume como um dispositivo secundário (/dev/sdf) à instância de resgate.

5. Conecte-se à sua instância de resgate por meio de SSH.

6. Crie um diretório de pontos de montagem (/rescue) para o novo volume anexado à instância de resgate

   $ sudo mkdir /rescue

7. Monte o volume no novo diretório:

   $ sudo mount /dev/xvdf1 /rescue

   Se você receber um erro, como “Wrong Fs type or UUID duplicate, Superblock is missing or badblock found”, consulte Por que não consigo montar meu volume do Amazon EBS?

   Observação: o dispositivo (/dev/xvdf1) pode ser anexado à instância de resgate com um nome de dispositivo diferente. Para determinar o nome correto do dispositivo, execute o comando lsblk para visualizar os dispositivos de disco disponíveis juntamente com seus pontos de montagem.

8. Se ainda não tiver feito isso, recupere o log do sistema da instância para verificar o erro. As próximas etapas dependem da mensagem de erro listada no log do sistema.

   A seguir, há uma lista de erros comuns que causam falha na verificação do status da instância. Para obter mais erros, consulte Solução de problemas relacionados aos erros de log do sistema para instâncias do Linux.

Solucionar problemas de “Kernel panic”

Se uma mensagem de erro de Kernel panic estiver no log do sistema, talvez o kernel não tenha os arquivos vmlinuz ou initramfs. Os arquivos vmlinuz e initramfs são necessários para uma inicialização bem-sucedida.

1. Execute os seguintes comandos:

   cd /rescue/boot
   ls -l

2. Verifique a saída para conferir se há arquivos vmlinuz e initramfs correspondentes à versão do kernel que você deseja inicializar.

   O exemplo de saída a seguir é para uma instância do Amazon Linux 2 com a versão do kernel, 4.14.165-131.185.amzn2.x86_64. O diretório /boot tem os arquivos initramfs-4.14.165-131.185.amzn2.x86_64.img e vmlinuz-4.14.165-131.185.amzn2.x86_64. Portanto, a inicialização será bem-sucedida.

   uname -r
   4.14.165-131.185.amzn2.x86_64
   
   cd /boot; ls -l
   total 39960
   -rw-r--r-- 1 root root      119960 Jan 15 14:34 config-4.14.165-131.185.amzn2.x86_64
   drwxr-xr-x 3 root root     17 Feb 12 04:06 efi
   drwx------ 5 root root       79 Feb 12 04:08 grub2
   -rw------- 1 root root 31336757 Feb 12 04:08 initramfs-4.14.165-131.185.amzn2.x86_64.img
   -rw-r--r-- 1 root root    669087 Feb 12 04:08 initrd-plymouth.img
   -rw-r--r-- 1 root root    235041 Jan 15 14:34 symvers-4.14.165-131.185.amzn2.x86_64.gz
   -rw------- 1 root root   2823838 Jan 15 14:34 System.map-4.14.165-131.185.amzn2.x86_64
   -rwxr-xr-x 1 root root   5718992 Jan 15 14:34 vmlinuz-4.14.165-131.185.amzn2.x86_64

3. Se os arquivos initramfs e vmlinuz não estiverem presentes, tente inicializar a instância usando um kernel anterior que tenha ambos os arquivos. Para obter instruções, consulte How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?

4. Execute o comando umount para desmontar o dispositivo secundário da instância de resgate:

   $ sudo umount /rescue

   Se a operação de desmontagem não for bem-sucedida, talvez seja necessário interromper ou reinicializar a instância de recuperação para uma desmontagem limpa.

5. Separe o volume secundário (/dev/sdf) da instância de resgate. Em seguida, anexe-o à instância original como /dev/xvda (volume raiz).

6. Inicie a instância e, em seguida, verifique se ela responde.

Para obter informações adicionais sobre como resolver erros de pânico do kernel, consulte How do I fix a "Kernel panic - not syncing" error on EC2 instances?

Solucionar problemas de “Failed to mount” ou “Dependency failed”

Erros como “Failed to mount” ou “Dependency failed” no log do sistema indicam que o arquivo /etc/fstab tem entradas de ponto de montagem incorretas.

1. Verifique se as entradas do ponto de montagem em /etc/fstab estão corretas. Para corrigir as entradas do arquivo /etc/fstab, consulte Por que minha instância Linux do EC2 está entrando no modo de emergência quando tento inicializá-la?

2. É uma prática recomendada executar a ferramenta fsck ou xfs_repair para corrigir inconsistências no sistema de arquivos.

   Observação: crie um backup do seu sistema de arquivos antes de executar a ferramenta fsck ou xfs_repair.

   Execute o comando umount para desmontar o ponto de montagem antes de executar a ferramenta fsck ou xfs_repair:

   $ sudo umount /rescue

   Execute a ferramenta fsck ou xfs_repair, dependendo do seu sistema de arquivos.

   Para sistemas de arquivos ext4, execute o seguinte comando:

   $ sudo fsck /dev/sdf
   fsck from util-linux 2.30.2
   e2fsck 1.42.9 (28-Dec-2013)
   /dev/sdf: clean, 11/6553600 files,
   459544/26214400 blocks

   Para sistemas de arquivos XFS, execute o seguinte comando:

   $ sudo xfs_repair /dev/sdf
   xfs_repair /dev/xvdf
   Phase 1 - find and verify superblock...
   Phase 2 - using internal log
           - zero log...
           - scan filesystem freespace and inode maps...
           - found root inode chunk
   Phase 3 - for each AG...
           - scan and clear agi unlinked lists...
           - process known inodes and perform inode discovery...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
           - process newly discovered inodes...
   Phase 4 - check for duplicate blocks...
           - setting up duplicate extent list...
           - check for inodes claiming duplicate blocks...
           - agno = 0
           - agno = 1
           - agno = 2
           - agno = 3
   Phase 5 - rebuild AG headers and trees...
           - reset superblock...
   Phase 6 - check inode connectivity...
           - resetting contents of realtime bitmap and summary inodes
           - traversing filesystem ...
           - traversal finished ...
           - moving disconnected inodes to lost+found ...
   Phase 7 - verify and correct link counts...
   done

3. Separe o volume secundário (/dev/sdf) da instância de resgate. Em seguida, anexe-o à instância original como /dev/xvda (volume raiz).

4. Inicie a instância e, em seguida, verifique se ela responde.

Solucionar problemas de “interface eth0: failed”

Verifique se o arquivo ifcfg-eth0 tem as entradas de rede corretas. O arquivo de configuração de rede correspondente à interface primária, eth0, está localizado em /etc/sysconfig/network-scripts/ifcfg-eth0. Se o nome do dispositivo da sua interface primária não for eth0, o nome do arquivo começará com ifcfg e será seguido pelo nome do dispositivo. O arquivo está no diretório /etc/sysconfig/network-scripts na instância.

1. Execute o comando cat para visualizar o arquivo de configuração de rede da interface primária, eth0.

   Veja a seguir as entradas corretas para o arquivo de configuração de rede localizado em /etc/sysconfig/network-scripts/ifcfg-eth0.

   Observação: Se necessário, substitua eth0 no comando a seguir pelo nome da sua interface primária.

   $ sudo cat /etc/sysconfig/network-scripts/ifcfg-eth0
   DEVICE=eth0
   BOOTPROTO=dhcp
   ONBOOT=yes
   TYPE=Ethernet
   USERCTL=yes
   PEERDNS=yes
   DHCPV6C=yes
   DHCPV6C_OPTIONS=-nw
   PERSISTENT_DHCLIENT=yes
   RES_OPTIONS="timeout:2 attempts:5"
   DHCP_ARP_CHECK=no

2. Verifique se ONBOOT está definido como yes. Se ONBOOT não estiver definido como yes, então eth0 (ou sua interface de rede primária) não está configurado para aparecer na inicialização.

   Para alterar o valor de ONBOOT, primeiro abra o arquivo em um editor. Este exemplo usa o editor vi:

   $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0

   Pressione I para inserir.

   Role o cursor até a entrada ONBOOT e altere o valor para yes.

   Para salvar e sair do arquivo, pressione :wq!

3. Execute o comando umount para desmontar o dispositivo secundário da instância de resgate:

   $ sudo umount /rescue

   Se a operação de desmontagem não for bem-sucedida, talvez seja necessário interromper ou reinicializar a instância de resgate para permitir uma desmontagem limpa.

4. Separe o volume secundário (/dev/sdf) da instância de resgate. Em seguida, anexe-o à instância original como /dev/xvda (volume raiz).

5. Inicie a instância e, em seguida, verifique se ela responde.

Informações relacionadas

Por que minha instância Linux do EC2 está inacessível e falhando suas verificações de status?

Solucionar problemas de instâncias com falhas nas verificações de status

Por que minha instância do Linux não está inicializando depois que eu mudei seu tipo para um tipo de instância baseado em Nitro?