In this tutorial we will explore yum
and dnf
command's ability to rollback updates and patches. Believe me when I say, this feature of yum
and dnf
is a life saver in enterprise, and I will explain you WHY.
yum
is linked to dnf-3
so both maintain the same database. Although it is possible that in future yum
and dnf-4
will maintain separate database so in such case you should use respective tool to revert the transactions
# ls -l $(which dnf) lrwxrwxrwx 1 root root 5 May 7 17:04 /usr/bin/dnf -> dnf-3 # ls -l $(which yum) lrwxrwxrwx 1 root root 5 May 7 17:04 /usr/bin/yum -> dnf-3
What is yum history command? Do I need this?
- In an enterprise level we perform time to time security updates and apply patches to make sure all the security vulnerabilities are addressed
- Normally this is performed using online or offline repositories using YUM or DNF
- Now imagine as part of some patching your server broke or it is possible that you wish to revert to the last installed environment. In production it is very important that you always have a fallback or backup option assuming if something fails.
- In such case if you have a backup then yes you can restore from backup but then we are "not" talking about files, we are talking about rpms so a backup and restore won't be helpful here.
- This is where
yum history
comes for the rescue. - YUM or DNF maintains and stores a
sqlite
database of information about each transaction. - The history is organized terms of transaction ids and is updated every time a yum transaction affects the package configuration of the system.
- Mostly this database can be found in the
/var/lib/yum/history/
directory. - So
yum history
provides an option to rollback to previous successful transactions without you having to worry about downgrading individual packages.
Why should I use yum history if I can use yum downgrade
- Yes this is a valid question.
- With recent Linux distribution yum is mapped to
dnf
which is far more stable and robust compared to earlier versions to handle downgrades but in some cases you would still face problems - For example while updating X rpm the yum will install certain rpms as part of dependencies but while downgrading this X rpm, it will fail to remove those additionally installed dependent packages.
- You can refer the official yum wiki to learn more about the problems with downgrades
- With
yum history
you can leave this handling to yum to make sure it will revert all the transactions.
Any risks of using yum history, when should I use yum history rollback
- Now here comes the bad news, we do have some risks involved with
yum history rollback
and history related arguments. - Rollback of
selinux
,selinux-policy-*
,kernel
,glibc
(dependencies ofglibc
such asgcc
) packages to older version is not supported. - Thus, downgrading a system to minor version is not recommended as this might leave the system in undesired state.
- You should use the
yum history
option for small update rollbacks only. - I have personally faced problems with
selinux
when yum rollback failed to revert the transaction. Although your system would be still in usable state as yum will not proceed unless all the dependency criteria are fulfilled.
So a lot with the theoretical explanations, let us jump into practical examples.
1. List all the yum transactions
Use yum history
command without any additional arguments to list all the transactions
# yum history
- The first column contains the ID of each transaction. You will use these ID to perform any operations with yum history
- The second column shows the command which was executed with yum or dnf on the terminal
- The third column provides the date and time information when the respective command was executed
- The fourth column provides the action used with yum or dnf. The "
I,U
" means both install and update was done. In that line I had performed yum install kernel but yum internally decided to also upgrade few packages dependent on kernel - The fifth column shows the number of rpms which were altered i.e. installed/removed/modified
2. Get list of packages installed or removed in individual transactions
Now the above output is brief as we know that with transaction id 38
, 3 rpms were altered but to get more information on these rpms and the action performed we will use:
# yum history info <transaction id>
So here we know more details about this transaction and the packages which were altered.
3. Get yum transaction history for individual rpm
If you wish to get the list of transaction ids when a particular package was altered then you can use
# yum history info <pkg_name>
This will give you a list of all the transaction history along with other relevant details from the respective transaction. For example here I want to get the list of transaction IDs when kernel package was altered.
To only get the transaction ID we can add grep to this command, as shown below:
4. Undo yum transaction
Now to go back in time is not possible in real life but is possible with yum and dnf🙂
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.
I had installed abrt
package with ID 42
42 | install abrt | 2020-08-22 14:04 | Install | 18
which now I don't need any more so let me undo this transaction:
# yum history undo 42
So all the packages installed as part of transaction ID 42 are reverted/removed.
5. YUM redo transaction
This command will re-perform a specific transaction (as defined by the transaction ID), as follows:
# yum history redo 42
So in this command we will re-perform the action as defined with transaction ID 42 i.e. to install abrt
and all it's dependency packages
6. YUM rollback to a certain transaction in history
Now this command is quite useful and equally dangerous as it will revert back all the yum related transactions upto the ID which you provide with YUM. In this example we will revert back our Linux server to the state of transaction ID 45 where in I had downgraded python3-bind. If you try to rollback to a very old transaction then it is also possible that the rollback would never go through due to one or the other dependencies.
So I will try to do rollback to a recent yum transaction:
45 | downgrade python3-bind-9 | 2020-08-22 14:13 | Downgrade | 5
In this example I will rollback to transaction ID 45,
# yum history rollback 45
as you see yum is about to do 5 upgrades, 21 downgrades and will remove 31 additional packages with this rollback.
When I tried to do a yum rollback
to much more previous transaction, I was getting below error:
Conclusion
In this tutorial I explained about different possible options with yum history to undo, redo or completely rollback to a previous system state. Doing full system backup prior to any update is always recommended, and yum history is NOT meant to replace systems backups. If you wish to perform software upgrades then you should opt for LVM snapshot based solution as a reliable alternative for restore instead of yum rollback.