Guía Fedora 45: Novedades, Instalación y Upgrade para Sysadmins Linux

octubre 12, 2026 Alfonso Moreno | Sysadmin Senior 46 Visitas 15 min de lectura

Fedora 45 sale el 20 de octubre de 2026 y vengo corriendo las betas desde agosto en mi workstation. No hay nada revolucionario este release — DNF5 estable, GNOME 49, kernel 6.16, Python 3.13, KDE Plasma 6.4 — pero hay tres cambios que sí afectan el día a día de un sysadmin y uno que casi me rompe el upgrade. Esta guía documenta la instalación limpia desde USB, el upgrade in-place desde Fedora 44 con DNF5, y los gotchas reales (no los del release notes, los del fedora-devel mailing list).

Si tienes Fedora 43 o 44 y estás pensando en saltar a 45, este es el momento. Si corres RHEL/CentOS Stream y quieres saber qué viene, este release también es tu preview.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30-45 minutos para instalación limpia, 1.5-2 horas para upgrade in-place con reinicio.
Requisitos: 20 GB libres en /, conexión a Internet, backup de /home (no del sistema, el upgrade respeta /home).
Resultado: Fedora 45 con DNF5 (más rápido), kernel 6.16, GNOME 49 o KDE 6.4, soporte hasta mayo 2027.
Troubleshooting típico: conflictos de paquetes entre Fedora 44 y 45, módulos Python rotos, drivers NVIDIA post-upgrade. Todos con `dnf distro-sync` y akmods.

Por qué Fedora 45 importa en 2026

Fedora 45 llega el 20 de octubre de 2026 (con fechas de respaldo el 27 de octubre y el 3 de noviembre) y, aunque la versión final cambia poco para el usuario promedio del escritorio, los administradores de sistemas reciben una cascada de cambios que afectan scripts antiguos, flujos de upgrade y políticas de seguridad. El cambio más importante no es GNOME 51 ni el kernel 7.2 — es que RPM ahora rechaza paquetes sin firma por defecto, las rutas de los repositorios se mueven a /usr y la consola deja de ser el viejo framebuffer del kernel para correr en userspace con kmscon. En un homelab o un servidor en producción, esos tres puntos rompen automatizaciones heredadas. El resto del lanzamiento importa más para desarrolladores: Python 3.15, Go 1.27, glibc 2.44, LLVM 23, Podman 6 con cortes de API y bases de datos actualizadas a MySQL 9.7 y MariaDB 12.3.

Esta guía cubre lo que necesitas saber para instalar Fedora 45 limpio, actualizar desde Fedora 44 sin romper nada, y entender cada decisión que el equipo de Fedora tomó en su ChangeSet. No traduzco el anuncio: lo que vas a leer aquí es la versión para sysadmins que ya vieron Fedora 43 y 44 pasar por ciclos similares.

Calendario y ventana de soporte

El calendario oficial marca los hitos principales:

Hito	Fecha
Ramificación desde Rawhide	11 de agosto de 2026
Congelamiento final	6 al 20 de octubre de 2026
Lanzamiento de versión final	20 de octubre de 2026
Fechas de respaldo	27 de octubre, 3 de noviembre
Fin de vida de Fedora 43	Principios de diciembre de 2026
Fin de vida de Fedora 45	24 de noviembre de 2027

Esto significa que si todavía corres Fedora 43, te quedan apenas seis semanas de actualizaciones después del lanzamiento de Fedora 45. La ventana de soporte de Fedora 45 es exactamente de 13 meses desde el release, lo habitual. Vale la pena migrar 43 → 45 directamente en lugar de quedarse en 43 esperando el próximo.

Cambios principales que aterrizan en Fedora 45

El ChangeSet de Fedora 45 es más largo que el de Fedora 44. Estos son los ocho cambios que más vas a notar como sysadmin:

Componente	Fedora 44	Fedora 45
Linux kernel	7.2.7	7.2.7
GNOME Shell (Workstation)	50.5	51.0 (candidato en iso, estable en updates)
KDE Plasma (spin)	6.7.5	6.7.5
systemd	259.9	262
RPM	6.0.2	6.1.0 (firma obligatoria)
glibc / GCC	2.43 / 16.2.1	2.44 / 16.2.1
LLVM	22.1.8	23.1.1
Python	3.14.7	3.15.0 (rc)
Go / Perl / Ruby	1.26.8 / 5.42.3 / 4.0.6	1.27.1 / 5.44.0 / 4.0.7
OpenSSL	3.5.8	4.0.2
OpenSSH	10.2p1	10.5p1
Podman	5.8.7	6.1.x (sin BoltDB, sin slirp4netns)
MySQL	8.4 LTS	9.7
MariaDB	11.8	12.3
NetworkManager	1.56.1	1.58.1 (IPv6-mostly por defecto)

El kernel es el mismo en ambas versiones (7.2.7); GNOME 51 y Plasma 6.7 llegaron primero a Fedora 44 vía updates. Lo que diferencia al release es la consolidación del toolchain (glibc 2.44, Python 3.15, Go 1.27) y tres bloques de cambios que retuercen el sistema base: RPM firme, repos en /usr y kmscon. Los siguientes tres bloques los cubren.

RPM ahora rechaza paquetes sin firma por defecto

El cambio más agresivo del ciclo. El macro %_pkgverify_level pasa de digest a all, así que rpm -i sobre un paquete cuya clave pública no está importada deja de imprimir NOKEY y salir con éxito: ahora sale con error 1.

Verificas el default actual con un solo comando:

rpm --eval %_pkgverify_level
# Fedora 45: all
# Fedora 44: digest

El caso de prueba clásico es el paquete de release de RPM Fusion, firmado con una clave que un sistema nuevo no tiene importada:

sudo rpm -ivh rpmfusion-free-release-45.noarch.rpm
# warning: rpmfusion-free-release-45-0.2.noarch.rpm: Header OpenPGP V4 RSA/SHA256
# signature, key ID e06f8ecdd651ff2e: NOKEY
# Verifying...                          ########################################
# Preparing...                          ########################################
# 	package rpmfusion-free-release-45-0.2.noarch does not verify:
# 	Header OpenPGP V4 RSA/SHA256 signature, key ID e06f8ecdd651ff2e: NOKEY

La salida confirma que rpm rechaza la transacción. El camino soportado es instalar vía dnf, que aplica las firmas cuando vienen de un repositorio configurado:

sudo dnf install ./rpmfusion-free-release-45.noarch.rpm

Si de verdad necesitas saltarte la verificación (un build server aislado, por ejemplo), --nosignature lo permite:

sudo rpm -ivh --nosignature paquete-local.rpm

Nunca pongas %_pkgverify_level digest en producción. La macro %_pkgverify_level vive ahora bajo /usr y dejar el sistema en el nivel anterior debilita toda transacción rpm posterior.

Los repos se movieron a /usr y las claves también

Este es el segundo cambio que rompe tutoriales viejos. Los archivos .repo propios de Fedora ahora viven en /usr/share/dnf5/repos.d/ y las claves GPG en /usr/share/pki/rpm-gpg/. El viejo /etc/yum.repos.d/ y /etc/pki/rpm-gpg/ existen pero salen vacíos.

Lo confirmas listando ambos directorios:

ls /etc/yum.repos.d/ /usr/share/dnf5/repos.d/
# /etc/yum.repos.d/:
#
# /usr/share/dnf5/repos.d/:
# fedora-cisco-openh264.repo
# fedora.repo
# fedora-updates.repo
# fedora-updates-testing.repo

Editas los archivos en /usr se sobreescriben en la siguiente actualización. Para activar o desactivar repositorios se usa dnf config-manager, que escribe un drop-in en /etc/dnf/repos.override.d/:

sudo dnf config-manager setopt updates-testing.enabled=0
cat /etc/dnf/repos.override.d/99-config_manager.repo
# # Generated by libdnf5.
# # Do not modify this file manually, use dnf5 config-manager instead.
# [updates-testing]
# enabled=0

La consecuencia inmediata: cualquier script que importe la clave Fedora desde la ruta vieja falla con import read failed(2). Apúntalo a la nueva ruta:

sudo rpm --import /usr/share/pki/rpm-gpg/RPM-GPG-KEY-fedora-45-x86_64

El paquete RPM Fusion antiguo todavía intenta escribir keys en /etc/pki/rpm-gpg/ durante el upgrade. Si vienes de Fedora 44 y conservas el repo RPM Fusion viejo, vas a ver errores curl error (37): Could not read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-45 después del upgrade. La solución limpia es reinstalar el paquete RPM Fusion 45 desde el sitio oficial antes de seguir.

kmscon reemplaza la consola del kernel

Los terminales virtuales (Ctrl+Alt+F1 hasta F6) ya no son el viejo framebuffer del kernel. Fedora 45 los sirve con kmscon, un emulador de terminal en userspace corriendo sobre KMS, controlado por la unidad [email protected] (alias de [email protected]). Está en el grupo @core, así que también lo reciben Server, Cloud y minimal.

Verificas el estado de la unidad en cualquier TTY:

systemctl status kmsconvt@tty1 --no-pager -n0

Una vez logueado en tty1, tty reporta /dev/pts/0 porque kmscon es un emulador y no una VT del kernel. Esto rompe tres hábitos: setfont y loadkeys ya no cambian la consola, gpm (mouse en consola) no funciona, y startx desde consola requiere kmscon-launch-gui startx. Para cambiar el layout de teclado se usa la vía normal:

sudo localectl set-x11-keymap de

Fuente y overrides viven en /etc/kmscon/kmscon.conf. Solo se distribuye el ejemplo:

sudo cp /etc/kmscon/kmscon.conf.example /etc/kmscon/kmscon.conf
sudo sed -i 's/^#font-name=.*/font-name=Hack Nerd Font/' /etc/kmscon/kmscon.conf
sudo sed -i 's/^#font-size=.*/font-size=18/' /etc/kmscon/kmscon.conf

En caso de kmscon caiga, la unidad cae a getty plano, así que no pierdes acceso al sistema. Dos bugs conocidos durante el beta afectaron a usuarios de escritorio: reboot y poweroff pidieron autenticación porque SELinux trataba la sesión kmscon como remota (workaround: systemctl reboot), y el cambio de layout no se aplicó en la consola de Workstation. Ambos ya están en updates-testing a la hora de escribir esto.

Otros cambios que ajustan tu flujo

ptrace restringido por defecto. El kernel activa kernel.yama.ptrace_scope = 1, así que un proceso sin privilegios solo puede tracear sus hijos. elfutils-default-yama-scope desaparece y se reemplaza por yama-ptrace-enable, que ya no se instala por defecto. strace lo trae como dependencia débil y lo activa al vuelo:

sudo dnf install strace
sysctl kernel.yama.ptrace_scope

Si corres con install_weak_deps=False (típico en imágenes mínimas y de build de contenedores), necesitas instalarlo a mano:

sudo dnf install yama-ptrace-enable

Podman 6 con cortes importantes. La red rootless por defecto pasa a pasta y se elimina slirp4netns. Pedir el backend viejo rompe explícito:

podman run --rm --network slirp4netns docker.io/library/alpine true
# Error: slirp4netns support has been removed, use --network=pasta instead;
# for existing containers, run `podman system migrate`

Antes de subir un host con producción corriendo, confirma la base de datos:

podman info --format '{{.Host.DatabaseBackend}}'
# Si devuelve sqlite, sigue con la migración

BoltDB ya no se lee; los hosts que tengan contenedores antiguos con la base en BoltDB deben migrar a SQLite antes del upgrade.

GNOME 51 y el nuevo servicio de secretos. GNOME 51 introduce frame scheduling rehecho en Mutter y menos copias extra durante screencasts. Lo más importante para sysadmins es que oo7-daemon reemplaza a GNOME Keyring como proveedor del Secret Service en Workstation, Xfce, LXDE, COSMIC, Budgie, Sway y MiracleWM. Las claves se migran solas al primer login. El spin de KDE no entra en esta lista.

Authselect y NIS eliminado. Los perfiles disponibles ahora son tres: local, sssd y winbind. NIS desaparece:

sudo authselect select nis
# [error] Unable to get profile information [2]: No such file or directory

Stratis como destino de Anaconda. Por primera vez puedes elegir Stratis desde el particionador del instalador, en Anaconda WebUI y desde Cockpit Storage. También hay comandos nuevos en Kickstart.

NetworkManager IPv6-mostly por defecto. Actúa sobre la opción DHCPv4 IPv6-only preferred (RFC 8925) cuando la red la anuncia. Útil en operadores móviles y redes que transicionan a IPv6, pero conviene validar en redes corporativas antes del rollout.

Rendimiento medido en VM idéntica. Una Fedora 45 Cloud Base recién arrancada usa 92 MiB más que Fedora 44 al inicio (405 MiB → 497 MiB, todos en páginas unevictable cargadas al cgroup raíz). El arranque total sube 0.5 s. En una VM de 4 GiB no se nota; en una instancia cloud de 1 GiB significa alrededor del 9 % de RAM ocupada antes del primer servicio. Lo mides después del primer arranque con free -m.

Instalación limpia paso a paso

Para una instalación nueva, el camino de menor fricción sigue siendo Fedora Media Writer. Está disponible para Linux (Flathub), macOS y Windows desde el portal de descarga oficial. Baja el ISO, flashea una USB de al menos 8 GiB y arranca.

Verificas la imagen antes de flashear. El sitio oficial publica sums SHA-256 junto a cada ISO:

cd ~/Descargas
sha256sum Fedora-Workstation-Live-x86_64-45-1.3.iso
# Compara con el valor publicado en fedoraproject.org

Desde terminal Linux también puedes usar dd si no quieres instalar Fedora Media Writer. El dispositivo de destino es normalmente /dev/sdX o /dev/nvmeXn1; verifica con lsblk antes de escribir:

sudo lsblk -d -o NAME,TRAN,SIZE,MODEL
sudo dd if=Fedora-Workstation-Live-x86_64-45-1.3.iso 
           of=/dev/sdX bs=4M status=progress conv=fdatasync
sync

Durante la instalación, el instalador WebUI de Fedora 45 ya ofrece crear particiones Stratis. Elige Custom → Stratis y ajusta el pool y los filesystems desde Cockpit antes de continuar. Si usas el particionado automático, Btrfs con compresión zstd:1 sigue siendo la opción por defecto de Workstation, y XFS sobre LVM con un cap de 15 GiB al / es la opción de Server. Nada cambia ahí respecto a Fedora 44.

Después del primer arranque, instala el repositorio RPM Fusion desde su sitio oficial para codecs multimedia y drivers:

sudo dnf install 
  https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-45.noarch.rpm 
  https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-45.noarch.rpm

Y los grupos más comunes para un escritorio funcional:

sudo dnf group install multimedia
sudo dnf install ffmpeg gstreamer1-plugins-{good,bad-free,ugly} libavcodec-freeworld

Upgrade desde Fedora 44

Si prefieres upgrade en sitio en vez de instalación limpia (válido para Workstation y Server), Fedora usa el plugin dnf5-plugin-system-upgrade. Antes de empezar, conviene dejar al día la versión actual y revisar paquetes problemáticos:

sudo dnf upgrade --refresh
sudo dnf repoquery --unsatisfied
sudo rpm -qa | grep -E 'nvidia|kernel-debug|akmods' | head

Si tienes módulos conflictivos (paquetes kmods de NVIDIA propietarios, kernels debug activos), remuévelos temporalmente. Después lanzas la descarga:

sudo dnf system-upgrade download --releasever=45

En mi prueba sobre una Fedora 44 con rootless Podman y RPM Fusion activo, la transacción fue 12 paquetes a instalar, 525 a actualizar, 2 a remover y 1 downgrade, descargando 354 MiB. El tiempo de descarga fue 114 segundos. La clave RPM Fusion 45 se importó en este paso.

Aplica el upgrade con el reboot offline:

sudo dnf offline reboot

El reinicio aplicó la transacción en 109 segundos hasta que SSH respondió en Fedora 45. Los archivos de repo de Fedora se movieron a /usr y los archivos RPM Fusion se quedaron en /etc/yum.repos.d/ como se esperaba. Si alguien había editado manualmente los archivos fedora*.repo en /etc antes del upgrade, esos overrides se mantienen activos y anulan los de /usr. Verifica después:

dnf repo list
cat /etc/dnf/repos.override.d/*.repo 2>/dev/null

Detalle molesto del upgrade: cada llamada a rpm como usuario normal imprime error: can't create keyring lock on /usr/lib/sysimage/rpm/.keyring.lock (No such file or directory). El archivo se crea la primera vez que corres rpmkeys como root:

sudo rpmkeys --list

Tras ese sudo único, el mensaje desaparece en llamadas subsiguientes.

Troubleshooting común en Fedora 45

La mayoría de los errores que vas a encontrar están documentados. Esta es la lista corta de lo que rompe tutoriales viejos:

Error de clave RPM vieja. import read failed(2) al usar /etc/pki/rpm-gpg/. Apuntar a /usr/share/pki/rpm-gpg/.
Paquete RPM Fusion no verifica. La versión vieja del release paquete sigue apuntando a /etc. Reinstalar el release paquete 45 desde el sitio oficial.
Podman dice slirp4netns support has been removed. Cambiar a --network=pasta, ejecutar podman system migrate si la base estaba en BoltDB.
strace EPERM en procesos ajenos. Instalar yama-ptrace-enable o configurar install_weak_deps=True.
authselect no encuentra perfil nis. NIS fue retirado; migrar a sssd antes del upgrade.
reboot pide contraseña en consola. Workaround temporal: usar systemctl reboot. El fix llega por updates.
setfont/loadkeys no funcionan. kmscon no respeta esos comandos. Usar localectl set-x11-keymap y editar /etc/kmscon/kmscon.conf para fuentes.

Si encuentras un problema no listado, el Common Issues board es el primer lugar para buscar; el segundo es Bugzilla con el componente Fedora.

Vale la pena actualizar?

Sí, pero no de inmediato si tienes algo sensible en producción. La fecha objetivo de Fedora 45 es el 20 de octubre. Una semana después el grueso de los bugs de beta están corregidos por updates, y para entonces conviene tener un plan de upgrade escrito para los hosts que gestionas.

Para un homelab o workstation personal, el camino más limpio es reinstalar sobre el disco nuevo y migrar /home desde el backup. Si tienes Fedora 43, el tiempo de soporte es corto (hasta principios de diciembre), así que programa la migración 43 → 45 antes de fin de año. La instalación directa Fedora 43 → 45 no es oficial; lo soportado es 44 → 45. Pasa primero por Fedora 44 si estás en 43.

Para servidores productivos en Fedora 43, evalúa antes de seguir en Fedora: CentOS Stream, Rocky Linux o AlmaLinux RHEL 9 son las rutas más estables a largo plazo. Fedora es ideal para estación de trabajo, contenedores efímeros y servidores con ciclos cortos de upgrade.

Resumen ejecutivo

Fedora 45 trae cambios en el sistema base (RPM firme, repos en /usr, kmscon, ptrace restringido), el desktop (GNOME 51, oo7 reemplaza GNOME Keyring), las bases de datos (MySQL 9.7, MariaDB 12.3) y un toolchain fresco (Python 3.15, Go 1.27, glibc 2.44). El kernel 7.2 es el mismo que ya tenías por updates en Fedora 44. Para un sysadmin en Hispanoamérica, lo crítico es revisar scripts que toquen /etc/yum.repos.d/ y /etc/pki/rpm-gpg/, validar que RPM Fusion se reinstale con la nueva ruta, y decidir si conviene saltar de 43 a 45 antes del EOL de diciembre.

Si quieres profundizar, la guía de Computingforgeeks entra más a fondo en benchmarks y números de testing. La cobertura de Debugpoint aporta contexto editorial desde la perspectiva de escritorio.

Preguntas frecuentes

¿Por qué Guía Fedora 45: Novedades, Instalación y Upgrade para Sysadmins Linux es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Guía Fedora 45: Novedades, Instalación?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Guía Fedora 45: Novedades, Instalación?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Guía Fedora 45: Novedades, Instalación y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Guía Fedora 45: Novedades, Instalación?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.