Se você administra servidor há tempo suficiente, sabe que algumas mudanças chegam como “patch de terça-feira” e outras chegam como reforma estrutural. Rocky Linux 10.1 é da segunda categoria. Ele não está só polindo o que já existia no EL8/EL9, ele está trocando a fiação inteira da casa, arrancando o encanamento antigo e jogando fora aquele armário cheio de coisas “que um dia podem ser úteis”. A mensagem é direta: o futuro é o padrão, e o passado virou exceção.
A boa notícia é que isso deixa o sistema mais consistente, mais seguro e mais alinhado com o que o ecossistema RHEL-based está virando na prática. A má notícia, para quem ainda vive de runbook velho e hardware veterano, é que alguns hábitos simplesmente não sobrevivem ao Rocky Linux 10.1.
O fim do hardware legado: x86-64-v3 vira a linha de corte
A ruptura mais “tectônica” começa no chão, literalmente, no CPU. No x86_64, o Rocky Linux 10 (e por consequência o 10.1) passa a exigir x86-64-v3 como base. Traduzindo para o idioma do datacenter: uma parte de servidores mais antigos fica fora do jogo. O “v3” é como subir o mínimo de exigência da infraestrutura elétrica de uma casa: você até pode ter uma geladeira antiga, mas a instalação agora pressupõe um padrão mais moderno de tomada e disjuntor.
No mundo real, isso significa que processadores equivalentes à geração Intel Haswell para cima (e um recorte semelhante no lado da AMD) entram no grupo “seguro”, enquanto CPUs anteriores podem nem instalar ou podem ter incompatibilidades. Se você tem aquele pool de máquinas antigas que virou infra de legado “porque ainda liga”, aqui está o alerta que muita gente só percebe tarde: o Rocky 10.1 não está mais tentando ser esse abrigo.
E tem mais: a compatibilidade com pacotes de 32 bits no x86_64 foi encerrada. Nada de “só instalar a lib i686 para salvar o software herdado”. A saída típica vira container, isolamento, ou replanejamento de dependências para 64-bit. Dói, mas é coerente: manter 32-bit em 2025 é como manter peça de reposição de carro que saiu de linha, caro, raro e sempre te puxando para trás.
Rede: adeus ifcfg, ifup/down e o “jeitinho” antigo
Se no EL8 e no EL9 você já via o ifcfg-rh como algo em extinção, no Rocky Linux 10.1 a extinção se concretiza. Os scripts legados simplesmente não estão mais disponíveis. Isso inclui:
- arquivos ifcfg-* em
/etc/sysconfig/network-scripts/(não suportados) - comandos ifup e ifdown (não existem mais)
- ganchos legados como ifup-local (também foram embora)
O recado é: NetworkManager agora é lei, com nmcli, nmtui e, para cenários mais “infra como código”, nmstate. Até o lugar onde “mora” a configuração muda, indo para /etc/NetworkManager/system-connections/. É aquele tipo de mudança que faz playbook antigo falhar em silêncio, do jeito mais irritante possível.
E na parte de DHCP a modernização acompanha: o cliente DHCP passa por subsistema interno do NetworkManager, e no lado de servidor o Kea DHCP entra como substituto do ISC DHCP, que já era peça de museu.
Nova era gráfica: Wayland no lugar do X.Org (e o efeito dominó em VNC e xrdp)
Aqui tem outro choque cultural: Wayland substitui totalmente o X.Org Server como base do desktop. Sim, existe Xwayland para segurar muitos clientes X11 que ainda não migraram, mas a direção é irreversível.
O impacto prático aparece onde mais dói em ambiente corporativo: acesso remoto e ferramentas “que sempre funcionaram”. No instalador, o acesso gráfico remoto muda, RDP entra como caminho principal no lugar do VNC. E no sistema em si, pacotes que dependiam de X11 podem simplesmente não existir mais. Então aquele procedimento clássico “instala xrdp” ou “sobe x11vnc” deixa de ser receita, vira nostalgia.
A leitura correta disso não é “o Rocky quebrou remoto”, é “o remoto precisa seguir o novo stack”. Em outras palavras: ajuste seus runbooks antes que eles te ajustem no susto, em produção.
Segurança de futuro: PQC por padrão e root desativado no instalador
A parte de segurança também deixa claro que a meta é a próxima década, não a anterior. Em OpenSSL e políticas cripto do sistema, o Rocky 10.1 prioriza Criptografia Pós-Quântica (PQC) em relação a algoritmos clássicos, e amplia a ativação de algoritmos PQC em mais bibliotecas e políticas, incluindo GnuTLS.
Para quem pensa “isso é cedo demais”, vale a analogia do cinto de segurança: você não coloca depois do acidente. O Rocky está mudando a postura padrão do sistema para reduzir risco futuro e, de bônus, simplificar compliance conforme o ecossistema evolui.
E tem uma mudança operacional importante: no instalador (Anaconda), a conta root vem desativada por padrão. O fluxo esperado é criar um usuário administrativo com sudo. Dá para habilitar root definindo senha, mas agora isso é escolha explícita e o padrão é menos permissivo. Esse detalhe mexe em automações antigas, kickstarts reaproveitados e naquela cultura de “entra como root e resolve”. A casa agora vem com fechadura reforçada de fábrica.
Novas tecnologias: soft reboot, XFS mais flexível e stack atualizado
No capítulo “coisas novas que vão te fazer sorrir quando bem usadas”, o systemd soft-reboot permite reinicializar apenas o userspace, sem reiniciar o kernel. Pense nisso como reiniciar só o “andar de cima” da casa sem desligar o disjuntor principal. Em cenário de patching rápido e janelas de manutenção apertadas, isso pode ser ouro, desde que você respeite as limitações e teste bem antes de levar para produção.
No storage, o XFS ganha ferramentas mais práticas: dá para fazer scrub em filesystem montado com xfs_scrub, e há cenários em que é possível reduzir o XFS com xfs_growfs (sim, o nome engana, e por isso mesmo é o tipo de nota que evita dor de cabeça).
E no pacote “ecosistema moderno”, o Rocky 10.1 chega com versões recentes de linguagens e runtimes, incluindo .NET 10, Node.js 24, OpenJDK 25 e Valkey 8, além de toolchains novos como GCC 15, LLVM 20 e Rust 1.88. Para quem mantém workloads mistos (infra mais app), isso reduz o atrito de ter que buscar “repositório extra” para tudo.
RISC-V chegou, mas com ressalvas no kernel
Sim, RISC-V aparece como arquitetura suportada, o que é um marco interessante para quem acompanha infraestrutura alternativa e boards de desenvolvimento. Só que aqui entra a parte pragmática: há known issues com um build específico do kernel em alguns sistemas RISC-V, e por ser arquitetura secundária no Rocky, isso não bloqueou o lançamento.
Na prática, o conselho é conservador: se você está em RISC-V e precisa estabilidade, evite atualizar o kernel por enquanto (por exemplo, usando dnf upgrade --exclude='kernel*' --exclude='kmod*') e trate o ambiente como desenvolvimento e validação, não como “produção sem sustos”.
Upgrade, migração e o aviso que evita tragédia
Para quem já está no Rocky Linux 10.0, a atualização é simples: dnf -y upgrade. Para quem está no 8.x ou 9.x, o Rocky mantém a regra que você já conhece do mundo Enterprise Linux: não há upgrade suportado entre major releases. A recomendação oficial é instalação limpa e restauração de dados a partir de backup.
Se você vem de outra distro baseada em Enterprise Linux 10, existe o caminho de conversão via migrate2rocky, que pode ser uma ponte útil em ambientes padronizados.
