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

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

Uma VPS que não arranca depois de uma atualização do kernel normalmente pode ser recuperada em poucos minutos, porque a atualização não eliminou o kernel que funcionava no dia anterior. 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 um prompt de login 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 mostrar o panic. O SSH também não responderá, porque a máquina nunca chegou ao ponto em que o sshd é iniciado. Tudo o que se segue é feito através da consola do seu fornecedor.

Leia primeiro o conteúdo da sua consola antes de alterar qualquer coisa. O texto apresentado determina a classe de falha, e dois servidores que “não arrancam” podem precisar de correções opostas.

Como acesso a consola quando o SSH está inoperacional?

Abra o painel de controlo do seu fornecedor e procure uma consola. Os nomes mais comuns são VNC console, web console, noVNC e serial console. Prefira a consola serial quando ambas estiverem disponíveis, porque permite ver texto real, percorrê-lo e copiá-lo, enquanto uma vista VNC é 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 impede que mantenha a calma necessária. Essa verificação faz parte de os primeiros dez minutos num VPS novo, juntamente com as regras da firewall e as chaves SSH.

A maioria dos painéis também oferece um modo de recuperação ou uma imagem de recuperação. Esse modo arranca 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 é a forma de copiar dados de um servidor que decidiu não recuperar.

Normalmente, terá de fazer um hard reset a partir do 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 desligar a alimentação. Os sistemas de ficheiros sofrem 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 o console desde o momento em que pressiona reset. Pressione Esc repetidamente durante os primeiros segundos ou mantenha Shift pressionado numa máquina que arranca em modo BIOS legado. A janela de oportunidade é curta, e o visualizador do console muitas vezes demora um segundo a ligar-se. Por isso, comece a pressionar cedo e continue a pressionar.

Quando o menu aparecer, escolha "Advanced options for Ubuntu". Esse submenu lista todos os kernels instalados, começando pelo mais recente, com uma entrada de modo de recuperação para cada um. Escolha a segunda entrada normal, que corresponde ao kernel abaixo do mais recente, e pressione Enter. O modo de recuperação é diferente: arranca um sistema mínimo de utilizador único e serve para tarefas de reparação, não para voltar a colocar os serviços online.

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

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

A saída de dpkg é a sua lista de kernels instalados. Se contiver apenas uma linha, não tem qualquer alternativa de fallback, e essa é a primeira coisa a corrigir.

O menu do GRUB nunca aparece. E agora?

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

Também existe o caso oposto: o menu aparece no ecrã, fica à espera e parece que o sistema bloqueou. O GRUB regista uma falha de arranque 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 mostra um menu e nada avança, 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 foi preservada, 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. Assim, ele aparece no visualizador disponibilizado pelo seu painel. Os argumentos de kernel console= fazem o mesmo para 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 twenty linhas antes de a consola deixar de avançar. Quatro padrões abrangem a maioria dos problemas que surgem 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 inexistente, e nunca aparece uma mensagem do kernel. O kernel ainda não está envolvido. Isto acontece depois de uma alteração no disco ou nas partições, ou quando o bootloader é gravado no dispositivo errado, e não apenas por causa de um pacote do kernel.

O kernel inicia, mas não consegue montar o root. As mensagens do kernel aparecem no ecrã e, depois, surge uma shell busybox com a prompt (initramfs), ou o arranque termina com um panic a indicar que não foi possível montar o filesystem root. O kernel foi carregado. O initramfs, que é o root temporário pequeno que localiza e monta o filesystem root real, não encontrou o disco. No Ubuntu, esta shell é normalmente precedida por uma mensagem a indicar que esgotou o tempo de espera pelo dispositivo root, incluindo o UUID pretendido. Copie esse UUID e compare-o mais tarde com o output de blkid.

Um logical volume 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 (logical volume manager) foi ativado, pelo que o dispositivo root ainda não existe. Ative manualmente os volume groups:

lvm vgchange -ay
ls /dev/mapper
exit

exit devolve o controlo ao script do initramfs, que tenta montar o filesystem novamente. Se o sistema arrancar, o novo initramfs não contém os componentes do LVM. 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 (unified extensible firmware interface), um ecrã vazio sem output do kernel ou um ciclo de reinício. A falha ocorre antes de o Linux ser executado. Depois de recuperar o acesso, confirme qual é o modo de arranque efetivamente usado pelo servidor, porque muitas instâncias VPS arrancam em modo BIOS legacy 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 EFI system partition escrevem então numa diretoria vazia normal. O firmware continua a iniciar a entrada de arranque antiga até essa entrada deixar de corresponder ao conteúdo do disco.

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

O pacote do kernel está danificado ou o initramfs?

Estes dois casos parecem idênticos na consola e 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 registos nos pacotes mostram as evidências:

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 apresenta exatamente quais os pacotes 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 a partir da 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 último ls é a verificação. Um ficheiro com tamanho normal indica que a imagem está agora presente. Se a própria imagem do kernel estiver danificada, ou se dpkg -l mostrar o pacote com qualquer estado diferente de ii, reinstale o pacote:

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

Reparar a partir do rescue mode quando nenhum kernel arranca

Se todas as entradas do menu falharem, arranque a rescue image 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 pode bloquear o trabalho.

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 kernel novo sem arriscar o próximo boot

O GRUB pode iniciar uma entrada uma única vez e depois voltar ao seu padrão escolhido. Aponte o padrão para um kernel em que confia e inicie o novo apenas nesse boot. Se falhar, um reset forçado no painel leva-o de volta ao kernel funcional, sem depender do tempo de resposta da consola.

Defina GRUB_DEFAULT=saved em /etc/default/grub, execute sudo update-grub e depois 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 mostrar o título escolhido como saved_entry. Essa saída confirma que o mecanismo funciona, porque guardar a configuração exige um /boot/grub/grubenv com permissões de escrita, e em alguns layouts isso não acontece de forma visível. A entrada 0 é a primeira do menu e 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 automaticamente. 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. Ele protege o kernel em execução e os mais recentes. O risco está no momento em que executa o comando. Execute sudo apt autoremove --purge logo depois de reiniciar com um kernel novo, e a lista de proteção já terá avançado. O kernel antigo de que dependia deixa de estar protegido. Numa máquina com teclado, isso é apenas um inconveniente. Num servidor sem acesso local, é a diferença entre escolher uma entrada do 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 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. A redução para um é uma interrupção de serviço à espera do próximo reboot.

Criar 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 uma falha, 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. Entender 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, não na noite anterior, para que o ponto de restauro corresponda à máquina que está prestes a alterar. Se essa atualização ainda não tiver sido disponibilizada no seu servidor, a causa é o calendário de disponibilização, não uma configuração danificada, porque uma atualização de LTS para LTS só fica disponível em o primeiro point release, 26.04.1.

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 pelo security pocket, tal 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 o sistema, a menos que tenha 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 não relacionado, para depois não conseguir arrancar. A alteração que deixou o arranque inoperacional tem três meses, por isso nada do que fez nesse dia explica o problema. /var/log/apt/history.log é onde encontra a execução que instalou o kernel com o qual o sistema está agora a falhar.

Faça o reboot de propósito, num dia escolhido por si, com a janela da consola já aberta. Esse único hábito transforma uma indisponibilidade misteriosa 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, e 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 bloqueia-os completamente e também bloqueia as correções de segurança do kernel. Trate essa opção como uma decisão com custos, não como uma medida de segurança.

FAQ

Como iniciar um kernel mais antigo numa VPS sem teclado?

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

Porque é que a minha VPS não mostra qualquer menu do GRUB?

As imagens cloud definem normalmente o tempo limite do GRUB como 0 num ficheiro dentro de /etc/default/grub.d/. Por isso, o kernel mais recente inicia sem dar tempo para premir 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 causa 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 selecionado. Evite executar sudo apt autoremove --purge sem especificar pacotes numa máquina sem teclado, porque a lista de kernels protegidos é regenerada a cada alteração do 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 falhe posteriormente ao arrancar, mas não reiniciam a máquina a menos que Unattended-Upgrade::Automatic-Reboot esteja definido como true em /etc/apt/apt.conf.d/50unattended-upgrades. O padrão habitual é uma falha adiada: 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 mais tarde. Faça o reboot de forma deliberada com a consola já aberta e consulte /var/log/apt/history.log para descobrir qual foi a execução que instalou o kernel que está a iniciar.