Downgrade RHEL 6.5 to 6.4
We have few RHEL Servers that are running RHEL 6.4. We added few more servers this week and those servers were updated to the RHEL v6.5 automatically with the YUM update.
In order to maintain the servers of a same project in same version, we would like to downgrade the RHEL OS 6.5 to RHEL OS 6.4. What is the right procedure to do that?
Looking forward for some useful assistance from the community.
Regards
Jo
Responses
I believe you have a number of possible "options" for your situation. Unfortunately I don't have access to my Satellite to provide actual advice, but I will try to get you going...
The first thing I would try and then validate (I actually don't know if it would work).
Select a previous machine that is at the correct patch level and has the packages you need and create a "profile" of that system (under Software | Profile - I believe). Once you have done that, then you can compare the profile you just created with the machine you just built. That will allow you to "sync" the 2 systems to the same profile. It also will ask you how to handle the differential, etc... The one thing I would double-check once you are done is the kernel and whether it removed the newer of the 2.
If you are able to rebuild the system:
Does your new system get registered via a boostrap file or during kickstart?
- bootstrap has a variable FULLY_UPDATE_THIS_BOX which you can change to 0 and it will not update the newly registered system.
- kickstart must have a similar declaration somewhere
Does your kickstart profile automatically install to the most current available? If so, you may need to create a separate kickstart profile and select a different distribution level (i.e. 6.3 or 6.4). This should be simple enough to do from your existing profile. Select the existing profile, then the Kickstart File - grab that kickstart file with your mouse to cut-and-paste and then select "upload new kickstart file" and then tweak the values you need. Specifically the --url line.
Jo - I sincerely apologize... for some reason I thought you had posted in the Red Hat Satellite section (which I most frequently visit) I had tried reading some of the threads on my iPad and I just hadn't paid attention. Again, sorry about that.
To answer your specific question regarding yum update and limiting how recent it patches to: Not that I am aware of. It would be tremendous if you could do yum update-to=20130201 - but, update-to= indicates a specific version for an individual package (I believe). That said - I think you still have options.
So - I was able to confirm that there is a section for Profiles if you are using RHN.
The first step is to ensure that the source system profiles is uptodate at RHN
[user@source ~] $ sudo rhn-profile-sync
Then...
Login to RHN - http://access.redhat.com
Click Subscriptions | RHN Classic | Registered Systems
(Pick the system that you want your new systems to look like)
Then click Software | Packages | Profiles
click Create System Profile and provide a name for it. From my experience, I have seen profiles for Web Servers vs App Servers vs Database Servers, etc... Cloud instances vs Local.. but you can obviously setup a profile for whatever you like.
After you build your new systems to a release that is the same or older than the source system, register the system to RHN but do NOT update it.
Browse to the Profiles page using the same path as above, but this time select the new profile you just created and click compare (this step will not do anything to your system at this point). It may take a little bit of time as it compares the 2 profiles. Once it is done, it will indicate the differences in packages and offer a few paths you can take to resolve the situation. Be sure to click all the way through. Which might sound odd, but I find that sometimes I think I have completed the task, but there is yet one more thing to click on to acknowledge or accept something. Once you have scheduled the task, you can run
[user@target ~] $ rhn_check
on the target system to initiate the waiting task immediately.
Now - If you use a number of repo's on the source system, then you should add those same repo's to the target system prior to the sync. Otherwise, I believe you can indicate that the sync should ignore packages from repos that don't exist on the target system.
Hey Jo - sorry for the absence (it's been a crazy week).
I'm puzzled at this point - but, do you have a "management entitlement" for your hosts? I suspect the Profile functionality may be provided as a part of Management.
If I was pressed for time and HAD to get this resolved, I would try the following:
(I was able to test this and it worked)
[root@source ~] # rpm -qa | sort > /tmp/rpm-qa.out
[root@source ~] # scp /tmp/rpm-qa.out user@source:/tmp/rpm-qa.out
[root@target ~] # yum clean all
[root@target ~] # cp /tmp/rpm-qa.out /tmp/rpm-qa.tmp
-- manually vi /tmp/rpm-qa.tmp and remove ALL the end of line terminators (hold down shift-J)
[root@target ~] # yum -y install `cat /tmp/rpm-qa.tmp`
Then, once the update is done, reboot... and then compare the 2 package lists
[root@target ~] # rpm -qa | sort > /tmp/rpm-qa-new.out
[root@target ~] # sdiff /tmp/rpm-qa.out /tmp/rpm-qa-new.out
There are a number of factors which may throw a false-positive with the sdiff comparision, but you should be able to get a pretty good idea of the outcome. If I get a chance to test this myself, I will update this thread.
EDIT: running yum -y install $PKG (505 times, in fact) is a HORRIBLE idea ;-)
TEST SCENARIO: I kickstarted 2 Virtual Machines. My system A1 was registered and fully updated to current and rebooted. System A2 was registered, but not updated. I was able to grab the rpm listing from A1 and use that to feed the yum update command.
This is not a method I would use regularly as there are a ton of possible issues that could arise - but this should get you through your current dilemma ;-)
You could also look into the yum history command. This has undo and rollback commands. man yum tells you exactly what is does.
I have installed RHEL 6.5 and need to back off to 6.4. The software package we need to install runs on 6.4 only at this time.. I need the easiest way to get back to 6.4. The system was initially installed as 6.4
I keep my boxes @6.4 for a specific reason, same as yours TBH. I just install the yum plugins, and use:
yum --security update
Mine are not set to auto update, only manually.
And here is a link to downgrade RHEL minor releases:
https://access.redhat.com/site/solutions/186763
Brian,
Even with "yum --security update" a kernel update is possible which would effectively bring you up a minor release?
If you wanted to explicitly exclude kernel you could, but I guess it really depends how you define a Red Hat minor release?
Kernel version?
Version of a certain group of packages?
What /etc/redhat-release says?
All packages released prior to a certain date (day before the next release?)
All of the above?
The alternative to this method is an EUS subscription if you want to continue to receive security updates for superseded minor versions.
https://access.redhat.com/articles/rhel-eus
Ok I may have been mis-guided I am looking for what redhat defines as a minor release which I though was mostly comprised in kernel updates? Is that not case?
Hi Jason,
A minor release is a point in time respin of the installation media, which will include all errata to that point and may also include a number of new features released on that date.
To help illustrate our position, I want to refer to the Software Certification Pages;
Thanks to Red Hat's compatibility assurance, ISVs do not need to re-certify for minor Red Hat Enterprise Linux updates.
The Compatibility Assurance document, linked from that page and is found at: https://access.redhat.com/articles/rhel-abi-compatibility. This page includes an
Appendix of Compatibility Levels for Specific Packages and Libraries (and some PDFs for offline use).
We understand that point releases are often viewed as somehow distinct and separate from the previous version, however Red Hat considers any divergence from compatibility (within the limits of the Compatibility Assurance program) to be a defect and will commit to addressing any such problems in future updates
Best regards,
Mark
Mark,
I strongly believe that this is something Red Hat need to address with vendors (ISVs). Unless Red Hat face this issue head on and address vendors targeting/certifying to specific minor versions, the practice will continue.
It causes no end of frustration when implementing products if you have an ISV insisting that the RHEL release can't roll forward from a specific minor release. With compatibility assurance, vendors should be restricted to certifying to major versions ONLY if they intend to use the Red Hat trademark for compatibility claims.
Why is this not better communicated to ISVs?
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
