Ejecutaste dnf update y ahora algo ha dejado de funcionar. En lugar de pasar horas solucionando problemas, solo quieres volver a la versión del paquete que funcionaba antes.
Esto ocurre más a menudo de lo que a la mayoría de los administradores de Linux les gustaría admitir. Tal vez una nueva versión de Nginx introdujo un cambio de configuración predeterminado que rompió tus hosts virtuales.
Una actualización de una biblioteca de Python cambió una API de la que dependen tus scripts internos. O quizás una actualización del kernel ya no funciona con un controlador de terceros.
Desde el punto de vista de DNF, todo se instaló correctamente, pero eso no siempre significa que tus aplicaciones sigan funcionando como se espera.
Degradar un paquete en distribuciones basadas en RHEL es fácil cuando se trata de un paquete independiente, pero las cosas se complican cuando otros paquetes dependen de la versión más reciente, porque DNF puede necesitar degradar también las dependencias relacionadas para mantener la coherencia del sistema.
En esta guía aprenderás a comprobar qué versiones de paquetes están disponibles, degradar un paquete de forma segura, evitar que se vuelva a actualizar, recuperar un paquete antiguo desde la caché local de RPM e incluso revertir una transacción completa de DNF si una actualización causó problemas.
¿Cómo maneja DNF las degradaciones?
Antes de empezar a degradar paquetes, es útil entender qué hace DNF entre bastidores.
Cada vez que instalas, actualizas, eliminas o degradas un paquete, DNF registra la operación como una transacción en su base de datos de historial. Este historial permite revisar cambios anteriores y, en muchos casos, revertir una transacción completa en lugar de arreglar manualmente paquetes individuales.
Cuando ejecutas una degradación de paquete, DNF no se limita a reemplazar el paquete más nuevo por uno más antiguo. Primero comprueba si la versión más antigua es compatible con el resto de paquetes instalados actualmente en tu sistema.
Si otro paquete depende de la versión más nueva, DNF detectará el conflicto y, según la situación, puede:
- Degradar también las dependencias necesarias.
- Rechazar la degradación porque rompería otros paquetes instalados.
- Pedir confirmación antes de realizar cambios adicionales.
Por eso conviene responder dos preguntas antes de ejecutar una degradación:
- ¿Es la versión que quieres compatible con los paquetes instalados actualmente en tu sistema?
- ¿La versión más antigua sigue estando disponible en alguno de tus repositorios habilitados o en la caché local de paquetes?
Tomarse un minuto para comprobar esto puede ahorrarte crear aún más problemas de dependencias más adelante.
¿Cómo comprobar qué versiones están disponibles?
Antes de degradar un paquete, comprueba qué versión está instalada actualmente y si la versión más antigua sigue disponible en los repositorios habilitados.
Para listar todas las versiones disponibles de un paquete, ejecuta:
dnf list --showduplicates nginxEjemplo de salida:
Installed Packages
nginx.x86_64 1:1.26.2-2.el10 @appstream
Available Packages
nginx.x86_64 1:1.24.0-4.el10 appstream
nginx.x86_64 1:1.26.2-2.el10 appstreamLa sección Installed Packages muestra la versión actualmente instalada en tu sistema.
La sección Available Packages enumera todas las versiones que tus repositorios habilitados ofrecen actualmente. Si la versión que deseas aparece aquí, puedes degradarla.
Si no aparece, el repositorio ya no tiene esa versión del paquete. No te preocupes: más adelante en esta guía cubriremos cómo recuperar paquetes antiguos desde la caché local de RPM.
Si quieres más información sobre el paquete instalado, incluido el repositorio del que provino, usa:
dnf info nginxEjemplo de salida:
Installed Packages
Name : nginx
Epoch : 1
Version : 1.26.2
Release : 2.el10
Architecture : x86_64
Size : 1.7 M
Source : nginx-1.26.2-2.el10.src.rpm
Repository : @System
From repo : appstream
Summary : A high performance web server and reverse proxy server
License : BSD
Description : Nginx is a web server and a reverse proxy server for HTTP, SMTP,
: POP3 and IMAP protocols, with a strong focus on high concurrency,
: efficiency and low memory footprint.Presta atención a los campos Version, Release y Epoch. Juntos identifican de forma única la versión del paquete. Si necesitas degradar a una versión específica, usarás esta información en el comando de degradación.
¿Cómo degradar a la versión anterior?
Si simplemente quieres volver a la versión anterior de un paquete, usa el comando dnf downgrade:
sudo dnf downgrade nginxEjemplo de salida:
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 appstream 42 k
Transaction Summary
================================================================================
Downgrade 1 Package
Total download size: 42 k
Is this ok [y/N]: yEl comando sudo ejecuta DNF con privilegios de administrador, necesarios al instalar, eliminar o degradar paquetes del sistema.
El comando dnf downgrade selecciona automáticamente la versión más alta disponible que sea más antigua que la actualmente instalada. Revisa el resumen de la transacción y, si todo parece correcto, pulsa y para continuar.
Una vez completada la degradación, verifica que la versión esperada está instalada:
nginx -vEjemplo de salida:
nginx version: nginx/1.24.0Si la versión mostrada coincide con la que esperabas, la degradación fue exitosa.
nginx-core o nginx-filesystem se degraden junto con nginx. Sin embargo, si DNF quiere eliminar paquetes de los que dependen otras aplicaciones o servicios, cancela la operación e investiga los cambios de dependencias antes de continuar.¿Cómo degradar a una versión específica?
Si necesitas degradar a una versión que está más de una versión por detrás, especifica el nombre del paquete seguido de la versión objetivo:
sudo dnf downgrade nginx-1.24.0-4.el10Ejemplo de salida:
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 appstream 42 k
Transaction Summary
================================================================================
Downgrade 1 Package
Total download size: 42 k
Is this ok [y/N]: y
Downloading Packages:
nginx-1.24.0-4.el10.x86_64.rpm 42 kB/s | 42 kB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Downgrading : nginx-1:1.24.0-4.el10.x86_64 1/2
Cleanup : nginx-1:1.26.2-2.el10.x86_64 2/2
Verifying : nginx-1:1.24.0-4.el10.x86_64 1/2
Verifying : nginx-1:1.26.2-2.el10.x86_64 2/2
Downgraded:
nginx-1:1.24.0-4.el10.x86_64
Complete!El resultado de la transacción es fácil de seguir:
- Downgrading muestra la versión del paquete más antigua que DNF está instalando.
- Cleanup muestra la versión más nueva que se está eliminando del sistema.
- Verifying confirma que la degradación se completó correctamente y que la base de datos RPM es coherente.
Después de que finalice la transacción, verifica la versión instalada:
nginx -vSi la salida muestra la versión solicitada, la degradación fue exitosa.
Bloquear la versión del paquete con versionlock
Después de degradar un paquete, el siguiente dnf update intentará instalar de nuevo la última versión disponible. Si quieres mantener el paquete en su versión actual, utiliza el plugin versionlock.
Primero instala el plugin, que suele estar en el paquete python3-dnf-plugins-core:
sudo dnf install python3-dnf-plugins-coreUna vez disponible el plugin, bloquea la versión actual del paquete:
sudo dnf versionlock add nginxPara ver todos los paquetes bloqueados, ejecuta:
sudo dnf versionlock listEjemplo de salida:
Last metadata expiration check: 0:02:31 ago on Mon Jun 29 11:14:08 2026.
nginx-1:1.24.0-4.el10.*El .* al final es un comodín que coincide con todas las arquitecturas de esa versión del paquete. Con el bloqueo activo, los futuros comandos dnf update omitirán nginx, dejándolo en la versión fijada.
Cuando estés listo para recibir actualizaciones de nuevo, elimina el bloqueo:
sudo dnf versionlock delete nginxexclude=nginx a /etc/dnf/dnf.conf. Sin embargo, exclude bloquea todas las actualizaciones futuras de ese paquete hasta que elimines la configuración, mientras que versionlock es más manejable y visible con dnf versionlock list.¿Cómo degradar desde un archivo RPM local?
A veces, la versión que necesitas ya no está disponible en los repositorios habilitados. Puede haber sido reemplazada por una versión más reciente, eliminada del repositorio o estás trabajando en un sistema sin acceso a internet.
Si todavía tienes el archivo RPM antiguo, puedes instalarlo directamente.
Primero, comprueba si el paquete sigue disponible en la caché local de DNF:
find /var/cache/dnf -name "nginx*.rpm"Ejemplo de salida:
/var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpmSi encuentras la versión que necesitas, instálala especificando la ruta completa al archivo RPM:
sudo dnf install /var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpmEjemplo de salida:
Examining /var/cache/dnf/appstream-3f8c21a9d4b72e01/packages/nginx-1.24.0-4.el10.x86_64.rpm: 1:nginx-1.24.0-4.el10.x86_64
Marking nginx-1.24.0-4.el10.x86_64.rpm as an update to 1:nginx-1.26.2-2.el10.x86_64
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
nginx x86_64 1:1.24.0-4.el10 @commandline 42 k
Transaction Summary
================================================================================
Downgrade 1 Package
Is this ok [y/N]: y
...
Complete!Aunque estés instalando un archivo RPM manualmente, DNF reconoce que el paquete es más antiguo que la versión instalada y realiza una degradación en lugar de una instalación normal. También comprueba las dependencias igual que lo haría al instalar desde un repositorio.
Si descargaste el RPM de otro sistema o de una fuente externa, verifica su firma antes de instalarlo:
rpm --checksig nginx-1.24.0-4.el10.x86_64.rpm¿Cómo usar el historial de DNF para revertir una transacción completa?
Si una actualización del sistema rompió más de un paquete, no tienes que degradar cada paquete individualmente. DNF mantiene un historial de cada transacción, lo que permite deshacer una actualización completa con un solo comando.
Primero, visualiza tus transacciones recientes de DNF:
sudo dnf history listEjemplo de salida:
ID | Command line | Date and time | Action(s) | Altered
-------------------------------------------------------------------------------
12 | update nginx | 2026-06-29 09:14 | Update | 1
11 | install httpd | 2026-06-28 14:22 | Install | 3
10 | update | 2026-06-27 08:00 | Update | 47
9 | install python3-flask | 2026-06-26 16:44 | Install | 5Cada transacción tiene un ID único. Usarás este ID si deseas inspeccionar o deshacer una operación específica.
Para ver exactamente qué cambió durante una transacción, ejecuta:
sudo dnf history info 12Ejemplo de salida:
Transaction ID : 12
Begin time : Sun Jun 29 09:14:22 2026
Begin rpmdb : 847:f3a2c...
End time : Sun Jun 29 09:14:38 2026 (16 seconds)
End rpmdb : 847:9b14d...
User : root
Return-Code : Success
Command Line : update nginx
Transaction performed with:
Installed rpm-4.19.1-1.el10.x86_64
Installed dnf-4.18.0-1.el10.noarch
Packages Altered:
Upgrade nginx-1:1.26.2-2.el10.x86_64 @appstream
nginx-1:1.24.0-4.el10.x86_64 @SystemEsta salida muestra que la transacción 12 actualizó nginx de la versión 1.24.0 a la 1.26.2.
Para deshacer esa transacción, ejecuta:
sudo dnf history undo 12Después de confirmar la transacción, DNF restaurará los paquetes a las versiones que tenían antes de aplicar la transacción 12.
Si simplemente quieres deshacer la transacción más reciente de DNF, no necesitas buscar su ID:
sudo dnf history undo last¿Cómo manejar dependencias rotas después de una degradación?
Si terminas en un estado donde DNF se niega a instalar o actualizar algo debido a dependencias rotas, primero ejecuta una comprobación de consistencia:
sudo dnf checkEjemplo de salida:
nginx-1:1.24.0-4.el10.x86_64 requires nginx-filesystem = 1:1.24.0-4.el10
nginx-filesystem-1:1.26.2-2.el10.x86_64 is a newer versionEsta salida te dice exactamente qué está roto y por qué. En este caso, nginx fue degradado pero nginx-filesystem no, por lo que el requisito de versión no se cumple.
Arréglalo degradando también la dependencia:
sudo dnf downgrade nginx-filesystemEjecuta dnf check de nuevo para confirmar que no hay nada más roto:
sudo dnf checkLa ausencia de salida significa que la base de datos RPM es consistente y todas las dependencias están satisfechas.
Conclusión
Degradar paquetes en sistemas RHEL con DNF es un proceso manejable si entiendes las herramientas disponibles: dnf downgrade para versiones anteriores, versionlock para fijar versiones, la caché local para versiones antiguas y el historial para revertir transacciones completas.
Con estos conocimientos, puedes recuperarte rápidamente de actualizaciones problemáticas y mantener la estabilidad de tu sistema.
Recuerda siempre verificar las dependencias antes de confirmar una degradación y mantener copias de seguridad de los archivos de configuración críticos.
Artículo actualizado en 2026. Basado en la documentación oficial de DNF y experiencias prácticas en sistemas RHEL/CentOS/Rocky/AlmaLinux.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.