RHEL 9 a RHEL 10 con Leapp — los checks pre-flight y los baches que pillamos

Los upgrades de versión mayor in-place en RHEL ahora son genuinamente usables. Leapp hace el grueso del trabajo pesado: inventario pre-flight, checks de compatibilidad de paquetes, migración de configuración, y la transacción de upgrade en sí. El camino exitoso es real y está bien documentado.

El camino no exitoso también está bien documentado, y es donde sucede la ingeniería. Este es el workflow de Leapp que usamos en flotas de cliente, y los baches que pillamos consistentemente al ir de RHEL 9 a RHEL 10.

La secuencia pre-flight + upgrade

# Habilitar + ejecutar el reporte pre-upgrade
yum install -y leapp-upgrade
leapp preupgrade
 
# LEE /var/log/leapp/leapp-report.txt
# Resuelve cada inhibitor antes de continuar
# (cgroups v1 → v2, servicios deprecados, paquetes removidos)
 
# Resolver inhibitors específicos con respuestas
leapp answer --section remove_pam_pkcs11_module_check.confirm=True
 
# Ejecutar el upgrade real
leapp upgrade
reboot   # Arranca en initramfs upgrade-mode y hace el trabajo

Lo más importante: lee el reporte pre-upgrade. Te dirá exactamente qué va a romper. No ejecutes leapp upgrade hasta que cada inhibitor esté o resuelto o explícitamente reconocido.

El artículo completo cubre:

• El inventario pre-flight — qué chequea Leapp y qué pasa por alto
• Implicaciones de la transición cgroups v1 → v2 para cargas containerizadas
• Python 3.9 → 3.12 — qué se elimina y qué código de aplicación hay que actualizar
• El cambio de crypto-policies (legacy → DEFAULT o FUTURE)
• Módulos de kernel custom que no sobreviven al upgrade
• Baches reales post-upgrade (Postgres, Apache, Nginx — shifts de sintaxis de config)
• Cuándo recomendamos fresh installs en vez de upgrades in-place

Ejecutamos este playbook en cada upgrade de flota RHEL gestionada.