Kernel and System Updates

The kernel updates separately from installed applications, as its own package - and unlike most updates, doesn't take effect until a reboot, because the running kernel stays loaded in memory regardless of what gets installed on disk.

Administration Updated August 29, 2026

  • administration
  • kernel
  • updates

Updating the kernel looks like updating any other package, but behaves differently in one important way: the change is inert until reboot, because the currently running kernel is loaded into memory and keeps running exactly as it was, untouched by whatever gets written to disk.

Checking what's running vs. what's installed

uname -r

6.8.0-45-generic

This is the kernel actively running right now - not necessarily the newest one installed. Compare against what's actually on disk:

dpkg -l | grep linux-image      # Debian/Ubuntu
rpm -qa | grep kernel           # Fedora/RHEL

A mismatch between the newest installed kernel and uname -r almost always means a pending update hasn't been activated with a reboot yet.

The kernel is just a package

sudo apt install linux-image-generic    # Debian/Ubuntu
sudo dnf install kernel                  # Fedora/RHEL

Ordinary apt upgrade / dnf upgrade pulls in kernel updates the same way as anything else - there's usually no separate step, just the requirement to reboot afterward for it to matter. See APT and dpkg and DNF and RPM for the package managers themselves.

Multiple kernels, kept side by side

Installing a new kernel doesn't remove the old one immediately - most distributions keep a small number of previous kernel versions installed specifically so there's a known-good fallback. GRUB (the boot loader) presents them as separate boot menu entries:

sudo update-grub                # Debian/Ubuntu: regenerate the boot menu after a kernel change

If a new kernel fails to boot, or boots but breaks a driver (a common symptom: a GPU or Wi-Fi adapter that worked before an update stops working), reboot and select the previous kernel version from the GRUB menu (usually reachable by holding Shift, or Esc on some systems, during boot) to get back to a working state while investigating.

Pinning a kernel version deliberately

Occasionally a specific kernel needs to be held in place - a known driver incompatibility with a newer version, for instance:

sudo apt-mark hold linux-image-generic     # Debian/Ubuntu
sudo dnf versionlock add kernel            # Fedora/RHEL, needs python3-dnf-plugin-versionlock

See APT and dpkg for more on holding packages generally.

Checking whether a reboot is actually needed

cat /var/run/reboot-required          # Debian/Ubuntu: exists if a reboot is pending
needs-restarting -r                    # RHEL/Fedora (dnf-utils package), exit code signals status

Useful on servers where rebooting isn't something to do casually - these let you confirm a pending kernel update is actually why a reboot is being requested, rather than assuming.

Live patching: updating without rebooting

For situations where even a brief reboot is unacceptable (critical security patches on a system with strict uptime requirements), kernel live patching applies specific fixes - almost always security-related, not full version upgrades - to a running kernel without restarting it. Canonical's livepatch service (Ubuntu) and Red Hat's kpatch are the two mainstream implementations. This covers a narrow set of patches, not a substitute for eventually rebooting into a current kernel - live patches accumulate as a stopgap, not a permanent alternative to updating.