Update the kernel with your distribution's package manager for routine upgrades. On Debian and Ubuntu that is apt, on Fedora and RHEL it is dnf, on Arch it is pacman, on openSUSE it is zypper. That is the right call for almost every linux kernel update you will ever run. The exception is when you are chasing a specific bug fix or CVE your distro has not backported yet. Then you need to know which branch actually contains the fix before you touch anything, and you confirm that by reading the changelog and the source diff, not a forum thread that says "this worked for me."

Last updated: 2026-07-21

What actually happens when you update the Linux kernel?

A kernel update swaps out the running heart of your system, and it touches more than one file. The package drops a new vmlinuz image and a matching set of modules under /lib/modules/<version>/. It then regenerates the initramfs, the tiny early-boot filesystem that loads the drivers needed to mount your real root. Finally it rewrites a bootloader entry so GRUB knows the new kernel exists.

That is why a kernel update needs a reboot and an ordinary application update does not. Your apt upgrade of, say, curl just replaces a binary the running kernel keeps serving. The kernel itself cannot be hot-swapped underneath a running system without live patching. So the new kernel sits on disk, staged, until you reboot into it.

Here is what happens when any of those three steps goes wrong. A half-built initramfs gives you a kernel that will not find its root disk. A missing GRUB entry gives you a machine that boots the old kernel and leaves you confused about why uname -r never changed. Understand the mechanism and the failures stop being mysterious.

Which command will install a new version of the Linux kernel?

Use the one that matches your distribution. Each package manager pulls the kernel your maintainers already tested, which is what you want for a routine upgrade.

Every one of these only stages the kernel. It writes the files and the boot entry, then stops. The new kernel does not run until you reboot, so do not read a clean upgrade log as proof you are on the new version. On Ubuntu specifically, do not be surprised at how many kernels exist upstream. Ubuntu maintains around 163 supported kernel variants across its repositories, which is why apt sometimes offers a jump you did not expect.

One correction to bad advice: apt upgrade can hold back a new kernel because it pulls in new packages. Use full-upgrade (or dist-upgrade on older systems) so the kernel metapackage actually installs.

How do you update the Linux kernel step by step?

Follow these in order. The whole run is quick on a desktop, though a kernel update on Red Hat Enterprise Linux 7 can take around 40 minutes or more once you count the initramfs rebuild and reboot on server hardware.

1. Check what you are on. Run uname -r. Write down that version so you can prove the change later.
2. Refresh and upgrade. Run your distro command from the table above. Read the output and confirm a linux-image or kernel package is in the list. If it is not, there is no new kernel to install.
3. Watch the initramfs step. On Debian and Ubuntu you will see update-initramfs run. If it errors, stop. A failed initramfs is a failed boot waiting to happen.
4. Reboot. Run sudo reboot. There is no way around this for a normal kernel change.
5. Verify. Run uname -r again. The number must match the new version, not the old one.

If step five still shows the old kernel, GRUB booted the wrong entry. Check /boot/grub/grub.cfg for the new kernel and run sudo update-grub to rebuild the menu. Do not reinstall the package blindly; the files are almost certainly there and the bootloader is the real problem.

How do you set up automatic kernel upgrades safely?

Automatic kernel upgrades are fine on a laptop and risky on a server you cannot easily reach. The tool depends on your distro. Debian and Ubuntu use unattended-upgrades; Fedora and RHEL use dnf-automatic. Both can pull security kernels on their own, which matters because kernel security patches ship every 24 to 48 hours during active periods.

The trap is the unattended reboot. Installing a kernel changes nothing until reboot, so an auto-installer that never reboots gives you a false sense of safety. One that reboots on its own can drop a remote server onto a broken kernel at 3am with nobody watching. Configure the reboot window deliberately in /etc/apt/apt.conf.d/50unattended-upgrades and pick a time you are awake.

For machines that must never go down, look at live patching. Tools in the kernel-care family patch a running kernel in memory, so you close a CVE without a reboot. The tradeoff is that live patches only cover select fixes, not full version bumps, and you still owe the box a real reboot eventually. I cover the mechanics in upgrading a kernel without a reboot.

Whatever you enable, keep at least one known-good kernel installed. Automatic upgrades plus an aggressive old-kernel cleanup is how you end up with zero fallback the one night it breaks.

Mainline, stable, or longterm: which kernel branch should you run?

Run whatever your distribution ships, and stop there for most machines. The upstream project publishes several tracks, and each exists for a different reason. You can read the current list on the official kernel releases page.

• Mainline is where new development lands. It is the newest hardware support and the freshest bugs. Run it only if you need a driver that just landed.
• Stable is mainline after the sharp edges get filed off. Short support window.
• Longterm (LTS) gets backported fixes for years. This is what most distros base their kernels on.

The firm rule: deviate from your distro's kernel only when you have a named reason. New hardware with no driver in the shipped kernel is a real reason to reach for mainline. A years-old LTS on a server you cannot risk is a real reason to check its end-of-life date. Chasing a bigger version number because it feels newer is not a reason; it is how you trade a working system for a driver regression.

Watch the end-of-life dates too. Linux 5.10 LTS, for example, is slated to reach end of support on December 31, 2026. After that it stops getting backported fixes, and running it means you are exposed on purpose.

How do you build and install a kernel straight from source?

Build from source only when the packaged kernel is genuinely too old for what you need. It is slower and it is on you to maintain. Budget the disk first: a kernel compilation can eat around 10GB on top of the base image once you count the source tree, objects, and modules.

1. Grab the source. Download the tarball from kernel.org and unpack it: tar -xf linux-x.y.z.tar.xz && cd linux-x.y.z.
2. Start from your working config. Run cp /boot/config-$(uname -r) .config then make olddefconfig. This reuses the settings that already boot your machine instead of guessing from scratch.
3. Adjust if needed. make menuconfig opens the option tree. If you are unsure what a symbol does, leave it. There is a guide to enabling kernel config options if you have a specific one in mind.
4. Compile. Run make -j$(nproc) to use every core. This is the slow step.
5. Install modules and kernel. sudo make modules_install && sudo make install. That places the image, builds the initramfs, and adds a boot entry.
6. Update the bootloader and reboot. sudo update-grub, then sudo reboot.

Confirm with uname -r afterward. If it boots and dmesg is clean, you own a custom kernel now, and every future security fix is your job to pull.

How do you know if your kernel is end of life or missing a critical patch?

Start with your running version and cross-reference it. Run uname -r, then check that release against the lifecycle table on kernel.org. If your branch is marked end of life, it receives no more fixes, and no distro backport will save an upstream branch that upstream abandoned.

Missing a specific patch is a different question, and you answer it from the changelog, not a hunch. Read the ChangeLog for the versions between yours and the fix. Search it for the CVE number or the commit subject. If the fix landed in a version newer than yours, you are exposed; if your distro backported it into your current package, apt changelog linux-image-$(uname -r) or rpm -q --changelog kernel will show it.

That distinction trips people constantly. Your version string can look old while carrying a fix your distro backported. The changelog is the only thing that tells you which it is. If tracing versions interests you, the kernel version history from 0.01 onward lays out how the numbering evolved.

How do you confirm the update actually fixed your problem?

Verify against the original failure, not the version number. uname -r proves you booted the new kernel and nothing more. It does not prove the bug you updated for is gone. This is the step most people skip, and it is the one that matters.

Run this first: sudo dmesg -T | tail -40 right after boot. Read the kernel ring buffer for the same error that sent you here. If the driver warning, the oops, or the hardware timeout is gone, that tells you the update landed where you needed it. If it is still there, the fix was in a different branch than you thought, and you go back to the changelog.

For a userspace symptom, reproduce it under strace. If a program was dying on a syscall the old kernel mishandled, strace -f ./yourprogram shows whether the call now returns cleanly or still fails with the same errno. Assuming an update worked because it installed cleanly is how the same bug comes back next week. Make the failure reproducible, then prove it stopped.

What do you do if the kernel update breaks boot or hardware?

Do not reinstall and do not reformat. Your old kernel is still on disk, and GRUB can boot it. At the boot menu, open Advanced options and pick the previous kernel entry. That gets you back to a working system in under a minute, and now you can diagnose instead of panic.

Once you are back on the good kernel, stop the bad one from returning. On Debian and Ubuntu, sudo apt-mark hold linux-image-<badversion> pins it so the next upgrade does not reinstall it. Then figure out what actually broke. Boot the bad kernel once more and read journalctl -b -1 -p err from the previous boot, or dmesg if you got far enough. A missing module, a failed initramfs, or a driver regression each leaves a distinct trail.

If a driver regressed, that is exactly the "boot the previous kernel to confirm it is a regression" test, and it tells you whether to report a bug upstream or fix your config. Full steps live in the guide on rolling back a kernel update. Blind reinstalling skips the one thing that prevents a repeat: knowing why it failed.

FAQ

Do I need to reinstall my graphics or VPN drivers after a kernel update?
Only if they are out-of-tree modules built with DKMS. In-tree drivers ship with the kernel and just work after reboot. DKMS rebuilds third-party modules automatically during the update, so watch that step in the log. If it errors, the module will be missing and dmesg will say so on next boot.

Why does uname -r still show the old version after I updated?
Because you have not booted the new kernel yet, or GRUB defaulted to the old entry. The upgrade only stages files. Reboot, and if it still shows the old version, check that a new entry exists in the boot menu and run sudo update-grub to rebuild it.

Is it safe to delete old kernels to free space?
Yes, but keep at least one prior version as a fallback. On Debian and Ubuntu, sudo apt autoremove --purge clears kernels the system marks obsolete while leaving the current one. Never remove the kernel you are currently running. If you want to trim leftover modules separately, see the guide on removing unused kernel modules.

How do I check the current stable kernel version without guessing?
Ask kernel.org directly. Run curl -s https://www.kernel.org/finger_banner and it prints the current mainline, stable, and longterm releases. That beats trusting any static number in a blog post, since a new release can ship the same day.

Can I run a mainline kernel on Ubuntu without breaking the distro packages?
You can, but be deliberate about it. Ubuntu ships mainline builds for testing, and they install alongside your distro kernel rather than replacing it. Keep the distro kernel installed as your fallback, and hold the mainline one only while you need the specific driver or fix it carries.