|
Finishing an interrupted "yum upgrade"
Being a brilliant mind and as all brilliant minds sometimes make small mistakes, I have thought of making a "yum upgrade" while browsing through the morning news and having a coffee. "A small mistake" was doing an upgrade few months due (i.e. going through hundreds of transactions) through a terminal session at my laptop with a failing battery (which is otherwise an excellent device that limits the "browsing news while having a coffee" time and makes you sit at your desk and do some paid work).
Anyway, when the inevitable shutdown happend just a few seconds before I connected the charger (and the upgrade process at the main computer was interrupted), the recovery had to be done. As I have previously encoutered broken upgrades with yum, I had no hopes for "yum-complete-transactions" to work (though I have tried it in vain, "hope dies last"). There are too many duplicate versions of the packages and specifically the interrupt of course happens just when a multilib package has installed the new x86_64 version of the package but not the i686 version (or whatever can break the upgrade flow).
The mess I have made was cleaned as follows:
1. Find the duplicate packages with "yum check". As I've had almost 300 duplicates, manually deleting the duplicates (with "rpm -e") was not something I'd really like to do (and clients waiting for the projects would not be too apreciative, either).
2. Realizing that the output of the "yum check" actually is a table with 6 columns, e.g.
"PyQt4-4.10.1-4.fc17.x86_64 is a duplicate with PyQt4-4.10-1.fc17.x86_64", awk can help.
3. rpm is not happy processing stdin (I have read that the paranoic anaconda is the reason), but is quite happy to process a bash variable.
So, this is what I have done:
yum check >yumcheck
mylist=`awk '{print $6}' yumcheck; rpm -ev $mylist
So I have manually removed old versions of the packages - I guess removing the new version (with $1 instead of $6) would work too.
(I guess I could do without the temporary file like:
yum check | mylist=`awk '{print $6}' -; rpm -ev $mylist
but I haven't tested it as my yum database is clean now :-)
When running "yum upgrade" again there was another problem with the abovementioned multilib and I have had to run two "rpm -e" commands to clean the stuff, but this was peanuts compared to 277 duplicated before. When yum reports problem with multilib, I ran the rpm command to find the problem, it happened to be glibc (that's what yum reported):
rpm -q glibc
produced
glibc-2.15-58.fc17.x86_64
glibc-2.15-58.fc17.i686
glibc-2.15-59.fc17.x86_64
I have removed the "new" version (the old ones had many dependent packages) and ran the "yum upgrade" again.
rpm -e glibc-2.15-59.fc17.x86_64
yum upgrade
There might be more than one unfinished multilib packages, just remove the partially installed new packages and eventually the "yum upgrade" will work.
Hopefully this helps some other "brilliant minds" and also some of the normal people who just happened to experience a "non-anthropogenic" interrupt during the critical upgrade phase.
|
