Kernel patching: running versions, live patches and safe reboots
Separate installed and running kernels, understand live-patch limits and choose a reboot batch from service capacity. Verify recovery with kernel, boot and application evidence.
TL;DR: Installing a kernel package does not prove the running kernel contains the intended fix. Verify the active kernel or live-patch state, then coordinate required reboots around service capacity, failure domains and a tested recovery path.
Installed software and executing software can differ
A conventional kernel update writes a new kernel and associated files to disk. The machine normally starts that kernel on a subsequent boot. uname -r reports the running kernel release; package-manager inventory answers a different question. Distribution security fixes can be backported, so comparing upstream version numbers alone can also misclassify exposure.
Identify the vendor advisory, affected package and fixed distribution build. Record the active kernel, installed packages and any live-patch status against that advisory. A reboot-required marker is useful operational evidence where the distribution provides one, but it is not a portable proof that every process and component is current.
Linux system calls and processes explains the boundary affected by a kernel change. User-space library updates can separately require process restarts even when the kernel is already current.
Live patching has a coverage boundary
Live-patch services apply supported changes to a running kernel. They do not make every future kernel update, firmware change or low-level repair reboot-free. Canonical's reboot guidance distinguishes supported live fixes from changes requiring a newer booted kernel.
Use live patching when it closes the relevant exposure and buys time for a controlled maintenance window. Verify that the exact running kernel and vulnerability are covered. Keep the ordinary package-update and reboot lifecycle: an enabled service is not evidence that every relevant advisory has been applied.
Worked capacity decision
Consider an illustrative stateless service with six equivalent nodes. Each safely handles 100 requests per second at the target latency, while current demand is 420 requests per second. Removing two nodes leaves only 400 requests per second of safe capacity. A two-node patch batch therefore violates the operating target even though four of six nodes remain online.
A one-node batch leaves 500 requests per second, but only 80 requests per second of margin under the assumed steady demand. Check traffic variation and failure tolerance before accepting that batch. Adding temporary capacity or scheduling a lower-demand window may be justified. The arithmetic must use tested safe capacity, not the maximum throughput observed while latency was already unacceptable.
Select a canary representative of the kernel flavor, hardware and workload. Drain new traffic, wait for bounded in-flight work, reboot and verify the active kernel plus application behavior. SSH recovery alone is insufficient. A storage driver regression can allow login while the application fails under I/O.
This example is stateless. A database quorum or replicated storage system needs its own membership and recovery constraints. “One at a time” is not automatically safe when a second member is already unavailable.
| Evidence | Question answered | Remaining limitation |
|---|---|---|
| Vendor fixed-package advisory | Which distribution build addresses the issue? | Does not prove installation |
| Package inventory | Is the approved package present? | Does not identify the executing kernel |
| Running kernel and live-patch status | What code/fixes are active? | Does not prove workload compatibility |
| Boot and driver logs | Did required components initialize? | Does not establish user-facing health |
| Representative application probe | Does the service work after maintenance? | Needs sufficient workload coverage |
Recovery must exist before the first reboot
Confirm out-of-band access, boot selection and a retained known-working kernel where supported. Test that someone can reach the console if ordinary networking fails. A rollback that requires SSH after a network-driver failure is circular.
Booting an older kernel can restore service while reopening the original vulnerability. Record that as a temporary recovery state with a remediation owner. Do not silently count the node as patched because the maintenance playbook completed.
Automate the evidence collection through Ansible rolling orchestration. Preserve each node's before/after state and stop expansion when the first representative failure appears. Endpoint fleets use similar staged reasoning in Windows update rings, though their control channels and user restart experience differ.
Test the operational claim
The package manager says the kernel update succeeded. Can the change close? Only after confirming active fix coverage and required restarts, then validating the service. Installed-package success covers one stage.
Does live patching mean the kernel release string must change? No. Live fixes can alter running behavior without booting a different kernel release. Use the vendor's patch-status evidence and advisory mapping rather than a release-string comparison alone.