ArticlesRocky Linux

Understanding LTS Package NVRs (Name-Version-Release)

rocky linuxltskernelfipshow-topackages

Arsalan Zaidi
Lead Customer Support Engineer

May 07, 2026

Introduction

This article explains the Name-Version-Release (NVR) format CIQ uses for LTS packages, how to read each segment of the kernel NVR, how the FIPS-compliant kernel naming changed in late 2025, and how to identify what is installed on a running system.

Userspace LTS packages

Userspace LTS packages use the standard RHEL release format with a CIQ dist tag:

<name>-<version>-<rhel-release>.el<MAJOR>_<MINOR>_ciq.<arch>.rpm

The el<MAJOR>_<MINOR>_ciq dist tag identifies the package as a CIQ LTS build. Examples:

glibc-2.28-251.el8_10_ciq.x86_64.rpm
openssl-3.0.7-27.el9_2_ciq.x86_64.rpm

When CIQ ships an additional patch on top of the upstream RHEL release, the release segment is bumped (e.g., -251.1, -251.2). The dist tag stays the same.

Kernel NVR

Current consolidated format:

kernel-<base-version>-<centos-patchset>.<rhel-patchset>.<rhel-buildid>+<ciq-patchset>.<ciq-buildid>.<dist-tag>

Example:

kernel-5.14.0-570.60.1+2.2.el9_6_ciq.src.rpm

Segments:

  • 5.14.0: upstream kernel.org tag the CentOS Stream fork is based on.
  • 570: CentOS Stream patch version.
  • 60: Red Hat minor release patch version.
  • 1: Red Hat build identifier (almost always 1).
  • +2.2: CIQ patchset and CIQ build identifier (see below).
  • el9_6_ciq: CIQ dist tag, identifying the major.minor base and CIQ vendor.

The + separator is intentional. It guarantees CIQ builds sort as newer than the upstream RHEL build during version comparison.

What +X.y means

X is the CIQ patchset, y is the CIQ build identifier, both relative to the RHEL base in front of the +. The same +2.1 can appear on different RHEL bases and represent different content.

While a product is still rolling (RHEL base advancing), the CIQ patchset resets each time RHEL ships a new base: CIQ rebases onto the new RHEL build, drops anything RHEL absorbed upstream, and starts the CIQ patchset back at +2.1.

kernel-5.14.0-570.52.1+2.1.el9_6_ciq      ← CIQ content on top of RHEL 570.52.1
kernel-5.14.0-570.58.1+2.1.el9_6_ciq      ← rebased to 570.58.1, patchset reset
kernel-5.14.0-570.60.1+2.1.el9_6_ciq      ← rebased to 570.60.1, patchset reset
kernel-5.14.0-570.60.1+2.2.el9_6_ciq      ← second build at 570.60.1+2

Once a product becomes LTS (RHEL base frozen), only +X.y increments from that point on:

kernel-5.14.0-284.30.1+12.1.el9_2_ciq
kernel-5.14.0-284.30.1+13.1.el9_2_ciq
kernel-5.14.0-284.30.1+14.1.el9_2_ciq

For LTS-frozen products, +X.y is the field to watch when tracking which fixes are included.

Legacy kernel naming

Before late 2025, CIQ used product-specific suffixes (cld_next, ciq_lts, ciqfips, ciqcbr) placed after the dist tag. Those names still exist on systems that have not been updated. The mapping into the current naming:

kernel-4.18.0-553.79.1.el8_10.cld_next.2.1   →  kernel-4.18.0-553.79.1+2.1.el8_10_ciq
kernel-4.18.0-372.32.1.el8_6.86ciq_lts.16.1  →  kernel-4.18.0-372.32.1+16.1.el8_6_ciq
kernel-5.14.0-284.30.1.el9_2.92ciq_lts.12.1  →  kernel-5.14.0-284.30.1+12.1.el9_2_ciq
kernel-3.10.0-1160.119.1.el7_9.ciqcbr.9.1    →  kernel-3.10.0-1160.119.1+9.1.el7_9_ciq

Version comparison works correctly across the two formats. A dnf update will pull the consolidated build over a legacy build automatically.

FIPS-compliant kernel naming

The FIPS-compliant kernel was previously published with a ciqfips suffix. Starting in late 2025, the FIPS modules were merged into the consolidated kernel build. FIPS-compliant kernels now ship under the same el<MAJOR>_<MINOR>_ciq naming as the LTS kernel, with no separate ciqfips identifier in the filename.

This is a packaging change. The FIPS modules are still maintained on top of the certified kernel base, and CIQ continues to monitor upstream changes to ensure no FIPS algorithm-impacting code is altered. Two practical effects:

  1. FIPS-compliant kernels pick up CVE fixes from the upstream Rocky/RHEL kernel, so vulnerability scanners flag fewer issues.
  2. The package filename no longer distinguishes FIPS from non-FIPS. The repository the package comes from is the source of truth.

If you are pulling from your product's FIPS-compliant repository, the kernel package in that repository is the FIPS-compliant kernel for your product, regardless of whether the filename contains ciqfips or just ciq.

For LTS 9.2 and 9.6, the FIPS and LTS kernels have been converged: the same kernel NVR ships to both the LTS repository and the FIPS-compliant repository. A CVE fix delivered to LTS reaches the FIPS-compliant repo at the same NVR.

Compliant vs. certified repositories

CIQ publishes two separate FIPS repositories per product, and they are not interchangeable:

  • FIPS-compliant (e.g., fips-9.2-compliant, fips-9.6-compliant): receives ongoing CVE fixes through the converged LTS kernel. This is the repository to use if your requirement is to run a FIPS-validated module set with current security updates. New kernel builds land here as soon as they are released.
  • FIPS-certified (e.g., fips-9.2-certified): frozen at the formally certified NVR (for example, kernel-5.14.0-284.30.1.el9_2.ciqfips.0.8.1). New builds do not land in this repository until a new round of formal certification completes, which can take several months and is outside CIQ's control.

Most customer use cases do not require packages to come from the certified repository. If you need formal certification for your deployment, work with your CSM to confirm the current certification status for your product line.

Repository paths follow this pattern in Depot:

https://depot.ciq.com/my/<repo-id>/<repo-id>-<arch>/Packages/k

For example:

https://depot.ciq.com/my/fips-9.2-compliant/fips-9.2-compliant-x86_64/Packages/k

FIPS-compliant kernel NVR transition by product

Each FIPS-compliant product transitioned from the legacy ciqfips suffix to the consolidated +X.y.el<MAJOR>_<MINOR>_ciq form at a specific build. Any build at or above the cutoff in that product's FIPS-compliant repository is FIPS-compliant.

Product Last legacy compliant NVR First consolidated FIPS-compliant NVR
FIPS 8.6 4.18.0-553.16.1.el8_6.ciqfips.0.13.1 4.18.0-553.83.1+2.2.el8_6_ciq
FIPS 8.10 4.18.0-553.16.1.el8_10.ciqfips.0.13.1 4.18.0-553.83.1+2.2.el8_10_ciq
FIPS 9.2 5.14.0-284.30.1.el9_2.ciqfips.0.21.1 5.14.0-284.30.1+22.1.el9_2_ciq
FIPS 9.6 5.14.0-570.52.1.el9_6_ciqfips.2.1 5.14.0-570.60.1+2.2.el9_6_ciq

Notes on the table:

  • For FIPS 9.6, 5.14.0-570.56.1+2.1 and earlier +2.1 builds on bases prior to 570.58.1 predate the FIPS module integration and are not FIPS-compliant.
  • The FIPS-compliant guarantee applies to the kernel and packages built directly from the kernel SRPM. For other packages, refer to your product documentation.

LTS kernel base reference

LTS Product RHEL Kernel Base
LTS 8.6 kernel-4.18.0-372.32.1.el8_6 (frozen)
LTS 8.8 kernel-4.18.0-477.27.1.el8_8 (frozen)
LTS 8.10 rolling on the 4.18.0-553.x.1.el8_10 line for the lifetime of 8.10
LTS 9.2 kernel-5.14.0-284.30.1.el9_2 (frozen)
LTS 9.4 kernel-5.14.0-427.42.1.el9_4 (frozen)
LTS 9.6 kernel-5.14.0-570.60.1.el9_6
CIQ Bridge 7.9 kernel-3.10.0-1160.119.1.el7_9

For frozen LTS products, the segments before the + will match the base shown above. The +X.y after identifies which CIQ build is installed.

Reading the NVR on a running system

Running kernel:

uname -r
# Example: 5.14.0-284.30.1+14.1.el9_2_ciq.x86_64

Installed kernel package:

rpm -q kernel
# Example: kernel-5.14.0-284.30.1+14.1.el9_2_ciq.x86_64

All installed CIQ-built packages (covers both new and legacy naming):

rpm -qa | grep -E '_ciq($|\.|-)'

Available kernel versions in the configured repositories:

sudo dnf list --showduplicates kernel

Notes

When comparing two systems on the same LTS product family, the segments before the + should match. The +X.y then tells you which has more recent CIQ content, provided both are on the same RHEL base.

If the RHEL base differs between two systems on a rolling product, +X.y values are not directly comparable, since each was reset when its respective RHEL base was bumped. Compare the full NVR.

For FIPS-compliant kernels, the repository the package was pulled from is the authoritative answer to "is this FIPS-compliant?" The filename suffix is not a reliable indicator on its own once you account for the legacy/consolidated transition.

Rocky Linux Mirror List for LTS Customers

Handling Vulnerabilities and CVEs