Upgrading Fedora distribution with yum distro-sync fails with Error: Protected multilib versions

blankabout asked:

Using these instructions we are carrying out a yum upgrade on a Slicehost slice (NB. this is not a Rackspace vhost, if it was we could probably just do a standard install of the latest Fedora distro) from Fedora 15 to 16, this follows an apparently successful yum upgrade from 14 to 15.

The setup is standard apart from a binary install of MySQL 5.6 and we are using the command:

yum -y --releasever=16 --disableplugin=presto distro-sync --exclude=mysql-libs --exclude=perl-DBD-MySQL --skip-broken

After many messages about the packages that will be upgraded, the process halts with these error messages:

Error: Protected multilib versions: dracut-013-18.fc16.noarch != dracut-009-12.fc15.noarch
Error: Protected multilib versions: initscripts-9.33-1.fc16.x86_64 != initscripts-9.30.1-1.fc15.x86_64

Followed by the suggestion:

 You could try running: rpm -Va --nofiles --nodigest

Using the suggestion does not help, could anyone suggest a way around the errors?

My answer:

Fedora is really not meant to be upgraded this way. And you haven’t even gotten to the difficult one yet (16-17). That said, I’ve done this dozens of times and run into just about every conceivable thing that could go awry. Here are my recommendations.

If at all possible, the best and fastest way to do this is to create a new cloud instance with the latest vesrion of Fedora (17) and then transfer your data and configuration to it. Then destroy the old cloud instance. Of course this relies on Rackspace having a Fedora 17 installation image, and I don’t know if they do.

I have two custom shell scripts just for this purpose, one of which copies all of the config files I need and the data being served from the old system, and the other of which unpacks all the data created by the first script and then installs any necessary packages.

If you’re set on continuing down this path of madness, then keep reading.

The error Protected multilib versions usually occurs when you have two different versions of a package on your system, and sometimes one of them is of one architecture and one is of another (e.g. the old package is i686 and the new is x86_64). It can also occur if a previous run of yum was interrupted and you tried to do another yum transaction without resuming the interrupted one. This suggests to me that your upgrade from Fedora 14 to 15 was not as complete as you thought it was.

First, stop trying to update to 16 or higher until you resolve this issue.

Run yum-complete-transaction to finish any pending yum updates. This is the easy fix. If this fixes the issue, skip the rest of this. If not, continue…

Now, for each package throwing this error, check to see what you have installed:

rpm -q dracut initscripts

You should get two or more packages listed for each of these. Delete one of them: If one is 32-bit and the other is 64-bit, delete the 32-bit package even if it’s newer than the 64-bit package. Otherwise, delete the older package. Ultimately you should have only one of each package installed:

rpm -e dracut-00####.fc## initscripts-#.##-#.fc##

If you found only one version of the package, you will have to delete it from the RPM database without actually removing it from the filesystem (since they’re required for booting and installation). For instance if there was only one version of dracut:

rpm -e --nodeps --noscripts --justdb dracut-00####.fc##

After this, you should be able to continue with yum --releasever=16 distro-sync.

After distro-sync finishes, if you had to delete the only version of a package from the RPM database, don’t continue with the Fedora instructions until you replace it:

yum --releasever=16 reinstall dracut

At this point you should be able to continue with the Fedora instructions.

Keep in mind in the future: Fedora only keeps two release versions active at any given time. After that, the old distros may be removed from mirrors, making it impossible to update in this manner. So you should stay at most one version behind. Alternately, consider using a more stable distribution such as CentOS so that you mostly avoid this mess entirely.

View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.