It happened several times already that when I started upgrade via 'yum update' gnome-shell, or X, would crash and leave package database in an inconsistent state. One of those inconsistent states is the following one:
# yum checkNow, you could try with yum-complete-transaction command, which should complete transaction, as suggested by its name:
Loaded plugins: langpacks, refresh-packagekit
apr-1.5.0-2.fc20.x86_64 is a duplicate with apr-1.4.8-2.fc20.x86_64
apr-util-1.5.3-1.fc20.x86_64 is a duplicate with apr-util-1.5.2-4.fc20.x86_64
apr-util-ldap-1.5.3-1.fc20.x86_64 is a duplicate with apr-util-ldap-1.5.2-4.fc20.x86_64
bijiben-3.10.2-1.fc20.x86_64 is a duplicate with bijiben-3.10.1-1.fc20.x86_64
cifs-utils-6.2-5.fc20.x86_64 is a duplicate with cifs-utils-6.2-4.fc20.x86_64
duplicity-0.6.22-1.fc20.x86_64 is a duplicate with duplicity-0.6.21-1.fc20.x86_64
ghc-numbers-3000.2.0.0-1.fc20.x86_64 is a duplicate with ghc-numbers-3000.1.0.3-3.fc20.x86_64
...
Error: check all
# yum-complete-transactionThis didn't help, as evidenced by running 'yum check' command. Note that running suggested commands, package-cleanup and rpm, with given options will not help either.
Loaded plugins: langpacks, refresh-packagekit
There are 1 outstanding transactions to complete. Finishing the most recent one
The remaining transaction had 46 elements left to run
--> Running transaction check
---> Package apr.x86_64 0:1.4.8-2.fc20 will be erased
---> Package apr-util.x86_64 0:1.5.2-4.fc20 will be erased
---> Package apr-util-ldap.x86_64 0:1.5.2-4.fc20 will be erased
---> Package bijiben.x86_64 0:3.10.1-1.fc20 will be erased
---> Package cifs-utils.x86_64 0:6.2-4.fc20 will be erased
---> Package duplicity.x86_64 0:0.6.21-1.fc20 will be erased
---> Package ghc-numbers.x86_64 0:3000.1.0.3-3.fc20 will be erased
--> Processing Dependency: ghc-numbers = 3000.1.0.3-3.fc20 for package: ghc-numbers-devel-3000.1.0.3-3.fc20.x86_64
...
--> Running transaction check
---> Package ghc-numbers-devel.x86_64 0:3000.1.0.3-3.fc20 will be erased
--> Finished Dependency Resolution
Dependencies Resolved
Transaction size changed - this means we are not doing the
same transaction as we were before. Aborting and disabling
this transaction.
You could try running: package-cleanup --problems
package-cleanup --dupes
rpm -Va --nofiles --nodigest
Transaction files renamed to:
/var/lib/yum/transaction-all.2013-12-29.10:53.49.disabled
/var/lib/yum/transaction-done.2013-12-29.10:53.49.disabled
I solved this using 'yum reinstall' command. Namely, for each line that 'yum check' showed, e.g.
apr-1.5.0-2.fc20.x86_64 is a duplicate with apr-1.4.8-2.fc20.x86_64I run 'yum reinstall' with a first name, i..e.
yum reinstall apr-1.5.0-2.fc20.x86_64The problem with this approach is that it is too demanding, you have to do it package by package. Now, if you try something like this:
yum reinstall `yum check | cut -f1 -d" "`You'll receive a message like the following one:
Error: Multilib version problems found. This often means that the root
cause is something else and multilib version checking is just
pointing out that there is a problem. Eg.:
1. You have an upgrade for gnutls which is missing some
dependency that another package requires. Yum is trying to
solve this by installing an older version of gnutls of the
different architecture. If you exclude the bad architecture
yum will tell you what the root cause is (which package
requires what). You can try redoing the upgrade with
--exclude gnutls.otherarch ... this should give you an error
message showing the root cause of the problem.
2. You have multiple architectures of gnutls installed, but
yum can only see an upgrade for one of those architectures.
If you don't want/need both architectures anymore then you
can remove the one with the missing update and everything
will work.
3. You have duplicate versions of gnutls installed already.
You can use "yum check" to get yum show these errors.
...you can also use --setopt=protected_multilib=false to remove
this checking, however this is almost never the correct thing to
do as something else is very likely to go wrong (often causing
much more problems).
Protected multilib versions: gnutls-3.1.18-1.fc20.i686 != gnutls-3.1.17-3.fc20.x86_64
Looking a bit what is happening here didn't reveal a course. This is the problem with multilib programs/libraries and it seems that yum isn't processing them correctly due to either a bug or, more probably, some configuration setting. Luckily, in this case there is a way around this problem, and that is to first deinstall the old versions, and then to reinstall new ones, just in case. Because we are doing two operations that depend on state of the RPM database _before_ we begin, we'll save list of problematic packages into a file:
yum check > yum_check
Now, we first deinstall old versions of packages:
One cautionary note! When you issue 'yum remove' command very carefully check what is yum going to remove. It also removes dependencies and it might remove some critical components that can make your system unusable! As a rule of thumb, in this particular case, no dependencies should be listed for removal!
yum remove `cut -f6 -d" " yum_check`That started all right, but again the GUI crashed!? Worse, I didn't paying attention on which package! Going through the whole process again, there were no problems!? Obviously a bug, but where is a whole different story. Anyway, after removing old packages, the new ones can be reinstalled using the following command:
yum reinstall `cut -f1 -d" " yum_check`And that's it, the package database should be good again.
One cautionary note! When you issue 'yum remove' command very carefully check what is yum going to remove. It also removes dependencies and it might remove some critical components that can make your system unusable! As a rule of thumb, in this particular case, no dependencies should be listed for removal!
