Kernel HWE o GA en tu servidor Ubuntu: cuál elegir

¿Una versión de mantenimiento instala un kernel nuevo en mi servidor Ubuntu?

No. En un servidor Ubuntu, la elección entre el kernel HWE y el kernel GA depende de un paquete que se instala por separado. Una versión de mantenimiento no lo instala automáticamente. La palabra «enablement» se usa con dos funciones diferentes en las notas de la versión, y ahí empieza la confusión. Hardware enablement (HWE) es la rama de kernel más reciente. Upgrade enablement es el momento independiente en que se abre la ruta de actualización de una versión LTS a la siguiente. Un servidor que ya está en ejecución y usa GA permanece en GA durante todas las versiones de mantenimiento de su versión LTS.

Qué son las ramas de kernel GA y HWE

GA (disponibilidad general) es el kernel con el que Ubuntu LTS se publica el día del lanzamiento. Mantiene la misma versión de kernel upstream durante el periodo de soporte estándar de la versión. Las correcciones de seguridad y los errores se incorporan mediante backport, por lo que el último número de uname -r cambia cada pocas semanas. La versión upstream al principio de la cadena no cambia.

HWE (habilitación de hardware) es la otra rama. Canonical incorpora al LTS el kernel de cada versión intermedia posterior y se detiene en el kernel del siguiente LTS. Por eso, el kernel de habilitación pasa a una versión upstream más reciente aproximadamente cada seis meses hasta alcanzar esa última versión. Canonical denomina a esto modelo de actualización continua. El kernel de habilitación final es el kernel GA del siguiente LTS y mantiene esa versión upstream durante el resto del ciclo del LTS, incorporando correcciones del mismo modo que GA. Las imágenes de escritorio instalan el kernel de habilitación de forma predeterminada. Las imágenes de servidor y de nube instalan GA de forma predeterminada, y la pila de habilitación se instala mediante un paquete opcional.

La diferencia es sencilla. GA ofrece una versión de kernel que no cambia durante años. HWE ofrece controladores y funciones de kernel más recientes, pero requiere actualizar la versión y reiniciar aproximadamente cada seis meses mientras la rama siga en actualización continua.

¿Qué rama del kernel estoy usando ahora?

uname -r nunca contiene la palabra hwe. Ambas ramas muestran una versión que termina en -generic, por lo que el nombre del kernel en ejecución no responde por sí solo a la pregunta. El metapaquete instalado indica qué rama siguen sus actualizaciones, y compararlo con uname -r indica qué kernel está ejecutándose realmente.

uname -r
grep VERSION_ID /etc/os-release
apt-cache policy linux-generic linux-generic-hwe-24.04

Sustituya 24.04 por el número que muestra VERSION_ID en su propia máquina. apt-cache policy muestra una línea Installed: por cada paquete que indique. Esa línea confirma que un paquete está instalado, pero no que su kernel sea el que está ejecutándose. Installed: (none) para el paquete -hwe-, junto con una versión para linux-generic, significa que sus actualizaciones siguen GA, siempre que no haya otro metapaquete de enablement instalado, como linux-virtual-hwe-24.04. Los comandos siguientes lo comprueban. Lo contrario significa que sigue la rama de enablement. Si ambos tienen una versión, ambos kernels están en el disco. Con el GRUB_DEFAULT=0 predeterminado de Ubuntu, GRUB arranca el más reciente, que es el de enablement, pero si alguien estableció GRUB_DEFAULT en una entrada específica o en saved, el kernel GA todavía puede ser el que arranque. Sólo uname -r indica qué kernel está ejecutándose.

Algunas imágenes de proveedores instalan linux-image-virtual en lugar de linux-generic. Es un conjunto de módulos más pequeño creado para máquinas virtuales y tiene su propia variante de enablement. No adivine el nombre. Consulte qué paquetes del kernel se eligieron en la máquina y, después, qué paquetes de enablement existen en el archivo para su versión.

apt-mark showmanual | grep '^linux-'
apt-cache search linux-image | grep hwe
apt-cache depends linux-image-generic-hwe-24.04
dpkg -l 'linux-image-*' | grep '^ii'
ls /boot/vmlinuz-*

apt-cache depends muestra a qué imagen del kernel apunta actualmente el metapaquete de enablement. Si la versión de esa imagen coincide con uname -r, está ejecutando el kernel de enablement. ls /boot/vmlinuz-* muestra qué está instalado y se puede arrancar realmente, que a menudo es más de lo esperado.

Qué hace cada lanzamiento menor en cada rama

En la rama GA, un lanzamiento menor no cambia nada en un servidor en ejecución. Un lanzamiento menor es una imagen de instalación actualizada junto con las actualizaciones que apt ya le ha estado entregando. Determina qué recibe una máquina recién construida, no qué ejecuta una máquina existente. Qué cambia realmente un lanzamiento menor de Ubuntu explica el resto.

En la rama de habilitación, el metapaquete cambia durante un ciclo ordinario de actualización del kernel que tiene lugar antes del lanzamiento menor, no el día del lanzamiento. Mientras la rama siga avanzando, Canonical actualiza el kernel de habilitación antes de cada lanzamiento menor de una LTS posterior al primero, hasta llegar al que incorpora el kernel GA de la siguiente LTS. En 24.04 fue 24.04.5, con 7.0. Después de ese paso, un lanzamiento menor no incorpora ningún kernel de habilitación nuevo: Ubuntu 20.04.6 se publicó en marzo de 2023, pero la página del ciclo de vida de los kernels de Ubuntu indica que 5.15, procedente de 20.04.5, fue el último kernel de habilitación de 20.04. Para 24.04.3, publicado el 2025-08-07, el cambio de 6.11 a 6.14 estaba previsto para el ciclo SRU del kernel de 2025.06.16. linux-image-generic-hwe-24.04 cambia su dependencia a una imagen de kernel más reciente, y la siguiente ejecución de actualización ordinaria instala esa imagen. La página del manual de apt explica claramente por qué basta una ejecución normal de la actualización: "Se instalarán paquetes nuevos si son necesarios para satisfacer dependencias, pero nunca se eliminarán paquetes existentes." Por tanto, apt upgrade incorpora el kernel nuevo. Este sólo pasa a ser el kernel en ejecución después del siguiente reinicio.

En 24.04, la transición ya ha terminado. A fecha de 2026-10-21, linux-generic-hwe-24.04 en amd64 depende de una imagen de kernel 7.0, que es el kernel GA de 26.04. A partir de ese momento, esa rama recibe correcciones, pero no más saltos de versión del kernel principal.

Que un trabajo desatendido haga esto depende de su propia configuración. Lea /etc/apt/apt.conf.d/50unattended-upgrades y revise el bloque Allowed-Origins. La configuración predeterminada incluida habilita los repositorios de lanzamiento y seguridad, y deja comentado el repositorio de actualizaciones. Esto no impide los cambios de habilitación, porque Ubuntu también publica las actualizaciones de los metapaquetes del kernel, incluidos esos cambios, en el repositorio de seguridad. A fecha de 2026-10-21, la versión 7.0.0-38.38~24.04.4 de linux-generic-hwe-24.04 está publicada en noble-security. Por tanto, con la configuración predeterminada y el metapaquete de habilitación instalado, unattended-upgrades instala por sí solo cada kernel de habilitación nuevo. El kernel sólo se ejecuta después de un reinicio. Compruebe el archivo en lugar de asumir una cosa u otra.

Los periodos de soporte se derivan del mismo mecanismo. El kernel GA recibe soporte durante el periodo estándar de la versión LTS sin que tenga que hacer nada. Cada kernel de habilitación recibe soporte hasta que lo sustituye el siguiente kernel de habilitación. El último es la excepción: recibe soporte durante el resto de la LTS. Hasta llegar a ese último paso, HWE sólo es una rama compatible mientras se instalen todos los pasos. Si se queda dos pasos atrás en esa rama, el sistema ejecuta un kernel que ya no recibe correcciones, y apt no indicará nada al respecto.

No tome fechas exactas de ninguna entrada de blog, incluida esta. Canonical publica las fechas de finalización del soporte de los kernels en la página del ciclo de vida de los kernels de Ubuntu, y las fechas de lanzamiento y soporte en la página del ciclo de versiones de Ubuntu. Sin embargo, la tabla de kernels no incluye todos los kernels. A fecha de 2026-10-21 no contiene ninguna fila para los kernels de habilitación 6.11 y 6.14 de 24.04, ni para 5.19, 6.2 y 6.5 de 22.04, por lo que no hay ninguna fecha de finalización que consultar para ellos. Las filas disponibles muestran el patrón del párrafo anterior: 6.17, el kernel de habilitación de 24.04.4, llegó al final del soporte estándar en julio de 2026, el mismo mes en que 7.0 lo sustituyó en esa rama. Compare esas páginas con lo que uname -r y grep VERSION_ID /etc/os-release muestran en su servidor. Ese conjunto de dos datos es lo único que describe su máquina.

Por qué el kernel HWE rara vez ayuda en un VPS

HWE existe para el hardware. Un portátil o un servidor físico con una NIC (tarjeta de interfaz de red), un controlador de almacenamiento o una GPU más nuevos que el kernel LTS no funcionan correctamente hasta que llega un kernel más reciente. El kernel HWE resuelve ese problema y, en hardware real, a menudo marca la diferencia entre una máquina operativa y una que no arranca.

Un VPS alquilado no tiene ese problema porque no ve ese hardware. El sistema invitado ve un conjunto reducido y deliberadamente antiguo de dispositivos virtuales. Compruebe el suyo.

sudo apt install -y pciutils
lspci -nnk

lspci -nnk muestra cada dispositivo y, debajo, el controlador del kernel asociado. En la mayoría de las instancias VPS, la lista es corta: virtio_net para la red y virtio_blk o virtio_scsi para los discos. Esos controladores forman parte del kernel principal desde hace muchos años. El dispositivo virtual ofrece una interfaz estable de forma intencionada, porque el sistema invitado debe seguir funcionando cuando el proveedor lo mueve a otro hardware físico. Por tanto, el motivo principal para instalar el kernel HWE normalmente no existe en un servidor alquilado.

El coste sí existe. Cada actualización HWE instala un binario de kernel nuevo y requiere su propio reinicio, además de los reinicios que ya realiza para instalar kernels de seguridad. En un VPS único sin otro sistema al que conmutar, el reinicio implica una interrupción que debe programar y supervisar. El parcheo dinámico del kernel puede eliminar algunos reinicios de seguridad, pero no puede eliminar el reinicio necesario para cambiar de versión, porque se trata de un kernel diferente y no de un kernel parcheado.

Cuándo debería cambiar al kernel enablement

Hay cuatro casos en los que la respuesta es realmente afirmativa.

• El hipervisor ofrece un dispositivo que su kernel no puede controlar. El síntoma es concreto: falta una interfaz en ip -brief link o un disco en lsblk, aunque el dispositivo aparece en lspci -nnk y no hay ninguna línea Kernel driver in use: debajo.
• El software que ejecuta documenta una versión mínima del kernel superior a la suya. Los runtimes de contenedores, las bases de datos y las herramientas eBPF hacen esto. Compare el mínimo indicado por el proveedor con uname -r y siga la recomendación del proveedor.
• Ha encontrado un error que se corrigió upstream después de la versión GA y no se incorporó mediante un backport. Confirme que la corrección esté realmente en la versión enablement antes de cambiar, o tendrá que reiniciar el servidor y conservará el error.
• Necesita una función del sistema de archivos o de red incorporada después de la versión GA, y esa función es el motivo por el que existe el servidor.

Si ninguno de estos casos describe su servidor, GA es la opción correcta. Dejarlo sin cambios es una decisión, no una negligencia.

Cómo cambiar de kernel y qué comprobar después del reinicio

Compruebe primero el espacio libre. Si /boot es una partición independiente pequeña, añadir una segunda línea de kernel puede llenarla y apt se detendrá con la configuración a medias junto con No space left on device.

df -h /boot
sudo apt update
sudo apt install --install-recommends linux-generic-hwe-24.04
ls /boot/vmlinuz-*
sudo reboot

Cuando el servidor vuelva a estar disponible, confirme qué ha cambiado y qué no.

uname -r
ip -brief link
lsblk
journalctl -k -b 0 -p err --no-pager

uname -r ahora debería coincidir con la imagen apt-cache depends linux-image-generic-hwe-24.04 especificada. En 24.04, eso significa actualmente una versión upstream superior a la anterior: 7.0 en lugar de 6.8. En una versión cuyo canal de enablement todavía no haya avanzado, la versión upstream puede mantenerse igual: a fecha de 2026-10-21, tanto linux-generic como linux-generic-hwe-26.04 en 26.04 dependen de 7.0.0-38.38. Las listas de red y de discos deberían ser exactamente iguales que antes, porque los mismos dispositivos virtuales siguen presentes. La ausencia de una interfaz es el único fallo importante en este caso, porque normalmente significa que sólo se puede acceder al servidor desde la consola del proveedor. journalctl -k -b 0 -p err muestra los mensajes del kernel de este arranque con prioridad de error o superior (err, crit, alert y emerg), que en un VPS en buen estado está vacío o contiene muy pocas líneas. Lectura del registro del kernel en un VPS explica qué significan las líneas ruidosas. No elimine el kernel antiguo el mismo día. Es su forma de volver atrás.

Cómo volver atrás si el kernel nuevo da problemas

El kernel anterior sigue instalado y aparece en el menú de GRUB. Abra la consola de su proveedor, reinicie y seleccione el kernel anterior en «Advanced options for Ubuntu». Hacerlo una vez confirma que el kernel anterior todavía arranca. Mantener esta selección después de los reinicios es una tarea distinta, que se explica en fijar el kernel con el que arranca su VPS. Si la máquina no vuelve a arrancar y la consola muestra un indicador de GRUB o un kernel panic, un VPS que no arranca después de actualizar el kernel explica el procedimiento de recuperación.

Una vez que haya arrancado con un kernel que funcione, revierta los paquetes.

sudo apt install linux-generic
sudo apt remove linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04
sudo reboot

Eliminar los meta-paquetes impide que llegue el siguiente paso de habilitación. No elimina la imagen del kernel ya instalada, por lo que no cambia nada mientras el sistema está en ejecución. Después de reiniciar, confirme que uname -r vuelve a mostrar la versión GA. sudo apt autoremove --purge elimina algunas imágenes antiguas, pero no necesariamente la que acaba de abandonar. APT siempre conserva el kernel en ejecución y el kernel instalado más reciente, y la imagen de habilitación suele ser la más reciente. Cuando uname -r confirme que no está ejecutando esa versión, elimine por nombre sus paquetes linux-image-, linux-modules- y linux-modules-extra-, usando la versión que muestra dpkg -l 'linux-image-*'. Eliminar los kernels antiguos de /boot explica el caso más complejo, en el que /boot se llenó antes de llegar aquí.

Hay otro aspecto importante: la cuestión de la rama se resuelve en la siguiente LTS. Pasar a la siguiente LTS le proporciona su kernel GA, que es más reciente que el kernel GA que usa actualmente, y reinicia el periodo de soporte. Si está considerando las versiones intermedias porque planea hacer ese cambio, actualizar 24.04 a 26.04 es el procedimiento. Mantenerse en GA hasta entonces es una decisión normal y justificable para un servidor alquilado.

FAQ

¿Una versión de mantenimiento cambia el kernel en un servidor que ya he instalado?

No en el canal GA. Una versión de mantenimiento es principalmente una imagen de instalación actualizada, por lo que determina qué obtiene una máquina nueva. Un servidor existente conserva el canal que indican los nombres de sus metapaquetes instalados. Si hay un paquete linux-...-hwe-... instalado, la activación llega como una actualización normal del kernel, publicada antes de la versión de mantenimiento a la que pertenece, y el siguiente apt upgrade la instala. El nuevo kernel empieza a ejecutarse en el siguiente reinicio, no cuando apt termina.

¿Cómo sé si estoy ejecutando el kernel HWE o el GA?

Ejecute apt-cache policy linux-generic linux-generic-hwe-24.04 y sustituya 24.04 por su propio número de versión. El paquete que tenga una versión real en su línea Installed: es el canal que siguen sus actualizaciones. Esto no demuestra qué kernel está ejecutándose, así que compare uname -r con los nombres de imagen apt-cache depends linux-image-generic-hwe-24.04. No intente determinar el canal sólo con uname -r, porque el nombre del kernel en ejecución termina en -generic en ambos canales y nunca contiene hwe. Si no hay ninguno de los dos paquetes instalado, ejecute apt-mark showmanual | grep '^linux-', ya que algunas imágenes de proveedores usan en su lugar la familia linux-image-virtual.

¿El kernel HWE es menos estable que el kernel GA?

Cada kernel de activación es un kernel de Ubuntu con soporte, así que no es una cuestión de calidad. Es una cuestión de cambios. El kernel GA mantiene una versión de upstream durante años, por lo que el comportamiento con el que hizo las pruebas permanece sin cambios. El kernel de activación pasa a una versión de upstream más reciente aproximadamente cada seis meses hasta alcanzar el kernel de la siguiente LTS, y cada uno de esos cambios puede modificar el controlador predeterminado o un sysctl durante su carga de trabajo. En un servidor que rara vez modifica, tener menos componentes cambiantes vale más que disponer de controladores más recientes.

¿Debería usar mi VPS el kernel HWE?

Normalmente, no. Una máquina virtual ve un conjunto fijo de dispositivos virtuales, principalmente virtio, cuyos controladores llevan años en el kernel, por lo que el soporte de hardware que proporciona el canal de activación no aporta nada a un VPS. Los reinicios adicionales siguen siendo necesarios. Cambie por un motivo concreto: un dispositivo que el kernel actual no pueda controlar o una versión mínima documentada del kernel que necesite el software que debe ejecutar.

¿Qué ocurre si instalo el kernel de activación y nunca reinicio?

La nueva imagen del kernel se escribe en /boot y se añade al menú de GRUB, mientras el servidor sigue ejecutando la anterior. uname -r indica qué se está ejecutando realmente, no la lista de paquetes. Ubuntu crea /var/run/reboot-required cuando un paquete instalado necesita un reinicio para aplicar sus cambios, por lo que ls -l /var/run/reboot-required indica que hay un reinicio pendiente. Hasta que se produzca ese reinicio, ocupa espacio en disco con el nuevo kernel sin obtener ninguna de sus correcciones.