Kernel Updates, Reboots and Livepatch

A new kernel package can be installed while the machine still runs the old kernel. The installed files are the next-boot candidates; uname -r reports the running kernel. A safe update keeps these facts separate and preserves a workable route back to the console.

Inspect the running and installed kernels

On bl05-packages-lab, inspect without changing boot selection:

uname -r
dpkg-query -W 'linux-image-*' 2>/dev/null
ls -l /boot/vmlinuz-* /boot/initrd.img-* 2>/dev/null
ls -l /var/run/reboot-required* 2>/dev/null

The package query may include records for packages that are not installed. Inspect their status with dpkg-query -l PACKAGE. The reboot-required files are useful signals when present, not a complete list of all reasons to restart and not proof of which change triggered them. Missing files or unmatched globs may produce errors on a particular image. /boot can be separate and can fill independently of the root filesystem:

findmnt /boot
findmnt /boot/efi
df -h /boot /boot/efi

An absent separate mount is not necessarily an error; verify the actual layout before changing it. Meta-packages track a kernel series and flavor, while versioned image, modules and headers packages serve different roles. Out-of-tree modules, including DKMS-built drivers, must be compatible with the target kernel and the host’s Secure Boot policy. See the earlier boot chapters for initramfs and boot-entry evidence.

Plan the transition

Before applying updates, record the current kernel, the intended target, storage space, bootloader entry and fallback console. A fallback requires an installed, bootable previous kernel with its matching modules and initramfs; an old filename alone is not a tested fallback. Preserve access to any encrypted root unlock mechanism and confirm a recovery environment is available. Review package proposals before removing old kernels: keeping every version indefinitely can fill /boot, while deleting the only tested fallback can make recovery harder.

After the controlled update in the preceding chapter, compare installed versioned images with uname -r. If the next boot should use a newer kernel, arrange a reboot within the window:

sudo systemctl reboot

Run this only on the lab clone after confirming its identity and access through the VM console. A reboot ends sessions and interrupts workloads. Reconnect after startup and verify:

uname -r
systemctl is-system-running
journalctl -b -p warning --no-pager
sudo dpkg --audit

A degraded state warrants investigation; unrelated warnings require context. Verify the actual workload, network and any external kernel modules, not just the version. If the new kernel fails, use the known bootloader fallback through the console, capture its failure evidence and repair the cause before trying again. Do not blindly restore an older kernel indefinitely or disable boot security to make an unsigned driver work.

Livepatch changes the timing, not the lifecycle

Canonical Livepatch can apply selected security fixes to a supported running Ubuntu kernel. Coverage, kernel support and subscription availability vary; it does not cover all kernel fixes or eliminate normal package updates and planned reboots. Check the service’s actual status and advisory coverage, not merely the presence of a client package. Ubuntu’s security-update documentation describes the service and its limits. Other Linux systems have different live-patching implementations and support policies.

Worked diagnosis: package updated, vulnerability remains

An administrator installs a fixed kernel image but the scanner still sees the old running release. Compare uname -r with the installed version, inspect the planned boot entry and determine whether the relevant issue is covered by an active live patch. If a reboot is required, schedule one, then verify the running release and service acceptance. If the booted version remains old, investigate the actual boot selection and boot logs rather than repeatedly reinstalling the image.

Practice and recall

Record running and installed kernels before and after the lab reboot. Identify one reason a version string is insufficient to establish security status and one reason a fallback kernel is not a substitute for a tested restore.