Kernel novo: quando vale atualizar e como voltar atrás

O kernel é o único componente cuja atualização pode deixar a máquina sem subir. Não é o mais provável de dar errado — na prática, atualização de kernel funciona quase sempre —, mas é o que tem a pior consequência quando falha, porque não sobra sistema para diagnosticar.

Isso cria uma tentação compreensível: adiar indefinidamente. E adiar kernel é justamente o que mais acumula exposição, porque é ali que aparecem as falhas de escalação de privilégio — aquelas em que um usuário comum, ou um processo comprometido, vira root.

O equilíbrio existe, e depende de separar dois tipos de atualização que costumam ser tratados como um só.

Correção não é o mesmo que versão nova

Dentro de uma versão estável de distribuição, o kernel recebe correções aplicadas sobre a mesma linha. Ubuntu 24.04 permanece na série do kernel que veio com ele, recebendo apenas o necessário. O comportamento não muda, os módulos continuam compatíveis, e o risco é baixo.

Versão nova de linha é outra história: suporte a hardware mais recente, mudanças de comportamento, e a possibilidade real de um módulo de terceiro parar de compilar.

uname -r
cat /proc/version
apt list --installed 2>/dev/null | grep linux-image

Em Ubuntu, os pacotes linux-image-generic mantêm a linha original, enquanto os linux-image-generic-hwe-* trazem linhas mais novas conforme elas são liberadas. A diferença entre os dois é exatamente a diferença entre os dois parágrafos acima.

Para servidor, a recomendação é ficar na linha padrão da distribuição e aplicar correção com regularidade. Linha nova só quando houver motivo concreto: hardware que não é reconhecido, recurso específico necessário, ou desempenho comprovadamente melhor no seu caso.

Quando atualizar não é opcional

Algumas situações tiram a decisão da sua mão:

• Falha de escalação de privilégio divulgada. É a categoria mais séria em kernel, porque converte qualquer acesso limitado em controle total da máquina.
• Servidor com múltiplos usuários ou que executa código de terceiro. Aí o isolamento fornecido pelo kernel é a única barreira que existe.
• Container. Todos compartilham o kernel do hospedeiro. Uma falha ali atravessa o isolamento entre containers, o que é frequentemente esquecido por quem confia no container como fronteira de segurança.

Nessas situações, o cálculo se inverte: o risco de não atualizar passa a ser maior que o de atualizar.

Atualizar sem reiniciar, até certo ponto

Existe atualização de kernel em memória — livepatch no Ubuntu, kpatch no RHEL. Ela aplica correções sem reinício, o que é valioso em servidor único.

sudo snap install canonical-livepatch
sudo canonical-livepatch enable SEU_TOKEN
canonical-livepatch status

Vale entender o limite. O livepatch cobre correções de segurança que podem ser aplicadas em funções isoladas. Ele não cobre mudanças estruturais, e não substitui o reinício — apenas o adia, permitindo que ele aconteça em janela planejada em vez de emergencial.

Uma máquina com livepatch ativo ainda acumula pendência de reinício, e vale acompanhar:

ls /var/run/reboot-required 2>/dev/null && \
  cat /var/run/reboot-required.pkgs

Antes de reiniciar

Reinício com kernel novo é onde o risco se materializa. Três verificações reduzem bastante a chance de surpresa.

Confirme que o kernel antigo continua instalado. É ele que salva você:

dpkg -l | grep linux-image | awk '{print $2, $3}'
ls /boot/vmlinuz-*

Se houver apenas um, não há para onde voltar. Limpeza agressiva de kernel antigo — comum em máquina com /boot pequeno — remove justamente a rede de segurança.

Verifique módulos de terceiro. Driver de armazenamento, ferramenta de virtualização e agente de monitoramento costumam compilar contra a versão do kernel:

dkms status
lsmod | grep -vE '^(ext4|xfs|nf_|ip_|br_|overlay)'

Um módulo DKMS que não recompilou aparece aqui, e o sintoma depois do reinício é o serviço que dependia dele simplesmente não funcionar.

Tire um snapshot. Para atualização de kernel, ele é praticamente obrigatório — o snapshot é o que transforma uma máquina que não sobe em cinco minutos de retorno.

Voltar quando não sobe

Se a máquina não completa o boot, o caminho é escolher o kernel anterior no menu do GRUB. E aqui está o detalhe que decide se você consegue: isso exige console.

O console no browser entra pela virtualização, não pela rede, então continua funcionando com o sistema fora do ar — é o único acesso disponível nesse cenário, e é por isso que vale saber onde ele fica antes de precisar.

No menu do GRUB, o caminho é Advanced options e ali a lista de kernels instalados. Escolha o anterior e deixe a máquina subir.

Se o menu não aparece, ele está oculto por configuração:

# /etc/default/grub
GRUB_TIMEOUT_STYLE=menu
GRUB_TIMEOUT=5

sudo update-grub

Vale deixar isso configurado antes de precisar. Um menu com cinco segundos de espera custa cinco segundos por boot e resolve a situação em que não há outro jeito.

Já de volta no kernel antigo, torne a escolha permanente enquanto investiga:

grep -E '^menuentry|^\s+menuentry' /boot/grub/grub.cfg | \
  cut -d"'" -f2 | nl -v0

sudo grub-set-default "gnulinux-advanced-.../gnulinux-5.15.0-Nversão..."
sudo update-grub

E segure o pacote para ele não voltar a subir na próxima rodada de atualização:

sudo apt-mark hold linux-image-generic linux-headers-generic

Depois de subir, o que conferir

Kernel novo pode subir e ainda assim ter quebrado algo. A verificação leva um minuto:

uname -r                          # subiu com o esperado?
systemctl --failed                # algum serviço não voltou?
sudo dmesg -l err,warn | head -30 # erro na inicialização?
ip -br addr                       # rede como antes?
lsblk                             # discos todos presentes?
df -h                             # tudo montado?

A ordem não é aleatória: rede e disco são o que mais quebra com módulo incompatível, e são também o que impede você de investigar remotamente se falhar.

Vale conferir também os serviços que dependem de recurso do kernel, como container e firewall:

docker ps 2>/dev/null | head
sudo nft list ruleset | head -20

Regras de firewall que não voltaram são o problema silencioso desse momento — a máquina funciona, e está aberta. O artigo sobre firewall na VM e na nuvem explica por que o firewall de perímetro continua protegendo enquanto isso.

/boot cheio, que é o problema mais comum

Ironicamente, o obstáculo mais frequente na atualização de kernel não é falha — é falta de espaço. A partição /boot costuma ter poucas centenas de megabytes e cada kernel ocupa uma fatia relevante.

df -h /boot

Quando enche, a atualização falha no meio, às vezes deixando o pacote em estado inconsistente. A limpeza:

sudo apt autoremove --purge

Esse comando remove os kernels antigos preservando o atual e o anterior — que é exatamente o que você quer. Remover manualmente com dpkg é o caminho para apagar o kernel em uso, que é a forma mais rápida de tornar a máquina não inicializável.

Vale conferir quantos ficaram:

ls -1 /boot/vmlinuz-* | wc -l

Dois ou três é o número saudável. Um só é arriscado; dez significa que o autoremove nunca rodou, e o /boot vai encher em breve.

O arranjo defensável

• Linha padrão da distribuição, com correções aplicadas por atualização automática de segurança.
• Reinício em janela planejada, com o aviso de pendência acompanhado.
• Sempre dois kernels instalados, e /boot com espaço.
• Menu do GRUB visível, com timeout de alguns segundos.
• Snapshot antes, e o console de emergência localizado.

Com isso, atualizar o kernel deixa de ser a operação que ninguém quer fazer e vira uma tarefa de manutenção comum — que é o que ela deveria ser. O que a torna assustadora não é a probabilidade de falhar, é a ausência de um caminho de volta conhecido.

Kernel e container: o ponto cego

Uma consequência que merece destaque próprio, porque contraria a intuição de quem adotou container esperando isolamento.

Container não tem kernel próprio. Todos os containers de uma máquina compartilham exatamente o mesmo kernel do hospedeiro. A imagem carrega bibliotecas e binários de uma distribuição, o que dá a impressão de um sistema completo, mas as chamadas de sistema vão para o kernel de fora.

Duas implicações práticas. A primeira é que atualizar a imagem base não corrige falha de kernel — isso depende do hospedeiro, e só dele. Uma frota de containers impecavelmente atualizados sobre um hospedeiro de dois anos atrás está exposta a tudo que apareceu no período.

A segunda é que uma falha de escalação no kernel atravessa a fronteira entre containers. O isolamento que eles oferecem é construído sobre recursos do kernel — namespaces e cgroups — e uma falha nesse alicerce derruba a separação inteira.

Isso não desqualifica container; apenas posiciona corretamente o que ele entrega. Para isolamento com fronteira mais dura, a separação é por máquina virtual, que tem kernel próprio. Para o uso comum, a resposta é manter o hospedeiro atualizado e tratar o kernel dele como componente crítico — inclusive quando "só rodam containers" ali.