Upgrade from RedHat 7.3 to RedHat 7.4

Latest response

Hello,

I seem to have an issue in that when I try to upgrade a Redhat Server 7.3 to 7.4 it is not doing the upgrade. I connect to a RedHat Satellite 6.2 server and I thought it would be transparent. I was able to upgrade to 7.3 without any issues.

This is how my redhat.repo looks:

[rhel-7-server-rpms]
metadata_expire = 1
sslclientcert = /etc/pki/entitlement/1337237208733725132.pem
baseurl = https://rhs1v.xxx/pulp/repos/xxxx/Library/content/dist/rhel/server/7/7.3/$basearch/os
ui_repoid_vars = basearch
sslverify = 1
name = Red Hat Enterprise Linux 7 Server (RPMs)
sslclientkey = /etc/pki/entitlement/1337237208733725132-key.pem
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
enabled = 1
sslcacert = /etc/rhsm/ca/katello-server-ca.pem
gpgcheck = 1

Any thought of what I am missing? Should it not be transparent to do the upgrade and be able to take the updates or am I miising something in my satellite configuration.

Any help is greatly appreciated.

Responses

Looking at the baseurl https://rhs1v.xxx/pulp/repos/xxxx/Library/content/dist/rhel/server/7/7.3/$basearch/os, you can see that this system is locked to a particular release (7.3 in your case). This repository type contains ONLY RHEL content from GA until the day before RHEL 7.4 is released. (Basically 7.3 and nothing more)

This explains why you do not see updates and cannot update to 7.4. A couple of way resolve this:

  • Option 1: switch to a 7.4 repo.
  • Option 2: switch to the 7Server repo. (The 7Server repo is the 'always updated' version of RHEL)

In either scenario you'd:

  • enable & sync the repo in Satellite
  • Switch the client to the required release version

enable & sync the repo in Satellite

ORG=Example
RELEASE=7Server
 hammer repository-set enable \ 
  --organization "$ORG" \
  --product 'Red Hat Enterprise Linux Server' \
  --basearch='x86_64' \
  --releasever='$RELEASE' --name 'Red Hat Enterprise Linux 7 Server (RPMs)' `


hammer repository synchronize \
  --organization "$ORG" \
  --product 'Red Hat Enterprise Linux Server'  \
  --name  "Red Hat Enterprise Linux 7 Server RPMs x86_64 ${RELEASE}" \
  --async

enable the repo on the client

RELEASE=7.4
subscription-manager release --set $RELEASE

More on the different repository types can be found in Understanding Red Hat Content Delivery Network Repositories and their usage with Satellite 6

Hi Rich,

So I ran the command subscription-manager release --set '7.4' on my client and this allowed me to upgrade to the RedHat 7.4 without any issues on my test server.

However, from what I can tell on my Satellite server I have the repository for 7.4 enabled so I am not really understanding the 1st part of you solution above.

Would it be similar to this? https://access.redhat.com/solutions/1286683

Thank you again for your help.

On your Satellite Server, you have both (7.3 & 7.4) repos enabled, meaning that Satellite will sync both of them. However, a client can have exactly 1 release version. That is, you cannot have both the 7.3 & 7.4 repos enabled simultaneously. (bad things re: dependency resolution happen if you do). That explains why you were able to update once you changed the release version via the subscription-manager command.

Hi Rich. I have a similar question. I have local repositories on the server. I do not call out to the internet to pull down the latest updates. How can I avoid updating the OS to the latest version? For example, if I am upgrading from 7.3 to 7.4, I don't want the server to automatically upgrade to 7.5 when the update is available in the same repository. I've tried yum --releasever=7.4 update (https://access.redhat.com/solutions/238533) but it still updates to 7.5. Any advice?

Rich - thank you so much for the update, so basically to go from 7.3 to 7.4 I need to force the upgrade by via the command: subscription-manager release --set '7.4' for any server I want to upgrade. Would this be the same to upgrade a 6.9 server to 7.3 or 7.4 or would I have to install the Operating System from CD as this is a project I have in the pipeline.

As always thank you so much for your help, it is always very informative as you have helped me with one or two other issues.

Regards, Patrick Broderick

I'm new to RedHat. Is there a cookbook on how to in-place upgrade a system from one dot release to another? I have been given a 7.3 system, but the application vendor says they require 7.4+; therefore I need to upgrade the system to 7.4. However, since I've never done that type of operation I need to find the beginner's instructions. I'm happy to read the manual, but I don't know where the manual is.

Hello Donald,

This might be what you are looking for.

https://access.redhat.com/solutions/92383

Hi Joe,

Thanks for the link.

Hi Donald,

You are three point releases behind - so if you try to upgrade the system, this might lead to running into issues.
If you aren't an experienced user, I recommend to perform a fresh installation of RHEL 7.6 - the latest release. :)

Regards,
Christian

Hi Christian,

I would rather go to 7.6, but the application vendor requested we supply 7.4 for their proof-of-concept. I suspect that the vendor has not "certified" their application to run on later levels. While I suspect it would probably run without issue, it is not my call.

Thanks for the advice.

Anyone landing here, know that the original poster who created this discussion started it on Oct 20th 2017.

In principle, I'd recommend where possible going to RHEL 7.current. Now I recognize that 3rd party software we are chained to will some times scuttle this and say they won't "certify" or "support" some really important 3rd party software to the latest edition of RHEL.

We had one vendor in particular that caused us significant issues by not supporting the latest kernel for many months, almost a year, which was intolerable for us. We ended up presenting the impact to our customer and they in turn pressed the vendor and this was a period of months, so it was not a one-time event. I recognize your circumstances here might differ slightly, but vendors that don't support either a current major/minor release or even the continuing kernels that come out end up causing the pain to be felt increasingly incrementally to the customer.

The 3rd party software company in our case finally started supporting the latest kernels (after nearly a year, and us facing significant issues, and applying a lot of pressure).

Regards

RJ

Hi RJ ! :)

Shame on such vendors ... such a behavior is (partly) responsible for vulnerabilities we have to fight. Not nice ... :(

Regards,
Christian