Modernizar Fedora Linux Utilizando Complemento de Sistema DNF

Michael Wu, Anthony McGlone, El Equipo Documental de Fedora Versión F42 Last review: 2025-08-28

La instrucción dnf system-upgrade (integrada en el DNF5 y un complemento dnf-plugin-system-upgrade para el gestor de paquete DNF4) se utiliza para modernizar su sistema a la publicación actual de Fedora Linux. Para Fedora Silverblue y Fedora CoreOS, los cuales utilizan rpm-ostree, puede referir el documentación de rpm-ostree para detalles.

Este es el método de actualización recomendado desde la línea-instrucción. Funciona de la siguiente manera:

  1. Los paquetes se descargan mientras el sistema esté ejecutándose normalmente

  2. El sistema reinicia en un entorno especial (implementado como un systemd destino) para instalarlos

  3. Hasta completar, el sistema rearranca en la liberación nueva de Fedora Linux

Revisar las Notas de Lanzamiento

Antes de iniciar la instalación de versión superior, revise las notas de la versión de Fedora Linux a la que se está modernizando. Esto le permitirá estar al tanto de los cambios importantes, las nuevas funciones y cualquier problema potencial que pueda afectar a su sistema.

Consulte las notas del lanzamiento nuevo en: https://docs.fedoraproject.org/es/fedora/latest/release-notes/

Modernización del sistema en curso

Respalde sus datos antes de realizar una modernización completa del sistema como cada modernización del sistema es potencialmente arriesgado. Como una precaución, descargue la imagen de Fedora Workstation Live dentro del evento si algo va mal.

  1. Para actualizar su versión de Fedora Linux desde la línea de comandos haga lo siguiente:

    sudo dnf upgrade --refresh

    y reinicie su equipo.

    Importante: No omitir este paso. Las actualizaciones del sistema son requeridas para recibir claves de liberaciones de versiones más altas, y a menudo reparan problemas relacionados para el proceso de modernización.

  2. Descargue los paquetes actualizados:

    sudo dnf system-upgrade download --releasever=43

    Cambie el número de --releasever= si desea actualizar a una versión diferente. La mayoría de los usuarios querrán actualizar a la última versión estable, 43, pero en algunos casos, como cuando actualmente utiliza una versión anterior a 42, puede que desee actualizar solo a Fedora Linux 42. La actualización del sistema solo está oficialmente soportada y probada en un máximo de dos versiones (por ejemplo, de 41 a 43). Si necesita actualizar a través de más versiones, se recomienda hacerlo en varias etapas más pequeñas (read more).

    También puede usar 44 para modernizar a una versión Ramificada, o rawhide para modernizar a una versión estable Rawhide. Tenga en cuenta que ninguna de estas dos versiones es estable. Para obtener más información sobre el proceso de actualización y los problemas comunes relacionados con estas dos versiones, consulte las secciones correspondientes en las páginas enlazadas anteriormente.

  3. Si algunos de tus paquetes tienen dependencias no satisfechas, la actualización se detendrá hasta que la ejecutes de nuevo con la opción --allowerasing. Esto suele ocurrir con paquetes instalados desde repositorios de terceros para los que aún no se ha publicado una versión actualizada. Analiza detenidamente el resultado y examina qué paquetes se eliminarán. Ninguno debería ser esencial para el funcionamiento del sistema, pero algunos podrían ser importantes para tu productividad.

    • En caso de dependencias no satisfechas, puede ver algunas veces más detalles si añade la opción --best a la línea de instrucción.

    • Si desea desinstalar/instalar algunos paquetes manualmente antes de ejecutar dnf system-upgrade download de nuevo, se le advierte realizar aquellas operaciones con la opción de instrucción de dnf --setopt=keepcache=1. En otro caso el caché del paquete completo será desinstalado tras su operación, y necesitará descargar todos los paquetes de nuevo.

  4. Cuando se importa la clave GPG nueva, se le solicita que verifique la huella de la clave. Refiérase a https://fedoraproyecto.org/security para hacerlo.

  5. Ejecuta el proceso de actualización, según la versión de DNF que utilice su sistema:

Si estás utilizando DNF 4 (predeterminado en liberaciones de Fedora más anteriores):+

$ sudo dnf system-upgrade reboot

This will reboot your machine immediately into a special upgrade environment. Close all programs and save your work first. No countdown or confirmation is given.

If you’re using DNF 5 (starting from Fedora 41+):

$ sudo dnf5 offline reboot

This performs the upgrade offline during the next boot. To cancel the upgrade and delete downloaded files:

$ sudo dnf5 offline clean

  1. Once the upgrade process completes, your system will reboot a second time into the updated Fedora Linux release.

Tareas opcionales de post-upgrade

These are some of the tasks you can do after a successful upgrade.

Actualiza los archivos de configuración del sistema

Most configuration files are stored in the /etc folder. If you have changed the package’s configuration files, RPM creates new files with either .rpmnew (the new default config file), or .rpmsave (your old config file backed up). You can search for these files, or use the rpmconf tool that simplifies this process. To install rpmconf, enter:

$ sudo dnf install rpmconf

Una vez que la instalación está completa introduzca:

$ sudo rpmconf -a

Some third-party packages drop edited configuration files in /etc/yum.repos.d/ and reverting these files to their original versions may disable updates for the software. Please remember to review configuration files in this directory carefully.

For more information you can refer to the man pages (man rpmconf).

If you use rpmconf to upgrade the system configuration files supplied with the upgraded packages then some configuration files may change. After the upgrade you should verify /etc/ssh/sshd_config, /etc/nsswitch.conf, /etc/ntp.conf and others are expected. For example, if OpenSSH is upgraded then sshd_config reverts to the default package configuration. The default package configuration does not enable public key authentication, and allows password authentication.

Update GRUB bootloader on BIOS systems

Systems with the BIOS firmware have the GRUB RPM packages updated. However, the installed or embedded bootloader is never updated automatically. It is a good idea to update it between Fedora Linux release versions.

Find the device node the /boot/ directory is located on:

$ sudo mount | grep "/boot "
/dev/sda4 on /boot type ext4 (rw,relatime,seclabel)

The device node is /dev/sda4. Reinstall the bootloader while specifying the device node without the number:

$ sudo grub2-install /dev/sda

La salida correcta sería:

Installing for i386-pc platform.
Installation finished. No error reported.

Clean-up retired packages

With every release, Fedora retires a few packages. There are various reasons; the packages become obsolete, they have a dead upstream, or the maintainer steps down. Fedora no longer distributes these packages; however, they are still on your system. These packages will not receive upgrades. It is highly recommended to remove them.

If you upgrade across one release (e.g. Fedora Linux 42 to 43), run the following commands:

$ sudo dnf install remove-retired-packages
remove-retired-packages

If you upgrade across two releases (e.g. Fedora Linux 41 to 43), you must supply the old release version to remove-retired-packages:

sudo dnf install remove-retired-packages
remove-retired-packages 41
La modernización a través de más de dos liberaciones no están admitidas.

Purgar paquetes antiguos

Puede ver paquetes duplicados (paquetes con múltiples versiones instaladas) con:

$ sudo dnf repoquery --duplicates

Y puede desinstalarlas con:

sudo dnf remove --duplicates

Esta instrucción utiliza su binario dnf por defecto del sistema: * En Fedora 38: Apunta a DNF4 * En Fedora 39+: Apunta a DNF5

Si es necesario, está disponible la versión anterior DNF4 como dnf4, pero se recomienda la instrucción predeterminada dnf para uso general.

Run sudo dnf upgrade first, as this list is only valid if you have a fully updated system. Otherwise, you will see a list of installed packages that are no longer in the repositories because an update is available. This list may also contain packages installed from third-party repositories who may not have updated their repositories.

Para los paquetes de los repositorios oficiales, debe instalarse la última versión. Sin embargo, algunos paquetes que aún se encuentran en su sistema podrían no estar ya en los repositorios. Para ver una lista de estos paquetes, haga:

$ sudo dnf list --extras

If you see a package you do not need, or use, you can remove it with:

$ sudo dnf remove $(sudo dnf repoquery --extras --exclude=kernel,kernel-\*,kmod-\*)

You can safely remove packages no longer in use with:

$ sudo dnf autoremove

DNF decides that a package is no longer needed if you haven’t explicitly asked to install it and nothing else requires it. However, that doesn’t mean that the package is not useful or that you don’t use it. Only remove what you are sure you don’t need.

Clean-up old kernels

After you boot into the latest kernel and test the system you can remove previous kernels. Old kernels remain even after dnf autoremove to avoid unintentional removals.

One of the easier ways to remove old kernels is with a script that retains the latest kernel. The script below works whenever Fedora updates a kernel, and does not depend upon a system upgrade.

#!/usr/bin/env bash

old_kernels=($(dnf repoquery --installonly --latest-limit=-1 -q))
if [ "${#old_kernels[@]}" -eq 0 ]; then
    echo "No old kernels found"
    exit 0
fi

if ! dnf remove "${old_kernels[@]}"; then
    echo "Ha fallado al desinstalar el kernel anterior"
    exit 1
fi

echo "Kernel anterior desinstalado"
exit 0

Limpiar claves antiguas confiables para la firma de paquetes RPM

Las claves de versiones anteriores de Fedora y repositorios de terceros se acumularán en la base de datos RPM con el tiempo. Puede eliminar las claves que ya no se referencian en /etc/yum.repos.d/ con:

sudo dnf install clean-rpm-gpg-pubkey
sudo clean-rpm-gpg-pubkey

Es posible que haya enlaces simbólicos inactivos en el sistema de archivos después de una actualización. Puede eliminarlos instalando la utilidad de enlaces simbólicos y eliminando los antiguos.

$ sudo dnf install symlinks

Una vez instalada la utilidad, puede auditar los enlaces simbólicos rotos como se muestra a continuación. -r significa recursivo.

sudo symlinks -r /usr | grep dangling

Después de verificar la lista de enlaces simbólicos rotos, puede eliminarlos como se muestra a continuación. -d significa eliminar.

sudo symlinks -r -d /usr

Actualizar el kernel de rescate

Anaconda genera el kernel de rescate y el initramfs durante la instalación del sistema. El initramfs se actualiza al actualizar el kernel, pero el kernel de rescate podría no actualizarse. La actualización del kernel de rescate depende de la configuración del sistema.

Si el kernel de rescate no está actualizado, ejecute los siguientes comandos para regenerarlo.

$ sudo rm /boot/*rescue*
$ sudo kernel-install add "$(uname -r)" "/lib/modules/$(uname -r)/vmlinuz"

El proceso de regeneración del núcleo de rescate se puede automatizar instalando el paquete dracut-config-rescue.

sudo dnf install dracut-config-rescue

Una vez instalado, el kernel de rescate se regenerará siempre que dracut sea el generador de initrd. Consulte /usr/lib/kernel/install.d/51-dracut-rescue.install para obtener más información.

Resolver los asuntos post-upgrade

Siga estos pasos solo si tiene problemas con su sistema actualizado.

Recompilar la base de datos de RPM

Si ve advertencias al trabajar con herramientas RPM/DNF, su base de datos podría estar dañada. Puede reconstruirla para ver si se solucionan los problemas. Siempre haga primero un respaldo de /usr/lib/sysimage/rpm. Para reconstruir la base de datos, ejecute:

$ sudo rpm --rebuilddb

Utilice distro-sync para resolver asuntos de dependencia

La herramienta de actualización del sistema usa dnf distro-sync por defecto. Si su sistema está parcialmente actualizado o detecta problemas de dependencia de paquetes, intente ejecutar otra distro-sync manualmente para ver si esto soluciona el problema. Esto intentará que los paquetes instalados tengan la misma versión en los repositorios habilitados, incluso si es necesario degradar algunos paquetes:

sudo dnf distro-sync

También puede usar la opción --allowerasing para eliminar los paquetes con dependencias insatisfechas. Revise siempre qué paquetes se eliminarán antes de confirmarlo:

sudo dnf distro-sync --allowerasing

Reetiqueta archivos con la última normativa de SELinux

Si encuentra alguna advertencia sobre políticas de SELinux, es posible que algunos archivos tengan permisos incorrectos. Esto puede ocurrir si SELinux se deshabilitó anteriormente. Para reetiquetar SELinux en el sistema, ejecute el siguiente comando y reinicie:

sudo fixfiles -B onboot

El proceso de arranque tomará un tiempo largo, ya que comprueba y repara etiquetas de permisos de SELinux sobre todos los archivos en su sistema.

Preguntas Más Frecuentes

¿Cómo puedo informar asuntos con la modernización?

  1. Consulte defectos (bichos) comunes para comprobar si es un problema conocido que la comunidad ya está al tanto.

  2. Search Bugzilla for an existing bug report filed against DNF5, resp. DNF4 plug-in.

Si no encuentra un informe que coincida con sus síntomas, puede crear uno nuevo desde la página de búsqueda. Siga las instrucciones para informar errores que se indican en el README del repositorio de GitHub.

Si encuentra cualquier asunto tras la modernización con un paquete específico, envía un defecto (bug, bicho) relativo al paquete con cual está teniendo este asunto.

¿DNF System Upgrade verifica el software que ejecuta o instala durante una versión nueva?

Sí. Las claves de firma de paquetes de la versión más reciente de Fedora Linux se envían a las versiones anteriores para que DNF pueda verificar la integridad de los paquetes descargados. Puede desactivar esta función si es necesario, pero no se recomienda, ya que estará expuesto a ataques de software malicioso.

¿Se modernizarán los paquetes en repositorios de terceros?

Yes, if they are configured like regular DNF repositories and the version numbers are not hard-coded in the repository file (usually found in /etc/yum.repos.d/). Commonly used third-party repositories like RPM Fusion should work. However, if attempting to upgrade prior to, or soon after, an official Fedora Linux release, they may not have updated their repository paths, and DNF may be unable to find their packages. Usually, this should not prevent the upgrade from running successfully. Also, you can update packages from the third-party repository later.

¿Puedo modernizar desde un Fin de Vida (FDV) de liberación?

Se recomienda encarecidamente modernizar una versión EOL en cualquier sistema de producción o cualquier sistema conectado a Internet público.

Cualquier modernización desde Fedora Linux 20 o anterior se realiza bajo su propio riesgo, ya que DNF no era la herramienta predeterminada de gestión de paquetes. Sin embargo, si tiene una versión posterior a Fedora Linux 20 que esté al final de su vida útil (FVU/EOL), puede intentar actualizar, pero este método no está soportado. Puede intentar actualizar mediante versiones intermedias hasta llegar a una versión con soporte actual, o intentar actualizar a una versión con soporte actual en una sola operación. Nuevamente, esto no está soportado y es bajo su propio riesgo.

¿Puedo realizar una única modernización en varias versiones (es decir, 30→34)?

Upgrades to the very next release (e.g. 42 to 43) as well as upgrades skipping one release (e.g. 41 to 43) are both supported. However, it is highly recommended to perform the upgrade before your release reaches End of Life (EOL). That happens roughly a month after N+2 release has been released (when you’re currently on release N). The Fedora Release Life Cycle is specifically designed to provide this approximate one month "grace period" to allow users the choice to upgrade their systems on a yearly basis, i.e. once every two releases. You can study Releases to see the current release status and schedule. Around a month after the new release comes out, the last-but-one release becomes End of Life (EOL). The upgrade is likely to work successfully after the release goes EOL, but the time period after the new release may be uncertain.

Upgrades across more than two releases are not supported, and issues encountered with such upgrades may not be considered significant bugs.

When upgrading across more than two releases, you may need to import the GPG key for the release you want to update to. You can do this with:

$ sudo rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-N-primary

(donde N es la versión de Fedora Linux).

¿Puedo emplear DNF System Upgrade para modernizar a una versión preliminar (por ejemplo, una versión Beta)?

Sí, pero esto está sujeto a fallos temporales, como cualquier otro aspecto de un prelanzamiento.

Want to help? Learn how to contribute to Fedora Docs ›