Actualizado: 9 de noviembre de 2026. Kernel.org marca Linux 7.2.15, del 1 de noviembre, como EOL y muestra Linux 7.3.3, del 6 de noviembre, como estable. Es motivo para revisar el inventario, no una orden de instalación para todos los equipos Linux. Importan el origen del paquete y el soporte del sistema concreto. [1]
Qué significa realmente el fin de vida
Esta guía está dirigida a usuarios experimentados de Linux y administradores. El fin de la rama upstream 7.2 no demuestra por sí solo que un paquete de la distribución haya dejado de recibir correcciones de seguridad. Los proveedores pueden adaptar correcciones a versiones anteriores y mantener plazos propios. Una familia antigua no prueba una vulnerabilidad sin corregir; una nueva tampoco prueba que un fallo concreto esté resuelto. Las versiones candidatas no son una recomendación general para producción. [2]
Preparación: asegurar primero la recuperación
Prepare una ventana de mantenimiento, una copia de seguridad verificada y un acceso de recuperación realmente disponible. En equipos remotos es importante una consola independiente: una sesión SSH abierta no sobrevive al reinicio. Documente el desbloqueo del cifrado, la selección de arranque y los controladores necesarios sin copiar claves al registro de trabajo. Una instantánea en el mismo disco no sustituye a una copia separada.
Cinco pasos para un cambio controlado
- Recopile el inventario sin realizar cambios.
uname -rmuestra el kernel en ejecución ycat /etc/os-releaseidentifica la distribución. Compruebe también el paquete de kernel instalado y su repositorio en el gestor de paquetes. En un contenedor,uname -rse refiere al kernel del anfitrión: el cambio corresponde al responsable del anfitrión, no a la imagen del contenedor. - Identifique la política de soporte correcta. Consulte los avisos para la distribución, edición, arquitectura y variante de kernel exactas. Ubuntu, por ejemplo, publica coberturas propias de productos y kernels. [4] Si el sistema sigue soportado y el paquete recibe correcciones, no abandone el canal del proveedor solo por el EOL upstream. Un kernel 7.2 compilado por usted requiere un sucesor mantenido y un plan de pruebas propio.
- Prepare la compatibilidad y el arranque alternativo. Revise el espacio libre en la zona de arranque y las indicaciones sobre módulos adicionales, DKMS, Secure Boot e initramfs. Conserve el kernel que funciona y sus módulos correspondientes; aprenda a seleccionarlo antes de una emergencia. No desactive protecciones para arrancar un paquete desconocido. Deténgase si la recuperación no está resuelta.
- Actualice mediante el procedimiento documentado. Use el canal de paquetes/imágenes soportado o el proceso de compilación propio previsto para esta instalación, no comandos sueltos ajenos. La documentación del kernel explica que compilar e instalar depende de la distribución. [3] Compruebe errores de instalación y módulos antes del reinicio previsto. Este artículo no modifica su sistema.
- Compruebe el resultado real tras reiniciar. Compare
uname -rcon el paquete instalado previsto. Pruebe almacenamiento, red, gráficos, servicios importantes y suspensión/reanudación en portátiles. En servidores, pruebe una nueva conexión externa. Un paquete instalado o un arranque satisfactorio no bastan.
Validar el resultado y recuperar el funcionamiento
Ante una regresión, vuelva al kernel conocido mediante la ruta de arranque/recuperación preparada, registre versiones y síntomas y consulte al proveedor. El kernel antiguo es una medida limitada de continuidad, no una solución permanente en una rama sin mantenimiento. Planifique la limpieza habitual solo tras una validación estable; no ejecute instrucciones genéricas de borrado.
Límites y fuentes
Procedimiento editorial, no un ensayo de kernel, hardware o ataque realizado por nosotros. No propone una versión universal, no afirma una corrección CVE ni garantiza compatibilidad. Prevalece la documentación actual del proveedor. Esta guía no comercial no contiene enlaces de afiliado.