Como atualizar o Ubuntu 24.04 para 26.04 em um VPS

Quando você poderá atualizar o Ubuntu 24.04 para o 26.04?

Você poderá atualizar o Ubuntu 24.04 para o 26.04 em um VPS quando a versão pontual 26.04.1 for lançada, prevista para 27 August 2026. Até lá, um servidor 24.04 não verá a nova versão, por design. 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 reúne as correções para problemas de instalação e atualização encontrados nos primeiros meses. Se essa numeração for nova para você, 26.04.1 não é uma versão diferente do Ubuntu, mas o mesmo 26.04 com quatro meses de correções incorporadas à mídia, e é exatamente por isso que ela é a primeira versão que a Canonical disponibiliza para um servidor existente.

Execute a verificação em um servidor 24.04 no início de August 2026 e você verá isto:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Isso não indica um problema no seu servidor. /etc/update-manager/release-upgrades contém Prompt=lts no Ubuntu Server, o que significa que a ferramenta oferece apenas a próxima versão de suporte de longo prazo, e somente quando a versão pontual .1 existir. Definir Prompt=normal faria a ferramenta conduzir você por 24.10, 25.04 e 25.10, nessa ordem; todas são versões intermediárias que já chegaram ao fim da vida útil. Mantenha lts e aguarde. As datas do calendário da Canonical podem mudar, portanto verifique novamente se o dia passar sem que a atualização seja disponibilizada.

Cada comando abaixo deve ser executado por você, no seu próprio servidor, na ordem apresentada. Não é possível ensaiar uma atualização de versão na máquina que está sendo atualizada. Ela substitui o kernel e a biblioteca C, e precisa de uma reinicialização para ser concluída.

Deve mesmo atualizar?

O Ubuntu 24.04 recebe atualizações de segurança padrão até 2029, portanto um servidor de produção funcional não está sujeito a nenhum prazo. Atualize porque precisa de algo que o 26.04 oferece: 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 atende clientes.

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

• Nunca abriu a consola do seu provedor (VNC ou serial) nem iniciou sessão através dela. Essa consola é a única forma de recuperar o acesso ao servidor se o SSH falhar. Descobrir que ela não funciona depois de ficar 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 nele.

A alternativa costuma ser melhor: crie um VPS 26.04 novo, 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 comprovar que está operacional. Assim, o rollback é uma alteração de DNS, e não uma restauração. Se seguir esse caminho, comece por os primeiros dez minutos num VPS novo e configure corretamente o novo servidor.

Passo 1: faça um backup que possa restaurar

Use duas camadas, porque elas falham de formas diferentes. Um snapshot do provedor cobre o disco inteiro e é restaurado em minutos, mas é criado enquanto as bases de dados estão a gravar. 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 um dump manual das bases de dados. 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 é aquele que irá realmente utilizar, porque contém todos os ficheiros de configuração sobre os quais a atualização está 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.

Etapa 2: corrija completamente a 24.04 primeiro

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

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

dpkg --audit sem saída significa que nenhum pacote está parcialmente configurado. apt-mark showhold sem saída significa que nenhum pacote está fixado numa versão que impediria a atualização. Liberte cada pacote listado 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 mudado, para fazer a atualização 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 novo conjunto de pacotes 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

É com menos de cerca de 5 GB livres em / que isto costuma falhar. Um /boot com menos de 300 MB 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.

Há mais uma coisa que deve parar antes de começar: 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-o novamente quando terminar.

Etapa 3: verifique 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 quebrar um sistema resolute. Depois, reativa as fontes que reconhece e deixa as restantes comentadas. Saiba o que está a manter 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 .list de uma só linha e os ficheiros .sources deb822 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 pacotes. Esta é a contagem real do que foi adicionado manualmente. Tudo o que estiver em /etc/apt/preferences.d/ é uma regra de prioridade, e uma regra escrita para noble continuará a selecionar um pacote antigo na nova versão.

Para cada repositório de terceiros, confirme que 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 expõem o mesmo diretório. Uma fonte apontada para uma suite inexistente produz esta mensagem no primeiro apt update após a 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 para o qual o fornecedor tenha compilado pacotes é uma forma de instalar 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 shell de login simples, o processo recebe SIGHUP e termina a meio da descompactação. Isso deixa o dpkg parcialmente configurado e pode deixar o servidor sem uma pilha de rede funcional para permitir uma nova ligação. Execute-o dentro de um multiplexador de terminal. Assim, o processo continua ativo no servidor quando o cliente se desconecta.

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 confirmação seria uma alteração inesperada. Abra a porta 1022 manualmente antes de iniciar e feche-a quando terminar o sudo ufw delete allow 1022/tcp. Lembre-se de que o fornecedor pode executar uma segunda firewall no respetivo painel de controlo, fora do servidor.

Se a ligação cair na mesma, volte a iniciar sessão e execute tmux attach -t upgrade. A atualização continuou enquanto esteve ausente. Se isso não aconteceu e encontrar o dpkg parcialmente configurado ou as fontes do apt com partes em noble e partes em resolute, a recuperação de uma atualização de versão falhada explica como reparar o estado dos pacotes e saber quando deixar de reparar e restaurar o snapshot.

Passo 5: responda deliberadamente aos pedidos sobre ficheiros de configuração

O dpkg só pede uma decisão para ficheiros que você ou um script alteraram. Cada pedido corresponde, portanto, a um ficheiro que editou de propósito. Premir Enter para fazer o pedido desaparecer é a 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 mudou e mantenha depois 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: não recebe as novas predefinições. Faça a reconciliação depois, quando o sistema já estiver operacional e não estiver sob pressão de tempo.

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

Cada ficheiro listado corresponde à versão do maintainer, guardada junto da sua versão. Compare-os individualmente e copie as definições importantes. Deve ter cuidado adicional com dois ficheiros: /etc/ssh/sshd_config, porque uma resposta errada termina a sua sessão, e a configuração do servidor web, porque uma resposta errada interrompe os sites.

A atualização também pergunta que 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 que foi eliminado do disco pode falhar num pedido posterior, num momento em que não está a monitorizar o sistema.

Etapa 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 finaliza a instalação das atualizações publicadas desde que as imagens da versão foram compiladas.

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

Ubuntu 24.04 fornece PostgreSQL 16 e 26.04 fornece PostgreSQL 18. A atualização instala o 18 ao lado do 16, mas não move os seus dados. A camada postgresql-common do Debian cria um novo cluster vazio para a nova versão principal na próxima porta livre. Assim, o 16 continua a usar a porta 5432 com todos os seus dados, enquanto o 18 fica vazio na porta 5433. A sua aplicação continua a comunicar com a porta 5432 e nada parece errado. Por isso, muitas pessoas só descobrem o problema meses depois.

pg_lsclusters

Se aparecem dois clusters na lista, a migração ainda não foi feita. 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 18 vazio, porque pg_upgradecluster não escreve num cluster de destino que já exista. O método predefinido exporta o 16 e carrega os dados no 18. Por isso, precisa de espaço livre em disco aproximadamente igual ao tamanho da base de dados. -m upgrade usa pg_upgrade em vez disso e é muito mais rápido numa base de dados grande. Quando terminar, consulte a coluna Port: o novo cluster assume a porta 5432 e o antigo fica parado. Execute a análise manualmente, porque um cluster carregado recentemente 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 servidor de iniciar

26.04 atualiza o MySQL da versão 8.0 para a 8.4 LTS, e duas alterações afetam os servidores.

Primeiro, mysqld recusa-se a iniciar quando a configuração contém uma opção removida na nova versão. default_authentication_plugin é a opção 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 já não fica ativado por predefinição na versão 8.4. Por isso, uma conta que ainda o utilize não consegue iniciar sessão. Verifique isto enquanto ainda estiver na versão 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 reativar o plugin antigo na versão 8.4 adicionando mysql_native_password=ON em [mysqld]. Considere isto uma solução temporária com uma data de remoção definida, 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 versionados e nada reescreve a configuração do seu 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 apresenta:

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 faça reload:

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 inicia 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á foi removido.

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

Se instalou o servidor seguindo uma stack LAMP no Ubuntu 24.04, vale a pena verificar ambos os caminhos, porque o guia deixa um nome de módulo versionado e um socket versionado.

As definições de ajuste de php.ini também não são preservadas. memory_limit, upload_max_filesize e tudo o que definir estão 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 inteiro para o novo transporta os valores predefinidos do 8.3 para uma instalação do 8.5. Em seguida, execute php -m e compare: uma extensão instalada como php8.3-redis precisa do pacote php8.5- e, se tiver vindo de um PPA, o atualizador desativou essa origem e a extensão simplesmente não está instalada.

Os certificados exigem uma verificação própria. Execute sudo certbot renew --dry-run depois da atualização. Isto testa todo o processo de renovação, incluindo o hook de reload do servidor web, sem alterar o certificado em produção. Um hook que chama um nome de serviço ou um binário que mudou falha aqui, à sua frente, em vez de falhar silenciosamente daqui a 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 maintainer 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 instalada pelo pacote escutar na porta 22, a próxima ligação será recusada, e a sessão que tem aberta será a última disponível.

Evite isto 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 aparece abaixo. Mova as suas definições para um ficheiro que o dpkg não controla:

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 já não houver nada seu em /etc/ssh/sshd_config, esse prompt deixa de ser relevante: qualquer resposta mantém as suas definições, porque estão num ficheiro diferente.

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

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 utiliza ativação por socket para o sshd desde o 22.10, e é por isso que uma alteração em Port 2222 parece não produzir efeito. Defina-a diretamente na unidade socket, com sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

O ListenStream= vazio é obrigatório. Ele limpa o valor herdado. Sem ele, o socket escuta na porta 22 e também na 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 volte a iniciar sessão. Um shell funcional nesse segundo terminal é a única confirmação válida. Mantenha a primeira sessão aberta até conseguir isso. Reforçar a segurança do SSH num VPS apresenta as definições que vale a pena manter nesse ficheiro adicional.

Se já for tarde demais, a consola Web do seu fornecedor permite iniciar sessão sem utilizar SSH. Inicie sessão nessa consola, corrija a configuração, execute sudo sshd -t e reinicie o serviço. Essa consola existe precisamente para que teste o acesso a ela antes de uma atualização, e não durante a 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 configuração só oferece a próxima versão LTS 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é essa data, um servidor 24.04 não encontra nenhuma versão nova. Mantenha essa configuração em vez de mudar para Prompt=normal, que encaminharia a atualização pelas versões intermédias.

Preciso 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 usar as versões antigas até ser reiniciado. do-release-upgrade pede o reinício no final, e uma máquina mantida em execução até "mais tarde" fica a usar uma combinação de duas versões. Depois de o servidor voltar, verifique uname -r para confirmar o kernel novo e systemctl --failed para identificar os serviços que não reiniciaram corretamente.

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 armazenar estado difícil de migrar, 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 durante a hora em que decorre não permite voltar atrás facilmente.

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

Numa shell de login normal, o processo recebe SIGHUP e termina a meio da execução. Isso deixa o dpkg parcialmente configurado. Inicie o processo dentro de tmux ou screen para que ele continue em execução. Depois, volte a ligar-se e execute tmux attach -t upgrade para retomar a atualização. O atualizador também inicia um daemon SSH adicional na porta 1022 como alternativa de acesso. No entanto, não abre essa porta na firewall. Permita a porta 1022 primeiro e feche-a depois.

O meu site PHP devolve 502 depois da atualização. O que falhou?

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 vhost 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 faça reload do nginx. No Apache com mod_php, a correção equivalente é executar sudo a2dismod php8.3, seguido de sudo a2enmod php8.5 e de um reinício.