Guía Fedora 43: novedades e instalación paso a paso (2026)

Por qué Fedora 43 sigue siendo relevante un año después de su lanzamiento

Fedora 43 vio la luz el 28 de octubre de 2025 y, un año más tarde, sigue siendo la rama estable recomendada por el Fedora Project para workstations y servidores. Si vienes de Fedora 42, las novedades parecen modestas a primera vista; pero varias decisiones de plataforma (GNOME 49 sin X11, RPM 6.0, partición /boot ampliada a 2 GiB y el corte completo de OSTree en CoreOS) cambian realmente la forma en que administras un Fedora en producción.

Esta guía cubre tres cosas: qué cambió de verdad en Fedora 43, cómo hacer una instalación limpia paso a paso (incluyendo el nuevo Anaconda WebUI para Spins), y cómo subir desde Fedora 42 sin romper la configuración que ya tienes. Para sysadmins que mantienen flotas mixtas Fedora/RHEL, los comandos y los criterios de decisión aplican también a CentOS Stream y a Rocky/Alma cuando estén en línea.

Qué trae Fedora 43 (más allá del típico minor bump)

El ChangeSet oficial lista más de 30 cambios aceptados, pero los que de verdad tocan al usuario final son estos:

Componente	Fedora 42	Fedora 43	Impacto práctico
Kernel	Linux 6.11 → 6.12 LTS	Linux 6.17 (estable)	Mejor soporte de hardware nuevo (Intel/AMD recientes, Qualcomm); sin saltos forzados.
GNOME (Workstation)	GNOME 47, X11 disponible	GNOME 49, Wayland-only	Corte X11 definitivo; apps legacy requieren XWayland.
Instalador	Anaconda WebUI solo en Workstation	Anaconda WebUI en Spins también	Cambio menor para Spins; tras bambalinas es Anaconda WebUI universal.
RPM	4.x con firma única	RPM 6.0 con firma múltiple	Prepara el terreno para criptografía post-cuántica (PQC); Fedora 43 todavía firma con OpenPGP clásico, pero la maquinaria para convivir con PQC ya está.
CoreOS	OSTree + OCI (dual)	OCI exclusivo	Pipeline CI/CD nativo; ya no hay ostree repo que mantener.
DNF en Anaconda	Soporte de módulos	Sin selección de streams	Módulos se gestionan por CLI tras la instalación.
Partición /boot	1 GiB por defecto	2 GiB por defecto	Margen real para 4-6 kernels sin limpieza manual; era cambio de emergencia aceptado en septiembre de 2025.
Python	3.13	3.14	PEP 776, template strings en stdlib; recompilar wheels viejos.
Go	1.23	1.25	Mejoras en runtime; toolchain modularizada.
Java	OpenJDK 21 system JDK	OpenJDK 25, sin system JDK	Cada runtime declara su propio JDK.

Desde el ángulo de un homelab, la decisión de partición y el corte OSTree son los que más duelen. Los demás son evoluciones limpias que el sistema absorbe solito. Para un detalle exhaustivo de cada Self-Contained Change, el ChangeSet oficial sigue siendo la fuente primaria; aquí solo cubrimos lo que afecta decisiones de instalación o upgrade.

Requisitos mínimos y descarga del ISO

Antes de tocar nada, confirma que tu hardware entra en el target soportado:

• CPU: x86-64 con SSE4.2 (cualquier Intel desde Haswell o AMD desde Excavator) o aarch64 (Raspberry Pi 4/5, Apple Silicon vía Asahi).
• RAM: 2 GiB mínimo, 4 GiB recomendado para Workstation con GNOME.
• Disco: 20 GiB para una instalación mínima con escritorio; 40 GiB si vas a usar Flatpak pesado (Steam, DaVinci).
• UEFI con Secure Boot habilitado o no; Fedora 43 firma el bootloader con la clave de Microsoft UEFI CA.

Descarga el ISO desde getfedora.org y, antes de flashearlo, verifica la firma. Fedora distribuye el archivo Fedora-Workstation-43-1.6-x86_64-CHECKSUM y las claves GPG en fedoraproject.org/fedora.gpg. El SHA-256 del ISO debe matchear exactamente el checksum publicado.

En Linux el flujo de verificación es directo:

# Bajar clave pública y checksum publicados oficialmente
curl -O https://fedoraproject.org/fedora.gpg
curl -O https://fedoraproject.org/releases/43/Everything/x86_64/iso/Fedora-Workstation-43-1.6-x86_64-CHECKSUM
# Importar la clave al llavero del usuario
gpg --import fedora.gpg
# Verificar la firma sobre el CHECKSUM (no sobre el ISO)
gpg --verify-files *-CHECKSUM
# Validar el SHA-256 del ISO contra el CHECKSUM ya firmado
sha256sum -c Fedora-Workstation-43-1.6-x86_64-CHECKSUM

La doble verificación (firma GPG del CHECKSUM + SHA-256 del ISO) es la única manera de descartar un mirror MITM que intente sustituir el instalador. Si sha256sum -c devuelve OK, el ISO es auténtico y puedes flashearlo.

Instalación paso a paso con Anaconda WebUI

Para crear el USB booteable usa fedora-media-builder (Fedora), Ventoy (multi-ISO) o balenaEtcher (Windows/macOS). En sistemas Linux ya instalados, fedora-media-builder deja un shell limpio:

# Instalar el constructor de medios oficial de Fedora
sudo dnf install -y fedora-media-daemon
# O usar dd directo si confías en el ISO ya verificado
sudo dd if=Fedora-Workstation-43-1.6-x86_64.iso of=/dev/sdX bs=4M status=progress conv=fsync

Arranca el equipo desde el USB (F12 en la mayoría de firmware, F2/DEL para ajustar el orden de boot). Verás el menú de GRUB de Fedora con tres entradas principales:

• Start Fedora-Workstation-43: arranca el Live con GNOME y abre Anaconda WebUI en el navegador a https://localhost:9090.
• Test this media & start Fedora-Workstation-43: valida el medio antes de arrancar (suma minutos al boot pero descarta ISOs corruptos).
• Troubleshooting → Rescue mode: arranca un entorno mínimo para reparar instalaciones rotas.

Durante el particionado, el default automático crea /boot con 2 GiB y usa LVM para el resto; en una laptop es lo correcto. En un servidor con discos grandes te recomiendo crear un particionado manual con /boot también de 2 GiB (a no ser que uses UEFI con Secure Boot avanzado que requiera particiones más grandes) y dejar LVM con todo lo demás. Anaconda 43 ya no permite seleccionar streams de módulos en la UI; si necesitas PostgreSQL 16 y 17 a la vez, configura los módulos post-instalación con dnf module enable.

Al finalizar, el sistema reinicia. Si dejaste el USB puesto, recuerda retirarlo antes del primer boot; Anaconda no es capaz de distinguir el ISO del disco y bota en modo Live si encuentra un medio extraíble.

Post-instalación: dejar Fedora 43 listo para trabajar

Lo primero es actualizar todo y aplicar los parches publicados después del lanzamiento:

# Refrescar caché y aplicar todas las actualizaciones disponibles
sudo dnf upgrade -y --refresh
# Confirmar kernel activo y módulos
uname -r
rpm -q kernel-core

Para drivers NVIDIA propietarios y codecs multimedia de patentes dudosas (H.264 en Firefox, AAC en Spotify, etc.), habilita los repos RPM Fusion:

# RPM Fusion free y non-free (drivers NVIDIA, codecs, Steam)
sudo dnf install -y 
  https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-43.noarch.rpm 
  https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-43.noarch.rpm
# Swap completo a los paquetes multimedia restringidos en un solo comando
sudo dnf swap -y ffmpeg-free ffmpeg --allowerasing
sudo dnf install -y libva-intel-driver  # si tienes GPU Intel
sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda  # NVIDIA propietarios
# Códecs en Flatpak para apps que ya vienen en Flathub
flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

Si usas GNOME, hay tres tweaks que vale la pena aplicar de una vez para evitar fricciones con Wayland-only:

# Permitir autenticación de agentes polkit gráficos en sesiones Wayland
sudo dnf install -y polkit-gnome
# Habilitar RPM repos de extensiones de GNOME para los pocos casos que faltan en Flathub
sudo dnf install -y gnome-tweaks gnome-extensions-app
# Instalar la aplicación oficial de respaldos (Déjà Dup con backend de Borg opcional)
sudo dnf install -y deja-dup

Upgrade desde Fedora 42 sin perder el sistema

Fedora soporta oficialmente el camino de upgrade in-place usando dnf-plugin-system-upgrade. El flujo probado en Fedora 43 sigue siendo el de siempre, pero conviene revisar dos cosas específicas de esta versión: la nueva partición /boot (si la vieja es de 1 a 2 GiB, hay espacio para cuatro o cinco kernels antes de empezar a fallar updates) y los módulos de Python/Golang (3.14 y Go 1.25 pueden entrar en conflicto con paquetes compilados contra las versiones de F42).

# Backup preventivo (asume btrfs con snapshots, lo cual es el default de Workstation)
sudo snapper create --type pre --description "Antes de upgrade a Fedora 43"
sudo snapper list | head
# Actualizar todo a la última versión de Fedora 42 disponible
sudo dnf upgrade --refresh -y
sudo dnf install -y dnf-plugin-system-upgrade
# Bajar los paquetes de Fedora 43 (no instala todavía)
sudo dnf system-upgrade download --releasever=43
# Si la descarga falla por dependencias, --allowerasing permite
# remplazar paquetes conflictivos (ojo: solo cuando sepas qué se va a borrar)
sudo dnf system-upgrade download --releasever=43 --allowerasing
# Reiniciar y completar el upgrade; el sistema entra en modo rescue multi-target
sudo systemctl reboot
sudo dnf system-upgrade reboot   # si el comando anterior terminó con éxito

Al volver del reboot, verifica que la versión activa sea 43 y que la cadena de toolchain haya cambiado:

cat /etc/os-release | head -5
rpm -q fedora-release
python3 --version       # debería decir 3.14
go version             # debería decir go1.25
gcc --version          # gcc 15.2.x

Si vienes de un Fedora 42 con /boot montada en una partición separada de 1 GiB, el primer dnf upgrade post-43 puede fallar por espacio. La solución es limpiar kernels viejos antes de continuar:

# Listar kernels instalados (mantener siempre el actual y uno anterior como fallback)
sudo rpm -q kernel-core
# Borrar kernels viejos que ya no se usan
sudo dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)
sudo dnf autoremove -y

Problemas conocidos y troubleshooting

Aunque Fedora 43 va bien en hardware moderno, hay tres categorías de fallos que ya aparecen documentadas en el foro de discusión del proyecto:

• No booteo después de upgrade con kernel 6.17.8: bug conocido en sistemas con particiones LVM y swap encriptada. Solución: editar la entrada de GRUB temporalmente para eliminar rd.lvm.lv=fedora/swap y los parámetros rd.luks.uuid+rd.luks.options=, reiniciar, y dejar que dracut regenere el initramfs con sudo dracut --regenerate-all --force.
• Aplicaciones X11 dejan de funcionar: cualquier app que dependa de XWayland ahora vive sobre el traductor Wayland→X11. TeamViewer, viejos binarios de GUI en Java y algunos plugins de OBS pueden requerir XDG_SESSION_TYPE=x11 como workaround temporal; el camino correcto es migrar a versiones Wayland-native.
• NVIDIA híbrida Optimus: con el stack propietario sobre GNOME 49 hay que validar que nvidia-smi reporte la dGPU tras el primer boot. Si solo aparece la iGPU, toca forzar nvidia-drm.modeset=1 en /etc/dracut.conf.d/nvidia.conf y regenerar initramfs.

Para verificar el estado real del sistema tras cualquier update o instalación nueva, una lista corta de comandos cubre la mayoría de los casos de soporte:

# Resumen del estado del sistema
rpm -q fedora-release
uname -r
systemctl --failed
journalctl -p 3 -b 0 | head -50
# Estado de SELinux (Fedora lo lleva en modo enforcing por defecto)
getenforce
sudo sealert -a /var/log/audit/audit.log
# Drivers gráficos y Wayland
echo $XDG_SESSION_TYPE
glxinfo | grep "OpenGL renderer"

¿Vale la pena actualizar a Fedora 43?

Si vienes de Fedora 42 y tu hardware es post-2020, sí: el kernel 6.17 es estable, GNOME 49 trae mejoras reales de rendimiento gráfico, y Anaconda WebUI ya pulió los bugs iniciales de su debut en Workstation 42. Para un homelab que corre Fedora Server o Fedora CoreOS, lo más interesante es la transición 100% OCI: te deja versionar tu CoreOS como cualquier imagen Docker y desplegar por registries internos.

Si tu equipo depende de software que todavía requiere X11 (algunos agentes comerciales de administración remota, drivers propietarios viejos, flujos de screen recording con pipelines X11), considera esperar a GNOME 50 o migrar el stack problemático antes de actualizar. El corte X11 no es un experimento: upstream ya lo eliminó y Fedora no lo va a reactivar.

Para servidores, Fedora 43 es una base razonable para evaluación, pero Fedora Server tiene ciclos de soporte de 13 meses; si llegas al final de F43 a finales de 2026 conviene saltar directamente a F44 en lugar de esperar puntos de release. En entornos productivos críticos que ya están en Fedora 41 o 42, RHEL sigue siendo la opción de menor riesgo; los derivados comunitarios como Rocky Linux o AlmaLinux tomarán varias semanas en absorber los paquetes de F43 antes de considerarlos estables para producción.

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux