Upgrade from RedHat 5.8 to RedHat 6.9
Hello,
I am about to upgrade my RedHat 5.8 server to RedHat 6.9 and I am asking the community if there are any known problems with this upgrade that anyone may have encountered in the past. I am sure there are many companies that have done this in the past so any help and advise would be greatly appreciated.
What I intend to do is first upgrade the 5.8 to 5.11 version. This should be relatively easy.
However, my concern is with the upgrade to 6.9 from 5.11. I am asking if there are any known issues with doing this. I intend to boot to the cd and perform the upgrade this way.
So is there any known issues that I may encounter or is there a simpler way to do this that I am not aware of.
As always thank you for your assistance.
Patrick Broderick
Responses
Guru
10133 points
Hi Patrick,
Unfortunately, doing an in-place upgrade from one major version to another is not supported by Red Hat https://access.redhat.com/solutions/21964 (Please check that link out, it may be a bit long, but there's worthwhile info there). So now that we've got that out of the way, that article does explain a method of "upgrading" from one major version to another.
I'd personally recommend against it and devise a method to create a new fresh system (even if virtual) and later have your new system take over the IP address for the old (perhaps, if that is appropriate, you'd have to update ssh keys due to the machine-key issue).
Just curious, are you facing a vendor-support issue that presents a roadblock for you to just migrate your system to RHEL 7.4?
What role does this server perform? Could another, separate (even if virtual) system be loaded and configured to perform the role of the previous server you're intending to replace? I can't immediately find the examples, but I've heard some people who roll the dice and it goes, maybe ok, and yet there's risk so I've heard of examples where it doesn't go ok.
I personally make new systems, or intensively review the server in question and rekickstart it (if possible, depending on it's role). I can't speak directly to known issues, because it's been a while, but there seemed to be enough risk to not make it worthwhile and I instead did a reload of either the server in question (where possible) or a replacement server.
I don't know the full extent of your scenario, so it's hard to directly comment. Again, check out that article.
Oh, here's another link that boasts the possibility of going from RHEL 5 to 6 or 7 Red Hat Blog migration of RHEL 5 or 6 to RHEL 7
Upgrades (not wipe/reload, or reload another system) incur a lot of risk. Please if you do attempt it, I'd highly recommend the first link I posted and review all the recommendations for the unsupported upgrade from one major number to another.
Hope it goes well. There maybe other options available.
Guru
9710 points
Hi Patrick,
I completely agree with R. Hinton - upgrading the system (especially in this case) is not the best idea. Too many things changed, some of them deeply hidden under the hood. You may experience huge issues sooner or later, so I would suggest to save or move your data to an external media, set up a clean fresh new server with the latest edition RHEL 7.4, install the software you need on top and copy / move back the data to the new system. My personal experience is, that it takes so much less time than trying to fix a possible mess. :)
Regards,
Christian
Hello Patrick,
Yes, this upgrade path from RHEL5.x to RHEL6.x is not a supported method and Red Hat doesn't recommend as commented by Hinton. I go with Christian that it is a better approach to do clean installation instead of fighting to fix the mess after the upgrade. However, as I know there are a times that due to many restrictions, we'd be forced to try out the upgrade. As per my suggestion if upgrade is the only option for you then remove any GUI packages installed, keep the system in runlevel 3, remove un-wanted packages, stop un-necessary services, disable SELinux, stop all application services or un-mount any network shares, so keep it simple and try the upgrade. There would be many RHEL5.x packages which were not found in RHEL6.x (i mean deprecated), so there is no straight forward answer if something goes wrong after the upgrade, you know what I'm talking about. It is a good idea to try the upgrade process on a cloned image as you said. All the best! Keep the post updated...
Guru
10133 points
Patrick, do you have the installation disks for the 3rd party software? You could load a test system running RHEL 6.9 (supported for 2 more years, then you have 2 years to figure something else out) or better yet, attempt loading it on RHEL 7.4 which is supported for much longer.
What form of risk, or consequence are you going to face if this system is rendered unusable? What is the name of the program you spoke of? I wholly agree with Christian's statements in his last post (And Sadashiva has very good points there too), you might end up with a worse set of issues, a larger mess. Perhaps consider finding the software, copy off all the configurations on the other system and attempt to make it work on a fresh system, even if it is a test virtual system. This could save you from being in a panic mode especially if you have a business relying on something and you're suffering getting that back up whilst other things still need to be done.
Please reconsider all the replies in this thread, Christians, Sadashiva Murthy & myself's inputs previously.
Wish you well with this
RJ
Check out if there any packages which are not part of standard ISO image or server repo which were installed in your RHEL5.x version for which the installation program trying to find out an updated version which is not available.
Check if you could boot system into older RHEL5.x kernel and check if there any broken/corrupted/duplicates/orphan packages and clean them up.
To find out all dependency problems:
package-cleanup --problems
To find out any duplicate packages in local database and clean them up:
package-cleanup --dupes
package-cleanup --cleandupes
To find out installed packages which are not available from currently configured repositories, run:
package-cleanup --orphans
Once done check if there any packages (third party) installed apart from standard server repo for which you may have to pull out respective newer version, put them into a local repo, and then try upgrade. If this is the case then better you could create/mirror ISO image into a local repo and create another repo with all packages which are not part of standard RHEL image (I mean updated versions) and then try the upgrade by running "yum update" command.
Hi Patrick,
The command "package-cleanup" is from yum-utils which is not installed on your RHEL5.x system. Anyways, good to see that you brought the system up with RHEL6.0, that is nice. So, to sum it up, you upgrade from RHEL5.8 > RHEL5.11 > RHEL6.0. ?
All the best! Sadashiva Murthy
Guru
10133 points
Sadashiva Murthy, EDITED --- OPPS, I meant this for Patrick, in summary, this post is to highlight the importance of backing up his highly unique one-off system in some fashion.
From that unsupported article I provided from Red Hat, that seems ... likely - but I could find nothing in print to back up that statement. You've seemed to pioneer a method that's unsupported, and averted the risk I and Christian spoke of.
If you haven't already, back that system up. Highly consider making a "P to V" (physical to virtual) instance of that system in case it crashes irreparably unexpectedly. You could stand up an free vmware ESXI system with a lot of hard drive space and RAM and possibly perform a P to V instance of that server. Measure 3 times, cut once. Make some form of backup.
RJ, I was just rephrasing what Patrick had said before. Yes, the truth is that such upgrades are not supported or recommended by Red Hat as we all know. In this case, even Patrick is well aware of such constraints and risks. Yes, all necessary precautions such as backup/clone to be taken before such an attempt, I guess Patrick got enough time to experiment and ready to take risks/challenges.
Guru
10133 points
Apologies Sadashiva Murthy, I meant to address Patrick Broderick (inadvertently addressed you, sorry) and meant to in summary say (maybe I wasn't clear) that we're glad it went well even though there was risk involved, and to suggest to do some form of backup and to consider making a "P-to-V" for a backup "just in case" the original unique system crashes irreparably for some reason.
Guru
9710 points
Hi Patrick,
Although it seems to work (somehow) at the moment, please bare in mind that what you did so far has to be considered as a highly experimental approach. As I said before, you should expect more or less serious trouble later on ... hence I want to stress that I still recommend to perform a clean installation of RHEL 7.4 Server. :)
Regards,
Christian
Guru
10133 points
Side note, when cloning VMware systems, consider this Red Hat discussion, and what Tom Jones suggested. I personally have been following his recommendation in the occasional VMware clones I perform. In addition to the good suggestion Tom Jones makes, I create new ssh host keys for the cloned system so that the clone doesn't have identical host keys.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.