Update 8.5 without upgrading to 8.6

Hello All!!
As the title say, i would like to update 8.5 without upgrading to 8.6. Is this possible?

Thank you !!

In general, you can’t, but it might be worth explaining why you’d want to do this?

The 8.6 is the update to 8.5. No more updates have been, nor can be made for 8.5 since the moment RHEL 8.6 was released. If you did install updates between release of RHEL 8.6 and release of Rocky 8.6, then you surely already have all there ever was.

One possibilty is that if you stick to security updates only than it can update relevant package only without updating to 8.6 like

yum update-minimal --security

If you need to stay on a particular version for some critical reason and it’s worth the cost eg. a business with critical 3rd party software that’s broken for a number of minor releases - then RHEL with Extended Update Support might be worth a look - more here.

AFAIK, there is no EUS for RHEL 8.5.

With RHEL, you could do this using:

subscription-manager release --set=8.5

unfortunately, this is not possible outside of RHEL since subscription-manager doesn’t exist.

Maybe so, dunno - that’s where sales directed me when I asked specifically about staying on a minor release and pretty sure I specified 8.5 … though it was a submission box so no record / couldn’t swear… clarify b4 u pay I guess.

EUS is only available for even minor releases (the exception being 8.1), see Red Hat Enterprise Linux Life Cycle - Red Hat Customer Portal.

It would be of interest to known the reason for such request. Why should x not work after updating to 8.6 (its not a upgrade!) …

How does that make sense ? You want the option of EUS as an insurance / to be reasonably sure things don’t get stuffed, you’re on an uneven number (eg. 8.5) , they introduce a problem in the next release (eg. 8.6) - you can’t move to 8.6 and you can’t get any security or other fixes for 8.5 ? Do you stick it out for 6 months and fingers crossed hope it gets fixed then or try revert (gulp!) to the last even number (eg. 8.4) ?

Ah let me guess ! you never upgrade to an uneven number - you HAVE to buy EUS and hop from even numbers if you want to lock in LTS style reliability. Pleeeease tell me I’m wrong / explain the thinking behind EUS for evens only.

I have no affiliation with Red Hat so this is my personal interpretation.

I would assume that the uneven minor releases are for new stuff. The new stuff has a 6 month cycle to settle before the next even minor release.

You are right about not being able to stay on an uneven release, as soon as the next minor release comes there are no more updates for the previous release. That also applies to even releases if you do not have a EUS subscription.

The only way to stay on an older minor release and have some time to evaluate newer releases is to stay on an even release and have a EUS subscription, which gives you 24 months of updates (mostly security patches after the first 6 months).

So yes, avoiding uneven numbered releases is probably the way to go if you want to minimize the risk of getting stuck on an old unsupported release. That also means that you can’t use Rocky Linux (or - I assume - any other RHEL clone) since you will never have more than 6 months of updates for any minor release except the very last one.

Each minor release has new stuff. EUS was not “every even minor” before RHEL 8 – for example, most RHEL 7 minor release had EUS.

Time will tell. Given the strategy of every other release having the EUS option, it seems logical to introduce major changes in the uneven minor releases, but only Red Hat knows what’s coming.

It might be a coincidence but OpenJDK 11 was introduced i 8.3, OpenJDK 17 in 8.5. The following even releases had no OpenJDK version updates.

Hello people!!
Thanks for the answers. The Rocky Linux version I’m using is an Autodesk version of Flame. So there are some package versions that are specific to it. I was trying to install KDE, and before upgrading to 8.6, it was possible to update without affecting these packages. But I managed to install KDE, updating specific packages that KDE asked for.

Again, thanks for the replies!

If you are just using the stock repos, you might be able to get away with this (as root):

echo ‘8.5’ > /etc/yum/vars/releasever

Note, this is The Wrong Way ™ and will break the yum/dnf config files for epel-release which expect $releasever to be just the major number (i.e., ‘8’). If you were to continue down this path, you might fix this with:

echo ‘8’ > /etc/yum/vars/epelreleasever
sed -i -e ‘s/releasever/epelreleasever’ /etc/yum.repos.d/epel*

However, I think you might be setting yourself up for maintenance nightmare down the road.

As for reasons why you would want to pin to the latest releases under 8.5, I started looking at this when 8.6 broke my Ansible playbooks. As I understand it, the ansible.posix.selinux module had a dependency on libpython-selinux which had a dependency on python3.6 and rocky 8.6 updated to python3.8. The error trown by the playbook is “Failed to import the required Python library (libselinux-python) on 's Python /usr/bin/python3.8. Please read the module documentation and install it in the appropriate location. If the required library is installed, but Ansible is using the wrong Python interpreter, please consult the documentation on ansible_python_interpreter”. I believe this is a side effect of upstream moving from ansible to the ansible-core package (Updates to using Ansible in RHEL 8.6 and 9.0). Haven’t resolved this yet, but I have decided not to pin the release version to 8.5 and instead see if I can rebuild the python3-libselinux package on a system with python3.8 (the current package installs files under /usr/lib64/python3.6/…). Hopefully, upstream will fix this since, as is, it appears the ansible-collection-ansible-posix package is currently broken.

Or maybe I’m making an error somewhere else.

1 Like

Replying to my own post, I was able to resolve my particular use case by installing the python36 and ansible-collection-ansible-posix packages and adding ansible_python_interpreter=/usr/bin/python3.6 to the ansible config. With these changes, my playbook works with rocky 8.6 as it did with rocky 8.5

Just for anyone who stil needs/wants to pin to 8.5

The epel stuff is archived so you could probably use that or download the repo and use it locally until you moved on…haven’t tried it yet, can’t say what the issues might be.

Yes, you can still use epel with dnf with the minor hack above, but it isn’t elegant.

For more context, the issue is, if you set $releasever to “8.5” in /etc/yum/vars/releasever, it works fine for BaseOS and AppStream because the main repos have directories named 8.5 (see Index of /pub/rocky/). If you don’t set $releasever manually, it appears to default to “8” which works in the main repos since “8” is just a symbolic link to the latest 8.x directory in the series. Unfortunately, this is not true of the EPEL repo where the only directory that exists is the major number, i.e. “8” (see https://epel.mirror.constant.com/). You can edit the repo files from the epel-release package to use a different variable as mentioned, but you may have to maintain this hack when the epel-release package updates.

Note, I don’t use or recommend this because the maintainable solution to my particular issue was just to install python36 and configure Ansible to use that instead of the default python3 (3.8). I only mentioned the hack in case folks need a workaround to ping 8.5 for other use cases.

Yes, but I’m suggesting editing your epel repo files to point to the epel archive with the last epel updates for 8.5 which won’t update. Then when you unpin you set everything back to normal, but as I say I haven’t tried it.