Kernel updates need completion evidence

An update can be on disk while yesterday's kernel is still in charge.

Installed and active are different

The kernel enforces many process and resource boundaries. Maintenance therefore needs evidence about running code, not just downloaded packages. Distributors may backport a correction into an older version family, so an upstream version label alone can mislead.

A kernel replacement commonly requires a restart to become active. Supported live patching can apply particular corrections without that restart, but enrollment in a live-patching service does not prove coverage or successful application for every issue.

Supplied record: the booking desk

Bea maintains a fictional booking server. These invented build labels illustrate the reasoning, not a real advisory:

Vendor notice: this server’s build A is affected; build B includes the correction.
Package inventory: B installed this morning.
Running-state report: kernel build A.
Live-patch record: no applicable correction installed.
Service owner: approves a maintenance window tonight.

Assume the reports are current and the advisory matches the server’s distribution and kernel variant. The replacement is available, but this record does not support closing the correction as active. It also contains no evidence of exploitation.

Close with operating evidence

Write an acceptance note requiring the intended corrected running state after the approved maintenance, plus healthy booking and recovery checks. Assign Bea to attach the relevant vendor guidance and resulting state.

If a later record shows a supported live correction, reassess that specific issue rather than assuming every pending update is complete. Preserve the difference between package delivery, effective correction, and service availability.