How to use yum history to roll back an update in Red Hat Enterprise Linux 6 and later?

Solution Verified - Updated -


  • Red Hat Enterprise Linux 6, 7, 8, 9
  • yum


  • 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


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.

  • The following is an example of using yum to both install & undo (ie. remove) the screen package:

    • First will install screen RPM

      # yum install screen
      Dependencies Resolved
       Package          Arch       Version            Repository              Size        
       screen           i686       4.0.3-16.el6       rhel-6-server-rpms      484 k      
        screen.i686 0:4.0.3-16.el6
    • 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 8 prior 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
       screen           i686       4.0.3-16.el6       @rhel-6-server-rpms     783 k
        screen.i686 0:4.0.3-16.el6

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 history is 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-cleanup with following flags, --orphans, --problems, --dupes, --leaves.

  • yum history undo will 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 of package-cleanup --orphans to 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.

  • Component
  • yum

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.


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 to troubleshoot this.

Thank you

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.


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.


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?

--> Finished Dependency Resolution
Error: Trying to remove "systemd", which is protected

You can't rollback systemd, even if it's rolled back it may break the system. You can try 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

Warning: Rollback or downgrade of the following packages is unsupported as the packages themselves, and dependencies, either assume an update-only or install-only process:

glibc (dependencies of glibc such as gcc)

And this denotes the true intention of rollbacks:

Thus, downgrading a system to minor version (ex: RHELx.1 to RHELx.0) is not recommended as this might leave the system in an undesired state. If this operation is attempted, it is strongly recommended to only do so with working system backups in place. In general, use the yum history option is intended for small update rollbacks.


Recommend this article be compared with this solution at Should there be one solution or is having both solutions good? Perhaps just a link between both of them within the article.

Kind Regards

Dear Red Hat - Recommend this article's "NOTE" be rewritten for a currently-supported version of RHEL.


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?

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.