Ubuntu 26.04.1: o que é uma point release

O que é uma point release do Ubuntu

Uma point release do Ubuntu, como 26.04.1, é a versão que já tem instalada, com todas as atualizações publicadas desde o lançamento incorporadas numa nova imagem de instalação. Não é uma versão nova. O repositório a partir do qual é instalada não muda, nem muda o nome da suite nas fontes do apt. Por isso, um servidor que já esteja instalado e atualizado não tem nada para descarregar quando uma point release é publicada.

Duas coisas são disponibilizadas nesse dia. A mídia de instalação é recriada: são gerados novos ficheiros ISO e novas imagens cloud com base no estado do repositório nessa semana. E a string da versão muda: lsb_release -a passa a apresentar 26.04.1 LTS onde antes apresentava 26.04 LTS.

Todo o restante já estava disponível. O Ubuntu publica correções continuamente nos pockets -security e -updates de uma suite, resolute para 26.04 e noble para 24.04. Uma point release é um instantâneo desse fluxo. Não existe um destino separado para onde seja necessário migrar.

Por que o seu servidor atualizado não tem nada para descarregar

Porque o número da versão pontual está num pacote pequeno. Execute:

lsb_release -a
dpkg -S /etc/lsb-release

dpkg -S responde base-files: /etc/lsb-release. O pacote base-files fornece os ficheiros que contêm a sua cadeia de versão. Por isso, quando é publicada uma versão pontual, uma nova base-files é disponibilizada no repositório -updates e a próxima sudo apt upgrade instala-a. Esse pacote é todo o efeito visível de uma versão pontual numa máquina em execução. Tudo o resto incluído nela foi instalado semanas antes como atualizações normais.

Há uma forma comum de ficar para trás. O /etc/apt/apt.conf.d/50unattended-upgrades predefinido ativa a origem -security no bloco Allowed-Origins e deixa a linha -updates comentada. Assim, uma máquina que dependa apenas de atualizações automáticas recebe as correções de segurança, mas ignora o restante. Essa máquina continua a apresentar um número de versão pontual mais antigo durante meses. E está correto, porque realmente não tem esses pacotes. Abra o ficheiro e veja quais linhas estão comentadas: como são configuradas as atualizações automáticas no Ubuntu analisa esse bloco linha a linha.

Quando chegar a próxima versão de manutenção

Aprenda o ciclo, não a data. A primeira versão de manutenção de uma LTS é lançada alguns meses depois da versão original de abril. As seguintes são lançadas em intervalos de aproximadamente seis meses, acompanhando cada versão intermédia. As datas podem mudar. A Canonical anunciou inicialmente a primeira versão de manutenção da 26.04 para o início de agosto de 2026, mas adiou-a. Isto é normal e não indica um problema. Consulte a data na página do ciclo de versões do Ubuntu ou nas notas de versão da 26.04 LTS, e não em qualquer artigo, incluindo este.

Por que 24.04 não é oferecido como atualização para 26.04 até ao primeiro point release

Porque o pedido de atualização está configurado para esperar. Pode consultar essa configuração no próprio servidor.

cat /etc/update-manager/release-upgrades

[DEFAULT]
# never  - Never check for, or allow upgrading to, a new release.
# normal - Check to see if a new release is available.
# lts    - Check to see if a new LTS release is available.
Prompt=lts

Os comentários do ficheiro fornecido são mais extensos do que esse excerto e vale a pena lê-los na íntegra. Prompt=lts é o valor predefinido numa instalação LTS e tem duas funções: limita a oferta às versões LTS e envia a verificação para uma lista diferente.

Essa lista é indicada num segundo ficheiro:

cat /etc/update-manager/meta-release

URI aponta para https://changelogs.ubuntu.com/meta-release e URI_LTS aponta para https://changelogs.ubuntu.com/meta-release-lts. Com Prompt=lts, o atualizador lê a lista LTS, e a nova LTS não é oferecida como destino de atualização até existir o seu primeiro point release. Obtenha a lista e confirme:

curl -s https://changelogs.ubuntu.com/meta-release-lts | tail -40

Cada versão é um bloco de linhas Dist:, Version:, Supported: e UpgradeTool:. O atualizador precisa desse bloco antes de poder oferecer qualquer versão. A Canonical declara a mesma regra de forma explícita no anúncio de lançamento da 26.04 LTS: os utilizadores da 24.04 LTS recebem a oferta de atualização automática quando a 26.04.1 for lançada.

Assim, num servidor 24.04 antes desse ponto:

sudo do-release-upgrade -c

Checking for a new Ubuntu release
No new release found.

Esse é um resultado normal. Não indica uma falha. Quando o caminho estiver disponível, o mesmo comando indicará a versão, e a mesma mensagem aparecerá no banner de login:

New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Observe qual é a versão indicada. Não atualiza primeiro para 26.04 e depois para 26.04.1. Faz uma única atualização e termina no estado atual da 26.04.

Há outras duas causas para essa verificação não encontrar nada: Prompt=never, que algumas imagens de fornecedores definem, e um proxy ou mirror que não consegue aceder a changelogs.ubuntu.com. Uma mensagem diferente, Please install all available updates for your release before upgrading, significa que a verificação foi concluída e que o atualizador exige um ponto de partida totalmente atualizado. do-release-upgrade a indicar que não foi encontrada uma nova versão explica as restantes causas. Quando o caminho estiver disponível e estiver pronto, a própria atualização da 24.04 para a 26.04 é uma tarefa separada, com a sua própria preparação.

A flag -d direciona a mesma verificação para a lista de desenvolvimento. É assim que algumas pessoas avançam antes de o caminho normal ficar disponível. A espera existe por um motivo: é o período em que são corrigidos os bloqueios de atualização identificados pelos primeiros utilizadores. Num servidor que aluga e do qual depende, faz sentido deixar que esse período cumpra a sua função.

O que significa o kernel de habilitação de hardware numa VPS

Uma LTS disponibiliza um kernel durante todo o seu ciclo de vida, o kernel GA (general availability), e oferece uma segunda linha de atualizações contínuas chamada HWE (hardware enablement). A linha HWE é disponibilizada através de point releases. É a única parte de uma point release que contém código realmente novo, em vez de apenas reorganizar o que já tem instalado.

24.04 é o exemplo usado aqui. Foi disponibilizado com o kernel 6.8 e mantém o 6.8 na linha GA durante os cinco anos completos de suporte padrão. A linha HWE começou na segunda point release: a 24.04.2 trouxe o kernel 6.11 do Ubuntu 24.10, e a 24.04.3 trouxe o 6.14 do Ubuntu 25.04. Em agosto de 2026, este é o padrão estabelecido, e a 26.04 segue a mesma estrutura.

A linha que está a utilizar é indicada pelo nome de um pacote:

uname -r
apt list --installed 2>/dev/null | grep -E '^linux-(generic|virtual|image|kvm)'

linux-generic é a linha GA. linux-generic-hwe-24.04 é a linha contínua. As instalações Desktop usam HWE por predefinição, e as instalações Server usam GA por predefinição. As imagens fornecidas por um provedor para uma VPS podem usar algo ainda mais específico, como linux-virtual ou um linux-kvm específico para cloud. Confirme em vez de assumir, porque a predefinição depende de quem criou a sua imagem.

Em hardware virtual alugado, a habilitação de hardware normalmente não se aplica. O servidor vê dispositivos virtio e as interfaces paravirtualizadas de rede e disco apresentadas pelo hypervisor. Esses drivers estão estáveis no kernel há mais de uma década. Um portátil novo precisa de HWE. Uma VPS quase nunca precisa. O que um kernel mais recente oferece neste caso são funcionalidades do kernel: melhorias mais recentes no io_uring e no eBPF, ou uma correção de sistema de ficheiros que tenha um motivo específico para querer. o que há de novo no kernel Linux 7.1 é a forma de decidir se alguma dessas alterações justifica o risco e a manutenção adicional.

O custo são os reboots e o risco. O meta package HWE instala um kernel upstream novo aproximadamente a cada seis meses. Isso implica aceitar uma atualização do kernel e um reboot nesse intervalo. Módulos externos compilados com DKMS, normalmente o ZFS, podem falhar ao serem compilados para a nova versão. O problema pode ser detetado apenas no boot. Cada kernel também mantém a versão anterior instalada. É assim que um pequeno /boot fica cheio. Leia remover kernels antigos de um /boot cheio e escolher qual kernel a sua VPS inicia antes de precisar dessas instruções, e não depois.

A mudança para a linha HWE requer um comando e um reboot:

sudo apt install --install-recommends linux-generic-hwe-24.04
sudo reboot

uname -r depois do reboot deve indicar a versão mais recente. Mantenha o kernel anterior instalado até iniciar o novo e verificar os seus serviços. Se o novo kernel não arrancar, o procedimento de recuperação é selecionar a entrada anterior no menu de boot. Essa entrada ainda tem de existir. Se não existir, está perante um caso de recuperar uma VPS que não arranca depois de uma atualização do kernel.

Existe também uma variante -edge do pacote HWE que instala o kernel seguinte antes da point release. Destina-se a testes. Não a utilize num servidor.

A escolha predefinida para um servidor alugado é o kernel GA: uma versão do kernel durante cinco anos, com correções de segurança integradas nessa versão durante todo o período e sem uma atualização de versão programada. Mude para HWE quando conseguir indicar a funcionalidade de que precisa.

Por que uma instalação nova hoje é diferente de uma instalação feita no mês passado

As imagens são recriadas com mais frequência do que são lançadas versões de correção. O Ubuntu publica imagens para a nuvem com um número de série, e cada provedor atualiza os seus templates do Ubuntu segundo o seu próprio calendário. Por isso, dois servidores criados com seis meses de diferença a partir da mesma opção podem arrancar com versões diferentes do kernel e com versões diferentes dos pacotes. Nenhum dos dois está errado.

Isto é mais importante do que parece. Um procedimento que manda executar cinco comandos depois da instalação pressupõe silenciosamente um estado inicial que já pode não existir. Verifique lsb_release -a e uname -r em cada servidor, em vez de confiar no rótulo selecionado, e defina o estado final em código para que o estado inicial deixe de ser relevante. um primeiro playbook do Ansible para um VPS é a versão útil mais simples disso.

Mudar na atualização pontual ou esperar?

• Se já está no 26.04, não há para onde mudar. Continue a instalar as atualizações, e o número da atualização pontual avança automaticamente.
• Se está no 24.04, o suporte padrão vai até abril de 2029, por isso esperar tem baixo custo. A primeira atualização pontual é uma oportunidade, não um prazo.
• Faça primeiro o upgrade de uma cópia. Crie um snapshot do servidor ou recrie a mesma stack numa VPS descartável, execute o upgrade nesse ambiente e meça quanto tempo demora.
• Se pretende um kernel mais recente, e não uma versão mais recente, o track HWE disponibiliza isso no 24.04 sem qualquer upgrade de LTS.

A questão mais ampla sobre qual versão usar como base está explicada em LTS versus versões interim para um servidor.

O que verificar no seu próprio servidor

lsb_release -a
uname -r
grep -v '^#' /etc/update-manager/release-upgrades
sudo do-release-upgrade -c

Um resultado saudável é o seguinte: lsb_release -a informa a sua release com o número de revisão atual, uname -r corresponde à série do kernel que pretendia utilizar, Prompt=lts está presente e a verificação não encontra nada ou indica a release que será disponibilizada. Qualquer outro resultado deve ser analisado antes de uma atualização, e não durante ela.

FAQ

Tenho de fazer alguma coisa quando é lançada uma point release, como 26.04.1?

Não, desde que o servidor já esteja nessa release e a receber atualizações. Uma point release reúne as atualizações já publicadas num novo meio de instalação. Uma máquina em execução recebe o mesmo conteúdo através de apt upgrade à medida que este é publicado, e a string de versão em lsb_release -a muda quando o pacote base-files é atualizado. Não existe uma release separada para instalar nem é necessário reinstalar.

Porque é que o meu servidor ainda indica um número de point release mais antigo depois de executar apt upgrade?

Normalmente, porque as atualizações automáticas estão limitadas a correções de segurança. O /etc/apt/apt.conf.d/50unattended-upgrades predefinido ativa a origem -security e mantém comentada a linha -updates, e o pacote base-files, que contém a string de versão, é obtido através de -updates. Execute sudo apt update && sudo apt full-upgrade manualmente e verifique se base-files aparece na lista. Se estiver listado como mantido, existe algum pinning ou hold a impedir a atualização.

Porque é que o meu servidor 24.04 não recebe a proposta de atualização para 26.04?

Porque Prompt=lts em /etc/update-manager/release-upgrades é o valor predefinido numa LTS, e verifica a lista de LTS em https://changelogs.ubuntu.com/meta-release-lts. A nova LTS não é apresentada como destino de atualização até à sua primeira point release. Até lá, sudo do-release-upgrade -c apresenta No new release found., e esse comportamento está correto. A espera é deliberada: corresponde ao período em que os problemas de atualização encontrados pelos primeiros utilizadores são corrigidos.

Devo instalar o kernel HWE na minha VPS?

Normalmente, não. O hardware enablement existe para suportar hardware mais recente do que a release, e uma VPS apresenta dispositivos virtio cujos controladores já estão no kernel há anos. O kernel GA mantém-se numa versão durante todo o ciclo de vida da LTS, com as correções integradas nessa versão. Instale o kernel HWE quando conseguir indicar a funcionalidade do kernel de que precisa e aceite que terá de fazer uma mudança de kernel e um reboot aproximadamente a cada seis meses.