VPS não inicia após atualização do kernel: como recuperar

O que fazer primeiro quando um VPS não arranca depois de uma atualização do kernel

Um VPS que não arranca depois de uma atualização do kernel normalmente pode ser recuperado em poucos minutos, porque a atualização não apagou o kernel que funcionava ontem. O Ubuntu instala o novo kernel juntamente com o antigo e altera apenas a entrada que o GRUB inicia por predefinição. Por isso, o primeiro passo não é reparar o sistema. Selecione o kernel anterior no menu de arranque, volte a obter uma linha de início de sessão e faça o diagnóstico a partir de um sistema em execução.

Corrigir este problema num servidor é diferente de corrigi-lo num portátil, porque não há um teclado ligado nem um monitor a apresentar o panic. O SSH também não responderá, porque a máquina nunca chegou ao ponto em que o sshd arranca. Tudo o que se segue é feito através da consola do seu fornecedor.

Consulte primeiro a sua própria consola antes de alterar qualquer coisa. O texto apresentado nessa tela determina a classe de falha, e dois servidores que "não arrancam" podem precisar de correções opostas.

Como acedo à consola quando o SSH está indisponível?

Abra o painel de controlo do seu fornecedor e procure uma consola. Os nomes mais comuns são consola VNC, consola web, noVNC e consola série. Prefira a consola série quando ambas existirem, porque apresenta texto real que pode percorrer e copiar, enquanto uma vista VNC mostra apenas uma imagem do ecrã. Localize este controlo agora, enquanto a máquina está saudável, e confirme que abre. Procurá-lo durante uma indisponibilidade tira-lhe a tranquilidade de que precisa. Esta verificação pertence aos primeiros dez minutos num novo VPS, juntamente com as regras da firewall e as chaves SSH.

A maioria dos painéis também disponibiliza um modo de recuperação ou uma imagem de recuperação. Este inicia um sistema pequeno a partir da rede do fornecedor e liga o seu disco como um dispositivo adicional, para que nada no disco seja executado. O modo de recuperação é a alternativa quando o próprio GRUB está danificado. Também permite copiar dados de um servidor que decidiu não recuperar.

Normalmente, precisará de fazer um hard reset no painel para aceder ao menu de arranque, porque não pode executar sudo reboot numa máquina na qual não consegue iniciar sessão. Um hard reset equivale a cortar a alimentação. Os sistemas de ficheiros ficam com um encerramento não limpo, por isso deve esperar uma verificação do sistema de ficheiros no arranque seguinte.

Como escolher um kernel mais antigo no menu do GRUB?

Observe a consola desde o momento em que prime reset. Prima Esc repetidamente durante os primeiros segundos ou mantenha Shift premido numa máquina que arranque em modo BIOS legado. A janela de oportunidade é curta e o visualizador da consola demora frequentemente um segundo a estabelecer ligação. Por isso, comece a premir a tecla cedo e continue a fazê-lo.

Quando o menu aparecer, escolha "Advanced options for Ubuntu". Esse submenu lista todos os kernels instalados, começando pelo mais recente, e inclui uma entrada de recovery mode para cada um. Escolha a segunda entrada normal, que corresponde ao kernel imediatamente anterior ao mais recente, e prima Enter. O recovery mode é diferente: inicia um sistema mínimo de utilizador único e destina-se a operações de reparação, não a voltar a colocar os seus serviços online.

Se o kernel mais antigo arrancar, volta a ter um servidor em execução. Confirme qual está a utilizar e registe os números.

uname -r
dpkg -l 'linux-image-*' | grep '^ii'

O resultado de dpkg é a lista de kernels instalados. Se contiver apenas uma linha, não tem qualquer fallback, e essa é a primeira situação a corrigir.

O menu do GRUB nunca aparece. E agora?

As imagens de cloud incluem uma configuração que oculta o menu. As imagens Ubuntu normalmente definem o timeout como 0 num ficheiro em /etc/default/grub.d/, por isso o kernel mais recente arranca imediatamente e não há nada para premir.

Também existe o caso oposto: o menu aparece no ecrã e fica à espera, parecendo que o sistema bloqueou. O GRUB regista um arranque falhado e, no arranque seguinte, pode manter o menu aberto até alguém premir uma tecla. Num servidor sem teclado, essa espera nunca termina. Se a consola mostrar um menu e nada avançar, foi isso que aconteceu. Selecione uma entrada e continue.

Corrija ambos os casos enquanto a máquina está saudável. Edite /etc/default/grub:

GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=10
GRUB_RECORDFAIL_TIMEOUT=10
GRUB_TERMINAL="console serial"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200"
GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0,115200"

Depois aplique a alteração e confirme que ela persistiu, porque os ficheiros em /etc/default/grub.d/ são lidos depois de /etc/default/grub e podem substituir a sua configuração.

sudo update-grub
grep -rE 'TIMEOUT|TERMINAL' /etc/default/grub /etc/default/grub.d/

GRUB_TERMINAL="console serial" envia o menu para a consola gráfica e para a porta série, para que apareça no visualizador disponibilizado pelo seu painel. Os argumentos de kernel console= fazem o mesmo com as mensagens de arranque seguintes. Dez segundos de atraso por arranque é um preço baixo por um menu que pode realmente aceder às 2am.

Que classe de falha estou a analisar?

Leia as últimas vinte linhas antes de a consola deixar de avançar. Quatro padrões abrangem a maior parte do que acontece depois de uma atualização do kernel.

O GRUB não encontra os próprios ficheiros. Surge uma prompt grub rescue> ou um erro sobre uma partição ou ficheiro que não existe, e nunca aparece uma mensagem do kernel. O kernel ainda não está envolvido. Isto acontece depois de uma alteração ao disco ou às partições, ou quando o bootloader foi gravado no dispositivo errado, e não devido apenas a um pacote do kernel.

O kernel inicia, mas não consegue montar o root. As mensagens do kernel aparecem, depois surge uma shell busybox cuja prompt é (initramfs), ou o boot termina com um panic sobre a impossibilidade de montar o sistema de ficheiros root. O kernel foi carregado. O initramfs, que é o root temporário pequeno que encontra e monta o sistema de ficheiros root real, não encontrou o disco. No Ubuntu, esta shell é normalmente precedida por uma mensagem sobre a desistência de esperar pelo dispositivo root, que indica o UUID pretendido. Copie esse UUID e compare-o mais tarde com o resultado de blkid.

Um volume lógico nunca aparece. Esta é a classe anterior com uma causa específica. Na prompt (initramfs), execute ls /dev/mapper. Se a única entrada for control, nenhum volume do LVM (gestor de volumes lógicos) foi ativado, pelo que o dispositivo root ainda não existe. Ative manualmente os grupos de volumes:

lvm vgchange -ay
ls /dev/mapper
exit

exit devolve o controlo ao script do initramfs, que tenta novamente montar o sistema de ficheiros. Se o sistema arrancar nesse momento, faltam as componentes do LVM no novo initramfs. A correção consiste em reconstruir essa imagem, e não em alterar o kernel.

Não aparece nada do Linux. A consola mostra texto do firmware, uma shell UEFI (interface de firmware extensível unificada), um ecrã vazio sem saída do kernel ou um ciclo de reinícios. A falha ocorre antes de o Linux ser executado. Verifique qual é o modo realmente utilizado pelo servidor quando voltar a ter acesso, porque muitas instâncias VPS arrancam em modo BIOS legado e nunca utilizam o caminho EFI:

[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
mountpoint /boot/efi
sudo efibootmgr -v

Um /boot/efi não montado durante a atualização é uma causa comum em máquinas UEFI, porque os pacotes que mantêm a partição de sistema EFI escrevem então numa diretoria vazia normal. O firmware continua a iniciar a entrada de boot antiga até essa entrada deixar de corresponder ao que está no disco.

Existe ainda um padrão que não é uma falha de boot. Se chegar a uma shell root que indique que o sistema está em modo de emergência, o kernel arrancou e o userspace parou. Normalmente, isso significa que existe uma linha inválida em /etc/fstab ou que um sistema de ficheiros falhou a verificação. Execute journalctl -xb nessa shell e leia o nome da unidade que falhou.

O pacote do kernel está danificado ou o initramfs?

Estes dois problemas parecem iguais na consola, mas exigem correções diferentes. Arranque com o kernel antigo e compare os ficheiros.

ls -l /boot/vmlinuz-* /boot/initrd.img-*
df -h /boot

Deve existir um vmlinuz- e um initrd.img- correspondente para cada versão instalada, ambos com um tamanho plausível. A ausência de um initrd, ou um ficheiro muito menor do que os restantes, indica que a geração do initramfs falhou. A causa habitual é um /boot cheio, e os indícios estão nos logs dos pacotes:

sudo grep -iE 'no space|update-initramfs' /var/log/apt/term.log
sudo tail -n 40 /var/log/apt/history.log

history.log também mostra exatamente quais pacotes foram instalados nas últimas execuções e quando, esclarecendo qualquer dúvida sobre o que mudou.

Libere espaço primeiro se /boot estiver cheio. Em seguida, reconstrua a imagem para a versão necessária e atualize o menu. Obtenha a cadeia da versão na sua própria saída de ls, porque o marcador abaixo não representa uma versão real:

KVER=6.8.0-XX-generic
sudo update-initramfs -c -k "$KVER"
sudo update-grub
ls -l /boot/initrd.img-$KVER

Esse ls final é a verificação. Um ficheiro com tamanho normal significa que a imagem está novamente presente. Se a própria imagem do kernel estiver danificada, ou se dpkg -l mostrar o pacote com um estado diferente de ii, reinstale o pacote:

sudo apt install --reinstall linux-image-$KVER
sudo dpkg --configure -a

Reparar a partir do modo de rescue quando nenhum kernel arranca

Se todas as entradas do menu falharem, arranque a imagem de rescue do fornecedor e repare o disco a partir do exterior. O disco aparece como um dispositivo não montado, por isso nada nele está em execução e nenhum processo interfere com a reparação.

sudo lsblk -f
sudo vgchange -ay
sudo mount /dev/ubuntu-vg/ubuntu-lv /mnt
sudo mount /dev/vda2 /mnt/boot
sudo mount /dev/vda1 /mnt/boot/efi

for d in dev proc sys run; do sudo mount --rbind /$d /mnt/$d; done
sudo chroot /mnt /bin/bash

df -h /boot
update-initramfs -u -k all
update-grub
grub-install /dev/vda
exit

Testar um novo kernel sem comprometer o próximo arranque

O GRUB pode iniciar uma entrada uma única vez e depois voltar ao predefinido escolhido. Aponte o predefinido para um kernel em que confia e inicie o novo apenas durante um arranque. Se falhar, um reinício forçado pelo painel devolve-o ao kernel funcional, sem depender do tempo de resposta da consola.

Defina GRUB_DEFAULT=saved em /etc/default/grub, execute sudo update-grub e, em seguida, liste os títulos das entradas para poder indicar um deles exatamente:

grep -E "(menuentry|submenu) " /boot/grub/grub.cfg | cut -d"'" -f2
sudo grub-set-default "Advanced options for Ubuntu>Ubuntu, with Linux 6.8.0-XX-generic"
sudo grub-editenv list
sudo grub-reboot 0
sudo reboot

grub-editenv list deve apresentar o título escolhido como saved_entry. Esse resultado confirma que o mecanismo funciona, porque guardar exige um /boot/grub/grubenv com permissões de escrita e, em alguns layouts, isso não acontece de forma silenciosa. A entrada 0 é a primeira do menu, ou seja, corresponde ao kernel mais recente. Neste caso, os títulos são mais seguros do que os números, porque estes mudam sempre que um kernel é instalado ou removido.

Por que o autoremove é arriscado num servidor sem interface local

O APT mantém uma lista dos pacotes de kernel que não deve remover por conta própria. Consulte a sua:

cat /etc/apt/apt.conf.d/01autoremove-kernels
dpkg -l 'linux-image-*' | grep -c '^ii'

Esse ficheiro é regenerado sempre que os pacotes de kernel mudam e protege o kernel em execução e os mais recentes. O risco está no momento em que o comando é executado. Execute sudo apt autoremove --purge logo depois de arrancar com um kernel novo e a lista de proteção já terá avançado. O kernel antigo de que dependia deixará de estar protegido. Numa máquina com teclado, isso é apenas um inconveniente. Num servidor sem acesso local, é a diferença entre escolher uma entrada no menu e montar o disco a partir de uma imagem de recuperação.

Mantenha pelo menos dois kernels. Mantenha três quando /boot tiver capacidade para isso. Remova os kernels antigos pelo nome depois de verificar uname -r. Assim, nunca poderá eliminar o kernel em execução:

uname -r
sudo apt purge linux-image-6.8.0-XX-generic
dpkg -l 'linux-image-*' | grep '^ii'

Execute novamente o último comando depois disso. A redução da contagem de três para dois é uma limpeza normal. A redução para um significa que haverá uma indisponibilidade no próximo reboot.

Faça um snapshot antes da atualização

Um snapshot criado antes de apt upgrade é o único caminho de recuperação que não depende de arrancar nada. Restaurá-lo repõe o disco no estado em que o kernel antigo era o padrão, e permite tentar novamente a atualização com a consola já aberta. Snapshots de uma máquina em execução são consistentes com falhas, o que significa que capturam o disco como se a alimentação tivesse sido cortada. Por isso, desligue primeiro o servidor quando o seu provedor permitir criar um snapshot offline. Um snapshot também não é um backup, porque normalmente fica na mesma infraestrutura que o volume copiado. Compreender a diferença entre snapshots de VPS e backups reais determina qual deles o salva quando a falha é maior do que um kernel.

Isto é mais importante numa atualização de release, em que o kernel, as ferramentas do initramfs, o bootloader e a configuração do GRUB mudam na mesma execução. Crie o snapshot imediatamente antes de iniciar uma atualização do Ubuntu 24.04 para 26.04, e não na noite anterior, para que o ponto de restauração corresponda à máquina que está prestes a alterar.

Como o unattended-upgrades trata os pacotes do kernel

O unattended-upgrades do Ubuntu instala atualizações de segurança sem pedir confirmação, e os pacotes do kernel chegam através do security pocket, como os restantes pacotes. Daqui resultam duas consequências.

Primeiro, o novo kernel é instalado, mas não está em execução. Um kernel só entra em vigor no arranque. O ficheiro /var/run/reboot-required aparece, e /var/run/reboot-required.pkgs identifica o que solicitou o reboot, mas nada reinicia se não tiver ativado Unattended-Upgrade::Automatic-Reboot em /etc/apt/apt.conf.d/50unattended-upgrades.

cat /var/run/reboot-required.pkgs
grep -E 'Automatic-Reboot|Blacklist' /etc/apt/apt.conf.d/50unattended-upgrades

Segundo, esse intervalo oculta a causa. Um servidor pode instalar um kernel em março e reiniciar em junho por um motivo completamente diferente, para depois não arrancar. A alteração que impediu o arranque tem três meses, por isso nada do que fez nesse dia explica o problema. Em /var/log/apt/history.log encontra a execução que instalou o kernel que agora está a causar a falha.

Faça o reboot de propósito, no dia que escolher, com a janela da consola já aberta. Esse hábito transforma uma indisponibilidade inexplicável numa seleção de menu de dois minutos. Se quiser a automatização sem a surpresa, mantenha as instalações automáticas ativadas e os reboots automáticos desativados. Consulte como configurar o unattended-upgrades no Ubuntu para obter as definições exatas. Reter os pacotes do kernel com sudo apt-mark hold linux-image-generic impede completamente a instalação, incluindo as correções de segurança do kernel. Trate essa opção como uma troca deliberada, não como uma medida de segurança.

FAQ

Como inicializo um kernel mais antigo numa VPS sem teclado?

Abra a consola do provedor (VNC ou serial) e acione uma reinicialização forçada no painel de controlo, porque não pode iniciar sessão para reinicializar o sistema de forma limpa. Quando a máquina reiniciar, pressione Esc repetidamente ou mantenha Shift pressionado num arranque com BIOS legada, para manter o menu do GRUB aberto. Escolha "Advanced options for Ubuntu" e selecione a entrada abaixo do kernel mais recente. Depois de obter um prompt de início de sessão, execute uname -r para confirmar qual kernel está a ser usado e dpkg -l 'linux-image-*' para ver quais outros estão instalados. Só faça o diagnóstico depois de o sistema voltar a estar em execução.

Por que motivo a minha VPS não mostra qualquer menu do GRUB?

As imagens cloud normalmente definem o tempo limite do GRUB como 0 num ficheiro em /etc/default/grub.d/, pelo que o kernel mais recente é iniciado sem dar tempo para pressionar uma tecla. Defina GRUB_TIMEOUT=10 e GRUB_TIMEOUT_STYLE=menu em /etc/default/grub, adicione GRUB_TERMINAL="console serial" para que o menu também seja apresentado numa consola serial e execute sudo update-grub. Confirme com grep -r TIMEOUT /etc/default/grub /etc/default/grub.d/, porque os ficheiros desse diretório são lidos depois do ficheiro principal e podem substituir a sua alteração.

Devo remover kernels antigos para libertar espaço em /boot?

Remova os mais antigos e mantenha pelo menos dois. Um /boot cheio é uma condição de falha própria, porque a geração do initramfs falha e fica com um kernel sem uma imagem funcional. Remova os pacotes pelo nome exato depois de verificar uname -r, para que o kernel em execução nunca seja considerado. Evite executar sudo apt autoremove --purge indiscriminadamente numa máquina sem teclado, porque a lista de kernels protegidos é regenerada a cada alteração de kernel e uma execução num momento inadequado pode deixá-lo com apenas um kernel e sem uma entrada de fallback no menu.

As atualizações automáticas podem impedir o arranque?

Podem instalar um kernel que posteriormente falhe ao arrancar, mas não reiniciam a máquina, exceto se Unattended-Upgrade::Automatic-Reboot estiver definido como true em /etc/apt/apt.conf.d/50unattended-upgrades. O padrão habitual é uma falha atrasada: o kernel é instalado durante uma execução automática, /var/run/reboot-required aparece e o problema só se manifesta no próximo reboot, semanas depois. Reinicie deliberadamente com a consola já aberta e consulte /var/log/apt/history.log para descobrir qual execução instalou o kernel que está a arrancar.