If you’re a Linux system administrator or even a “mere” user, you’ve probably noticed that, when using a Red Hat-like system, if you do “yum update” it may well raise the minor version level (e.g. 6.7 to 6.9). In fact, it should move your system to the latest minor version (the number after the dot) of your current major version (the number before it).
You may, then, have wondered if it is possible to update your system and yet remain on your current version. You may even have been asked to do so by a very, very timid boss, or some development/application team (“this is supported only on Red Hat 7.1, we can’t move to 7.2!”).
Before I go on, I have to say that there is absolutely no technical reason to do this (EDIT: not necessarily true any longer, at least for 7.x, see CertDepot’s comment and link. Still true in most cases; the reason for this demand is almost always ignorance, fear, and laziness, not knowledge of any actual change causing incompatibilities). I really hope you’ve arrived here just because a boss, project manager or developer is demanding it (and, sadly, you don’t work at a place where you can say “no, that’s stupid, I won’t do it”… yet 😉 ), or simply because of scientific curiosity, not because you actually think that doing this is a good idea.
Red Hat (or CentOS) minor versions aren’t really” versions” in the usual sense, where new versions of software packages, libraries, etc. are included. Instead, (with a few desktop-related exceptions, such as web browsers) they take pains to only fix security problems and other bugs. If you look at a particular package’s versions, whether you’re on Red Hat Enterprise Linux 7.0 or 7.3, those always stay the same, only the “Red Hat” number (e.g. file-5.11-21.el7) increases. Therefore, there is never (EDIT: see above edit) any question of “compatibility”; it may, however, be a question of “officially supported”, which is code for “we tested our product with this version, and can’t be bothered to test it with any others.”
Sorry about the rant. 🙂 So, since you’re obviously a competent sysadmin, I’ll assume you’re being forced to do it. Here’s how:
To see which releases you have available:
subscription-manager release --list
# subscription-manager release --list +-------------------------------------------+ Available Releases +-------------------------------------------+ 5.11 5Server 6.2 6.7 6.8 6.9 6Server 7.0 7.1 7.2 7.3 7Server
To lock on a release (e.g. 7.1):
subscription-manager release --set=7.1
And to unlock it:
subscription-manager release --unset
(or maybe –set=7Server)
For a single update, add –releasever=x.y to your yum command; for instance:
yum --releasever=7.1 update
To set it permanently, add:
to the [main] section in your /etc/yum.conf file.
Notes: at least on CentOS, since CentOS 7.x, versions aren’t just “x.y”, they also include a third number, apparently the year and date of release. Browsing on http://vault.centos.org/centos/ , for instance, you see you have these versions available:
[DIR] 6.7/ 21-Jan-2016 13:22 - [DIR] 6.8/ 24-May-2016 17:36 - [DIR] 6.9/ 10-Apr-2017 12:48 - [DIR] 6/ 10-Apr-2017 12:48 - [DIR] 7.0.1406/ 07-Apr-2015 14:36 - [DIR] 7.1.1503/ 13-Nov-2015 13:01 - [DIR] 7.2.1511/ 18-May-2016 16:48 - [DIR] 7.3.1611/ 20-Feb-2017 22:23 - [DIR] 7/ 20-Feb-2017 22:23 -
and, yes, you have to specify the third number in your command/config file.
You may also have to enable the several entries in your /etc/yum.repos.d/CentOS-Vault.repo file (change enabled=0 to 1).
8 Replies to “How to update Red Hat or CentOS without changing minor versions”
Before saying “I have to say that there is absolutely no technical reason to do this.”, you should read this page: https://www.certdepot.net/rhel7-changes-between-versions/
You will learn that between minor RHEL 7 versions there are sometimes serious changes (NFS interface, RemoveIPC directive, Python certificates, etc). You will also read that between RHEL 7.1 and RHEL 7.2, there was a full update of Systemd.
Contrary to what you wrote, there may be technical reasons to say: “this is supported only on Red Hat 7.1, we can’t move to 7.2!”.
Thanks for the comment (which happens to be the very first on this blog!). I’ll edit the post a little.
What I wrote *used* to be true; apparently, Red Hat isn’t treating the 7.x series as conservatively as they did with previous versions. Also, while there *may* be technical reasons for something to work, say, in 7.1 but not in 7.2 or later, in all the situations I’ve handled at work, at least for the past year or so, it wasn’t due to developers/managers knowing about (much less mentioning) a particular change that caused incompatibility, it was just the usual “the vendor said 7.1, we’ll use 7.1”. Which, to me, still sounds like “we don’t want the last couple of years of bug fixes”…
Just to add proof to this. There is a definite incompatibility with hyper-v VSS with CentOS 7.6 versus 7.5. It breaks in 7.6. I don’t think this is a problem with hyper-v itself, but really with linux package hypervvssd which is broken in 7.6, it won’t even start. So now I have to go through the pain of “migrating” my CentOS application from 7.6 to 7.5 because downgrade of 7.6 to 7.5 just doesn’t work.
With some 3rd party software they could be locked to certain package versions or kernel versions such as Citrix VDA. Going from RHEL 7.5 to RHEL 7.6 completely breaks the ability to create a Machine Catalog from the updated system even after reinstalling Linux_VDA. Citrix will inform you that version 7.6 is not supported and the track by minor version builds.
Thanks for the comment. Yeah, the “there is no technical reason to do this” used to be true, but apparently Red Hat changed it for the 7.x releases, making changes (other than bug fixes) between minor versions, as I replied to CertDepot’s previous comment (which also made me edit the post a little). Anyway, this change actually makes this tutorial a bit more useful, as, when I wrote it, the only use I saw for it was to be able to satisfy timid managers… 🙂
yes, see IBM Spectrum Scale for an example of software that requires specific point release versions. (ie currently borken with 7.7, but works fine on 7.6)
RHEL 8.3 -> 8.4 broke installation of proprietary Nvidia drivers. It’s a result of the removal of vga_tryget in include/linux/vgaarb.h from kernel 4.18.0-350 (8.4) when it is present in 4.18.0-240 (8.3). If you look at kernel.org and browse the versions, it’s present in all versions until 5.10. If you don’t believe me, install the kernel-devel for 350 and 240, locate vgaarb.h, and do a diff on the two files.