Amillia Publishing Company Advertisement  ©
HOME RESUME ABOUT DEMOS Connect Message Mobile Right Column Mobile Left Column Mobile Poem Shards Mobile Coder's Edge Mobile
header_image copyright APC 2010

Paging Control

previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnewest column

Coders Edge

From Pattern to Process

installation failure recovery from too many dependencies.

Recently I had a bad time doing an upgrade. Not to point fingers, I don't want to blame anyone. Actually, I want to thank the Open Source community for still doing it. And I try to share my ideas here. You just need to poke around. And so, given the nature of the failure I can tell you how you can avoid it happening to you: if you have a plethora (a technical term) of static packages, such as fonts and image packages, that can numbers in the thousands if you find and install them freely, remove all of them before hand so that the dependency list is much shorter. Then the system will not bark with the error that the limit of the number of dependencies to check has been reached.

I needed to use:

rpm -e

I had to generate lists of duplicate packages, that had not been properly installed, and do the rpm -e on each of those. That way I was able to fix the packages that were only part way through. I needed to reinstall all of those. It was a lot of files.

It took some hours, I spent the day doing it, but I did get through it all. There is a one-liner for fixing duplicate packages, but because of the number of duplicates that one liner did not work. Fortunately the system was still reporting that it found duplicates. And from that reporting, garnered through the use of the list facilities of yum, quickly I could generate scripts to automate the application of the rpm -e. And the way that worked was I found out all of hte packages that I needed to remove with the rpm -e, and I made a giant file as a script with all of them in it, one line for each package with the rpm -e format. Then run that over and over and over (about five times. It may have completed everything the fourth time). And eventually the script would run and give just errors, which means that everythign was done that needed to be done. Basically you dno't need to know the order of the removal of the packages. These were all duplicates, and so they could safely be removed as their functinoality was taken up by the new install.

Fortunately I was able to safely log in as my usual identity and do all of this through calls to sudo, for the su facility. There wsa nothing wrong with my system, no harddrive failures, no out of resource messages, nothing physically or electrically wrong. And so all I needed to do was just fix the depency issues by removing all of the duplicates. Then I needed to reinstall, this time using yum, which does all of the rpm things for you, with the yum reinstall functionality. Again, I had to make a gaint file with all of the calls in it, chmod to allow it to be executed, and then run it. But this wassn't going to work, so I needed to do it a little bit differently, and make multiple calls to yum, utislizing the reinstall facility, giving it a small enough number of packages so that the dependecy checking didn't barf (fail), and this took the lions share of time becuase then I needed to keep rerunning yum list facility for checking for duplicatess. The report of a duplicate package would not be removed until after the rpm script was rerun by the reinstall that yum does. If that confuses, no swet, it's a little bit of inside baseball rpm stuff that really is necessary to understand unless you hit this problem, or if you are writing your own rpm build and making a package for others to install. Then you would learn all about it.

At the end of it all I still had a few more issues, with drivers. But I would have had them anyway. Because I was safely back into my Gnome desktop and haappily running everything just the same as I had before the upgrade. Minus a day of my time. But that was the day of the blizzard so who cares. Oh, and I spent a lot of time outside clearing snow.

A key part of being able to do this was realizing that the preinstaller (for the upgrade) had already downloaded every package that I needed to proceed. And so, even without an internet connection at that point I had everything I needed to get to a place where I would be back to the desktop. Once I was in I had an internet connection, I was able to get to the online repositories, and then I was fine. I actually set up that cache area as a local repository. I will need to remove that. It's all obsolte, so it won't ever find anything there. But it will check it everytime that PackageKit runs, or yum update.

Jan 30, 2015


 Software Metal
 If can't be broke
 you won't be either



Please visit DEMOS

Paging Control

previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through previousprevious click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnext click through nextnewest column ConnectAmillia Publishing Company Advertisement  ©