Actualizar el núcleo necesita evidencia

La actualización puede estar en disco mientras sigue gobernando el núcleo de ayer.

Instalado y activo son distintos

El núcleo aplica muchos límites entre procesos y recursos. Su mantenimiento necesita evidencia del código en ejecución, no solamente de paquetes descargados. Los distribuidores pueden incorporar una corrección a una familia anterior de versiones; mirar únicamente la versión original puede confundir.

Reemplazar el núcleo suele requerir reiniciar para activarlo. Los parches en vivo compatibles aplican determinadas correcciones sin ese reinicio, pero contratar el servicio no demuestra cobertura ni aplicación correcta para todos los problemas.

Registro proporcionado: las reservas

Bea mantiene un servidor ficticio de reservas. Estas etiquetas inventadas ilustran el razonamiento, no un aviso real:

Aviso del proveedor: A está afectada; B incluye la corrección.
Inventario de paquetes: B instalada esta mañana.
Estado en ejecución: núcleo A.
Parches en vivo: ninguna corrección aplicable instalada.
Responsable: aprueba una ventana de mantenimiento esta noche.

Supón que los informes están actualizados y el aviso corresponde a la distribución y variante del núcleo. El reemplazo está disponible, pero el registro no justifica cerrar la corrección como activa. Tampoco contiene evidencia de explotación.

Cierra con evidencia operativa

Redacta una nota que exija el estado corregido previsto tras el mantenimiento aprobado, además de comprobaciones satisfactorias de reservas y recuperación. Asigna a Bea documentar las indicaciones pertinentes del proveedor y el estado resultante.

Si después aparece una corrección en vivo compatible, reevalúa ese problema concreto. No supongas que se completaron todas las actualizaciones pendientes. Distingue entrega del paquete, corrección efectiva y disponibilidad del servicio.