“Actualizar o Linux” tem dois níveis com riscos muito diferentes: o update de pacotes (aplica melhorias e correcções de segurança dentro da mesma versão da distribuição — rotina, quase sem risco) e o upgrade de versão (salta para a distribuição seguinte — um processo de migração com passos próprios, que se planeia). Neste artigo ficam os dois: o ciclo diário nos gestores de pacotes mais usados (apt, dnf, zypper e pacman), a automatização de segurança nos servidores, e o salto de versão em Debian, Ubuntu e Fedora, com as ordens certas e os erros a evitar.

💡 A regra das duas filas

Actualizações de segurança: frequentes e automatizadas. Mudanças de versão (distro upgrade): planeadas — com cópia de segurança e leitura das release notes antes. Misturar os dois é onde os sysadmins se queimam.

Neste artigo

1. O vocabulário

Actualizar o índice (apt update, zypper refresh ou dnf check-update) só lê os repositórios e actualiza a lista do que existe — não instala nada. Aplicar updates (apt upgrade, dnf upgrade, zypper update, pacman -Syu) descarrega e instala as novas versões dos pacotes que já tens. E upgrade de versão é outra coisa toda: apontar a máquina a um novo “codename” da distribuição (Debian 12 “bookworm” → 13 “trixie”, Ubuntu 24.04 LTS → 26.04 LTS, Fedora 43 → 44) e migrar milhares de pacotes ao mesmo tempo. É o upgrade de versão que assusta — o resto deve ser tão banal como escovar os dentes.

Distro Gestor Actualizar Aplicar
Debian / Ubuntu apt apt update apt upgrade / full-upgrade
Fedora / RHEL dnf dnf check-update dnf upgrade
openSUSE zypper zypper refresh zypper update
Arch pacman (combinado) pacman -Syu

2. Debian e Ubuntu com apt

O ciclo padrão em qualquer servidor Debian/Ubuntu:

sudo apt update
sudo apt upgrade

o apt update lê os repositórios — se um mirror de terceiros estiver com erros de chave (NO_PUBKEY) aparece aqui, não na instalação. Para ver o que há sem instalar:

apt list --upgradable
# nginx/stable 1.26.4-1 amd64 [atualizável de: 1.26.3-1]
# openssl/stable-security 3.5.2-2 amd64 [atualizável de: 3.5.1-1]

A diferença entre upgrade e full-upgrade: o primeiro nunca remove pacotes — se um update exigir instalar/remover (mudanças de dependências), fica “prendido até ao próximo”; o full-upgrade (o dist-upgrade antigo, ainda válido) resolve essas trocas. Em máquinas onde os pacotes são críticos, corre apt full-upgrade de vez em quando e lê a lista “Removidos” — é aí que se apanham surpresas. No fim, limpa:

sudo apt autoremove --purge
sudo apt clean

Dois hábitos úteis: o apt-mark hold pacote “trava” um pacote (apt-mark unhold liberta) — útil quando um vendor desaconselha o update de um daemon até ao fim de uma janela de manutenção; e o /var/run/reboot-required — se o ficheiro existir depois dos updates, há bibliotecas ou o kernel em uso que mudaram e a máquina precisa de reboot:

ls /var/run/reboot-required && echo — reboot pendente
cat /var/run/reboot-required
# *** System restart required ***
cat /var/run/reboot-required.pkgs
# linux-image-generic
# openssl

⚠️ Histórico que vale ouro

Os logs de apt em /var/log/apt/history.log registam quem correu cada acção, quando e o que mudou — é o primeiro sítio onde se vai quando “deixou de funcionar há dois dias”. O /var/log/unattended-upgrades/ tem o paralelo do que correu sozinho.

3. Updates de segurança automáticos

Nos servidores, o objectivo é simples: as correcções de segurança aplicam-se sozinhas, o resto fica sob controlo humano. Em Debian/Ubuntu o pacote é o unattended-upgrades: no Debian está instalado por omissão na maioria das instalações actuais:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

O motor é o unattended-upgrade(8) — corre como backend da opção APT::Periodic::Unattended-Upgrade, agendado pelo systemd através do apt-daily-upgrade.timer (por omissão à noite). Os dois ficheiros de configuração que interessa conhecer:

# /etc/apt/apt.conf.d/20auto-upgrades — o agendamento
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

# /etc/apt/apt.conf.d/50unattended-upgrades — o que aplica
Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
};

O ficheiro distribuído por omissão não traz apenas a origem -security: inclui o pocket base e, no Ubuntu, também pode estar activo o -updates (confirma no teu 50unattended-upgrades). Para a política security-only deixa nessa lista só a origem -security — segurança sem ruído, com os updates de “normal” a aplicarem-se quando escolheres. Notas práticas: o mail com o resumo activa-se com Unattended-Upgrade::Mail (precisa de um MTA local ou sendmail configurado); um pacote pode ficar excluído com Unattended-Upgrade::Package-Blocklist; e antes de confiar, simula:

sudo unattended-upgrade --dry-run -d | grep -E 'Allowed|Would|Not allowed'

No Fedora/RHEL o papel do unattended-upgrades é assumido pelo dnf-automatic (pacote) — o upgrade_type = security aplica só as de segurança; no openSUSE/zypper o comando zypper patch tem a mesma função. Nota em todos: um update que mude o kernel ou glibc fica instalado mas “em uso” até ao reboot — repara no “reboot-required” (Debian/Ubuntu) ou no dnf “needs-restarting” (Fedora/RHEL, dnf needs-restarting -r).

4. Fedora e derivadas com dnf

O dnf (a versão moderna, dnf5, já instalada de fábrica nas versões recentes) segue a mesma lógica:

sudo dnf upgrade --refresh

A opção --refresh força a leitura dos metadados (no Fedora os metadados dos repos de updates expiram ao fim de 6 horas — metadata_expire=6h — por isso o update “sozinho” pode não ver os últimos). O dnf guarda histórico transaccional que é o seu melhor argumento:

dnf history
# ID     Comando        Data/Hora            Acções   Alterados
# 1203    upgrade        08-10-2026 09:14:21  Update  84
dnf history info 1203          # detalhe da transacção
dnf history undo 1203          # desfaz a transacção inteira

O history undo permite reverter uma actualização que partiu aplicações, sem restaurar backup. Para updates só de segurança no Fedora: dnf upgrade --security. No Workstation, o GNOME Software aplica os updates gráficos e prepara o reboot (aplica depois do reboot — “offline” também); nos servidores, dnf-automatic é o caminho (secção anterior). Limpeza: dnf autoremove e dnf clean all.

5. openSUSE, Arch e outros

openSUSE (zypper): zypper refresh + zypper update; patches de segurança concentram-se em zypper patch, que distingue patch (correcções oficiais da SUSE) de update (novas versões de pacote). O YaST/Software Management dá a mesma visibilidade gráfica e o histórico de patch fica em /var/log/zypp/history.

Arch (pacman): sudo pacman -Syu — sincroniza e actualiza numa só transacção. O que nunca se faz em Arch: pacman -Sy pacote (actualiza o índice e instala UM pacote só) — é o clássico “partial upgrade breakage” porque o pacote novo pode ficar com dependências dos pacotes antigos; em rolling release, tudo actualiza junto, sempre. O Arch Wiki (Pacman/Upgrading packages) tem a regra ao detalhe. No dia-a-dia é uma operação rápida: paccache -rk1 limpa versões antigas em /var/cache/pacman/pkg/.

6. Flatpak e Snap

Nas distribuições actuais há uma terceira fila: as aplicações em formato “sandbox”. Flatpak: flatpak update (ou o GUI do GNOME Software); Snap: snap refresh — o snapd já corre um timer (refresh.timer, 4× ao dia), por isso os snaps actualizam-se sozinhos — coisa que surpreende quem vem de outra distro. Se queres controlo: snap refresh --hold="24h". O flatpak update mostra o que há antes de aplicar. A regra: os gestores nativos NÃO actualizam flatpaks/snaps — a actualização destes É outro ciclo: se o esqueceres, os updates de sistema não apanham o browser nem as aplicações modernas.

7. Upgrade de versão da distro

Aqui a preparação muda de patamar: cópia de segurança completa + snapshot LVM (lvcreate -s) ou Timeshift (ou clone do disco com Clonezilla), a leitura das release notes da versão destino, e o calendário de suporte — o momento certo é ANTES do End of Life, não depois. Referência de calendários: Debian 13 “trixie” (lançado a 9/08/2025, 13.7 actual de 12/09/2026) tem 3 anos de suporte total até 9/08/2028 e LTS até 30/06/2030; Ubuntu 26.04 LTS (actualmente 26.04.1) tem 5 anos de suporte de base, até Maio de 2031; Fedora tem ~13 meses por versão — a 44 é a actual, a 45 sai a 20/10/2026, e a EOL de cada versão chega um mês depois da N+2 sair.

⚠️ Nunca saltes versões (a regra é distro a distro)

Debian actualiza-se um major de cada vez (de “bookworm” a “trixie” directamente), só via release notes oficiais. Fedora aceita no máximo saltar 2 releases (42 → 44). Ubuntu LTS → LTS (cada 2 anos), não interim. “Forky” é o Debian 14 (2027), não um salto de Debian 12 direitamente.

7.1 Debian: de “bookworm” a “trixie”

Pelas release notes do Debian, a sequência tem três fases — e a ordem importa:

sudo apt update
sudo apt upgrade

Fase 1 (acima): actualizar todos os pacotes dentro da versão actual, sem tocar nas fontes. Fase 2 — trocas as fontes: em /etc/apt/sources.list e nos ficheiros de /etc/apt/sources.list.d/, substitui "bookworm" por "trixie" (e "bookworm-security" por "trixie-security"); os repos de terceiros sem pacotes para "trixie" desactiva-os e religa-os depois. O apt modernize-sources aproveita para converter os sources ao formato deb822 actual:

sudo apt update
sudo apt upgrade --without-new-pkgs
sudo apt full-upgrade
sudo apt autoremove

Fase 3 (acima): a migração em si — o --without-new-pkgs apanha tudo o que actualiza sem instalar/remover novos; o full-upgrade final conclui as trocas de dependências. No fim: reboot e a leitura que as release notes exigem — o capítulo 4 explica o que muda nas configs da versão.

7.2 Ubuntu: do-release-upgrade

O Ubuntu embarca uma ferramenta própria, o do-release-upgrade — que já faz os checks de disponibilidade (só aparece quando a .1 da versão LTS está release, os caminhos de upgrade e o mirror válido):

sudo apt update
sudo apt upgrade
sudo do-release-upgrade

No Desktop, a mesma coisa é o Update Manager (Gráfico, menu “Actualizar para 26.04 LTS”). Se o prompt não aparece (o caso comum: ainda não saiu a .1 ou o update-manager-core não está instalado — do-release-upgrade -d aponta para a versão em desenvolvimento (nada para produção).

7.3 Fedora: dnf system-upgrade

O Fedora tem o processo mais “engenhoso”: descarrega tudo no sistema activo e o reboot entra num ambiente offline exclusivo para aplicar:

sudo dnf upgrade --refresh
sudo dnf system-upgrade download --releasever=44
sudo dnf offline reboot          # DNF5 — em DNF4 (≤Fedora 40): system-upgrade reboot

Depois do upgrade, os conflitos de configuração ficam marcados como .rpmnew/.rpmsave — o rpmconf -a (dnf install rpmconf) pergunta um a um; e o GRUB em sistemas BIOS não se actualiza sozinho entre versões (a quick-doc da Fedora indica o passo). Se algum passo recusar por dependências, o --allowerasing decide (mas lê a lista de remoção antes de aceitar!).

7.4 openSUSE e rollings

No openSUSE Leap o caminho de upgrade de versão usa o caminho oficial de migração (e na 16.0 há um processo de migração documentado no portal da versão); nos rollings do Arch não existe “upgrade de versão” — a distro flutua, e o -Syu diário É o upgrade de versão. É a abordagem mais simples conceptualmente e, ao mesmo tempo, a que exige a disciplina de actualizar em intervalos curtos.

8. Quando fazer o upgrade

  • No desktop: a partir da .1 da versão (2-3 meses após o GA — a 26.04.1, de 29/09/2026, abriu a via a partir da 24.04 LTS). Nos servidores: quando os pacotes críticos estiverem avaliados pelas aplicações que dependem deles — em produção, o esforço está na janela de manutenção, não no update em si.
  • Antes do EOL não há escolha: passado o Fim de Vida deixam de existir correcções de segurança e os repositórios ficam congelados. O ideal é actualizar 2-3 meses após o lançamento, quando os bugs do upgrade já foram apanhados pelos que foram à frente.

O ritual que evita dores: cópia de segurança + snapshot (Timeshift no desktop, um clone do disco ou o resto que quiseres — o site tem o material de backup: restic, Borg, rsync), ler as notas de versão (o Debian, com as release notes em PT, explica cada mudança que parte configs; o Fedora, com as notas na docs), e testar a aplicação crítica num clone se houver “ferramenta de negócio” instalada — o custo de 2 horas é inferior ao de um servidor de produção às cegas.

9. Erros comuns

  • Repositórios third-party (PPAs, COPR, OBS) ignorados no upgrade — ao subir de versão, os repositórios terceiros ficam apontados ao codename antigo; desactiva todos, sobe o básico, e reactiva só os que houver na versão nova (o Debian avisa os “não autênticos”; o Fedora os COPR não têm pacote para a nova versão).
  • Reboot ignorado — os updates aplicam-se ao disco, mas o processo que corre continua a carregar a versão antiga; o /var/run/reboot-required e o dnf needs-restarting existem para isto: verificar depois de cada ronda, agendar reboot em manutenção
  • Automático “em tudo” — unattended-upgrades sem limites (Origins mal configurados) numa máquina de produção pode aplicar o update de um motor de aplicações numa segunda-feira sem ninguém à vista; o padrão é: security-only por omissão + o resto humano.
  • Interrupção de dnf system-upgrade — a fase offline arranca no reboot e não deve ser interrompida: é o caso clássico de quem o corre num desktop sem bateria — UPS ligado, sempre.
  • Disco cheio no download do upgrade — o Fedora descarrega TUDO antes de aplicar (vários GB); o apt full-upgrade também pode precisar de espaço; check df -h / e limpeza antes.
  • Sem ler o “Removidos” — o apt/dnf mostram a lista de remoções ANTES de confirmar: um sysadmin distraído aceita a remoção de um meta-pacote crítico e o servidor perde funcionalidades essenciais. Lê sempre a lista de remoção.

Veredicto

O ritmo certo para um ambiente profissional: segurança automatizada (unattended-upgrades/dnf-automatic no ciclo noturno, security-only, com mail de alterações e reboot check) e updates manuais frequentes (semanal), com o upgrade de versão a correr numa janela planeada com backup/snapshot, notas de versão lidas e o calendário de EOL sempre à vista — nunca passando o limite de saltos da própria distro (Debian: um major; Ubuntu: LTS a LTS; Fedora: até 2 releases). É um ciclo que se automatiza quase todo — e é um dos motivos para o Linux ser o Sistema Operativo mais tranquilo de manter a longo prazo.

Artigos Relacionados

Fontes Oficiais