Como atualizar o Ubuntu 24.04 para 26.04 numa VPS

Quando é possível atualizar o Ubuntu 24.04 para 26.04?

É possível atualizar o Ubuntu 24.04 para 26.04 numa VPS assim que for lançada a versão pontual 26.04.1, prevista para 27 August 2026. Até lá, um servidor 24.04 não verá a nova versão, de forma intencional. O Ubuntu 26.04 LTS (Resolute Raccoon) foi lançado em 23 April 2026, mas a Canonical só disponibiliza o caminho de atualização entre versões LTS na primeira versão pontual, porque essa versão inclui as correções dos problemas de instalação e atualização encontrados nos primeiros meses.

Execute a verificação num servidor 24.04 no início de August 2026 para obter o seguinte:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Isto não indica um problema no servidor. /etc/update-manager/release-upgrades contém Prompt=lts no Ubuntu Server, o que significa que a ferramenta só disponibiliza a próxima versão com suporte de longo prazo, e apenas quando a respetiva versão pontual .1 existir. Definir Prompt=normal faria a ferramenta passar sequencialmente pelo 24.10, 25.04 e 25.10, versões intermédias que já chegaram ao fim de vida. Mantenha lts e aguarde. As datas do calendário da Canonical podem mudar, por isso volte a verificar se o dia passar sem alterações.

Todos os comandos abaixo são executados por si, no seu próprio servidor, pela ordem indicada. Não é possível ensaiar uma atualização de versão na máquina que está a ser atualizada. O processo substitui o kernel e a biblioteca C e precisa de um reboot para terminar.

Deve mesmo atualizar?

O Ubuntu 24.04 recebe atualizações de segurança padrão até 2029, por isso um servidor de produção em funcionamento não tem qualquer urgência. Atualize porque precisa de algo que o 26.04 inclui: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 ou o kernel 7.0. "O número aumentou" não é motivo para alterar uma máquina que presta serviço aos clientes.

Não faça a atualização no local quando qualquer uma destas condições for verdadeira:

• Nunca abriu a consola do seu fornecedor (VNC ou serial) nem iniciou sessão através dela. Essa consola é a única forma de voltar a aceder ao servidor se o SSH deixar de funcionar. Descobrir que ela não funciona quando já está bloqueado é tarde demais.
• Não pode suportar uma hora de indisponibilidade e não tem rollback.
• A sua stack depende de um repositório de terceiros que ainda não publicou pacotes para resolute.
• O servidor foi configurado manualmente há mais de dois anos e ninguém sabe o que está instalado.

A alternativa é muitas vezes melhor: crie um VPS novo com 26.04, instale a sua stack e restaure os dados. Depois, altere o DNS quando o novo servidor responder corretamente. Mantenha o servidor antigo em funcionamento até o novo servidor estar validado. Assim, o rollback consiste numa alteração de DNS, e não numa restauração. Se escolher esta opção, comece por os primeiros dez minutos num VPS novo e configure corretamente o novo servidor.

Etapa 1: faça um backup que possa restaurar

Use duas camadas, porque elas falham de formas diferentes. Um snapshot do provedor abrange todo o disco e é restaurado em minutos, mas é criado enquanto as bases de dados estão a escrever. Por isso, é consistente com falhas, e não consistente com a aplicação. Um backup ao nível dos ficheiros com restic, armazenado fora do servidor fornece ficheiros individuais e uma cópia que permanece disponível mesmo que a sua conta seja bloqueada.

Faça primeiro os dumps das bases de dados manualmente. Um dump é o único backup de uma base de dados em que pode confiar sem a parar.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction fornece um dump consistente apenas para tabelas InnoDB. As tabelas MyISAM exigem que a base de dados seja parada. O tarball /etc é o que irá realmente utilizar, porque contém todos os ficheiros de configuração sobre os quais a atualização estará prestes a fazer perguntas.

Um backup que nunca foi restaurado é apenas uma suposição. Extraia agora um ficheiro dele, antes de precisar dele sob pressão.

Passo 2: aplique primeiro todas as atualizações da versão 24.04

do-release-upgrade recusa-se a executar num sistema com o estado dos pacotes danificado, e uma versão 24.04 parcialmente atualizada torna mais difícil interpretar todas as falhas posteriores.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

A ausência de saída de dpkg --audit significa que nenhum pacote está parcialmente configurado. A ausência de saída de apt-mark showhold significa que nenhum pacote está fixado numa versão que bloquearia a atualização. Remova cada retenção listada com sudo apt-mark unhold e o nome do pacote, ou aceite que a retenção existe por uma razão e pare aqui.

Reinicie se o kernel tiver sido alterado. Assim, a atualização é feita a partir de uma máquina que está a executar o código que considera estar a executar.

[ -f /var/run/reboot-required ] && sudo reboot

Depois, verifique o espaço em disco. O atualizador descarrega todo o conjunto de pacotes novos antes de instalar qualquer coisa e aborta com uma mensagem que identifica o sistema de ficheiros se não houver espaço suficiente.

df -h / /boot

É abaixo de cerca de 5 GB livres em / que este problema costuma ocorrer. Um /boot com menos de 300 MB livres falha mais tarde, durante a instalação do kernel, com No space left on device. Os kernels antigos são normalmente a causa, e sudo apt --purge autoremove remove-os.

Antes de começar, pare também uma atividade: se as atualizações automáticas de segurança forem executadas durante o processo, mantêm o bloqueio do dpkg e o atualizador da versão termina com Could not get lock /var/lib/dpkg/lock-frontend. Execute primeiro sudo systemctl stop unattended-upgrades e inicie novamente quando terminar.

Etapa 3: verificar repositórios de terceiros e pacotes fixados

do-release-upgrade desativa todas as fontes do apt que não pertencem ao Ubuntu, porque um pacote compilado para noble pode causar falhas num sistema resolute. Depois, reativa as fontes que reconhece e deixa as restantes comentadas. Saiba o que está instalado antes de deixar a ferramenta decidir por si.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

O Ubuntu 24.04 usa dois formatos nesse diretório: os ficheiros antigos de uma linha .list e os ficheiros deb822 .sources, com os campos Types: e Suites:. A atualização desativa ambos. ubuntu-security-status --thirdparty lista os pacotes instalados para os quais nenhum arquivo do Ubuntu fornece uma versão. Esse é o número real do que foi adicionado ao sistema. Tudo o que estiver em /etc/apt/preferences.d/ é um pin, e um pin escrito para noble continuará a selecionar um pacote antigo na nova release.

Para cada repositório de terceiros, confirme se o fornecedor publicou uma versão para o novo codename antes de começar. As suites do Docker estão listadas em https://download.docker.com/linux/ubuntu/dists/, e os outros fornecedores disponibilizam o mesmo diretório. Uma fonte apontada para uma suite inexistente produz esta mensagem no primeiro apt update depois da atualização:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Mantenha essa fonte desativada até o fornecedor publicar uma versão compatível. Alterar o codename para outro que o fornecedor tenha compilado faz com que sejam instalados pacotes ligados às bibliotecas de sistema erradas.

Passo 4: execute a atualização no tmux, não numa sessão SSH simples

Se a ligação cair enquanto do-release-upgrade é executado numa sessão de login simples, o processo recebe SIGHUP e termina a meio da extração dos pacotes. Isso deixa o dpkg parcialmente configurado e pode deixar o servidor sem uma pilha de rede funcional para restabelecer a ligação. Execute-o dentro de um multiplexador de terminal. Assim, o processo continua ativo no servidor quando o cliente se desconectar.

sudo apt install -y tmux
tmux new -s upgrade

Dentro dessa sessão:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

O atualizador inicia um segundo daemon SSH na porta 1022 antes de alterar qualquer coisa e informa-o:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Ele não abre essa porta na firewall, porque abrir uma porta sem pedir confirmação seria uma alteração inesperada. Abra a porta 1022 manualmente antes de começar e feche-a quando terminar sudo ufw delete allow 1022/tcp. Tenha em atenção que o fornecedor pode executar uma segunda firewall no respetivo painel de controlo, fora do servidor.

Se a ligação cair mesmo assim, volte a iniciar sessão e execute tmux attach -t upgrade. A atualização continuou a ser executada enquanto esteve desligado.

Etapa 5: responda deliberadamente aos prompts do ficheiro de configuração

O dpkg só solicita ficheiros que você ou um script alteraram. Portanto, cada prompt corresponde a um ficheiro que foi editado intencionalmente. Premir Enter para fazer o prompt desaparecer é uma forma de um servidor protegido voltar silenciosamente à configuração predefinida.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Prima D primeiro, sempre. Leia o que foi alterado e mantenha a sua versão com N. A predefinição já é N, que é a resposta segura, porque o seu ficheiro funciona atualmente e o ficheiro fornecido pelo pacote nunca foi executado nesta máquina.

Manter o seu ficheiro tem um custo: você não recebe as novas predefinições. Faça a reconciliação depois, quando o sistema estiver operacional e você não estiver sob pressão de tempo.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Cada ficheiro que lista corresponde à versão do responsável pela manutenção, guardada junto da sua versão. Compare os ficheiros individualmente e copie as definições importantes. Deve ter cuidado adicional com dois ficheiros: /etc/ssh/sshd_config, porque uma resposta incorreta termina a sua sessão, e a configuração do seu servidor web, porque uma resposta incorreta deixa os sites indisponíveis.

A atualização também pergunta quais serviços devem ser reiniciados, através de needrestart. Aceite a lista completa. Um daemon que continue a executar com base num ficheiro de biblioteca partilhada eliminado do disco pode falhar num pedido posterior, quando você não estiver a monitorizar o sistema.

Passo 6: reinicie e verifique a máquina

sudo reboot

Quando voltar a arrancar:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a deve indicar Release: 26.04 e Codename: resolute. uname -r deve apresentar um kernel 7.0. systemctl --failed deve listar zero unidades; qualquer unidade listada é a sua próxima tarefa. O apt update final obtém as atualizações publicadas desde que as imagens da versão foram construídas.

PostgreSQL 16 para 18: o cluster que fica para trás sem aviso

Ubuntu 24.04 inclui PostgreSQL 16 e 26.04 inclui PostgreSQL 18. A atualização instala a versão 18 ao lado da 16 e não move os seus dados. A camada postgresql-common do Debian cria um novo cluster vazio para a nova versão principal na porta livre seguinte. Assim, a versão 16 mantém a porta 5432 com todos os seus dados e a versão 18 fica vazia na porta 5433. A aplicação continua a ligar-se à porta 5432 e nada parece errado. Por isso, este problema costuma ser descoberto meses mais tarde.

pg_lsclusters

A presença de dois clusters significa que ainda não fez a migração. Faça-a quando puder parar a aplicação:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Remova primeiro o cluster vazio da versão 18, porque pg_upgradecluster não escreve num cluster de destino que já exista. O método predefinido faz um dump da versão 16 e carrega-o na versão 18. Por isso, precisa de espaço livre em disco aproximadamente igual ao tamanho da base de dados. -m upgrade usa pg_upgrade, que é muito mais rápido numa base de dados grande. Quando terminar, leia a coluna Port: o novo cluster passa a usar a porta 5432 e o antigo fica parado. Execute a análise manualmente, porque um cluster acabado de carregar não tem estatísticas e as primeiras consultas serão lentas.

Teste a aplicação com o novo cluster durante alguns dias. Só depois remova o antigo:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

O diretório de dados do cluster antigo é o rollback mais rápido disponível. Não o elimine no dia da atualização.

MySQL 8.0 para 8.4: a opção removida que impede o arranque do servidor

26.04 atualiza o MySQL de 8.0 para 8.4 LTS, e 2 alterações afetam alguns servidores.

Primeiro, mysqld recusa arrancar quando a configuração contém uma opção removida na nova versão. default_authentication_plugin é a mais comum, porque muitos guias antigos indicam que deve ser definida. O serviço falha, e journalctl -u mysql -n 50 identifica diretamente a variável desconhecida. Remova essa linha do ficheiro em /etc/mysql/mysql.conf.d/ e, em seguida, sudo systemctl start mysql.

Segundo, o plugin mysql_native_password deixou de estar ativado por predefinição no 8.4. Por isso, uma conta que ainda o utilize não consegue iniciar sessão. Verifique isto enquanto ainda estiver no 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Migre todas as contas que apresentem mysql_native_password antes da atualização. Depois, atualize a palavra-passe na configuração da aplicação:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Se uma biblioteca cliente for demasiado antiga para comunicar com caching_sha2_password, pode voltar a ativar o plugin antigo no 8.4 adicionando mysql_native_password=ON em [mysqld]. Use esta configuração apenas como solução temporária, com uma data para a remover, porque o plugin será completamente descontinuado.

PHP 8.3 para 8.5: os seus vhosts apontam para um socket que desapareceu

24.04 inclui PHP 8.3 e 26.04 inclui PHP 8.5. Os pacotes são instalados em caminhos específicos da versão e nada reescreve a configuração do servidor web. Um vhost do nginx que contém fastcgi_pass unix:/run/php/php8.3-fpm.sock; passa a apontar para um socket que nenhum processo cria. Por isso, todos os pedidos PHP devolvem 502 e o log de erros do nginx mostra:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Aponte-o para o novo socket, teste a configuração e recarregue o serviço:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

No Apache com mod_php, o sintoma é diferente: o Apache não arranca e sudo apache2ctl -t informa que não consegue carregar libphp8.3.so porque o ficheiro não existe. O módulo ativado é um symlink para um pacote que já não está instalado.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Se instalou o sistema seguindo uma stack LAMP no Ubuntu 24.04, vale a pena verificar ambos os caminhos. O guia deixa uma configuração com um nome de módulo específico da versão e um socket específico da versão.

A configuração de ajuste de desempenho em php.ini também não é transferida. memory_limit, upload_max_filesize e tudo o que definiu ficam em /etc/php/8.3/, e a nova árvore começa com os valores predefinidos. Compare os dois ficheiros e copie os valores manualmente. Copiar o ficheiro antigo completo para substituir o novo transfere os valores predefinidos de 8.3 para uma instalação 8.5. Em seguida, execute php -m e compare os resultados: uma extensão instalada como php8.3-redis precisa do pacote php8.5-. Se tiver vindo de um PPA, o atualizador desativou essa origem e a extensão simplesmente não está instalada.

Os certificados merecem uma verificação própria. Execute sudo certbot renew --dry-run depois da atualização. O comando testa todo o processo de renovação, incluindo o hook de recarregamento do servidor web, sem alterar o certificado em utilização. Se um hook chamar um nome de serviço ou um binário que mudou, a falha ocorre neste momento, de forma visível, em vez de ocorrer silenciosamente dentro de 60 dias. Certbot com Let's Encrypt no nginx explica como esses hooks devem ser configurados.

SSH: a falha que encerra a sessão em que está a trabalhar

O prompt sshd_config é onde as pessoas ficam sem acesso ao servidor. Responder Y instala o ficheiro do mantenedor e elimina o seu PermitRootLogin, PasswordAuthentication, AllowUsers, Port e todas as outras linhas que adicionou. Se a firewall permitir apenas uma porta personalizada e a configuração fornecida pelo pacote escutar na porta 22, a ligação seguinte será recusada. A sessão em que está será a última disponível.

Evite este problema antes de atualizar. O /etc/ssh/sshd_config no 24.04 começa com Include /etc/ssh/sshd_config.d/*.conf, e o OpenSSH mantém o primeiro valor que lê para cada definição. Por isso, um ficheiro adicional incluído no início prevalece sobre tudo o que vem depois. Mova as suas definições para um ficheiro que o dpkg não controle:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Quando nada em /etc/ssh/sshd_config for seu, esse prompt deixa de ser relevante: qualquer resposta mantém as suas definições, porque elas estão num ficheiro diferente.

Uma porta personalizada requer uma verificação adicional, porque pode não estar onde espera:

systemctl is-enabled ssh.socket

Se isso mostrar enabled, o systemd controla a porta de escuta e a linha Port em sshd_config é ignorada. O Ubuntu usa ativação por socket para o sshd desde a versão 22.10. É por isso que uma alteração em Port 2222 parece não produzir efeito. Defina-a na unidade de socket, com sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

O ListenStream= vazio é necessário. Ele limpa o valor herdado. Sem ele, o socket escuta na porta 22 e na porta 2222. Aplique a alteração com sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Depois da atualização, antes de fechar a sessão em que está:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Em seguida, abra um segundo terminal no seu próprio computador e inicie sessão novamente. Um shell funcional nesse segundo terminal é a única confirmação válida. Mantenha a primeira sessão aberta até confirmar isso. Hardening do SSH numa VPS explica as definições que vale a pena manter nesse ficheiro adicional.

Se já for demasiado tarde, a consola web do seu fornecedor fornece um login que não usa SSH. Inicie sessão nessa consola, corrija a configuração, execute sudo sshd -t e reinicie o serviço. Essa consola existe precisamente para testar o acesso antes de uma atualização, e não durante uma atualização.

FAQ

Por que do-release-upgrade apresenta "No new release found" no Ubuntu 24.04?

Porque /etc/update-manager/release-upgrades contém Prompt=lts no Ubuntu Server, e essa definição disponibiliza a próxima versão de suporte de longo prazo apenas depois de existir a sua primeira point release. O Ubuntu 26.04 LTS foi lançado em 23 April 2026, e a versão 26.04.1 está prevista para 27 August 2026. Até esse dia, um servidor 24.04 não encontra nenhuma versão nova. Mantenha essa definição, em vez de mudar para Prompt=normal, que encaminharia a atualização pelas versões intermédias.

Tenho de reiniciar o servidor para concluir a atualização?

Sim. A atualização instala um kernel novo, uma biblioteca C nova e um sistema init novo. O sistema em execução continua a utilizar as versões antigas até ser reiniciado. do-release-upgrade pede o reinício no fim, e uma máquina deixada em execução até "mais tarde" fica a utilizar uma combinação de duas versões. Depois de voltar a arrancar, verifique uname -r para confirmar o kernel novo e systemctl --failed para identificar os serviços que não arrancaram.

Devo atualizar no local ou criar um servidor 26.04 novo?

Crie um servidor novo quando possível. Um VPS novo permite instalar a stack, restaurar os dados e testar tudo enquanto o servidor antigo continua a servir tráfego. Assim, o rollback consiste numa alteração de DNS, e não numa restauração a partir de backup. Faça a atualização no local quando o servidor contiver dados de estado difíceis de mover, quando o fornecedor cobrar por máquina ou quando tiver um snapshot e acesso comprovado à consola. O processo de atualização no local é conhecido, mas é uma operação sem retorno durante a hora em que decorre.

O que acontece se a minha ligação SSH cair durante a atualização?

Numa sessão de login normal, o processo recebe SIGHUP e termina a meio, deixando o dpkg parcialmente configurado. Inicie-o dentro de tmux ou screen. Assim, o processo continua em execução, pode restabelecer a ligação e executar tmux attach -t upgrade para retomar a operação. O atualizador também inicia um daemon SSH adicional na porta 1022 como segunda forma de acesso, mas não abre essa porta na firewall. Por isso, permita 1022 primeiro e feche-a depois.

O meu site PHP devolve 502 depois da atualização. O que deixou de funcionar?

O caminho do socket PHP FPM mudou com a versão. O Ubuntu 24.04 executa PHP 8.3 e o 26.04 executa PHP 8.5. Por isso, /run/php/php8.3-fpm.sock já não existe, enquanto o seu virtual host do nginx ainda o referencia. O log de erros do nginx mostra connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Atualize fastcgi_pass para o socket da versão 8.5, execute sudo nginx -t e depois recarregue o nginx. No Apache com mod_php, a correção equivalente é executar sudo a2dismod php8.3, seguida de sudo a2enmod php8.5 e de um reinício.