RHEL 9 para RHEL 10 com Leapp — os checks pre-flight e as pegadinhas que pegamos

Upgrades de versão major in-place no RHEL agora são genuinamente usáveis. O Leapp faz a maior parte do trabalho pesado: inventário pre-flight, checks de compatibilidade de pacotes, migração de configuração, e a transação de upgrade em si. O caminho de sucesso é real e bem documentado.

O caminho de falha também é bem documentado, e é onde a engenharia acontece. Este é o workflow do Leapp que usamos em frotas de cliente, e as pegadinhas que pegamos consistentemente indo de RHEL 9 para RHEL 10.

A sequência pre-flight + upgrade

# Habilitar + rodar o relatório de pré-upgrade
yum install -y leapp-upgrade
leapp preupgrade
 
# LEIA /var/log/leapp/leapp-report.txt
# Resolva cada inhibitor antes de prosseguir
# (cgroups v1 → v2, serviços depreciados, pacotes removidos)
 
# Resolver inhibitors específicos com respostas
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
 
# Rodar o upgrade real
leapp upgrade
reboot   # Boota em initramfs em modo upgrade e faz o trabalho

O mais importante: leia o relatório de pré-upgrade. Ele vai te dizer exatamente o que vai quebrar. Não rode leapp upgrade até que cada inhibitor esteja resolvido ou explicitamente reconhecido.

O artigo completo cobre:

• O inventário pre-flight — o que o Leapp checa e o que ele perde
• Implicações da transição cgroups v1 → v2 para cargas em container
• Python 3.9 → 3.12 — o que é removido e qual código de aplicação precisa atualizar
• A mudança de crypto-policies (legacy → DEFAULT ou FUTURE)
• Módulos de kernel customizados que não sobrevivem ao upgrade
• Pegadinhas reais pós-upgrade (Postgres, Apache, Nginx — mudanças de sintaxe de config)
• Quando recomendamos fresh installs em vez de upgrades in-place

Rodamos este playbook em cada upgrade de frota RHEL gerenciada.