Cinco linhas Linux LTS foram atualizadas ontem — a frota precisa de três versões, não de uma

A página upstream mudou; a sua política de atualização não deve saltar o canal suportado

A página principal do kernel.org mostra cinco linhas longterm atualizadas a 7 de agosto: 6.12.102, 6.6.150, 6.1.182, 5.15.215 e 5.10.264. Mostra ainda stable 7.1.7 e longterm 6.18.43 em 6 de agosto. Estes são factos de release upstream, não uma instrução universal para instalar diretamente esses artefactos em Ubuntu, Debian, RHEL, SUSE, appliances ou serviços cloud.

Os mantenedores de plataformas podem portar correções para números diferentes, adicionar patches, assinar builds e definir combinações suportadas com drivers. Trate upstream como sinal de mudança e contexto técnico. A ação da frota nasce do advisory e repositório suportados para cada ativo, com exceção explícita para hosts compilados e mantidos internamente.

O registo mínimo guarda três versões e a proveniência

Para cada host, guarde a linha upstream relevante, o pacote instalado e o kernel em execução. Junte distribuição, repositório, assinatura, build, data de boot, live patches, módulos externos, estado de taint e dono do serviço. O estado ‘instalado’ não prova que a atualização foi ativada; o estado ‘a correr’ não prova que o pacote veio da origem aprovada.

O indicador de taint do kernel não declara por si só a causa de uma falha, mas conserva condições como módulos proprietários, warnings ou intervenções que os mantenedores precisam de conhecer. Preserve esse estado e passos reproduzíveis quando surge regressão. A documentação oficial recomenda informação clara sobre versão, ambiente e reprodução ao reportar problemas.

Promova por coorte e trate o rollback como mudança de estado

Comece em hosts descartáveis ou de laboratório que tenham o mesmo hardware, módulos, rede e armazenamento. Passe para uma coorte interna, depois uma pequena percentagem de produção e só avance quando boot, erros de kernel, rede, I/O, latência e workload ficarem dentro de limites. Regressões raras exigem tempo de observação proporcional à criticidade.

Voltar ao kernel anterior pode não desfazer mudanças de dados, filas ou protocolos ocorridas enquanto o novo código esteve ativo. O plano precisa de uma entrada de boot conhecida, acesso de consola, compatibilidade de módulos, proteção contra promoção automática e reconciliação de trabalho. Depois do rollback, preserve o host ou a evidência necessária para reproduzir e reportar.

• Não trate um reboot automático como validação.
• Não misture atualização do kernel e grandes mudanças de aplicação na mesma coorte sem necessidade.
• Não apague o boot anterior antes de confirmar drivers, módulos e caminho de recuperação.
• Não anuncie ‘todos corrigidos’ enquanto instalado e ativo divergirem.