Por quanto tempo o Fedora recebe atualizações?

Quanto tempo uma versão do Fedora recebe atualizações de segurança?

Um servidor Fedora precisa de uma atualização de versão aproximadamente uma vez por ano, enquanto a máquina existir. O Fedora lança uma nova versão aproximadamente a cada seis meses. Cada versão recebe suporte até cerca de quatro semanas depois do lançamento da versão duas gerações mais recente. Isso corresponde a cerca de 13 meses de atualizações. Depois dessa data, a versão deixa de receber correções de segurança. O servidor continua a funcionar, mas com um conjunto de pacotes que já não é atualizado.

As datas tornam isto concreto. Em agosto de 2026, as versões suportadas são Fedora 43 e Fedora 44. O Fedora 44 foi lançado em 28 de abril de 2026, e o fim do suporte está agendado para junho de 2027. O Fedora 42 foi lançado em abril de 2025 e chegou ao fim do suporte em maio de 2026, quatro semanas depois da chegada do Fedora 44. Por isso, um servidor criado a partir de uma imagem Fedora 42 ficou sem suporte treze meses depois, sem que ninguém tivesse feito nada errado.

Fedora em comparação com uma LTS, em meses

LTS significa suporte de longo prazo: uma versão que o fornecedor continua a corrigir durante anos, em vez de meses. EOL significa fim de vida: a data em que as correções deixam de ser disponibilizadas. Abaixo está o que cada projeto publica para a versão que instalaria hoje.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Cada versão do Fedora recebe 13 meses de suporte. Uma Ubuntu LTS recebe 60, e uma reconstrução empresarial, como a AlmaLinux, recebe 120. Leia a segunda coluna como o custo de manutenção. Ao longo de dez anos, o Fedora exige aproximadamente 10 atualizações de todo o sistema operativo, contra 2 na Ubuntu LTS. O valor de 36 meses do Debian corresponde ao seu suporte de segurança regular, e uma equipa LTS separada prolonga a maioria das versões para cerca de cinco anos.

Estas são janelas de suporte publicadas, verificadas em agosto de 2026, e não uma medição de disponibilidade. A razão das diferenças entre os ciclos é explicada em a diferença entre Ubuntu LTS e versões intermédias num servidor. O que importa aqui é o trabalho que cada opção cria para si.

O que uma atualização de versão do Fedora realmente envolve

O DNF 5 é o gestor de pacotes predefinido desde o Fedora 41, e dnf executa-o. O comando system-upgrade faz parte do próprio dnf5, portanto não é necessário instalar primeiro nenhum plugin. Comece pela versão atual, totalmente atualizada:

sudo dnf upgrade --refresh
sudo reboot

O reboot é importante porque a atualização é resolvida com base no que está instalado e em execução. Portanto, uma atualização do kernel ou da glibc aplicada apenas parcialmente torna o passo seguinte mais difícil de analisar. Agora prepare a nova versão. Substitua 44 pela versão para a qual pretende atualizar:

sudo dnf system-upgrade download --releasever=44

Este comando resolve toda a transação e descarrega todos os pacotes, mas não altera o sistema em execução. Num servidor pequeno, espere alguns milhares de pacotes e entre um e três gigabytes. Se o dnf não conseguir resolver a transação, para neste ponto e identifica o pacote que a bloqueou. Esse é o cenário preferível, porque a falha ocorre enquanto a máquina ainda está operacional e ainda tem uma shell.

Depois, execute-a:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status confirma que existe uma transação preparada e pendente. dnf system-upgrade reboot reinicia a máquina para uma transação offline: um boot mínimo no qual a transação RPM é executada isoladamente. Isto é necessário porque substituir a glibc e o systemd enquanto os serviços estão em execução pode deixar o sistema instalado apenas parcialmente. O servidor fica inacessível durante toda a transação, normalmente durante vários minutos num VPS pequeno, e depois reinicia novamente com a nova versão. Planeie dois reboots e um período durante o qual o SSH não responde.

Quando o servidor voltar:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release deverá apresentar uma linha semelhante a Fedora release 44 (Forty Four). O subcomando log mostra o log da transação desse boot offline. Este é o único registo do que aconteceu enquanto não tinha uma shell. distro-sync aplica à nova versão tudo o que tenha ficado pendente. repoquery --extras lista os pacotes instalados que já não existem em nenhum repositório ativado. É nesse resultado que encontra resíduos de um repositório que nunca publicou pacotes para a nova versão.

Crie um snapshot do disco antes do passo de download. A transação é executada sem que possa ver o ecrã. Se falhar durante o boot offline, o SSH não voltará a responder, e a única forma de acesso será através da consola disponibilizada pelo fornecedor, por VNC ou por serial. Confirme que tem acesso a uma consola ou a um snapshot antes de começar, e não depois.

Há mais uma verificação que é frequentemente ignorada:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Quando um pacote fornece um novo ficheiro de configuração predefinido e editou o ficheiro antigo, o RPM não substitui o seu ficheiro. Em vez disso, grava a versão fornecida pelo pacote ao lado dele como .rpmnew. Assim, o seu sshd ou nginx continua a comportar-se exatamente como na versão antiga, enquanto as novas predefinições permanecem no disco sem serem utilizadas. Leia esses ficheiros depois de cada atualização. Instalar rpmconf e executar sudo rpmconf -a percorre-os um a um e mostra as diferenças.

Os repositórios de terceiros são o que interrompe a atualização

Os pacotes do próprio Fedora são atualizados em conjunto no dia do lançamento. Os pacotes externos ao Fedora seguem o calendário dos respetivos fornecedores. A maioria dos repositórios dos fornecedores inclui $releasever no URL. Por isso, assim que atualiza, o dnf começa a procurar um caminho que pode ainda não existir.

Liste os repositórios configurados:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Para cada repositório que não pertença ao Fedora, teste-o com a versão de destino antes de iniciar a atualização:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Se o fornecedor já publicou pacotes para essa versão, o dnf descarrega os metadados e termina sem apresentar erros. Caso contrário, recebe um erro 404 para um caminho como https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, e a mesma falha interromperá mais tarde system-upgrade download. Nas primeiras semanas após uma versão do Fedora ser lançada, esta é a causa mais comum para uma atualização não iniciar.

Tem duas opções. Aguarde algumas semanas até o fornecedor publicar os pacotes, o que normalmente é a decisão correta. Ou atualize sem esse repositório:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Desativar um repositório não remove os respetivos pacotes. Eles permanecem instalados e sem gestão. Se bloquearem a transação, o dnf informa-o. Adicionar --allowerasing permite que o dnf remova pacotes instalados para resolver o conflito. Por isso, leia a lista de remoções antes de a aceitar. É nessa lista que algumas pessoas acabam por remover um servidor de bases de dados que pretendiam manter.

O que acontece a um servidor Fedora que perde a janela

Nada acontece no próprio dia. A falha surge na próxima vez que usar o gestor de pacotes. As versões em fim de vida são retiradas da rede de mirrors e movidas para o arquivo, por isso dnf upgrade falha ao obter os metadados, com um erro 404 no URL do metalink da sua versão:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

A máquina continua a servir tráfego, o que torna este problema silencioso e perigoso. Não recebe atualizações de segurança. Também não consegue instalar nada. Assim, no dia em que surgir um aviso de segurança para o OpenSSH ou o nginx, não terá uma forma suportada de aplicar a correção.

É possível recuperar, mas o processo é lento. Pode apontar os repositórios para o arquivo do Fedora em https://dl.fedoraproject.org/pub/archive/fedora/linux/ e atualizar a partir daí. O Fedora pressupõe um salto de uma ou duas versões de cada vez. Assim, uma máquina que esteja quatro versões atrasada exige vários saltos consecutivos. Cada salto tem a sua própria possibilidade de falhar e é executado sem visibilidade durante um arranque offline. Num VPS, recriar a máquina com uma imagem atual e transferir os dados é normalmente um trabalho mais curto e seguro. É o mesmo trabalho que os primeiros dez minutos num VPS novo.

As atualizações automáticas aplicam correções a uma release. Nunca fazem o upgrade dela.

O Fedora pode instalar as atualizações segundo um temporizador:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

As definições ficam em /etc/dnf/automatic.conf, que substitui os valores predefinidos fornecidos em /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates está desativado por predefinição. Por isso, numa instalação sem alterações, o temporizador descarrega as atualizações, mas não instala nenhuma. upgrade_type escolhe entre default e security. reboot aceita never, when-changed ou when-needed.

Isto mantém o sistema atualizado dentro de uma release. Nunca fará o Fedora 43 passar para o Fedora 44, porque um upgrade de versão é uma operação separada e deliberada que reinicia o sistema para executar uma transação offline. Essa é a diferença prática em relação a uma LTS. No Ubuntu, as atualizações de segurança não assistidas mantêm uma máquina atualizada durante todo o período de cinco anos sem qualquer alteração de versão, e a alteração de versão é uma tarefa planeada, como o upgrade de 24.04 para 26.04, feita uma vez a cada poucos anos.

Quando o Fedora é a escolha certa para um servidor

O Fedora é uma boa escolha quando a novidade é o objetivo.

• Precisa de um kernel ou de um userspace mais recente do que qualquer LTS disponibiliza: hardware recente ou uma stack de contentores e systemd que ainda está a um ano de uma versão empresarial. O Fedora também passa para novos kernels upstream durante o ciclo de uma versão, por isso esta vantagem não ocorre apenas uma vez, no momento da instalação.
• Está a validar o que está a caminho do RHEL (Red Hat Enterprise Linux). O Fedora alimenta o CentOS Stream, que alimenta o RHEL, por isso o software que compila e funciona hoje no Fedora está a ser testado contra a plataforma empresarial de daqui a alguns anos.
• A máquina foi concebida para ter uma vida curta. Um build runner ou uma máquina de testes que é destruída ao fim de dois meses nunca chega à data de fim de vida. A mesma lógica aplica-se às VMs descartáveis que entrega a agentes de programação, em que a máquina é reconstruída com muito mais frequência do que as versões do Fedora.
• Alguém é responsável pela atualização. O Fedora funciona bem num servidor com um responsável identificado e uma entrada no calendário. É uma má escolha para a máquina de que todos se esqueceram.

O caminho intermédio: pacotes atuais numa base estável

A maioria das pessoas que quer Fedora num servidor precisa de dois ou três pacotes atuais, não de um sistema operativo atual. São necessidades separáveis. Use uma distribuição LTS ou uma reconstrução de uma distribuição empresarial como base e instale o software mais recente apenas onde for necessário. Uma imagem de contentor fornece a versão mais recente da aplicação num host que não precisa de ser atualizado por causa dela (executar Docker numa VPS). Um repositório do fornecedor para o pacote específico de que precisa, como PostgreSQL ou nginx, atualiza apenas esse componente e mantém a base inalterada.

A troca é clara nos dois sentidos. Um contentor fornece um userspace novo sobre o kernel antigo do host. Por isso, não resolve o problema quando o kernel é o componente que precisa de ser atualizado. Um repositório do fornecedor fornece um pacote novo numa base que o fornecedor testou menos. Em ambos os casos, as atualizações de segurança do sistema base continuam a seguir o ciclo da distribuição LTS. No Fedora, esse ciclo é o que exige uma janela de manutenção todos os anos.

Se escolher Fedora para um servidor, coloque o ciclo de atualizações no calendário. Quando uma versão for lançada, aguarde algumas semanas para que os repositórios dos fornecedores acompanhem a nova versão. Crie um snapshot, faça a atualização e confirme que os serviços voltaram a iniciar. Esse processo demora cerca de uma hora por ano e funciona. O processo que falha é aquele em que a atualização só é lembrada depois de algo já ter deixado de funcionar.

FAQ

Durante quanto tempo uma versão do Fedora recebe suporte?

Cerca de 13 meses. O Fedora publica uma versão aproximadamente a cada seis meses e mantém o suporte de cada uma até cerca de quatro semanas depois do lançamento da versão duas posições mais recente. O Fedora 44 foi lançado em 28 April 2026, com o fim de vida previsto para June 2027. Quando essa data chega, a versão deixa de receber atualizações de segurança e os respetivos pacotes são retirados dos mirrors e movidos para o arquivo do Fedora.

Posso ignorar uma versão do Fedora e atualizar duas versões de uma vez?

Sim, dentro de certos limites. dnf system-upgrade download --releasever= aceita como destino uma ou duas versões posteriores, e saltar duas versões de cada vez é precisamente o funcionamento de um ciclo de atualização anual. Ir além disso não é um caminho suportado, e cada versão adicional aumenta a probabilidade de uma alteração do nome de um pacote ou do formato de configuração interromper a transação. Se uma máquina já estiver várias versões atrasada e ultrapassar o fim de vida, normalmente é mais rápido recriá-la com uma imagem atual do que fazer uma sequência de atualizações.

O que acontece se o meu servidor Fedora chegar ao fim de vida?

Continua a funcionar, mas deixa de receber correções. O próximo dnf upgrade falha com um 404 no URL do metalink da sua versão, porque as versões que chegaram ao fim de vida são movidas para o arquivo em dl.fedoraproject.org. Pode redirecionar os ficheiros dos repositórios para esse arquivo e atualizar por etapas, ou recriar o servidor com uma versão suportada. Até fazer uma destas duas coisas, nenhuma atualização de segurança pode chegar à máquina e nenhum pacote será instalado.

O Fedora é uma má escolha para um servidor de produção?

É uma má escolha como padrão, mas uma escolha razoável quando existe um motivo. O custo é fazer uma atualização completa do sistema operativo todos os anos, indefinidamente, numa máquina que pode preferir não alterar. Escolha o Fedora quando precisar de um kernel ou de um userspace mais recente do que o fornecido por uma versão LTS, ou quando o servidor for concebido para ter uma vida curta. Escolha uma versão LTS ou uma reconstrução empresarial quando quiser corrigir um servidor durante anos sem alterar a sua versão.