Linux 6.18 LTS: las 5 novedades que vas a notar en 2026

agosto 14, 2026 Alfonso Moreno | Sysadmin Senior 84 Visitas 13 min de lectura

El kernel Linux 6.18 fue liberado a fines de noviembre de 2025 por Linus Torvalds tras el ciclo habitual de 10 semanas con 7 release candidates. Para servidores en producción, la novedad más relevante es que Greg Kroah-Hartman confirmó 6.18 como rama LTS a principios de 2026, con un compromiso de mantenimiento de al menos 2 años (hasta finales de 2027) y backports de fixes de seguridad garantizados. Esto coloca a 6.18 como la opción recomendada para nuevas instalaciones de servidores y como el destino natural de migración desde 6.6 LTS (que entró en year-2 maintenance) y 5.15 LTS (cuyo EOL se acerca en 2027). Este artículo baja al detalle técnico de cada novedad relevante para sysadmins: drivers Nouveau con GSP, refinamientos del scheduler EEVDF y los nuevos io_uring buffers grandes, con datos concretos y comandos para medir el impacto en tu propio hardware.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué importa el estado LTS de un kernel

El kernel estable tiene dos categorías principales: las ramas mainline (Torvalds las libera cada 9-10 semanas) y las ramas stable/LTS (mantenidas por Greg Kroah-Hartman y un equipo de mantenedores). Lo que las diferencia:

Mainline: recibe nuevas features, drivers y cambios importantes. Vida útil: hasta que sale la siguiente mainline (~2 meses).
Stable: backport limitado de bugfixes de mainline. Vida útil: variable según comunidad.
LTS: backport más conservador, enfocado en seguridad y stability. Vida útil: 2 a 6 años según la rama. Es donde los vendors de distribuciones (RHEL, SUSE, Canonical) alinean sus kernels.

Para servidores en producción, usar una rama LTS significa que tu distro tiene un compromiso formal de mantener backports de seguridad durante años. Usar una rama mainline o stable no-LTS implica que cuando aparezca un CVE crítico, puedes quedar sin parche upstream y depender solo de los esfuerzos de tu distro.

Tabla resumen: 6 novedades relevantes de 6.18 para sysadmins

#	Novedad	Impacto en producción	Workloads beneficiados
1	Status LTS formal (mantenimiento hasta finales 2027)	Decisión de adopción: ahora es seguro para fleets	Todos
2	io_uring con buffers grandes (registered buffers extendidos)	Menos copies user↔kernel, throughput en I/O denso	DB (Postgres, MySQL), object storage, message brokers
3	Refinamiento del scheduler EEVDF + hints de Intel Thread Director	Mejor selección de P-cores vs E-cores en CPUs híbridas	Laptops con batería, servers con carga mixta
4	Drivers Nouveau con firmware GSP para RTX 40/50	Display output en GPUs NVIDIA modernas sin driver propietario	Workstations con NVIDIA, servidores con GPU
5	Soporte mejorado para erasure coding en btrfs y dm-integrity	Rebuild más resiliente, menor riesgo de pérdida durante recovery	NAS, storage servers, backups
6	Drivers actualizados para Apple M3/M4 (SoC Apple Silicon)	GPU y power management funcionales en Linux nativo	Macs ARM como servers de bajo consumo o workstations

1. io_uring con buffers grandes: lo que necesitas saber

io_uring fue introducido en 5.1 (2019) como una interfaz de I/O asíncrono que evita el overhead del modelo tradicional de syscalls (cada read/write involucra context switch y copy de datos entre user space y kernel). En 6.18 el subsistema recibió una mejora sustancial: soporte para buffers registrados grandes que pueden exceder el límite previo de 1 GB por buffer y trabajar con memoria pinned de forma más eficiente.

El beneficio concreto en producción: las aplicaciones que usan io_uring (Postgres 16+, RocksDB, recent versions of Redis con módulo io_threads, aplicaciones Rust con tokio-uring) pueden mover datos entre disco y memoria con cero copias para bloques grandes. En workloads I/O-bound, esto se traduce en mejoras de throughput del 10-25% según benchmarks publicados por el equipo de PostgreSQL.

Cómo verificar que io_uring está habilitado en tu kernel

# Verificar si el kernel actual tiene io_uring disponible
cat /proc/sys/kernel/io_uring_disabled
# Esperado: 0 (habilitado). Si devuelve 1 o 2, está restringido.
# Verificar que sysfs muestra las features disponibles
ls /sys/kernel/io_uring/
# Debería mostrar: features, max_iod_entries, max_p iod_entries, etc.
# Para ver los flags de features soportados por el kernel actual
cat /sys/kernel/io_uring/features | tr ',' 'n'

Habilitar io_uring si está deshabilitado

# Temporal (hasta reboot)
sudo sysctl kernel.io_uring_disabled=0
# Permanente
echo "kernel.io_uring_disabled = 0" | sudo tee /etc/sysctl.d/99-uring.conf
sudo sysctl -p /etc/sysctl.d/99-uring.conf

Por qué podría estar deshabilitado: algunas distros hardened (Ubuntu con kernel hardened, RHEL con FIPS mode, distros con política de seguridad CIS) traen io_uring deshabilitado por defecto porque históricamente fue vector de varios LPE. Si tu distro está en este caso y quieres usar Postgres moderno o aplicaciones que dependen de io_uring, tienes que decidir explícitamente.

Benchmark rápido para medir el beneficio real

# Test simple con fio (Flexible I/O Tester)
sudo apt install fio   # o: sudo dnf install fio
# Test secuencial con I/O directo (bypassa page cache)
sudo fio --name=seq-read --filename=/tmp/fio-test --size=1G 
  --rw=read --bs=1M --ioengine=io_uring --iodepth=32 
  --runtime=30 --time_based
# Output relevante: BW (bandwidth) y IOPS
# Comparar con libaio tradicional
sudo fio --name=seq-read-aio --filename=/tmp/fio-test --size=1G 
  --rw=read --bs=1M --ioengine=libaio --iodepth=32 
  --runtime=30 --time_based

La diferencia entre ambos ioengine en el mismo hardware te da una medida concreta del beneficio de io_uring en tu workload. Si la diferencia es marginal (<5%), probablemente no vale la pena optimizar a nivel de aplicación.

2. Scheduler EEVDF refinado + Intel Thread Director

El scheduler EEVDF (Earliest Eligible Virtual Deadline First) fue introducido en 6.6 y reemplazó al clásico CFS (Completely Fair Scheduler). En 6.18 el equipo de scheduler (Peter Zijlstra y colaboradores) refinó el manejo de hints de Intel Thread Director, la tecnología que en CPUs Intel 12th gen+ informa al sistema operativo qué tarea debería correr en P-cores (high-performance) vs E-cores (efficient), y el equivalente AMD preferred cores en Ryzen 7000+.

El problema que EEVDF refinada en 6.18 resuelve: en cargas con latencia crítica, el scheduler algunas veces colocaba tareas críticas en E-cores aunque hubiera P-cores disponibles, porque las hints de Thread Director no se traducían bien en decisiones de scheduling. El fix mejora la latencia P99 en workloads mixtos (database queries + background batch + networking) entre un 8-15% en mediciones internas del kernel.

Cómo verificar tu scheduler y la topología de tu CPU

# Ver el scheduler actualmente activo
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# Ver la topología de tu CPU (P-cores vs E-cores)
lscpu -e
# Output relevante: CPU, CORE, SOCKET, NODE, BOOK, L1d, L1i, L2, L3, MHZ, ...
# Las filas con la misma columna CORE suelen indicar pares P+E en CPUs híbridas.
# Ver información detallada de Intel Thread Director (si tu CPU lo soporta)
sudo cpupower monitor
# Output muestra frecuencia de cada core en tiempo real.
# Para CPUs AMD Ryzen 7000+: preferred cores
cat /sys/devices/system/cpu/cpu*/cpufreq/amd_pstate_highest_perf
# Los cores con valor más alto son los preferred cores.
# Ver qué core ejecutó qué proceso en un momento dado (requiere root)
sudo perf record -a -e sched:sched_switch -g sleep 5
sudo perf report

Para laptops con batería: el scheduler puede reducir consumo

# Medir consumo antes/después de un workload (en watts)
sudo apt install powerstat   # o: sudo dnf install powerstat
sudo powerstat -d 30   # sample cada 30s
# Alternativa más precisa (si tienes batería)
cat /sys/class/power_supply/BAT0/power_now
# Valor en microwatts; comparar idle vs carga

Si tienes una laptop con Intel 12th gen+ o AMD Ryzen 7000+, la diferencia en duración de batería entre 6.6 y 6.18 con la misma carga es típicamente del 10-20% a favor de 6.18 (gracias a la mejor selección de E-cores para tareas ligeras).

3. Nouveau DRM con firmware GSP: NVIDIA RTX sin driver propietario (parcial)

El driver open source Nouveau históricamente sufría con GPUs NVIDIA modernas porque NVIDIA no liberaba documentación suficiente. En 6.18, Nouveau carga el firmware GSP (GPU System Processor) de NVIDIA — un binario que corre en la GPU y maneja la inicialización y gestión de power. Esto habilita display output y modosetting en GPUs Ada Lovelace (RTX 40 series) y Hopper sin necesidad del driver propietario.

Limitaciones importantes

Display output funciona: consola, desktop, composición Wayland.
No hay aceleración 3D completa: OpenGL funciona parcialmente; Vulkan todavía no está al nivel del driver propietario.
No hay CUDA: para compute, necesitas el driver propietario sí o sí.
Sin NVENC/NVDEC: el encoding/decoding por hardware no está disponible.

El caso de uso real: si tienes una workstation con RTX 4070+ y necesitas Linux para trabajo de oficina/desarrollo (no gaming, no compute), Nouveau te da un sistema funcional sin el peso de instalar el driver propietario de NVIDIA. Para gaming o CUDA, sigues necesitando el driver propietario.

Verificar si tu GPU está soportada por Nouveau con GSP

# Identificar tu GPU
lspci | grep -i vga
# Output típico: 01:00.0 VGA compatible controller: NVIDIA Corporation AD104 [GeForce RTX 4070]
# Ver qué driver cargó el kernel (Nouveau vs nvidia)
lsmod | grep -E "nouveau|nvidia"
# Solo nouveau cargado = driver open source activo.
# Solo nvidia cargado = driver propietario activo.
# Ambos cargados = conflicto, hay que purgar uno.
# Ver el firmware GSP cargado (si usas Nouveau)
ls /lib/firmware/nvidia/
# Debería mostrar archivos gsp-*.bin (GSP firmware binarios)

4. Erasure coding: btrfs y dm-integrity con mejor recovery

El subsistema de storage de 6.18 trae mejoras en el manejo de errores durante rebuild de erasure coding (EC). El caso concreto que importa: si tienes un array btrfs RAID5/6 con un disco fallando, el proceso de reconstrucción históricamente podía encontrar errores de lectura en otros discos durante el rebuild, lo que resultaba en pérdida de datos. Con los cambios en 6.18, la política de manejo de estos errores durante rebuild es más conservadora: el sistema marca el área como sospechosa y la excluye del rebuild, en lugar de sobrescribir silenciosamente.

Para servidores de storage (NAS, backups), este cambio reduce significativamente el riesgo de pérdida de datos durante escenarios de fallo múltiple. La mejora es transparente para el usuario: no hay nuevos comandos, solo comportamiento más seguro.

Verificar tu configuración de storage

# Para btrfs
btrfs filesystem df /mnt/storage
btrfs filesystem show /mnt/storage
btrfs device stats /mnt/storage
# Para ZFS
zpool status
zpool list -v
# Para dm-integrity (LUKS con integridad)
sudo dmsetup table | grep integrity

5. Apple Silicon M3/M4: soporte mejorado

El proyecto Asahi Linux fue pionero en llevar Linux a Macs ARM, y su trabajo se sigue integrando upstream. En 6.18, los drivers para SoC M3 y M4 incluyen soporte más maduro de:

GPU: driver DCP (Display Controller Pipeline) funciona para desktop y video; aceleración 3D limitada.
Power management: control de frecuencia de CPU y GPU operativo, lo que permite uso realista como servidor de bajo consumo.
Thunderbolt/USB: drivers actualizados, soporte para docks externos.
Audio: speaker, micrófono y headphone jack funcionales.

Para casos de uso como servidor doméstico de bajo consumo (Mac mini M3 con 8-16 GB RAM), Linux 6.18 da una alternativa real al macOS nativo con mejor tooling de sysadmin.

Instalación en Mac Apple Silicon

# NO hacer esto en una Mac de trabajo — la instalación borra macOS.
# Usar Fedora Asahi Remix: https://asahilinux.org/fedora/
# Descargar imagen y seguir el script oficial de instalación.
# Después de instalado, verificar versión del kernel
uname -r
# Esperado en 6.18: 6.18.x-asahi o similar
# Verificar drivers cargados
lsmod | grep -E "apple|dcp"
# Debería mostrar módulos como apple_dcp, ans_codecd, etc.

Cómo actualizar a 6.18 según tu distribución

Arch Linux y openSUSE Tumbleweed (rolling)

# Arch
sudo pacman -Syu
sudo reboot
# openSUSE Tumbleweed
sudo zypper dup
sudo reboot

Fedora

# Fedora 43+ debería traer 6.18 por defecto
sudo dnf upgrade --refresh
sudo reboot
# En Fedora 42 o anterior: usar el COPR kernel-mainline
sudo dnf copr enable @kernel/kernel-mainline
sudo dnf install kernel-mainline
sudo reboot

Ubuntu 24.04 LTS

# HWE stack trae 6.18
sudo apt install linux-generic-hwe-24.04
sudo reboot
# Verificar versión después del reboot
uname -r
# Esperado: 6.18.x (después del reboot)
# Si tienes Ubuntu Pro: livepatch puede aplicar el kernel nuevo sin reboot
sudo pro enable livepatch

Debian 12 (bookworm)

# Debian 12 viene con 6.1 por defecto. Para 6.18, usar backports:
sudo apt install -t bookworm-backports linux-image-amd64
sudo reboot

RHEL 9 / Rocky 9 / AlmaLinux 9

# RHEL 9 viene con kernel 5.14 por defecto; 6.18 disponible via ELevate o RHEL 10
# Para RHEL 10 / beta: ya trae 6.18+
sudo dnf update kernel
sudo reboot

Cuándo NO actualizar a 6.18

6.18 LTS es la opción correcta para la mayoría de las nuevas instalaciones, pero hay escenarios donde esperar o quedarse en otra rama es mejor:

Servers con drivers propietarios críticos: si dependés de drivers fuera del árbol (drivers de GPU NVIDIA propietarios, drivers de HBA storage tipo broadcom/mpt3sas antiguos, drivers de NICs específicos), espera 2-3 meses después del release antes de actualizar. Los vendors suelen tardar en certificar compatibilidad con versiones nuevas del kernel.
Containers/kubernetes: si tu workload corre dentro de containers, el kernel del host importa menos. Actualizá el host cuando tu distro lo recomiende, no antes.
Fleet con imágenes golden disk: si tienes imágenes de golden disk quemadas con un kernel específico (común en embedded/IoT), validar la imagen con la nueva versión en staging antes de producción.
Sistemas con EOL cercano: si tu distro llega a EOL en 2026-2027, considera migrar a una nueva versión en lugar de hacer upgrade de kernel sobre una distro que muere. El esfuerzo de migrar distro es similar al de migrar kernel.

Comparativa rápida: 6.18 vs 6.12 vs 6.6 LTS

Característica	6.6 LTS	6.12 LTS	6.18 LTS (recomendado)
Status LTS	Year-2 maintenance (hasta dic 2026)	Año 1, soporte hasta dic 2027	Año 1, soporte hasta finales 2027
EEVDF base	Sí (introducido en 6.6)	Refinamientos	Refinamientos + Thread Director hints mejorados
io_uring large buffers	No	Limitado	Sí (buffers >1GB pinned)
Nouveau con GSP para RTX 40	No	Parcial	Sí (RTX 40 y 50 series)
Apple M3/M4 soporte	Básico	Mejor	Maduro
Erasure coding rebuild safe	No	No	Sí
Live patching soporte	Sí (kpatch, Ubuntu Pro)	Sí	Sí

Si tienes que elegir entre mantener 6.6 (year-2), migrar a 6.12 o saltar a 6.18: para nuevas instalaciones, 6.18. Para sistemas existentes en 6.6 que funcionan bien, puedes quedarte hasta fin de año y planificar la migración a 6.18 con tiempo.

Resumen

Linux 6.18 LTS es la opción sólida para servidores y workstations en 2026. Sus mejoras en scheduler (mejor selección de P/E cores), io_uring (buffers grandes pinned), Nouveau con GSP (NVIDIA RTX funcional sin driver propietario) y erasure coding (rebuild seguro) cubren las demandas más comunes de fleets modernos.

Antes de actualizar en producción, validá en un equipo de staging que tu workload específico no tiene regresiones. Medí throughput de I/O (fio), latencia bajo carga (perf sched), y consumo de batería si aplica (powerstat). Una semana de staging te puede ahorrar un incidente de producción.

Preguntas frecuentes

¿Por qué Linux 6.18 LTS: las 5 novedades que vas a notar en 2026 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 Linux 6.18 LTS: las 5?

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 Linux 6.18 LTS: las 5?

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 Linux 6.18 LTS: las 5 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 Linux 6.18 LTS: las 5?

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.