A kernel update changes the part of Linux that manages processors, memory, devices, and system calls. A successful update means the machine boots, the required hardware works, and the workload still behaves correctly. Installing a package is only one step.
This guide focuses on maintaining a distribution-provided kernel. For the underlying concepts, see Understanding the Linux Kernel. Use the support instructions for your exact distribution and release when changing packages or boot settings.
Separate the running kernel from the installed packages
uname -r reports the kernel serving the current session. It does not list every installed kernel or tell you which entry the bootloader will select next. Installing a newer kernel normally leaves the existing one running until a reboot; live patching is a separate mechanism with its own coverage and limits.
uname -r
cat /etc/os-releaseOn Debian, dpkg -l 'linux-image*' lists matching package records. Look at the status column: ii means installed; other states may describe packages that are absent, partly configured, or removed with configuration left behind. Other distributions use different package names and tools. A directory under /lib/modules is useful evidence, but it is not a substitute for the package database.
The kernel.org release guide distinguishes mainline, stable, longterm, and distribution kernels. A distribution may backport security fixes while retaining an older-looking version number. Check its security advisory and package revision before deciding that a system is unpatched. Upstream maintenance dates do not by themselves describe a vendor's support commitment.
Prepare a recoverable change
Record the current kernel, distribution release, boot method, and important devices. Back up application data and configuration, and verify that recovery credentials are available. On a remote machine, test the management console or recovery service before rebooting. Working SSH access cannot help if the new boot loses networking.
On a small screen, scroll the table sideways to read all columns.
| Check | Evidence to keep | Why it matters |
|---|---|---|
| Known working boot | Current kernel and a retained boot entry | Recovery requires a usable kernel, its modules, and the required early-boot files. |
| Space and package state | Free space in the filesystems holding boot files; successful package configuration | An interrupted initramfs or boot-entry update can leave an incomplete installation. |
| Essential devices | Storage, network, graphics and encryption-unlock checks | The machine must reach its real workload, not merely display a login screen. |
| Recovery access | Tested console route and backup restore procedure | An earlier kernel cannot undo unrelated data or configuration changes. |
Use the distribution's supported kernel packages and update process. Review proposed removals, package errors, and boot-image generation messages. Retain a known working kernel until the new one is validated, subject to the distribution's retention policy. Do not delete files manually from the boot directory to make room; use the documented package cleanup procedure.
Check external modules and signing separately
Drivers included with the kernel are built as part of that kernel's configuration. An externally supplied driver may need a matching build for the new kernel. Systems using DKMS can rebuild registered external modules, but the build can fail because headers, compiler support, or compatible source are missing. If DKMS is installed, review dkms status and the relevant build logs before relying on a reboot.
Building a module and being allowed to load it are different tests. The kernel module-signing documentation describes signature checking and enforcement. On systems using Secure Boot, follow the distribution's supported signing and key-enrollment procedure. A signature-related error is not a reason to disable protection as a first troubleshooting step.
The kernel project's regression-reporting guide explains an important boundary: compatibility for userspace differs from the changing internal interfaces used by external modules. Record whether the failing driver came from the distribution or another supplier so the report reaches the appropriate maintainer.
Reboot, identify, and test the actual workload
After the planned reboot, run uname -r again. Test network access, required storage mounts, a representative application task, and any hardware-specific behavior. For a laptop, include suspend/resume and the usual dock. For a server, include service health and a representative client request.
On a system with systemd's journal, these read-only commands help compare boots:
journalctl --list-boots
journalctl -k -b 0 --no-pager
journalctl -k -b -1 --no-pagerThe journalctl manual documents boot selection. Previous-boot output is available only if the journal retained it; permissions may also limit what you see. A failed boot might not have saved a journal at all. Keep the exact symptom and relevant timestamps rather than assuming every warning is the cause.
Use the previous kernel as a diagnostic and recovery step
If the new kernel fails, use the distribution's boot menu or provider recovery console to select the retained working entry. With GRUB this is often under an advanced-options menu, but labels and menu access vary. Verify the running version after login. A one-time selection may not change the next boot's default.
Fictional regression: a workstation's network adapter works on its retained kernel but fails after the update. Booting the retained entry restores connectivity. That comparison narrows the investigation; it does not yet prove a kernel code defect, because firmware, module builds, and configuration also need comparison.
Report the exact working and failing versions, hardware identifiers, external module status, reproducible steps, and relevant logs to the distribution first. Remove secrets and unnecessary personal information before sharing logs. Do not stay indefinitely on an unmaintained fallback: track the supported fix and schedule another validation. Keep the failed entry and evidence until the support investigation no longer needs them.
Download the kernel update and recovery record (plain text) to capture the before/after evidence and next action.