Understanding LTS Package NVRs (Name-Version-Release)
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 always1).+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:
- FIPS-compliant kernels pick up CVE fixes from the upstream Rocky/RHEL kernel, so vulnerability scanners flag fewer issues.
- 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.1and earlier+2.1builds on bases prior to570.58.1predate 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.