Actualización del kernel de Linux, dejando el resto del sistema como está

Soy un usuario de OpenBSD. En las preguntas frecuentes de OpenBSD dice:

OpenBSD es un sistema completo, destinado a mantenerse sincronizado. No es un núcleo más utilidades que se pueden actualizar por separado.

Cuando actualiza un sistema, lo hace de una vez; Se reemplaza el núcleo y el sistema base. Luego vas y actualizas tus paquetes de terceros . Si compila desde la fuente , recompila el kernel y lo inicia. Luego reconstruye el sistema base y luego los paquetes que tiene instalados. Si han pasado más de un par de semanas / meses desde la última vez que reconstruyó todo, primero instale una instantánea y reconstruya desde allí (si está siguiendo la rama CVS más reciente).

Tener un núcleo no sincronizado, un sistema base y / o paquetes de terceros es una fuente potencial de problemas y lo descalifica más o menos para que no reciba ayuda seria de las listas de correo oficiales.

Estoy bastante de acuerdo con esto. De hecho, esta es una de las razones por las que uso OpenBSD. Hace que el sistema sea una unidad consistente y me facilita formar una descripción mental del mismo.

¿Cómo es en Linux? La mayoría de los Linux que conozco no tienen un "sistema base" en el mismo sentido que los BSD, sino una colección de paquetes ensamblados por el proveedor de distribución. Luego, un administrador local agrega más software a esto de tal manera que el límite entre lo que estaba allí desde el principio y lo que se agregó después es, en el mejor de los casos, borroso.

¿Linux (en general) no tiene un núcleo fuerte para el acoplamiento del espacio de usuario? El núcleo se actualiza, hasta donde yo sé, como cualquier otro paquete de software, y me confunde un poco que esto es posible. Agregue a esto el hecho de que algunos incluso compilan núcleos personalizados (que se desaconseja en OpenBSD), y tienen una multitud de varias versiones de kernel enumeradas en sus menús de arranque.

¿Quién o qué garantiza que los diversos subsistemas de un sistema Linux pueden cooperar entre sí a pesar de que se actualizan de forma independiente?

La razón por la que pregunto es porque otro usuario en este sitio me preguntó si reemplazar el kernel en su sistema Linux con una versión más nueva "sería factible". Desde el lado de OpenBSD, no podría decir que sí, esto garantizaría que no se rompa el sistema.

Utilizo "Linux" arriba como una abreviatura de "distribución de Linux", kernel + utilidades.

Linus Torvalds tiene una opinión muy firme contra los cambios en el kernel que resultan en regresiones del espacio del usuario (para más detalles, consulte la pregunta " El kernel de Linux: romper el espacio del usuario ").

La interfaz entre el espacio de usuario y el núcleo se proporciona mediante llamadas al sistema. Los núcleos más nuevos pueden tener más llamadas al sistema y cambios en los existentes cuando esos cambios no interrumpen las aplicaciones existentes. Cuando una interfaz de llamada del sistema tiene un parámetro de marca, los nuevos núcleos a menudo exponen la nueva funcionalidad con una nueva marca de bits. De esta forma, el núcleo mantiene la compatibilidad con las aplicaciones antiguas.

Cuando no ha sido posible alterar la interfaz existente sin romper el espacio del usuario, se han agregado llamadas al sistema adicionales que brindan la funcionalidad extendida. Es por eso que hay tres versiones dupy dos versiones de la umountllamada al sistema.

La política de tener un espacio de usuario estable es la razón por la cual las actualizaciones del kernel rara vez causan problemas en las aplicaciones del espacio de usuario y generalmente no se esperan problemas después de actualizar el kernel.

Sin embargo, la misma estabilidad API no está garantizada para las interfaces del núcleo y otros detalles de implementación . Sysfs (on /sys) y procsfs (on /proc/) exponen los detalles de implementación del kernel en la configuración de tiempo de ejecución, hardware, red, procesos, etc. que utilizan las aplicaciones de bajo nivel. Es posible que esas interfaces cambien de forma incompatible entre las versiones del kernel si hay una buena razón para hacerlo. Los cambios aún intentan minimizar las incompatibilidades, si es posible, y existen reglas sobre cómo las aplicaciones pueden usar las interfaces de la manera menos probable que causen problemas. El impacto también es limitado porque las aplicaciones que no son de bajo nivel no deberían usar estas interfaces.

@PeterCordes señaló que si un cambio en procfs o sysfs rompe una aplicación utilizada por sus scripts de inicio de distribución, podría tener un problema.

Esto depende en cierta medida de cómo su distribución actualice el núcleo (soporte a largo plazo o línea principal) e incluso entonces los problemas son relativamente raros ya que las distribuciones generalmente envían las herramientas actualizadas al mismo tiempo.

@StephenKitt agregó que el espacio de usuario actualizado podría requerir una versión más nueva del kernel, en cuyo caso el sistema podría no ser capaz de arrancar con el kernel anterior y las notas de la versión de distribución mencionan esto cuando es apropiado.

El kernel de Linux y el espacio de usuario de una distribución de Linux, que históricamente estuvo dominado por las herramientas de usuario desarrolladas por el proyecto GNU, están poco acoplados. En parte esto es por diseño, y en parte es por necesidad.

A diferencia de los BSD, donde el núcleo y el espacio de usuario base están diseñados y mantenidos juntos, el núcleo de Linux y su espacio de usuario fueron desarrollados y mantenidos por diferentes personas. Por lo tanto, mantenerlos estrechamente unidos sería difícil, incluso si la comunidad lo deseara, lo que no creo que haga.

Y @sebasth también señala que una política importante del proyecto del kernel de Linux es que no debe romper el espacio del usuario. Lo cual, por supuesto, es otro factor que impone el acoplamiento suelto.

Sin embargo, todavía hay cierto grado de acoplamiento. Un kernel de Linux suficientemente antiguo no funcionará con distribuciones modernas.

Tengo entendido que Linux es el núcleo, y todo lo demás es auxiliar. Definitivamente puede actualizar el kernel independientemente de (muchos) paquetes instalados, ya que generalmente están vinculados a bibliotecas en lugar de al kernel en sí. En general, solo verá dicho acoplamiento entre las versiones del kernel y los controladores de hardware (por ejemplo, controladores de GPU). Algunos programas solo son compatibles con ciertas versiones del kernel, pero eso debe especificarse en la documentación individual de esos programas.

Es bastante común tener dos conjuntos de paquetes de kernel instalados en un sistema: el paquete utilizado actualmente y el paquete instalado previamente. Al actualizar, después de asegurarse de que la nueva versión funcione correctamente, se puede eliminar la más antigua y aún tiene un respaldo seguro conocido. Red Hat (y sus primos), por ejemplo, tiene package-cleanup --oldkernels --count 2que hacer esto de forma automática.

Además de todos los buenos argumentos aquí, puedo agregar algunos puntos que ayudarán.

Ya conocemos la política del equipo del kernel y, como distribuciones de Linux, tratamos de mantener el código fuente del kernel lo más puro posible. Esto significa que, cada vez que surge una vulnerabilidad, o algo que necesita un parche, informamos al equipo del kernel e intentamos ayudar con los parches, pero al final, la decisión final es del equipo del kernel.

Algunas distribuciones agregan parches adicionales más que otros, pero la idea es mantenerlo tal como proviene de desarrolladores anteriores. Obviamente, hay algunos programas que necesitan una configuración especial del núcleo, especialmente la virtualización y los controladores de terceros y, por lo general, ambos se utilizan para trabajar con una versión específica del núcleo o al menos una versión no demasiado antigua ... la razón es que lo intentan para trabajar con las funciones más recientes del núcleo y, por eso, si intenta ejecutarlas con un núcleo antiguo, es posible que no se ejecuten correctamente.

Un elemento adicional a tener en cuenta es que todas las distribuciones de Linux tienen un equipo de mantenedores, personas que aseguran que todo el software es compatible con el sistema. Es por eso que casi todas las distribuciones tienen una versión estable e inestable. Los desarrolladores trabajan con software "inestable" y cuando todo se prueba lo marcan como estable, solo después de eso, un usuario normal puede actualizar el paquete, por lo que si la persona que le preguntó si es un usuario normal tiene un 90% de seguridad de que el software está bien probado .

Entonces, quién es, la comunidad, y luego cuál debería ser el enfoque común, necesitamos un software que trabaje en conjunto y no rompa el sistema, es por eso que tratamos de seguir algunos estándares como el Estándar de Jerarquía del Sistema de Archivos .