How to Update the Kernel on RHEL with DNF

On current RHEL systems, update the supported Red Hat kernel with DNF. The normal command is dnf upgrade kernel. DNF installs the new kernel alongside older kernel versions instead of replacing the running kernel immediately, giving you a fallback if the new kernel does not boot correctly.

Installing the RPM does not change the kernel currently running in memory. You must reboot into the new kernel and verify it afterward.

Quick Reference: Update the RHEL Kernel

The most important distinction is that the installed kernel and the running kernel are not the same until the server reboots into the newly installed version.

1. Check the Current and Available Kernel Versions

Start with the kernel that is running now:

uname -r

6.12.0-211.42.1.el10_2.x86_64

List the kernel RPMs already installed on disk:

rpm -q kernel kernel-core | sort

kernel-6.12.0-211.42.1.el10_2.x86_64
kernel-core-6.12.0-211.42.1.el10_2.x86_64

Check which kernel GRUB will boot by default on the next restart:

grubby --default-kernel

/boot/vmlinuz-6.12.0-211.42.1.el10_2.x86_64

These three checks answer different questions. uname -r shows the running kernel, rpm -q shows installed kernel builds on disk, and grubby --default-kernel shows the default boot entry. They are related but do not always match immediately after a kernel install.

See whether a newer kernel is available from enabled repositories:

dnf check-update kernel

kernel.x86_64       6.12.0-211.47.1.el10_2        rhel-10-for-x86_64-baseos-rpms

The columns show the package name, architecture, available version-release, and repository. If DNF prints nothing, the host may already have the newest kernel from its enabled repositories.

List installed and available builds when you need more context:

dnf --showduplicates list kernel

Installed Packages
kernel.x86_64       6.12.0-211.42.1.el10_2       @rhel-10-for-x86_64-baseos-rpms
Available Packages
kernel.x86_64       6.12.0-211.43.1.el10_2       rhel-10-for-x86_64-baseos-rpms
kernel.x86_64       6.12.0-211.44.1.el10_2       rhel-10-for-x86_64-baseos-rpms
kernel.x86_64       6.12.0-211.46.1.el10_2       rhel-10-for-x86_64-baseos-rpms
kernel.x86_64       6.12.0-211.47.1.el10_2       rhel-10-for-x86_64-baseos-rpms

2. Preview the Kernel Update

Preview the transaction before you change the system:

sudo dnf upgrade kernel --assumeno

Installing:
 kernel                x86_64  6.12.0-211.47.1.el10_2 rhel-10-for-x86_64-baseos-rpms  1.6 M
Installing dependencies:
 kernel-core           x86_64  6.12.0-211.47.1.el10_2 rhel-10-for-x86_64-baseos-rpms   19 M
 kernel-modules        x86_64  6.12.0-211.47.1.el10_2 rhel-10-for-x86_64-baseos-rpms   42 M
 kernel-modules-core   x86_64  6.12.0-211.47.1.el10_2 rhel-10-for-x86_64-baseos-rpms   31 M

Transaction Summary
===========================================================================================
Install  4 Packages

DNF resolves the matching kernel subpackages for you. You normally do not specify kernel-core, kernel-modules-core, and kernel-modules individually during a standard update. To understand what those packages contain, see RHEL kernel-core vs kernel and kernel-modules explained.

3. Update the Kernel with DNF

When the preview looks correct, install the update:

sudo dnf upgrade kernel

Installed:
  kernel-6.12.0-211.47.1.el10_2.x86_64
  kernel-core-6.12.0-211.47.1.el10_2.x86_64
  kernel-modules-6.12.0-211.47.1.el10_2.x86_64
  kernel-modules-core-6.12.0-211.47.1.el10_2.x86_64

Complete!

DNF treats supported kernel packages as install-only packages. Installing a new kernel leaves older kernel versions on disk instead of replacing them in place. That behavior is intentional and gives you a bootable fallback.

Do not run separate upgrade commands for every kernel subpackage unless you have a specific reason. Let DNF resolve the dependency set from kernel.

4. Verify the New Kernel Before Reboot

Confirm both the old and new kernel builds are installed:

rpm -q kernel kernel-core | sort

kernel-6.12.0-211.42.1.el10_2.x86_64
kernel-6.12.0-211.47.1.el10_2.x86_64
kernel-core-6.12.0-211.42.1.el10_2.x86_64
kernel-core-6.12.0-211.47.1.el10_2.x86_64

The older kernel remaining installed is expected. It provides a fallback if the new kernel fails to boot or causes a problem after reboot.

Check which kernel is selected for the next boot:

grubby --default-kernel

/boot/vmlinuz-6.12.0-211.47.1.el10_2.x86_64

That confirms the new kernel exists on disk and is the default boot target. uname -r can still show the older running kernel until you reboot:

uname -r

6.12.0-211.42.1.el10_2.x86_64

Optionally confirm the boot menu entries without turning this into a full GRUB tutorial:

grubby --info=ALL | grep -E '^kernel=|^title='

kernel="/boot/vmlinuz-6.12.0-211.47.1.el10_2.x86_64"
title="Red Hat Enterprise Linux (6.12.0-211.47.1.el10_2.x86_64) 10.2"
kernel="/boot/vmlinuz-6.12.0-211.42.1.el10_2.x86_64"
title="Red Hat Enterprise Linux (6.12.0-211.42.1.el10_2.x86_64) 10.2"

5. Reboot and Verify the Running Kernel

When the new kernel is installed and the default entry looks correct, reboot:

sudo reboot

After login, confirm the running kernel changed:

uname -r

6.12.0-211.47.1.el10_2.x86_64

Compare that with the default boot entry:

grubby --default-kernel

/boot/vmlinuz-6.12.0-211.47.1.el10_2.x86_64

Then confirm both kernel builds remain installed:

rpm -q kernel kernel-core | sort

kernel-6.12.0-211.42.1.el10_2.x86_64
kernel-6.12.0-211.47.1.el10_2.x86_64
kernel-core-6.12.0-211.42.1.el10_2.x86_64
kernel-core-6.12.0-211.47.1.el10_2.x86_64

A kernel update is not operationally complete until the host boots successfully into the new kernel and you validate the workloads that depend on it.

6. Validate the System After the Kernel Update

Check for failed systemd units first:

systemctl --failed

UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.

If the command lists a failed unit, investigate it before treating the post-reboot validation as complete.

Then validate what matters on that server: network connectivity, storage mounts, critical services, application health, and any hardware drivers the workload needs. The exact checks depend on what the host runs. A database server and a stateless web front end do not need the same post-reboot validation steps.

7. Fix Booting the Wrong Kernel or Return to the Previous Kernel

If the host boots an unexpected kernel, compare the running build with the default entry:

uname -r

Then check which kernel GRUB will boot next:

grubby --default-kernel

List the installed boot entries:

grubby --info=ALL

When a different installed kernel should be the default, set it with grubby:

sudo grubby --set-default /boot/vmlinuz-6.12.0-211.42.1.el10_2.x86_64

Verify the change:

grubby --default-kernel

If the new kernel fails to boot, select a previously working kernel from the GRUB menu at startup. After the fallback boot, uname -r should show the older kernel you chose. Booting an older installed kernel is not the same as downgrading or removing kernel RPMs. For the full default-kernel workflow, see change the default boot kernel. For GRUB menu recovery, see boot an older kernel with grubby.

8. Install a Specific Kernel Version

When you need one supported build instead of the newest available kernel, list candidates first:

dnf --showduplicates list kernel

Install the required version:

sudo dnf install kernel-6.12.0-211.46.1.el10_2

DNF resolves the matching kernel-core, kernel-modules-core, and kernel-modules packages in the same transaction. Use this workflow when reproducing a problem, testing a specific supported build, or meeting an explicit vendor requirement. Do not downgrade arbitrarily without a reason.

9. Remove Old Kernels After Verification

After the new kernel has booted successfully and you have validated the host, remove excess kernels with DNF rather than rpm -e. See remove old kernels on RHEL with DNF for the dnf remove --oldinstallonly workflow and installonly_limit behavior.

Keep a known-good fallback kernel until you are confident the new build is stable in your environment.

10. Why DNF Is Preferred Over Direct RPM Updates

Use DNF for normal RHEL kernel updates. Do not build the primary workflow around rpm -Uvh on downloaded kernel RPMs. DNF understands install-only kernel handling, resolves dependencies, and retains older kernel versions according to the configured retention policy.

A direct rpm -U upgrade can replace an existing kernel RPM in ways that remove your fallback boot option. The safer routine is:

sudo dnf upgrade kernel

Manual RPM installs belong in exceptional troubleshooting or tightly controlled offline repository workflows, not in routine production kernel maintenance.

Common Problems

Summary

RHEL kernel updates start with uname -r, dnf check-update kernel, and a preview using sudo dnf upgrade kernel --assumeno. The supported install command is sudo dnf upgrade kernel, which adds a new kernel build alongside older versions instead of replacing the running kernel immediately.

Before reboot, confirm the new RPMs are installed and that grubby --default-kernel points at the expected /boot/vmlinuz-* file. After sudo reboot, verify the change with uname -r and validate the services and applications that matter on that host.

Keep a known-good fallback kernel until the new build is proven stable, then use the dedicated old-kernel cleanup guide rather than rpm -e. For the package split behind the DNF transaction, see RHEL kernel-core vs kernel and kernel-modules explained.

References

• Managing, monitoring and updating the kernel — RHEL 10 kernel update and verification guidance
• Updating RHEL content with DNF — DNF upgrade behavior, including install-only packages
• Setting a default kernel with grubby — default boot kernel management on RHEL 10
• DNF configuration reference — installonlypkgs and installonly_limit