Seu servidor Ubuntu reinicia após uma atualização ou queda de energia e, em seguida, para na mensagem "Entrando no modo de emergência". O SSH fica indisponível, os serviços param e o console solicita manutenção. Isso geralmente significa que o systemd não conseguiu concluir uma etapa de inicialização necessária, frequentemente porque uma verificação do sistema de arquivos falhou ou um ponto de montagem necessário não foi encontrado. Considere a mensagem como uma pista: identifique a unidade com falha antes de editar arquivos ou executar um comando de reparo.
Este guia se aplica a instalações convencionais do Ubuntu Server usando systemd. Os comandos e menus de inicialização podem variar no Ubuntu Core, em sistemas criptografados, em imagens de nuvem e em servidores gerenciados por provedores. As páginas de manual atuais do Ubuntu descrevem o emergency.target como um shell mínimo que não inicia serviços normais nem monta sistemas de arquivos comuns; dependendo de como foi acessado, o sistema de arquivos raiz pode ser somente leitura ou leitura e gravação. Por isso, os primeiros passos são a inspeção e o backup.
1. Leia a mensagem de erro antes de fazer qualquer alteração.
Faça login no console local ou do provedor, se solicitado. Em uma máquina física, conecte um teclado e um monitor; em um servidor virtual, use o console serial ou de recuperação do provedor. Fotografe ou copie o erro completo, especialmente o nome da unidade, como `<nome_da_unidade>`, systemd-fsck@dev-disk-by-uuid-....serviceou uma unidade de montagem que termine em ` .mount.`. Um UUID ausente, uma verificação de sistema de arquivos com falha e um serviço corrompido exigem correções diferentes.
A partir do shell de emergência, inspecione as unidades com falha e o log de inicialização atual:
systemctl --failed
journalctl -xb
Procure o primeiro erro significativo, não apenas a linha final "dependência falhou". Se o log identificar uma montagem, anote o ponto de montagem e o UUID do dispositivo. Se identificar um serviço não relacionado ao armazenamento, não comece a alterá-lo /etc/fstabaleatoriamente; inspecione essa unidade específica systemctl status unit-namee suas mensagens de log recentes.
2. Verifique se o sistema de arquivos raiz permite edições.
Antes de editar um arquivo de configuração, verifique como o sistema de arquivos raiz está montado:
findmnt /
Se as opções mostrarem ro, o sistema de arquivos raiz é somente leitura. Se o sistema de arquivos estiver íntegro e você precisar fazer um pequeno reparo de configuração, remonte-o em modo de leitura e gravação:
mount -o remount,rw /
Execute findmnt /novamente para confirmar a alteração. Se a remontagem falhar, pare e registre o erro. Um volume raiz somente leitura pode ser uma medida de proteção em caso de problemas no sistema de arquivos; forçar gravações ou tentar remontar repetidamente pode dificultar a recuperação. Use um ambiente de recuperação ou entre em contato com o suporte do provedor se o volume raiz parecer danificado.
3. Inspecione os discos e compare-os com o arquivo /etc/fstab.
Uma causa comum é uma /etc/fstabentrada desatualizada: um disco foi removido, um UUID foi alterado ou um caminho de montagem foi digitado incorretamente. A primeira lista detectou os sistemas de arquivos e seus identificadores:
lsblk -f
blkid
Em seguida, leia a configuração da tabela de montagem:
cat /etc/fstab
Compare cada UUID configurado com a saída de `ls -l` lsblk -fou `ls -l` blkid, e verifique se o ponto de montagem e o tipo de sistema de arquivos estão corretos. Não substitua um nome de dispositivo, como `/dev/sd`, /dev/sdb1apenas com base na letra atual; a ordem dos dispositivos pode mudar. Os UUIDs costumam ser mais estáveis, mas ainda precisam corresponder ao sistema de arquivos real.
O /etc/fstabarquivo é traduzido em unidades de montagem do systemd durante a inicialização. Seus campos e opções têm significados específicos, portanto, consulte o manual oficial do fstab do Ubuntu se alguma entrada for desconhecida.
4. Ignorar temporariamente um suporte opcional ausente.
Se a entrada com falha apontar para um disco de dados não essencial que foi intencionalmente ausente, faça um backup /etc/fstabe comente apenas essa linha, colocando `\n` #no início dela. Isso permite testar se a montagem ausente é a causa do bloqueio de inicialização. Não comente o sistema de arquivos raiz, `/etc/fstab` /bootou uma entrada de volume criptografado, a menos que você entenda o layout de armazenamento do sistema.
cp -a /etc/fstab /etc/fstab.before-emergency-fix
nano /etc/fstab
Alternativamente, se o disco for opcional em operação normal, considere a nofailopção de montagem após verificar o comportamento desejado. Use-a apenas para montagens genuinamente opcionais: adicioná-la a um volume de sistema necessário pode ocultar uma falha real de armazenamento. Sistemas de arquivos de rede podem precisar de opções adicionais específicas do systemd e dependências de rede; não copie opções de uma configuração não relacionada.
Após a edição, solicite ao systemd que recarregue as unidades geradas e teste o arquivo:
systemctl daemon-reload
mount -a
Leia toda a saída. Um retorno sem erros não prova que todos os aplicativos podem usar os dados montados, mas um UUID, erro de sintaxe ou erro de montagem relatado indica o que ainda precisa ser corrigido. O manual do systemd-fstab-generator explica como o systemd converte entradas do fstab em unidades de montagem.
5. Corrija um UUID, caminho ou opção de montagem inválidos.
Se o disco estiver presente, mas seu UUID for diferente, verifique se você identificou o sistema de arquivos correto antes de atualizar o UUID=...campo correspondente. Confirme se o diretório do ponto de montagem existe, se o tipo de sistema de arquivos está correto e se as opções são válidas para esse sistema de arquivos. Corrija uma entrada por vez e execute novamente o systemctl daemon-reloadcomando mount -a.
Para um disco de dados removível ou secundário opcional, definir uma política de montagem opcional adequada pode impedir que um dispositivo ausente bloqueie a inicialização. Para um volume crítico, corrija o dispositivo, o cabo, o mapeamento de criptografia ou o identificador em vez de mascarar a falha. Se a unidade com falha nomear um dispositivo LUKS ou LVM, inspecione o mapeamento relacionado e o estado do volume; não substitua seu UUID por uma partição com nome semelhante.
6. Execute uma verificação do sistema de arquivos somente quando o destino estiver desmontado.
Se o console reportar erros específicos do sistema de arquivos, identifique o tipo e o dispositivo do sistema de arquivos antes de repará-lo. Não execute um utilitário de reparo em um sistema de arquivos que esteja montado, especialmente o sistema de arquivos raiz ativo. O manual do fsck do Ubuntu descreve o comando auxiliar; as opções corretas de verificação e reparo dependem do sistema de arquivos.
Para uma partição de dados ext2, ext3 ou ext4, primeiro confirme se ela não está montada com o comando `mount` findmnt. Se estiver montada, desmonte-a antes de verificar. Uma verificação típica de uma partição ext4 a partir de um ambiente de recuperação adequado é:
sudo e2fsck -f /dev/DEVICE
Substitua /dev/DEVICEsomente após encontrar a partição correta lsblk -f. Leia as perguntas e o status do verificador; não marque automaticamente "sim para tudo" sem entender o risco de perda de dados. Para um sistema de arquivos raiz que não pode ser desmontado a partir do shell de emergência em execução, inicialize um ambiente live ou de recuperação do provedor e verifique offline. Btrfs, XFS e outros sistemas de arquivos usam ferramentas e procedimentos de reparo diferentes. Em particular, não considere um fsckcomando genérico como prova de que todos os tipos de sistema de arquivos foram reparados.
7. Use o GRUB ou recuperação externa somente quando o shell estiver indisponível.
Se o servidor nunca conseguir acessar um shell de emergência, abra o menu GRUB e tente a entrada de recuperação da distribuição quando estiver disponível. Em uma instalação padrão do Ubuntu, o menu geralmente é acessado pressionando Shift em sistemas BIOS legados ou Esc em sistemas UEFI, mas máquinas virtuais hospedadas podem usar um fluxo de console diferente. Para uma inicialização de emergência única com o systemd, um administrador pode editar a entrada GRUB selecionada e adicionar systemd.unit=emergency.targeto comando ao kernel do Linux. A alteração se aplica apenas a essa inicialização; remova-a antes da próxima inicialização normal. Consulte a referência oficial do menu GNU GRUB .
Se o volume de inicialização não puder ser montado, use um ambiente Ubuntu Live ou o sistema de recuperação do provedor de nuvem para inspecioná-lo. Desbloqueie o armazenamento criptografado e ative o LVM somente se isso corresponder à instalação. Montar o sistema de arquivos raiz de um servidor a partir da recuperação apresenta riscos adicionais; evite gravar nele até que o disco e o sistema de arquivos tenham sido identificados. O Ubuntu Core usa seu próprio fluxo de trabalho de recuperação e não é reparado seguindo cegamente as etapas do GRUB de desktop ou de servidor convencional.
8. Reinicie e verifique se o reparo foi concluído.
Quando a causa relatada for corrigida e os testes de montagem forem aprovados, reinicie:
reboot
Após a inicialização, verifique se o host atinge seu alvo multiusuário usual, se os sistemas de arquivos esperados estão montados e se os serviços importantes estão ativos:
systemctl is-system-running
systemctl --failed
findmnt --target /
Verifique os pontos de montagem de dados esperados com `--verify` findmnt /path/to/mounte confirme os serviços críticos com `--confirm` systemctl status service-name. Se o modo de emergência retornar, revise novamente a primeira falha da nova inicialização em vez de repetir o mesmo reparo. Um resgate bem-sucedido significa que o servidor conclui uma inicialização normal e que seu armazenamento e serviços necessários estão disponíveis; apenas chegar à tela de login não é suficiente.
Para obter informações sobre o comportamento atual do systemd, consulte o manual de unidades especiais do Ubuntu . As versões dos pacotes e os menus de recuperação podem variar de acordo com a versão do Ubuntu e a plataforma de hospedagem; portanto, use a documentação da versão instalada quando um comando ou unidade apresentar diferenças.