Actualización del núcleo: por qué la actualización más peligrosa es la más silenciosa

Una actualización del núcleo se instala, la instalación termina sin problemas y nada parece haber cambiado. El sistema sigue corriendo con el núcleo viejo, porque un núcleo nuevo solo entra en juego al reiniciar.

Y ahí es precisamente donde se esconde el peligro.

Entre causa y efecto se meten semanas

La mayoría de los fallos de paquetes aparecen mientras estás mirando. Un servicio se cae, da error, te enteras el mismo día.

El núcleo no es así. El problema aparece en el siguiente arranque, y ese arranque puede no ser una noche de mantenimiento planificada. Se va la luz, la máquina se reinicia sola, y no vuelve.

En ese momento nadie lo relaciona con "la actualización que hice el mes pasado". Lo que tienes es una avería inexplicable que no parece en absoluto un problema de actualización.

El principio general: lo nuevo no debe ser lo predeterminado hasta que se demuestre

Esta es la lección trasladable de este artículo, y no vale solo para núcleos.

Un núcleo nuevo se puede instalar, pero lo predeterminado persistente debe seguir siendo el núcleo viejo. Lo nuevo solo debe probarse como "prueba esto una vez en el próximo arranque".

Montado así, la forma del fallo cambia: si la máquina se queda colgada, en el arranque siguiente vuelve sola al viejo. Porque una elección de un solo uso vale, por definición, una vez.

Lo que ganas es esto: el nombre del fallo pasa a ser "no pasó nada", no "la máquina desapareció".

La segunda capa: lo instalado no debe volverse predeterminado en silencio

En cuanto se instala un núcleo, la mayoría de los sistemas dicen "a partir de ahora arranco con el más nuevo". Si no quieres eso, antes de actualizar hay que fijar el núcleo en marcha.

Fijar no bloquea el núcleo nuevo, solo le impide volverse predeterminado por sí solo. Cuando quieras probarlo, eliges tú.

La tercera capa: quién va a notar el cuelgue

Para que un mecanismo de repliegue funcione, algo tiene que decir "esta máquina no arrancó". Si hay un vigilante a nivel de hardware, eso lo hace él y reinicia la máquina.

Si no lo hay, el repliegue exige un reinicio manual. Eso no hace inútil el mecanismo, pero hay que saberlo: la frase "vuelve atrás automáticamente" es solo media verdad sin vigilante.

La regla que vale incluso sin producto

Tras una actualización del núcleo, reinicia a propósito y pronto. Mientras estás mirando.

Un reinicio que planificaste tú es una prueba. Un reinicio impuesto tres semanas después por un corte de luz es un incidente. La única diferencia entre los dos es si estabas delante en ese momento.

Qué hace Atlas

Cuando Atlas hace una actualización, fija por defecto el núcleo en marcha, de modo que el núcleo recién instalado no se convierta por sí solo en el predeterminado de arranque. Este comportamiento no es obligatorio: se ofrece como una opción que se puede desactivar en la interfaz. El producto no decide aquí, hace que lo predeterminado sea el lado seguro.

El mecanismo de transición verificada también está construido sobre el principio anterior: lo predeterminado persistente es siempre el núcleo viejo, el nuevo solo se prueba con un arranque de una sola vez, y si se cuelga el sistema vuelve solo. El tipo de gestor de arranque se detecta en tiempo de ejecución, porque cambia de máquina a máquina.

Y dos límites honestos:

Este mecanismo funciona por defecto en modo de solo observación. Es decir, dice qué haría pero no toca la configuración de arranque. Intervenir de verdad es una elección aparte.

Si no hay vigilante de hardware, el mecanismo no lo pasa por alto en silencio: se desactiva con elegancia y dice que puede hacer falta un reinicio manual. Aparentar una garantía que no existe es peor que no dar ninguna.