Question regarding OS pinning and kernel update prevention

Rocky Linux General
1

Hello,

I am a newbie who is fairly comfortable with the Linux environment. So, I request you to be patient with my question as I am not deeply informed about Linux or the nomenclature.

At my office, we ordered a new workstation for CFD simulations and I decided to install Rocky Linux as Star-CCM+ (Third-party software) usually performs better in Linux. The software has been tested extensively and certified for certain versions of Rocky Linux (8.6, 8.8, 8.9 and 9.0, 9.2). Therefore, I went ahead and installed 9.2.

I soon realized that the kernel updates the moment I do sudo dnf update or sudo dnf upgrade. Since I am not sure if any repositories/libraries necessary for the software change between 9.2 and 9.3, I would like to stick to 9.2. I read a couple of suggestions on the forum, tried them out and ran into some challenges.

Method 1: Editing the dnf config file (Suggestion)
In the /etc/dnf/dnf.conf file, I added exclude = kernel*. This posed a problem when I wanted to install any drivers (USB WiFi adapter as the office has no LAN port). I attach below an example:

[abc@localhost ~]$ sudo dnf group install "Development Tools”
Rocky Linux 9 - BaseOS
Rocky Linux 9 - AppStream
Rocky Linux 9 - AppStream
Rocky Linux 9 - Extras
Error:
Problem 1: package glibc-devel-2.34-83.e19.12.x86_64 requires kernel-headers >= 3.2, but none of the providers can be installed
 - cannot install the best candidate for the job
 - package kernel-headers-5.14.0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
Problem 2: package redhat-rpm-config-201-1.e19.noarch requires kernel-srpm-macros >= 1.0-6, but none of the providers can be installed
 - conflicting requests
 - package kernel-srpm-macros-1.0-13.e19.noarch is filtered out by exclude filtering
Problem 3: package rpm-build-4.16.1.3-27.e19_3.x86_64 requires system-rpm-config, but none of the providers can be installed
- package redhat-rpm-config-201-1.e19.noarch requires kernel-srpm-macros >= 1.0-6, but none of the providers can be installed
 - conflicting requests
 - package kernel-srpm-macros-1.0-13.e19.noarch is filtered out by exclude filtering
Problem 4: package gcc-11.4.1-2.1.e19.x86_64 requires glibc-devel >= 2.2.90-12, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.x86_64 requires kernel-headers >= 3.2, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.1686 requires kernel-headers >= 3.2, but none of the providers can be installed
 - conflicting requests
 - package kernel-headers-5.14.0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
Problem 5: package gcc-11.4.1-2.1.e19.x86_64 requires glibc-devel >= 2.2.90-12, but none of the providers can be installed
 - package gcc-c++-11.4,1-2.1.e19.x86_64 requires gcc  - 11.4.1-2.1.e19, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.x86_64 requires kernel-headers >= 3.2, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.1686 requires kernel-headers >= 3.2, but none of the providers can be installed
conflicting requests
 - package kernel-headers-5.14.0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
Problem 6: package gcc-11.4.1-2.1.e19.x86_64 requires glibc-devel >= 2.2.90-12, but none of the providers can be installed
 - package Libtool-2.4.6-45.e19.x86_64 requires gcc(major)  - 11, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.x86_64 requires kernel-headers >= 3.2, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.1686 requires kernel-headers >= 3.2, but none of the providers can be installed
 - conflicting requests
 - package kernel-headers-5.14,0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
Problem 7: package systemtap-4.9-3.el9.x86_64 requires systemtap-devel  - 4.9-3.e19, but none of the providers can be installed
 - package systemtap-devel-4.9-3.e19.i686 requires gcc, but none of the providers can be installed
 - package systemtap-devel-4.9-3.e19.x86_64 requires gcc, but none of the providers can be installed
 - package gcc-11.4.1-2.1.e19.x86_64 requires glibc-devel >= 2.2.90-12, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.x86_64 requires kernel-headers >= 3.2, but none of the providers can be installed
 - package glibc-devel-2.34-83.e19.12.1686 requires kernel-headers >= 3.2, but none of the providers can be installed
 - conflicting requests
- package kernel-headers-5.14,0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages:

[abc@locathost ~]$ sudo dnf upgrade
Last metadata expiration check: @:00:22 ago on Mon 15 Apr 2024 02:37:38 PM CEST
Error:
Problem: package kmod-kvdo-8.2.1.6-102.e19_3.x86_64 requires kernel-core-uname-r >= 5.14.0-362.24.1.e19_3, but none of the providers can be installed
 - cannot install the best update candidate for package kmod-kvdo-8.2.1.6-75.e19_2.x86_64
 - package kernel-core-5.14.0-362.24.1.e19_3.0.1.x86_64 is filtered out by exclude filtering
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages:

I guess this is normal since I excluded the kernel. But if that is the case, how can I go about installing drivers (Realtek, Nvidia) and other software (RustDesk)?

Method 2: Using the version lock plugin (Suggestion)
When I do this, sometimes a checkbox appears when I shut the workstation down (Install pending software updates) and one time I did not pay heed to it, it updated to Rocky 9.3.

Is there anyway I can lock the version on Rocky Linux? I remember I didn’t have to worry about this during my internship where I used Fedora. Even shutting down with “Install pending software updates” would not update to the next version.

Thanks in advance!

2

O’ the joy of proprietary software and certified setups.
Rocky (same as most enterprise linux distributions) keeps user-space software stable (as in, no major version changes that could break compatibility). Short of 3rd-party software that have a kernel-side component or explicitly check for specific version installed, your application should work the same on 9.2 and 9.3.

But if you really really want to stick with 9.2, read on:

From what I can tell, you want to:

  • retain the ability to install some software (meaning you can’t just disable all RPM repositories, if said software has dependencies that would need to be installed for Rocky repositories)
  • prevent upgrade of any packages beyond 9.2 state

Rocky vault maintains ISOs and RPM packages from 9.2 at Index of /vault/rocky/9.2/, so you would be able to either:

  1. configure new repositories in /etc/yum.repos.d/ to point to vault for 9.2, or
  2. download and mount Rocky 9.2 full ISO and configure dnf to uses that as installmedia

RedHat example for 2 can be found here: Need to set up yum repository for locally-mounted DVD on Red Hat Enterprise Linux 7 - Red Hat Customer Portal

Both would give you kind of "frozen-in-9.2-time " state of packages. Note that this procedure basically prevents you from receiving security updates, so exercise care.

1 Like
3

But there’ s bigger decision here. First explain to 3rd party vendor that you can’t just sit on 9.2 because of IT security, and get them to sort it out.

Second, explain to managers that you’re being expected to run an insecure o/s and ask them what they want to do about it. If they say “go ahead”, then you warned them and they ignored you.

1 Like
4

In theory the managers do have three options:
A. Keep system secure by upgrade (and drop the poorly supported third-party application)
B. Keep system secure by switching to RHEL EUS and paying for it
C. Take full responsibility for insecure and unsupported system

5

Hello again,

Thank you for your answers. I have raised an issue with the third-party application. Waiting to see what they have to say about it. Ideally as @anthyve said, there may be no problem moving to 9.3 from their side.

On the off-chance they say that it is only compatible with 9.2, I think option B of @jlehtone seems more appealing since A and C aren’t really options for me. Is this similar to the subscription-manager --set-release method? I will read up about RHEL EUS, and take a decision after explaining the stakes to my manager.

Thank you all for your help!

6

See Red Hat Enterprise Linux 9 Extended Update Support (EUS) and Enhanced Extended Update Support (Enhanced EUS) FAQ - Red Hat Customer Portal
The Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal shows that RHEL 9.2 EUS ends May 31, 2025.

In case it was not clear: The use of RHEL EUS implies that one purchases RHEL 9 and no longer uses Rocky 9 (on that machine).

7

AFAIK, CIQ offers extended support for Rocky Linux 9.2: https://ciq.com/services/long-term-support/

8

Thanks! I will go through these links.

@jlehtone : It was clear regarding RHEL EUS. We have a 1-year subscription that came with the workstation (I turned to Rocky as it would help us save a recurring cost.) I guess the EUS would be a subscription in addition to the exisiting one.

@anthyve: So this would be a way to preserve the version of Rocky Linux while also having assured security. Do you think would CIQ be beneficial in terms of the cost involved?

9

Do you think would CIQ be beneficial in terms of the cost involved?

@p.shukla I do not really know, having never had to purchase a support contract from either RedHat nor CIQ.