How to keep in Rocky linux 9.3 ( not update 9.4)

Rocky Linux Help & Support
1

Congratuation, and thnaks your work 9.4 new reease

but my team using over 600 servers still keep 9.3.
until 9.4 will stablized and recongized

Add to /etc/dnf/dnf.conf something like this: is still useful ?

exclude=kernel*
excludepkgs=kernel*
2

Excluding those packages will not stop you from updating to 9.4; that only stops the kernel from updating. You would need to switch to the vault, which is not a supported configuration.

9.3 is no longer supported and you are recommended to keep your system up to date.

3

Thanksreply . and suppiort.

but i tested 9.3 azure snapshot .
dnf update made kernel 9.4. :joy: :joy:

cat /etc/os-release | grep ROCKY_SUPPORT_PRODUCT_VERSION
ROCKY_SUPPORT_PRODUCT_VERSION=“9.4”

/var/log/dnf.log told , exclude was fine.
2024-05-14T15:48:59+0900 DEBUG Excludes in dnf.conf: kernel*
[root@RL-MASTER log]# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

exclude=kernel*
excludepkgs=kernel*

4

“Excluding those packages will not stop you from updating to 9.4;”
is meaning " dnf update makes 9.3 to 9.4 " ?

“that only stops the kernel from updating.”
is meaning " when in kernel 9.3 installing some products, mysql,psql or php.kernel module excude 9.3 patch " ?

5

Thanks your support.

exclude=kernel,rocky**
excludepkgs=kernel,rocky**

protected !

cat /etc/os-release | grep REDHAT_SUPPORT_PRODUCT_VERSION
REDHAT_SUPPORT_PRODUCT_VERSION=“9.3”

dnf update

Last metadata expiration check: 0:06:08 ago on Tue May 14 17:43:54 2024.
Dependencies resolved.
Nothing to do.
Complete!

mod /etc/dnf/dnf.conf , exclude ,excludepackages, to comment
we can check
dnf check-update kernel*
Last metadata expiration check: 0:07:25 ago on Tue May 14 17:43:54 2024.

kernel.x86_64 5.14.0-427.16.1.el9_4 baseos
kernel-core.x86_64 5.14.0-427.16.1.el9_4 baseos
kernel-modules.x86_64 5.14.0-427.16.1.el9_4 baseos
kernel-modules-core.x86_64 5.14.0-427.16.1.el9_4 baseos
kernel-tools.x86_64 5.14.0-427.16.1.el9_4 baseos
kernel-tools-libs.x86_64 5.14.0-427.16.1.el9_4 baseos
[root@RL-MASTER log]# dnf check-update rocky*
Last metadata expiration check: 0:07:32 ago on Tue May 14 17:43:54 2024.

rocky-gpg-keys.noarch 9.4-1.5.el9 baseos
rocky-logos.x86_64 90.15-2.el9 appstream
rocky-release.noarch 9.4-1.5.el9 baseos
rocky-repos.noarch 9.4-1.5.el9 baseos
[root@RL-MASTER log]#

6

All you did was stop the kernel installing and stop rocky-release from saying it’s Rocky 9.4. The remainder of packages that are updated are still 9.4. So your system is Rocky 9.4, except the fact rocky-release was blocked by you. So doesn’t really mean you are on 9.3 at all.

If you wanted to stay on 9.3, you just change the /etc/yum.repos.d/*.repo files to point to the vault and 9.3. But that isn’t recommend, since you no longer get updates, and have vulnerable systems as well without bug fixes and security fixes.

7

How to keep in Rocky linux 9.3 ( not update 9.4)

Easy. Do nothing. Don’t run update. Don’t install any more packages.

(Naturally, your system is unsupported and new security vulnerabilities will be discovered in it, but that is what you want?)

2 Likes
8

@az1minami - what is actually your problem that you want to be addressed?

If you want stability then you should update to the current and only supported version - the latest available one. Everything else will destabilize over time, especially in terms of security.

2 Likes
9

@Ritov I’d guess that the “actual problem” behind

is some of:

  • Incomplete comprehension of what “stable” means in Enterprise Linux
  • Use of third-party packages that are not (yet) in sync with el9_4
  • Third-party applications that have hardcoded is this supported platform checks – for “reasons”

Third parties rebuild their packages/repos when they do. The trivial (but not the safest) solution is to not update before they have done their part.
Third-party (proprietary) vendors might need incentives (e.g. “I’ll take my money elsewhere”) to abandon their “no exact X.Y → no support” practices. Again, no update, no change will help temporarily.

One can let test system to update completely and then run test to verify that everything still functions correctly. It either does, or doesn’t. If it does, then perhaps Neo starts to believe … (in Rocky)

10

@jlehtone - sure - everything valid. The OP didn’t provided the problem description. So, hardly to tell if the underlying problem is actually the 9.4 compose or just a coincidence.

11

Thank you for your advice and opinions.
Thanks your time to spend us.

We do not trying to block 9.4 development or dislike updates.
Once again, I would like to express my gratitude to the developers.

Specifying the OS version is very important when delivering products to customers.

We know about,
There may be other items to check besides the contents of the /etc/os-release file.
and it would be dangerous to determine the OS version based only on the LOGIN banner version.

However, “os-release, login banner” is a confirmation requirement for “systems”

“keeping repository” no-requirement, old version php and psql,mysql ando more , reasone is products ownd repository was installed.

The 9.4 update Projects will start after the delivery of 9.3.
In this case, the customer will incur the cost.

Stopped delivary 9.3 and re-configure , test applications. taking cost is … Customer will not pay for us.

Fortunately, the service outage is minimal for updates 9.3->9,4.
In case there is no version update of Psql, mysql, etc.

The preliminary test for updating from 9.3 to 9.4 requires the same steps and requires a certain amount of man-hours.

Customers will not hope to pay the cost of throwing away all previous 9.3 test results and restarting over.

Due to the end of support for CentOS7, 9.3 was selected as the migration destination.

The release of 9.4 , support for 9.3 ended, so we will be retesting and preparing for rockylinux 9.4 on over 600 machines after delivary 9.3.

temporary freezes on 9.3, it’s still somewhat better than continuing to use CentOS7.

If a super critical issue is reported with CVE-nnnn-nnnn and the only option is to upgrade to 9.4,I will not hesitate to upgrade to 9.4.

Once again, would like to express my gratitude to the developers.

regards and Thanks!

1 Like
12

Set all repos to “disable” it’s done.

13

You appear to have a fundamental misunderstanding of how versions and releases of Enterprise Linux work, as mentioned by @jlehtone. This is easily remedied by understanding that while you may have installed the release 9.3, you are running version 9 and will continue to do so until you replace it.

While keeping your systems which are running EL9 up-to-date, as you should, you will notice that tools and files which report release versions will increment minor versions as all the installed packages which constitute your installed platform, including the “release” package(s) which contains this detail, are updated.

$ rpm -ql $( rpm -qf /etc/os-release )

Now that you understand, you should be able to explain to your customers how you, as a responsible provider, keep your installed EL9 platforms stable and secure with regular (and occasionally irregular) updates (with a suitable acceptance testing, QA, etc. process).

14

No sane customer should accept release 9.3-based anything any more. It was known already last year that 9.3 is dead this month.

Rocky did build and test the entire 9.4 within couple weeks.

15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.