How to properly update kernel in RHEL/CentOS 7/8 Linux
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
# 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 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 =================================================================================================================================== 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
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