Por que minha instância Linux do EC2 está entrando no modo de emergência quando tento inicializá-la?
Quando inicializo minha instância Linux do Amazon Elastic Compute Cloud (Amazon EC2), ela entra no modo de emergência, e o processo de inicialização falha. Em seguida, a instância fica inacessível.
Breve descrição
Uma instância pode ser inicializada no modo de emergência pelos seguintes motivos:
- Há um kernel corrompido na instância.
- Há falhas de montagem automática devido a entradas incorretas no arquivo /etc/fstab.
Para verificar o tipo de erro, veja a saída do console da instância. Você poderá ver uma mensagem de erro de pânico de kernel na saída do console se o kernel estiver corrompido. Mensagens de falha de dependência aparecerão na saída do console se ocorrerem falhas na montagem automática.
Resolução
Erros de pânico de kernel
Mensagens de erro de pânico de kernel ocorrem quando a configuração do grub ou o arquivo initramfs estão corrompidos. Se houver algum problema com o kernel, você poderá ver o erro "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)" na saída do console.
Para resolver erros de pânico de kernel:
1. Reverta o kernel para um kernel anterior estável. Para obter instruções sobre como reverter para um kernel anterior, consulte How do I revert to a known stable kernel after an update prevents my Amazon EC2 instance from rebooting successfully?
2. Depois de reverter para um kernel anterior, reinicialize a instância. Em seguida, corrija os problemas no kernel corrompido.
Erros de falha de dependência
As instâncias entrarão no modo de emergência se houver falhas na montagem automática devido a erros de sintaxe no arquivo /etc/fstab. Além disso, se o volume do Amazon Elastic Block Store (Amazon EBS) listado no arquivo estiver separado da instância, o processo de inicialização da instância poderá entrar no modo de emergência. Se algum desses problemas ocorrer, a saída do console será semelhante à seguinte:
------------------------------------------------------------------------------------------------------------------- [[1;33mDEPEND[0m] Dependency failed for /mnt. [[1;33mDEPEND[0m] Dependency failed for Local File Systems. [[1;33mDEPEND[0m] Dependency failed for Migrate local... structure to the new structure. [[1;33mDEPEND[0m] Dependency failed for Relabel all filesystems, if necessary. [[1;33mDEPEND[0m] Dependency failed for Mark the need to relabel after reboot. [[1;33mDEPEND[0m] Dependency failed for File System Check on /dev/xvdf. -------------------------------------------------------------------------------------------------------------------
Os exemplos anteriores de mensagens de log mostram que o ponto de montagem /mnt falhou ao ser montado durante a sequência de inicialização.
Para evitar que a sequência de inicialização entre no modo de emergência devido a falhas de montagem, adicione o seguinte ao arquivo /etc/fstab.
- Adicione uma opção nofail no arquivo /etc/fstab para as partições secundárias (/mnt, no exemplo anterior). Quando a opção nofail está presente, a sequência de inicialização não é interrompida, mesmo se a montagem de um volume ou partição falhar.
- Adicione 0 como a última coluna do arquivo /etc/fstab para o respectivo ponto de montagem. A coluna 0 desativa a verificação do sistema de arquivos, e a instância é inicializada com êxito.
Há três métodos que você pode usar para corrigir o arquivo /etc/fstab.
Importante:
os métodos 2 e 3 exigem a interrupção e o início da instância. Esteja ciente de que:
- Os dados armazenados em volumes de armazenamento de instâncias são perdidos quando a instância é interrompida. Salve um backup dos dados antes de interromper a instância. Diferentemente dos volumes baseados em EBS, os volumes de armazenamento de instâncias são efêmeros e não oferecem suporte à persistência de dados.
- 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 se a instância for interrompida, use um endereço IP elástico.
Para obter mais informações, acesse O que acontece quando você interrompe uma instância.
Método 1: usar o Console de Série do EC2
Se você ativou o Console de série do EC2 para Linux, poderá usá-lo para solucionar problemas com tipos de instâncias com suporte baseadas em Nitro e instâncias bare metal. Você pode acessar o console de série no console do Amazon EC2 ou na AWS Command Line Interface (AWS CLI). Você não precisa de uma conexão ativa para se conectar à instância quando usar o console de série do EC2.
Observação: se nunca usou o Console de Série do EC2, certifique-se de rever os pré-requisitos e configurar o acesso antes de tentar se conectar. Se não for possível estabelecer contato com a instância e você não tiver configurado o acesso ao console de série, siga as instruções nos Métodos 2 ou 3.
1. Abra o console do Amazon EC2.
2. Escolha Instâncias.
3. Selecione a instância e, em seguida, escolha Ações, Monitorar e solucionar problemas, Console de Série do EC2, Conectar.
-ou-
Selecione a instância e depois escolha Conectar, Console de Série do EC2, Conectar.
Uma janela do terminal no navegador é aberta.
4. Pressione Enter. Se a conexão com o console de série for estabelecida, um prompt de login será retornado. Se a tela permanecer preta, use as informações a seguir para ajudar a resolver problemas de conexão com o console de série:
-
Verifique se você configurou o acesso ao console de série. Para obter mais informações, consulte Configurar o acesso ao Console de Série do EC2.
-
Use o SysRq para se conectar ao console de série. O SysRq não exige uma conexão por meio do cliente baseado em navegador. Para obter mais informações, consulte Solucionar problemas de instâncias do Linux usando SysRq.
-
Reinicie o getty. Se você tiver acesso SSH à instância, conecte-se à instância usando SSH e reinicie o getty usando o comando a seguir.
[ec2-user ~]$ sudo systemctl restart serial-getty@ttyS0
-
Reinicialize a instância. É possível reinicializar a instância usando o SysRq, o console do EC2 ou a AWS CLI. Para obter mais informações, consulte Solucionar problemas de instâncias do Linux usando SysRq ou Reinicializar a instância.
5. No prompt de login, digite o nome de usuário baseado em senha que você configurou anteriormente e pressione Enter.
6. No prompt Senha, digite a senha e pressione Enter.
Agora você está conectado à instância e pode usar o console de série do EC2 para solucionar problemas.
Você também pode se conectar usando a sua própria chave e um cliente SSH.
Para obter mais informações sobre como usar o console de série do EC2, consulte Conectar-se ao console de série do EC2.
Método 2: execute o documento de automação AWSSupport-ExecuteEC2Rescue
Se a instância estiver configurada para o AWS Systems Manager, você poderá executar o documento de automação AWSSupport-ExecuteEC2Rescue para corrigir problemas de inicialização. Uma intervenção manual não é necessária ao usar esse método. Para obter informações sobre como usar o documento de automação, consulte Run the EC2Rescue tool on unreachable instances.
Método 3: editar o arquivo manualmente usando uma instância de resgate
1. Abra o console do Amazon EC2.
2. Escolha Instâncias e selecione a instância que está no modo de emergência.
4. Desassocie o volume raiz do Amazon EBS (/dev/xvda ou /dev/sda1) da instância interrompida.
5. Execute uma nova instância do EC2 na mesma zona de disponibilidade da instância danificada. A nova instância se torna sua instância de resgate.
6. Anexe o volume raiz que você separou na etapa 4 à instância de resgate como um dispositivo secundário.
Observação: você pode usar nomes de dispositivos diferentes ao anexar volumes secundários.
7. Conecte-se à sua instância de resgate usando SSH.
8. Crie um diretório de pontos de para o novo volume que você anexou à instância de resgate na etapa 6. No exemplo a seguir, o diretório do ponto de montagem é /mnt/rescue.
$ sudo mkdir /mnt/rescue
9. Monte o volume no diretório que você criou na etapa 8.
$ sudo mount /dev/xvdf /mnt/rescue
Observação: o dispositivo (/dev/xvdf, no exemplo anterior) pode estar conectado à instância com um nome de dispositivo diferente. Use o comando lsblk para visualizar seus dispositivos de disco disponíveis junto com seus pontos de montagem para determinar os nomes corretos dos dispositivos.
10. Depois que o volume for montado, execute o comando a seguir para abrir o arquivo /etc/fstab.
$ sudo vi /mnt/rescue/etc/fstab
11. Edite as entradas em /etc/fstab conforme necessário. O exemplo de saída a seguir mostra três volumes do EBS definidos com UUIDs, a opção nofail adicionada para ambos os volumes secundários e um 0 como a última coluna para cada entrada.
------------------------------------------------------------------------------------------ $ cat /etc/fstab UUID=e75a1891-3463-448b-8f59-5e3353af90ba / xfs defaults,noatime 1 0 UUID=87b29e4c-a03c-49f3-9503-54f5d6364b58 /mnt/rescue ext4 defaults,noatime,nofail 1 0 UUID=ce917c0c-9e37-4ae9-bb21-f6e5022d5381 /mnt ext4 defaults,noatime,nofail 1 0 ------------------------------------------------------------------------------------------
12. Salve o arquivo e execute o comando umount para desmontar o volume.
$ sudo umount /mnt/rescue
13. Separe o volume da instância temporária.
14. Anexe o volume à instância original e inicie a instância para confirmar se ela foi inicializada com êxito.
Conteúdo relevante
- AWS OFICIALAtualizada há 4 meses
- AWS OFICIALAtualizada há um ano