YUM Update without upgrade to minor release

Latest response

Hello everyone,

We recently upgraded one of our RHEL 5.8 servers using the yum update command.  There were over 200 items in the list and we went ahead with all of them. Unbeknownst to us the system was upgraded to the next minor release (5.9) and is now unsupported by some of our hardware vendors.

The question I have is:  is it possible to update packages for the most important security fixes without upgrading to the minor version of the software?  Is there a best practice approach to using yum?  As you can imagine the above scenario is not optimal to say the least.

Thanks for your help in advance!




Hello Ilya,

Yes with the help of yum-security plugin it is now possible to limit yum to install only security updates (as opposed to bug fixes or enhancements).

It provides the ability to list all security updates applicable to the system as well as the ability to install just the security updates.

More details on the same can be found in the knowledgebase solution Is it possible to limit yum so that it lists or installs only security updates?


I'm curious as to which hardware became unsupported in your environment... Red Hat's stance is that once hardware is supported, it's supported for the life of the RHEL product and only needs to be certified once.

Red Hat, Inc.

I'd like to echo Adrius' curiosity about your statement that a hardware vendor only supports up to a certain minor release of RHEL. I know software vendors say nonsense like that all the time, but hardware vendors?

Anyway... Paresh covered the answer to your direct question (i.e., how to do only security updates in the future).

For the immediate issue however, I'd like to point out a couple things. In my experience, oftentimes when vendors say they only support a specific RHEL point release, they are usually saying this without understanding how RHEL major/minor releases work at all (i.e., that Red Hat goes to great pains to gauarantee ABI/API stability/compatibility for the length of a RHEL major release's lifecycle). They're simply trying to cover their butt.

If they actually intend to enforce such arbitrary pronouncements, I suspect they'll check one or more of 3 things on the system:

  • /etc/redhat-release and/or the version of the redhat-release* package
    • I have had customers who wanted a way to prevent this package from being updated (can be added to exclude= in yum.conf) and have had other customers that insisted on downgrading the package after updating to a newer minor release
  • The version of the running kernel (and/or installed kernel packages)
    • I've had customers that update to a new minor release but refuse to run the newer kernel
  • The version of glibc

In any case, YMMV.

The "RHEL 5 Server" channel will always contain the latest RHEL 5. If you require to stay on a specific minor version, then we do provide an Extended Update Support [1] channel for some RHEL 5 releases (and all RHEL6), however 5.8 is not an EUS release so that wouldn't have done much good here.

With our Satellite product, you're able to clone a channel to a certain date. You could create a clone of the "RHEL 5 Server" channel say the day before RHEL 5.9 goes GA (check dates at [2]) then use that custom channel as your "RHEL 5.8 Channel".

As the above posters have indicated, we have an ABI guarantee [3] which extends to all components of the OS. Third-party software should should work fine across all minor releases (5.x) of a major release (5). A userspace application probably has no awareness of the kernel version you are running, a kernelspace component will probably just need a recompile. If such a thing stops working, then please open a support case to let us know, as we put a huge amount of development and testing effort into compatibility, and we will usually fix regressions as a priority.

[1] https://access.redhat.com/support/policy/updates/errata/
[2] https://access.redhat.com/knowledge/articles/3078
[3] https://access.redhat.com/knowledge/articles/119073

Wow you guys are a really helpful lot - what a wonderful support board!  Just to clarify - the issue happened with a device driver for the EMC VfCache card - a pass-through cache card to the SAN.  Their official support matrtix lists 5.8 and they would not support us when the card stopped working for 5.9.  Its probably related to their RPM driver that is incompatible with the newer version of the kernel.  I will continue working with them to see if I can get a source rpm and recompile.

The tip on the security plug-in is the answer I was really looking for - many thanks Paresh.

Again, thank you everyone for contributing your assistance.



We, too, have vendor-specific RHEL-point-release-specific support constraints.

Two simple solutions:

  1. Add the following in /etc/yum.conf  "exclude=redhat-release* kernel*" (without the quotes)
  2. Try out the yum plugin called versionlock:  yum install yum-versionlock

Where is the yum-versionlock package...it does not seem to be available from Redhat?

That is "yum-plugin-versionlock"...

I have tried solution #2 using versionlock with the --releasever option but without success. When I tried solution #1 and update the /etc/yum.conf with "exclude=redhat-release* kernel*" (without the quotes) I receive the following error. Error: unbound-libs conflicts with redhat-release-server-7.0-1.el7.s390x You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

ok im att 5.0 is ok for you all team redhat