How to use yum history to roll back an update in Red Hat Enterprise Linux 6 and later?
Environment
- Red Hat Enterprise Linux 6, 7, 8, 9
- yum
Issue
- How to roll back an update using yum in Red Hat Enterprise Linux-6 and later?
- How to use yum history?
- Information on best practice to enable easy backout of yum patching
Resolution
Note: Rollback of selinux, selinux-policy-*, kernel, glibc (dependencies of glibc such as gcc) packages to an older version is not supported. Thus, downgrading a system to minor version (ex: RHEL6.1 to RHEL6.0) is not recommended as this might leave the system in undesired state. Use the yum history option for small update rollbacks.
-
If you decide to proceed with rollback, rather then reinstall, please start with following documentation.
- RHEL 6 Deployment Guide - 8.3.3. Reverting and Repeating Transactions
- RHEL 7 System Admin Guide - 9.4.3. Reverting and Repeating Transactions
- RHEL 8 System Admin Guide - 12.8 Handling package management history
- RHEL 9 System Admin Guide - 9. Handling package management history
-
The following is an example of using
yumto both install & undo (ie. remove) thescreenpackage:-
First will install
screenRPM# yum install screen <snip> Dependencies Resolved ================================================================================= Package Arch Version Repository Size ================================================================================= Installing: screen i686 4.0.3-16.el6 rhel-6-server-rpms 484 k <snip> Installed: screen.i686 0:4.0.3-16.el6 Complete! -
Next, identify the transaction ID that we want to 'undo'
# yum history Loaded plugins: product-id, refresh-packagekit, subscription-manager Updating Red Hat repositories. ID | Login user | Date and time | Action(s) | Altered ------------------------------------------------------------------------------- 8 | root <root> | 2011-10-03 14:40 | Install | 1 7 | root <root> | 2011-09-21 04:24 | Install | 1 ## 6 | root <root> | 2011-09-21 04:23 | Install | 1 ## 5 | root <root> | 2011-09-16 13:35 | Install | 1 4 | root <root> | 2011-09-16 13:33 | Erase | 1 3 | root <root> | 2011-09-14 14:36 | Install | 1 2 | root <root> | 2011-09-12 15:48 | I, U | 80 1 | System <unset> | 2011-09-12 14:57 | Install | 1025 -
The transaction ID we are interested in is '8', so move forward with undo step. If you want to see additional information to verify this is transaction you are interested in, use
yum history info 8prior to performing the undo# yum history undo 8 Loaded plugins: product-id, refresh-packagekit, subscription-manager Updating Red Hat repositories. Undoing transaction 8, from Mon Oct 3 14:40:01 2011 Install screen-4.0.3-16.el6.i686 Resolving Dependencies --> Running transaction check ---> Package screen.i686 0:4.0.3-16.el6 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: screen i686 4.0.3-16.el6 @rhel-6-server-rpms 783 k <snip> Removed: screen.i686 0:4.0.3-16.el6 Complete!
-
NOTE
If the downgrade fails, you may still be able to downgrade the packages back to the versions you need.
Diagnostic Steps
-
Doing full system backup prior to any update is always recommended, and
yum historyis NOT meant to replace systems backups. -
General documentation of the system state both prior to and after patching is always good practice. This should include running
package-cleanupwith following flags, --orphans, --problems, --dupes, --leaves. -
yum history undowill require access to all the previous RPM version; thus, need to ensure the older RPM versions are available to the system. It is recommended that prior to doing updates, you closely inspect the output ofpackage-cleanup --orphansto know what currently installed RPMs are no longer available in the enabled repositories. This should not be a concern if using the standard RHEL repositories provided by Red Hat as multiple versions of RPM are maintained in these locations. -
As after any RPM changes, recommend checking the yum output/logs for any messages and/or rpm{new,orig,save} files created.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
20 Comments
No luck... I still see:
root@fnt1fmw011 ~> yum update > /tmp/errors.txt
Error: Protected multilib versions: db4-4.7.25-17.el6.i686 != db4-4.7.25-16.el6.x86_64
Error: Protected multilib versions: audit-libs-2.2-2.el6.i686 != audit-libs-2.1.3-3.el6.x86_64
Error: Protected multilib versions: libgcc-4.4.6-4.el6.i686 != libgcc-4.4.6-3.el6.x86_64
Error: Protected multilib versions: glibc-2.12-1.80.el6_3.7.i686 != glibc-2.12-1.47.el6_2.12.x86_64
Error: Protected multilib versions: libstdc++-4.4.6-4.el6.i686 != libstdc++-4.4.6-3.el6.x86_64
Error: Protected multilib versions: libselinux-2.0.94-5.3.el6_3.1.i686 != libselinux-2.0.94-5.2.el6.x86_64
Hi Scott. Sorry to hear that. If you're still experiencing this issue after trying the above resolution, you should open a support case with Red Hat.
When I do a yum update from 6.4 to 6.5 then I lose my network connectivity. The OS thinks the NIC connects are good but ping, ssh, yum, nslookup, etc. just hang.
Hello Chris,
I apologise for the delay caused in responding to your query. However, if still the issue unresolved, you could open a support case with Red Hat at https://access.redhat.com/support/cases/new/ to troubleshoot this.
Thank you
Nitin
Hello all,
Are the mentioned issues already solved?
The issue mentioned by Scott is one I have seen multiple times, the x86_64 patches are not always released at the same time as the i686 patches for the some package. It can take hours since the x86_64 patch is release before the i686 patch is released.
As I patch my virtual machines in one "non production" environment on 6 hours schedule this causes many errors.
yum history fails sometimes if you try to undo a i686 action that has a x86_64 equivalent.
Kind regards,
Jan Gerrit Kootstra
Does it works for the rpm's which are of non-redhat repo. If yes..Please let me know how to perform.
This works very well when applying security patches, for example using "yum update -y --cve CVE-2016-2118" which installs just the minimum required for the security updates, then rolling back worked just fine for the Samba badlocks issues as a test.
DISREGARD
So if I wish to roll-back to 4, will 5-8 also be rolled back? or just the items in 4?
Hi John,
If in step 4 you installed dependencies for packages added in 5-8, and you rollback step 4 you may also partly rollback steps 5-8.
So it is an "it depends on what you rollback" situation.
Regards,
Jan Gerrit Kootstra
If you want to rollback to ID#4 then try "yum history rollbackup 4" as undo can only undo a given transaction which is 8 in this KB.
Undo – will undo a specified transaction. Rollback – will undo all transactions up to the point of the specified transaction.
Does anyone knows how can I install multiple packages at once but have them assigned to individual yum transaction ID per package? This will make rollback more functional if I need to go back and rollback changes to that transaction ID some time in the future
This is not possible as the entire operation of yum is considered for a single transaction at that moment. Ex: "#yum install abc.noarch bcd.noarch ccd.noarch" , this command will have a unique transaction number for the operation "install" , it's not separated with the arguments provided as package names. The only way is to looping them and adding to list to get install using a for or while loop.
How do i fix this?
You can't rollback systemd, even if it's rolled back it may break the system. You can try https://access.redhat.com/solutions/3424281 if it helps.
I may have missed it, but it would be good to put the clarity of the warnings above in the RHEL 8 documentation.
See the important warnings for rolling back to a minor version here https://access.redhat.com/solutions/29617
And this denotes the true intention of rollbacks:
Regards,
RJ
Recommend this article be compared with this solution at https://access.redhat.com/solutions/29617 Should there be one solution or is having both solutions good? Perhaps just a link between both of them within the article.
Kind Regards
RJ
Dear Red Hat - Recommend this article's "NOTE" be rewritten for a currently-supported version of RHEL.
Regards,
RJ
I assume you're referring to this note but specifically what would you like changed? I can update the example to say 9.1 to 9.0, but what else is off about this that doesn't apply anymore?