How to properly update kernel in RHEL/CentOS 7/8 Linux

How To, Linux, Tips and Tricks

This tutorial has been written considering RHEL/CentOS/Rocky Linux/AlmaLinux/SuSE and similar distributions which rely on YUM or DNF as package manager. If you are using any other distro then the package manager may differ.


Important dos and don’ts before you upgrade kernel

The kernel is the most important patch to test. As the core of the Linux operating system, an upgraded kernel can affect everything. There are several principles that you should follow when planning to update kernel:

  • Never upgrade to a new kernel in a way, that overwrites your existing kernel. Do not delete the existing kernel until you’re finished testing the new kernel.
  • Most distributions support side-by-side installations of new and existing kernels. In fact, when you install (and don’t upgrade) an existing kernel using a customized binary package, Red Hat/Fedora, SUSE, and Debian all “dual-boot” the new and existing kernels.
  • Test how the new kernel manages your boot process. Watch as it detects your hardware and starts your services. If there are problems or even unusual delays, the new kernel may have a problem with the associated hardware or service.
  • Check the log files associated with the boot process. Pay particular attention to services that won’t start or hardware that isn’t detected.
  • Test the new kernel on your system, based on the release notes. Make sure the new kernel works as intended on your computers.
  • Test your services and applications under the new kernel. Pay attention to any changes in behaviour. Document these changes.
  • When you’re ready to upgrade the kernel on production computers, tell your users what they can expect.

How to properly update kernel in RHEL/CentOS 7/8 Linux


Never update kernel using "rpm -U"

Whenever you install a patch, there are risks. Professionally speaking from experience one should always avoid updating kernel using "rpm -U". With "-U" switch you are upgrading the existing kernel which means that after the upgrade if something fails then there is nothing to fallback to. For example, many kernel patches may lead to situations where you’re unable to boot Linux.

If you run into a situation where a patch leads to a crash, you may be able to restore your system from a backup. If you’re unable to boot your system for this purpose, you may need to use a “rescue mode” for your distribution. Rescue modes are available using the first installation CD associated with Red Hat/Fedora and SUSE.

Updating kernel is a critical change so it is always recommended to keep the old kernel before removing it. Let me show you what I mean with this. Here currently 3.10.0-957.21.3.el7 version of kernel is loaded on my RHEL Linux node

# uname -r

# rpm -q kernel

To list all the installed kernel rpms. (The main one is kernel-3.10.0-957.21.3.el7.x86_64)

# rpm -qa| grep kernel

Now I have downloaded an updated version of kernel rpm and the dependency rpm from RHEL online portal.

# rpm -Uvh /tmp/kernel-3.10.0-1062.el7.x86_64.rpm /tmp/linux-firmware-20190429-72.gitddde598.el7.noarch.rpm
warning: /tmp/kernel-3.10.0-1062.el7.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:linux-firmware-20190429-72.gitddd################################# [ 25%]
   2:kernel-3.10.0-1062.el7           ################################# [ 50%]
Cleaning up / removing...
   3:kernel-3.10.0-957.21.3.el7       ################################# [ 75%]
   4:linux-firmware-20180911-69.git85c################################# [100%]

As you see from the message, the older kernel is being removed. Now rpm is unable to identify the difference between kernel rpm and other system rpms hence it treats kernel the same way.

# rpm -qa| grep kernel

Now here after boot if the system halts due to some problem and fails to come up then you have no way to recover your Linux node. The only option left for you would be to go into rescue mode and then try recovering your system which is a lot of trouble (believe me when I say this)


How to properly update kernel using yum/dnf

You MUST always prefer to use either YUM or DNF to update kernel and all dependent packages without risk of breaking your server.

Now let us try to perform the same task using yum command. With yum you can either use "yum install" or "yum update" to update kernel, either way yum will understand that you are trying to update kernel hence it will perform "install" action. Hence the older kernel will not be removed while the newer one will still be installed.

To check the list of kernel available in your repository

# yum list kernel
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
kernel.x86_64                     3.10.0-957.el7                           @anaconda/7.6
Available Packages
kernel.x86_64                     3.10.0-1062.1.1.el7                      rhel-7-server-rpms
If you are not subscribed to RHN then you can manually download the kernel rpm along with it's dependencies and then perform yum install by giving the absolute path of the rpm.

Next let us try to install the new kernel. For the sake of this example I will update kernel and all other relative packages

# yum install kernel kernel-tools kernel-tools-libs
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package kernel.x86_64 0:3.10.0-1062.1.1.el7 will be installed
--> Processing Dependency: linux-firmware >= 20190429-72 for package: kernel-3.10.0-1062.1.1.el7.x86_64
---> Package kernel-tools.x86_64 0:3.10.0-957.el7 will be updated
---> Package kernel-tools.x86_64 0:3.10.0-1062.1.1.el7 will be an update
---> Package kernel-tools-libs.x86_64 0:3.10.0-957.el7 will be updated
---> Package kernel-tools-libs.x86_64 0:3.10.0-1062.1.1.el7 will be an update
--> Running transaction check
---> Package linux-firmware.noarch 0:20180911-69.git85c5d90.el7 will be updated
---> Package linux-firmware.noarch 0:20190429-72.gitddde598.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

 Package                        Arch                Version                                  Repository                       Size
 kernel                         x86_64              3.10.0-1062.1.1.el7                      rhel-7-server-rpms               50 M
 kernel-tools                   x86_64              3.10.0-1062.1.1.el7                      rhel-7-server-rpms              7.8 M
 kernel-tools-libs              x86_64              3.10.0-1062.1.1.el7                      rhel-7-server-rpms              7.7 M
Updating for dependencies:
 linux-firmware                 noarch              20190429-72.gitddde598.el7               rhel-7-server-rpms               73 M

Transaction Summary
Install  1 Package
Upgrade  2 Packages (+1 Dependent package)

Total size: 139 M
Total download size: 65 M
Is this ok [y/d/N]: y
Downloading packages:
No Presto metadata available for rhel-7-server-rpms
(1/3): kernel-tools-3.10.0-1062.1.1.el7.x86_64.rpm                                                          | 7.8 MB  00:00:01
(2/3): kernel-tools-libs-3.10.0-1062.1.1.el7.x86_64.rpm                                                     | 7.7 MB  00:00:01
(3/3): kernel-3.10.0-1062.1.1.el7.x86_64.rpm                                                                |  50 MB  00:00:07
Total                                                                                              9.1 MB/s |  65 MB  00:00:07
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : linux-firmware-20190429-72.gitddde598.el7.noarch                                                                1/7
  Updating   : kernel-tools-libs-3.10.0-1062.1.1.el7.x86_64                                                                    2/7
  Updating   : kernel-tools-3.10.0-1062.1.1.el7.x86_64                                                                         3/7
  Installing : kernel-3.10.0-1062.1.1.el7.x86_64                                                                               4/7
  Cleanup    : kernel-tools-3.10.0-957.el7.x86_64                                                                              5/7
  Cleanup    : linux-firmware-20180911-69.git85c5d90.el7.noarch                                                                6/7
  Cleanup    : kernel-tools-libs-3.10.0-957.el7.x86_64                                                                         7/7
  Verifying  : kernel-3.10.0-1062.1.1.el7.x86_64                                                                               1/7
  Verifying  : kernel-tools-3.10.0-1062.1.1.el7.x86_64                                                                         2/7
  Verifying  : kernel-tools-libs-3.10.0-1062.1.1.el7.x86_64                                                                    3/7
  Verifying  : linux-firmware-20190429-72.gitddde598.el7.noarch                                                                4/7
  Verifying  : kernel-tools-libs-3.10.0-957.el7.x86_64                                                                         5/7
  Verifying  : linux-firmware-20180911-69.git85c5d90.el7.noarch                                                                6/7
  Verifying  : kernel-tools-3.10.0-957.el7.x86_64                                                                              7/7

  kernel.x86_64 0:3.10.0-1062.1.1.el7

  kernel-tools.x86_64 0:3.10.0-1062.1.1.el7                     kernel-tools-libs.x86_64 0:3.10.0-1062.1.1.el7

Dependency Updated:
  linux-firmware.noarch 0:20190429-72.gitddde598.el7


Now our task of update kernel was successful. We can verify the same using below command. As you see now we have two versions of kernel rpm installed.

# rpm -qa | grep kernel

Currently my system is still running with older kernel version

# uname  -r

But as you see post reboot the RHEL Linux node is planned to come up with newly installed kernel (3.10.0-1062.1.1.el7.x86_64). If you have installed multiple version of kernel then you can also switch between different kernel version to change the boot order in RHEL 7 and RHEL 8 both.

# grep saved /boot/grub2/grubenv
saved_entry=Red Hat Enterprise Linux Server (3.10.0-1062.1.1.el7.x86_64) 7.6 (Maipo)

Now we will reboot our RHEL 7 Linux host. As expected the node has come up with new kernel

# uname -r

And we still have both version of kernel installed on our node.

# rpm -qa | grep kernel

For all the available kernel, we will also have mapped initramfs and vmlinuz file under /boot

# ls -l /boot/
total 163328
-rw-r--r--. 1 root root   152980 Aug 14 00:14 config-3.10.0-1062.1.1.el7.x86_64
-rw-r--r--. 1 root root   151918 Oct  5  2018 config-3.10.0-957.el7.x86_64
drwx------. 3 root root     4096 Jun 28  2018 efi
drwx------. 5 root root     4096 Sep 12 23:13 grub2
-rw-------. 1 root root 74302690 Jul 11 12:25 initramfs-0-rescue-22ee5ba282da4d6ca9bfead578a8fe21.img
-rw-------. 1 root root 32195401 Sep 12 23:13 initramfs-3.10.0-1062.1.1.el7.x86_64.img
-rw-------. 1 root root 32608707 Jul 11 12:28 initramfs-3.10.0-957.el7.x86_64.img
drwx------. 2 root root    16384 Jul 11 12:09 lost+found
-rw-r--r--. 1 root root   318717 Aug 14 00:15 symvers-3.10.0-1062.1.1.el7.x86_64.gz
-rw-r--r--. 1 root root   314036 Oct  5  2018 symvers-3.10.0-957.el7.x86_64.gz
-rw-------. 1 root root  3595191 Aug 14 00:14
-rw-------. 1 root root  3543471 Oct  5  2018
-rwxr-xr-x. 1 root root  6635920 Jul 11 12:25 vmlinuz-0-rescue-22ee5ba282da4d6ca9bfead578a8fe21
-rwxr-xr-x. 1 root root  6734128 Aug 14 00:14 vmlinuz-3.10.0-1062.1.1.el7.x86_64
-rwxr-xr-x. 1 root root  6635920 Oct  5  2018 vmlinuz-3.10.0-957.el7.x86_64

Now since we know our system has installed successfully with newer kernel, so now we can safely remove the old kernel (if required or you can plan to keep it)

# rpm -e kernel-3.10.0-957.el7.x86_64


Lastly I hope the steps from the article to update kernel on RHEL/CentOS 7 and 8 Linux was helpful. So, let me know your suggestions and feedback using the comment section.


Views: 1,369
Deepak Prasad

Deepak Prasad

He is the founder of GoLinuxCloud and brings over a decade of expertise in Linux, Python, Go, Laravel, DevOps, Kubernetes, Git, Shell scripting, OpenShift, AWS, Networking, and Security. With extensive experience, he excels in various domains, from development to DevOps, Networking, and Security, ensuring robust and efficient solutions for diverse projects. You can connect with him on his LinkedIn profile.

Can't find what you're searching for? Let us assist you.

Enter your query below, and we'll provide instant results tailored to your needs.

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

Buy GoLinuxCloud a Coffee

For any other feedbacks or questions you can send mail to

Thank You for your support!!

11 thoughts on “How to properly update kernel in RHEL/CentOS 7/8 Linux”

  1. I was having some doubts about last update (with yum) and your article was of great help. Thank you so much.

  2. Thank you for your help! I was able to install the newer kernel manually using -ivh, however, my kernel-tools and libs did not update. I have the newer rpms on a disc and try to upgrade them using -U but am getting an error that it depends on the older versions. Any suggestions on how to get them all to match up manually?

  3. Hello, i got this error following your guide:
    # yum list kernel
    Last metadata expiration check: 0:05:08 ago on Fri 19 Jun 2020 09:31:23 AM CEST.
    Installed Packages
    kernel.x86_64 4.18.0-147.8.1.el8_1 @BaseOS
    Available Packages
    kernel.x86_64 4.18.0-193.6.3.el8_2 BaseOS

    [root@escort40 user1]# yum install kernel kernel-tools kernel-tools-libs
    Last metadata expiration check: 0:05:45 ago on Fri 19 Jun 2020 09:31:23 AM CEST.
    Package kernel-4.18.0-147.8.1.el8_1.x86_64 is already installed.
    Package kernel-tools-4.18.0-147.8.1.el8_1.x86_64 is already installed.
    Package kernel-tools-libs-4.18.0-147.8.1.el8_1.x86_64 is already installed.
    Problem: The operation would result in removing the following protected packages: kernel-core
    (try to add ‘–skip-broken’ to skip uninstallable packages or ‘–nobest’ to use not only best candidate packages)

    • This article needs an update. Thank you for bringing this to my notice

      With RHEL 8 now the kernel package is broken into kernel-core and kernel-modules. In your environment most likely you are using kernel-core which is why you get this error
      First of all check the list of installed kernel
      # rpm -qa | grep kernel

      if you are not using kernel and instead using kernel-core then you should use
      # yum install kernel-core kernel-modules

      If you also have kernel-modules-extra installed then add that to the list


Leave a Comment