SupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 1. The Linux kernel

Learn about the Linux kernel and the Linux kernel RPM package provided and maintained by Red Hat (Red Hat kernel). Keep the Red Hat kernel updated, which ensures the operating system has all the latest bug fixes, performance enhancements, and patches, and is compatible with new hardware.

1.1. What the kernel is
Link kopieren

The kernel is a core part of a Linux operating system that manages the system resources and provides interface between hardware and software applications.

The Red Hat kernel is a custom-built kernel based on the upstream Linux mainline kernel that Red Hat engineers further develop and harden with a focus on stability and compatibility with the latest technologies and hardware.

Before Red Hat releases a new kernel version, the kernel needs to pass a set of rigorous quality assurance tests.

The Red Hat kernels are packaged in the RPM format so that they are easily upgraded and verified by the YUM package manager.

Warning

Kernels that are not compiled by Red Hat are not supported by Red Hat.

1.2. Understanding RHEL kernel version numbers
Link kopieren

The kernel version string reported by your system identifies the Red Hat Enterprise Linux (RHEL) kernel package. It does not describe all of the code in that kernel.

On RHEL, the output of the uname -r command and the version of the kernel RPM package use the same naming pattern, for example, 4.18.0-553.28.1.el8_10.x86_64. The string has the following parts:

  • An upstream Linux base version, such as 4.18.
  • A Red Hat patch count, such as -553.
  • An optional additional patch level, such as .28.1.
  • A RHEL release tag, such as .el8_10.
  • The system architecture, such as x86_64.

The RHEL release tag identifies the RHEL major or minor stream that built the package. It does not mean that every driver or subsystem in the kernel matches that upstream base version.

1.2.1. What the version string does not mean
Link kopieren

The upstream base number in the kernel version string does not list every change in the kernel source.

Red Hat does not treat the upstream base number as a promise that your kernel behaves like an unmodified upstream kernel at that tag.

Over the life of a RHEL major release, Red Hat backports fixes and enhancements from newer upstream Linux kernels into the same major kernel stream. As a result, the following situations can occur:

  • Individual drivers and core subsystems can include code from upstream kernels that are newer than the base version in the string.
  • The difference between the version string and upstream mainline grows as the RHEL major release matures.
  • You cannot use the version string alone to determine whether a specific upstream feature, API, or driver behavior is present.

This model applies across supported RHEL majors, including RHEL 8, RHEL 9, and RHEL 10.

1.2.2. How RHEL kernels evolve
Link kopieren

After Red Hat stabilizes a RHEL major release, the kernel continues to change through backports and Red Hat-specific work.

When Red Hat stabilizes a new RHEL major release, engineers select an upstream Linux base as the starting point for that major’s kernel stream. That base appears in the version string for the life of the major release.

After that point, Red Hat continues to update the kernel by adding the following:

  • Backports of security fixes, bug fixes, and selected features from newer upstream kernels
  • Hardware and platform enablement for supported configurations
  • Red Hat-specific hardening, testing, and integration work

The base upstream version chosen for the .0 release does not limit which upstream changes can be backported later in the same RHEL major lifecycle.

1.2.3. Examples on RHEL 8, RHEL 9, and RHEL 10
Link kopieren

Review typical RHEL kernel version strings on RHEL 8, RHEL 9, and RHEL 10.

The following table shows typical version-string shapes with examples. They are not a full list of what is backported into each release.

Table 1.1. Typical RHEL kernel version strings
RHEL majorExample version stringUpstream base in the string

RHEL 8

4.18.0-553.28.1.el8_10.x86_64

Linux 4.18

RHEL 9

5.14.0-503.23.1.el9_5.x86_64

Linux 5.14

RHEL 10

6.12.0-124.15.1.el10_1.x86_64

Linux 6.12

For example, a RHEL 8.10 system can report a 4.18 base in uname -r while individual subsystems include changes from much newer upstream kernel versions. The same backport model applies over the RHEL 8 lifecycle.

1.2.4. How to determine kernel capabilities
Link kopieren

Use the kernel version string together with release documentation and package details to determine whether a capability is supported on your system.

Use the version string to identify the installed RHEL kernel package and to distinguish RHEL kernel builds from non-Red Hat kernels. To determine whether a specific capability is supported on your system, also review the following items:

  • RHEL release notes and feature documentation for your major and minor release
  • Hardware and software certification and support statements for your platform
  • The installed kernel package details, for example, by using the dnf info kernel command

If you rely on vulnerability management or compliance tooling, remember that live kernel patches can fix some issues on the running kernel before a new kernel package is installed. Note that the version string from uname -r alone might not reflect that state.

1.3. RPM packages
Link kopieren

An RPM package consists of an archive of files and metadata used to install and erase these files. Specifically, the RPM package contains the following parts:

GPG signature
The GPG signature is used to verify the integrity of the package.
Header (package metadata)
The RPM package manager uses this metadata to determine package dependencies, where to install files, and other information.
Payload
The payload is a cpio archive that contains files to install to the system.

There are two types of RPM packages. Both types share the file format and tooling, but have different contents and serve different purposes:

  • Source RPM (SRPM)

    An SRPM contains source code and a spec file, which describes how to build the source code into a binary RPM. Optionally, the SRPM can contain patches to source code.

  • Binary RPM

    A binary RPM contains the binaries built from the sources and patches.

1.4. The Linux kernel RPM package overview
Link kopieren

The kernel RPM is a meta package that ensures required subpackages are properly installed, including kernel-core and kernel-modules for the Linux kernel binary and modules.

kernel-core
Provides the binary image of the kernel, all initramfs-related objects to bootstrap the system, and a minimal number of kernel modules to ensure core functionality. This subpackage alone could be used in virtualized and cloud environments to provide a Red Hat Enterprise Linux 8 kernel with a quick boot time and a small disk size footprint.
kernel-modules
Provides the remaining kernel modules that are not present in kernel-core.

The small set of kernel subpackages above aims to provide a reduced maintenance surface to system administrators especially in virtualized and cloud environments.

Optional kernel packages are for example:

kernel-modules-extra
Provides kernel modules for rare hardware. Loading of the module is disabled by default.
kernel-debug
Provides a kernel with many debugging options enabled for kernel diagnosis, at the expense of reduced performance.
kernel-tools
Provides tools for manipulating the Linux kernel and supporting documentation.
kernel-devel
Provides the kernel headers and makefiles that are enough to build modules against the kernel package.
kernel-abi-stablelists
Provides information pertaining to the RHEL kernel ABI, including a list of kernel symbols required by external Linux kernel modules and a yum plug-in to aid enforcement.
kernel-headers
Includes the C header files that specify the interface between the Linux kernel and user-space libraries and programs. The header files define structures and constants required for building most standard programs.

1.5. Displaying contents of a kernel package
Link kopieren

By querying the repository, you can see if a kernel package provides a specific file, such as a module. It is not necessary to download or install the package to display the file list.

Use the dnf utility to query the file list, for example, of the kernel-core, kernel-modules-core, or kernel-modules package. Note that the kernel package is a meta package that does not contain any files.

Procedure

  1. List the available versions of a package: 

    $ yum repoquery <package_name>

  2. Display the list of files in a package: 

    $ yum repoquery -l <package_name>

1.6. Installing specific kernel versions
Link kopieren

Install new kernels using the yum package manager.

Procedure

  • To install a specific kernel version, enter the following command: 

    # yum install kernel-5.14.0

1.7. Updating the kernel
Link kopieren

Update the kernel using the yum package manager.

Procedure

  1. To update the kernel, enter the following command: 

    # yum update kernel

    This command updates the kernel along with all dependencies to the latest available version.

  2. Reboot your system for the changes to take effect.
Note

When upgrading from RHEL 7 to RHEL 8, follow relevant sections of the Upgrading from RHEL 7 to RHEL 8 document.

1.8. Setting a kernel as default
Link kopieren

Set a specific kernel as default by using the grubby command-line tool and GRUB.

Procedure

  • Setting the kernel as default by using the grubby tool.

    • Enter the following command to set the kernel as default using the grubby tool: 

      # grubby --set-default $kernel_path

      The command uses a machine ID without the .conf suffix as an argument.

      Note

      The machine ID is located in the /boot/loader/entries/ directory.

  • Setting the kernel as default by using the id argument.

    • List the boot entries using the id argument: 

      # grubby --info ALL | grep id

    • Set an intended kernel as default: 

      # grubby --set-default /boot/vmlinuz-<version>.<architecture>
      Note

      To list the boot entries using the title argument, execute the # grubby --info=ALL | grep title command.

  • Setting the default kernel for only the next boot.

    • Execute the following command to set the default kernel for only the next reboot using the grub2-reboot command: 

      # grub2-reboot <index|title|id>
      Warning

      Set the default kernel for only the next boot with care. Installing new kernel RPMs, self-built kernels, and manually adding the entries to the /boot/loader/entries/ directory might change the index values.

Red Hat logoGithubRedditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Legal Notice

Theme

© 2026 Red HatNach oben