Kernel updates: install, reboot safely and roll back

Updated November 2026

A kernel security fix protects you only after you boot into the new kernel. The safe routine is short: install the update, keep the previous kernel as a fallback, make sure you can reach the console, reboot, and check that the new kernel is the one running.

Running kernel versus installed kernel

Package managers install a new kernel next to the old ones. Nothing changes in memory until you reboot. So the first question is always: which kernel is running, and is it the newest one installed?

# the running kernel
uname -r

# installed kernels: Debian and Ubuntu
ls /boot/vmlinuz-*
dpkg -l 'linux-image-*' | grep '^ii'

# installed kernels: RHEL, Alma, Rocky, Oracle Linux, Fedora (newest first)
rpm -q --last kernel

# installed kernels: SUSE
rpm -q kernel-default

If uname -r shows an older version than the newest installed kernel, the server is still exposed to every kernel fix in between. The tools from Restarts and reboots do this comparison for you: sudo needrestart -k, sudo dnf needs-restarting -r or sudo zypper needs-rebooting.

Live patches do not change uname -r. If you use live patching, check its status tool as well.

Install the update

# Debian, Ubuntu
sudo apt update && sudo apt upgrade

# RHEL family, Fedora
sudo dnf upgrade kernel

# SUSE (all security patches, including the kernel)
sudo zypper patch

On Debian and Ubuntu, each kernel update is usually a new package with the version in its name. apt upgrade installs new packages when an update needs them, so the new kernel is pulled in. The older apt-get upgrade does not install new packages and may hold the kernel back; use apt upgrade or apt-get dist-upgrade.

Before installing, check free space in /boot with df -h /boot. A full /boot can leave a kernel without a working initramfs, which then fails to boot.

Keep a known-good kernel

Never be left with a single kernel. If the new one fails, the previous one is your way back.

DNF keeps up to 3 kernels by default (installonly_limit=3 in /etc/dnf/dnf.conf) and never removes the running kernel (protect_running_kernel, on by default).
APT marks kernels as automatically removable once newer ones are installed, but protects recent ones. Before running apt autoremove, preview it with apt autoremove --dry-run and make sure the running kernel and at least one other stay.
Zypper on SUSE keeps several kernels side by side (multiversion). Which ones are removed is set by multiversion.kernels in /etc/zypp/zypp.conf; preview a cleanup with sudo zypper purge-kernels --dry-run.

Do not remove the old kernel until the new one has run cleanly for a few days.

Check the default boot entry

After a kernel install, the newest kernel normally becomes the default. Check it before you reboot.

# RHEL family: show and change the default kernel
sudo grubby --default-kernel
sudo grubby --info=ALL | grep -E '^(index|kernel|title)'
sudo grubby --set-default /boot/vmlinuz-VERSION

# Debian, Ubuntu: list GRUB menu entries
sudo grep -E "^\s*(menuentry|submenu) '" /boot/grub/grub.cfg | cut -d"'" -f2

Debian and Ubuntu boot the first menu entry by default, which is the newest kernel. To pin a different default, set GRUB_DEFAULT=saved in /etc/default/grub, run sudo update-grub, then use grub-set-default. Entries inside the "Advanced options" submenu are named as submenu title>entry title, with no spaces around the >.

Reboot a remote server safely

A server can fail to come back after a reboot for reasons that have nothing to do with the kernel fix itself: a full /boot, a missing driver module, a network interface that comes up with a different name, or a service that was never enabled at boot. Prepare for them.

Make sure you have out-of-band access and that it works today: the server's management controller (IPMI, iDRAC, iLO), the hypervisor console, or your cloud provider's serial console.
Check that critical services start at boot: systemctl is-enabled nginx (use your service names).
Reboot one server of a group at a time, and drain it from the load balancer first.
Warn logged-in users and give yourself time to cancel.

# reboot in 5 minutes, with a message to logged-in users (REBOOTS THE SERVER)
sudo shutdown -r +5 "Kernel security update, back in a few minutes"

# changed your mind? cancel it
sudo shutdown -c

# reboot at 02:00 tonight instead (REBOOTS THE SERVER)
echo "systemctl reboot" | sudo at 02:00
sudo atq          # list scheduled jobs
sudo atrm 3       # remove job number 3

With a delay, shutdown blocks new logins during the last 5 minutes before the reboot.

Try the new kernel once

For servers where a failed boot is costly, boot the new kernel for one boot only and keep the old kernel as the default. If the new kernel hangs, a power cycle from the console brings the server back on the old one.

# Debian, Ubuntu (needs GRUB_DEFAULT=saved and update-grub, see above)
sudo grub-set-default "Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux OLD-VERSION"
sudo grub-reboot "Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux NEW-VERSION"
sudo systemctl reboot     # REBOOTS THE SERVER

# RHEL family
sudo grubby --set-default /boot/vmlinuz-OLD-VERSION
sudo grub2-reboot INDEX   # index of the new kernel from grubby --info=ALL
sudo systemctl reboot     # REBOOTS THE SERVER

Copy the entry titles exactly from the listing above; Ubuntu titles start with "Ubuntu". If the new kernel works, make it the default (grub-set-default or grubby --set-default). On Debian and Ubuntu, you can also set GRUB_DEFAULT=0 again and run sudo update-grub, so that future kernels become the default automatically; otherwise the saved entry stays the default even after newer kernels are installed. One limit: when GRUB cannot write its environment block, for example when /boot is on LVM or software RAID, the one-time choice may stay the default after the reboot.

After the reboot

uname -r                        # should show the new version
systemctl --failed              # should list nothing new
sudo journalctl -b -p err       # errors since this boot

Then run the restart check once more; it should report no outdated kernel.

Roll back a bad kernel

At the console, open the GRUB menu during boot (on Debian and Ubuntu under "Advanced options") and pick the previous kernel.
Once booted, make that kernel the default so the next reboot does not return to the bad one: grub-set-default on Debian and Ubuntu, grubby --set-default on the RHEL family.
Look for a known issue in your vendor's bug tracker or advisories, and report it if there is none.
Move to the next fixed kernel as soon as it ships. Running an old kernel, or blocking kernel updates with a package hold or exclude, leaves you without the security fixes, so keep any block short and written down.

A note on kexec

kexec boots a new kernel directly from the running one and skips the firmware's hardware setup, so a reboot takes seconds instead of minutes. sudo systemctl kexec loads the default boot entry and switches to it after a clean shutdown of services (it REBOOTS INTO THE NEW KERNEL). Do not run kexec -e by hand: it skips the normal shutdown. Because hardware is not reset by firmware, some devices and drivers do not cope well; test kexec on the same hardware before relying on it, and keep console access anyway.

Do not confuse it with systemctl soft-reboot, which restarts only user space and leaves the running kernel in place. It does not apply a kernel update.

Distribution kernels, not kernel.org

Use the kernel your distribution ships. kernel.org's longterm kernels are the upstream base, but distributions maintain their own kernels and backport fixes, so version numbers cannot be compared directly with upstream. As of November 2026, kernel.org projects end of life for longterm kernels 5.10 and 5.15 in December 2026; if you run a self-built kernel from either line, plan a move to a newer longterm series. If your whole release is out of support, see Is my OS supported?.