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.
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 3.10.0-957.21.3.el7.x86_64 # rpm -q kernel kernel-3.10.0-957.21.3.el7.x86_64
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 kernel-tools-libs-3.10.0-957.21.3.el7.x86_64 kernel-3.10.0-957.21.3.el7.x86_64 kernel-tools-3.10.0-957.21.3.el7.x86_64
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
kernel-3.10.0-1062.el7.x86_64
kernel-tools-libs-3.10.0-957.21.3.el7.x86_64
kernel-tools-3.10.0-957.21.3.el7.x86_64
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
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 =================================================================================================================================== Installing: kernel x86_64 3.10.0-1062.1.1.el7 rhel-7-server-rpms 50 M Updating: 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 Installed: kernel.x86_64 0:3.10.0-1062.1.1.el7 Updated: 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 Complete!
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 kernel-tools-3.10.0-1062.1.1.el7.x86_64 kernel-tools-libs-3.10.0-1062.1.1.el7.x86_64 abrt-addon-kerneloops-2.1.11-52.el7.x86_64 kernel-3.10.0-1062.1.1.el7.x86_64 kernel-3.10.0-957.el7.x86_64
Currently my system is still running with older kernel version
# uname -r 3.10.0-957.el7.x86_64
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 3.10.0-1062.1.1.el7.x86_64
And we still have both version of kernel installed on our node.
# rpm -qa | grep kernel kernel-tools-3.10.0-1062.1.1.el7.x86_64 kernel-tools-libs-3.10.0-1062.1.1.el7.x86_64 abrt-addon-kerneloops-2.1.11-52.el7.x86_64 kernel-3.10.0-1062.1.1.el7.x86_64 kernel-3.10.0-957.el7.x86_64
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 System.map-3.10.0-1062.1.1.el7.x86_64 -rw-------. 1 root root 3543471 Oct 5 2018 System.map-3.10.0-957.el7.x86_64 -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.
I attempted to upgrade my x86_64 Intel server running RHEL 8.6 to the 5.14 RT kernel from RHEL repositories but encountered SSH connection issues and unresolved dependencies despite trying SSH RHEL-9 dependency packages. Is it advisable to upgrade only the RT kernel to 5.14 on RHEL 8.6?
I was having some doubts about last update (with yum) and your article was of great help. Thank you so much.
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?
With rpm command you will have to manually install the dependent packages. For kernel-tools and libs you can download the package of the same version as of kernel and then use
rpm -UvhWhen I tried that I got a dependency error. Tools needed libs but libs needed tools. I think we found a fix to rpm both at the same time.
yes correct both needs to be installed together using rpm command
Hi,
May i know how to upgrade sendmail from 8.14.4 to 8.17.1 on oracle linux enterprise 6.10?
You can refer this Install old rpm or downgrade rpm to specific version using yum
very very good
Hello, i got this error following your guide:
# yum list kernel
[root@escort40 user1]# yum install kernel kernel-tools kernel-tools-libs
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
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.
Error:
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
# rpm -qa | grep kernel
kernel-coreandkernel-modules. In your environment most likely you are using kernel-core which is why you get this errorFirst of all check the list of installed 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-extrainstalled then add that to the listGreat, great, great post!
Thanks for the simple way you are explaining the process. Very informative!