This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

What to do when apt-get fails

By Bruce Byfield on October 21, 2005 (8:00:00 AM)

Share    Print    Comments   

When you install an application package in a Debian-based system, sometimes prerequisite application packages are unavailable. These missing packages are known as broken dependencies. Left unresolved, they can cripple your system's ability to install new packages. They're a disaster that isn't supposed to happen in Debian, thanks to the Advanced Packaging Tool (APT) and the scripts contained in Debian packages. That makes broken dependencies all the more devastating when they happen. Some users have even been known to reinstall the whole operating system, despairing of otherwise having a functioning package management system. However, depending on how the broken dependencies arose, you have several options to try before you consider reinstalling.

Package management in Debian-based distributions centers on apt-get, a utility with a high-level set of functions for package management. Normally, for Debian users, apt-get interacts with four online repositories -- experimental, unstable, testing, and stable -- as listed in each user's /etc/apt/sources.list file. (The repositories may differ for users of some Debian-derived distributions.) CDs and even local directories can also serve as package sources. Apt-get is supported by a cluster of related utilities, including apt-cache, apt-config, and apt-listchanges.

Apt-get calls on dpkg, the command that actually installs and removes packages. Like apt-get, dpkg is also supported by related utilities, including dpkg-reconfigure and dpkg-deb.

The two commands have several interfaces, including Aptitude, Synaptic, KPackage, Gnome-Apt, and dselect. Several of these interfaces, in particular Aptitude and dselect, include some of the tools you need for recovering from broken dependencies. However, as usually happens when an administrative problem arises on GNU/Linux, you have the widest set of options if you open a terminal while logged in as the root user and type the commands directly.

When broken dependencies occur

One case in which you have limited options for recovering the system is when you are installing unofficial .deb packages from a third party, instead of from a Debian-approved source. Although more free and open source software (FOSS) projects provide Debian packages than they did five years ago, too often they build them without dependencies calculated. That leaves users in the same dependency hell that RPM users had to endure in the bad old days before Yum and apt4rpm.

In this case, the only way out is to patiently track down the dependencies and install them one at a time. The trouble is, often the dependencies are unique to the project and the developers never bothered to make Debian packages for them. Admittedly, converting RPMs with alien or building do-it-yourself Debian packages are possibilities, but these options may require more effort than a casual user would find worthwhile.

More often, broken dependencies result from attempts to upgrade specific packages or the entire system. Unsurprisingly, they usually happen when using the experimental or unstable repositories, whose contents are still being tested. However, problems with packages also occur in testing, and even occasionally in stable. Mixing sources from different Debian-derived distributions can also cause problems. A package may need programs that are not available from the repositories in /etc/apt/sources.list, or a newer version of a program. Sometimes, a requested package or dependency conflicts with an already installed package, and the scripts included in the .deb do not yet have a suggested solution, such as holding back a package or removing the conflicting one.

Many users perform system upgrades when a new official version of Debian is released. In such large upgrades, a few problems are only to be expected. Usually, though, information about problems and workarounds can be found via an Internet search, if you can stand waiting for a week or two. If you're too impatient to wait, then you have a number of solutions that you can try on your own.

Preparing to find a solution

When broken dependencies occur, your first priority should be gathering information. The main source, of course, is messages generated by apt-get, which specify exactly what packages are causing problems. You can also run apt-get check to check for broken dependencies. If you still have Web access, you can also check the Debian bug-tracking system to see if anyone else is having the same problem.

If you know that your upgrading habits are risky, it's also advisable to plan ahead and install packages that can help you when broken dependencies hit. Use apt-cache or the list of packages on the Debian Web site to look at the utilities and related programs for both apt-get and dpkg. An especially useful one is apt-listchanges, which shows the differences between two versions of the same package. If you're comfortable with building Debian packages, you might also consider installing equivs, a utility for building packages that contain only dependency information.

Another useful tool is script, which allows you to save a log file of your recovery efforts from a command shell. By keeping this record, you can avoid repeating failed solutions and ensure that any information you gather isn't lost.

Escalating solutions

No matter how the broken dependencies arise, you have several ways to resolve the problems. In the order in which you should try them (and in ascending order of consequences, if something goes wrong), are:

  1. Wait to see if a bug-fix resolves the problem. You may speed this process by reporting your own experiences on the Debian bug-tracking system. On the whole, though, this is a more passive solution than most users would care for. After all, apt-get is all about instant gratification, right?
  2. Check the broken dependencies' availability. Run apt-get update to get the latest list of packages from your sources, then retry the installation. If it still isn't working, edit /etc/apt/source.list by adding another source, then run apt-get install again. If the package is just announced, some mirrors may take a few days to have it and all its dependencies.

  3. Run apt-get -f install or apt-get -f remove without specifying a package, to force completion of package installations. If you are attempting a system upgrade, then use apt-get upgrade -f dist-upgrade. You might want to add the --no-download switch, so that you are working only with packages already on your system, rather than downloading other ones and possibly compounding your problems.

    If neither command works, try them again specifying the packages of the broken dependencies one at a time, specifying either the version number (apt-get -f install packagename=versionnumber ) or the repository (apt-get -f install -t repository packagename ). You can use the list of packages on the Debian Web site to help choose the version number of the packages.

    Alternatively, try dpkg --configure -a to attempt to reconfigure partly installed packages another way.

    In my experience, these commands rarely solve dependency problems. Still, since they do the least possible violence to your system, you should try them before employing stronger measures. Some users suggest trying these options several times before giving up on them.

  4. Use dpkg -r package to remove the packages causing problems, or dpkg --purge package to remove all traces of the packages from the system, including any installation files. Both these approaches are frequently successful.
  5. Use dpkg --force-auto-select package and dpkg --force-all package , in that order. As the names suggest, the first option forces the installation of packages you select, and the second option turns on all --force options.
  6. After making backups, manually edit the package causing the trouble in /var/cache/apt. If you open the control file in the package's control.tar.gz archive, you may be able to change the package dependencies, then regain a working system by installing the package then automatically removing it. If the package is already partially installed, you may find useful information for further steps in the scripts located in /var/lib/dpkg/info. Files labelled .confiles may lead you to configuration files in the /etc/ directory, while .list files show which files a package installs. The occasional .preinst script, which runs before the package is installed, may also contain useful information. If you are comfortable writing shell or Perl scripts, you might even experiment with your own ways of making the package installable. These solutions require patience, and work best with expertise, but, even if they fail, they will teach you some of the fundamentals of the Debian package system.

    When you are finished with any modifications, run dpkg --configure -a to install with the modified scripts or packages. If you receive an error message about missing configuration files, check whether there is a configuration file for the package in /etc with an extension of .dpkg-new and use the mv command to rename it.

  7. Use equivs to create a package that contains only dependency information. This solution can be combined with editing scripts for a greater chance of success. The main drawback the approach is that it requires knowledge of how Debian packages are built, or at least a detailed set of instructions prepared ahead of time. In the middle of a crisis, beginning or intermediate users probably won't be open to learning anything new.
  8. Try dpkg --force-downgrade to attempt to resolve problems by reverting to earlier versions of a package. Note, though, that --force-downgrade works without checking dependencies, so it can leave you worse off than you were before. Use it only as a forlorn, last-ditch effort.

By this point, if you still don't have a working package management system, you can safely conclude that your system is unrepairable. A few hours older and more frustrated, you can begin to think about reinstalling the operating system without accusing yourself of wimping out -- either that, or about resigning yourself to the fact that you won't be installing anything new on your system unless it's from a tar file.

Avoiding broken dependencies

When you have a working system -- by whatever means -- consider taking steps to avoid broken dependencies in the future. Given Debian's reputation for slow testing, few users are likely to be content practicing safe computing and confining their installations to packages from the stable repository. However, there are at least three steps that you can take to protect yourself while still installing and upgrading with some freedom.

To start with, before installing or upgrading a package, check its dependencies on the Debian Web site. As a rule, the more libraries in a package's dependencies -- especially common ones, like glibc -- the greater the chances of broken dependencies. In other words, upgrading gnome-desktop-environment is a higher risk undertaking than installing PySol. If you have a strong need for a particular program, this information may do little except inform you of the risk. However, if your interest in a program is casual, it may cause you to think twice.

If you regularly use experimental or unstable, you can supplement the information from the Debian site by scanning the Debian User's mailing list to see what problems people are having. This step is time-consuming if you are a compulsive upgrader, but can often alert you to problems and solutions.

Finally, before you actually install, use the -s or --dry-run options with apt-get to simulate your results before actually facing them. This step alone may be enough to save you from disasters. Unfortunately, it is exactly the sort of step that is easy to forget at the end of the day.

The power of apt-get and dpkg is rightly considered a major feature of Debian distributions. Yet it's worth remembering that the same power that provides convenience can lead to catastrophe if you're careless. A little planning can go a long way in avoiding problems, or at least telling you the odds. And if catastrophe strikes anyway, the same power that got you into the situation may lead you out of it, if you work systematically through the options.

Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge and the Linux Journal Web site.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on What to do when apt-get fails

Note: Comments are owned by the poster. We are not responsible for their content.

oh come on Bruce!

Posted by: Anonymous Coward on October 21, 2005 11:19 PM
One case in which you have limited options for recovering the system is when you are installing unofficial<nobr> <wbr></nobr>.deb packages from a third party, instead of from a Debian-approved source. Although more free and open source software (FOSS) projects provide Debian packages than they did five years ago, too often they build them without dependencies calculated. That leaves users in the same dependency hell that RPM users had to endure in the bad old days before Yum and apt4rpm

Get real! "Testing" and "unstable" care so called for a reason. RPM based distro have the (well-named) "RPM hell" with their so-called (or not) "stable" (or wannabe stable) releases.

Also, Debian has 15000+ packages to choose from. But if you go fishing for the "15001st" one you have to be willing to cope with the consequences.

The question should be:

How often have you seen the 15000+ stable packages have dependencies problems?

And the answer is obvious!

#

Re:oh come on Bruce!

Posted by: Anonymous Coward on October 22, 2005 01:33 AM
If you want stability, and still to play with unstable software, all you have to do is run debian sid (=unstable) in a chroot. The debian reference even has detailed instructions on how to do this with an X login. There is absolutely no reason to run testing/unstable as a standalone system.

You can also add experimental apt sources to your sid chroot, and really live on the edge with no danger to your system or data.

#

Re:oh come on Bruce!

Posted by: Anonymous Coward on October 22, 2005 02:53 AM
More information and instructions: <a href="http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot" title="debian.org">http://www.debian.org/doc/manuals/reference/ch-ti<nobr>p<wbr></nobr> s.en.html#s-chroot</a debian.org>

I'm thinking about doing this. I have one question, though: How do I handle cron under the chroot?

#

Re:oh come on Bruce!

Posted by: Anonymous Coward on October 22, 2005 03:08 AM
When the getty on the host is set up as in the instructions, and<nobr> <wbr></nobr>/etc/X11/gdm/gdm.conf is set to start on vt11, just

login on the sid console (vt10 for me)
cd<nobr> <wbr></nobr>/etc/init.d
sudo<nobr> <wbr></nobr>./xfs start
sudo<nobr> <wbr></nobr>./cron start
sudo<nobr> <wbr></nobr>./gdm start

I have sid set to autologin for my user id, so that gives an X login with cron running. I should mention that debootstrap is an easy way to install the chroot system.

#

What do to when apt-get fails ?

Posted by: Anonymous Coward on October 22, 2005 01:37 AM
./configure && make && make install

#

Re:What do to when apt-get fails ?

Posted by: Anonymous Coward on October 22, 2005 03:43 AM
right on!

#

Re:What do to when apt-get fails ?

Posted by: lahvak on October 22, 2005 08:45 PM
./configure && make && checkinstall

#

Re:What do to when apt-get fails ?

Posted by: Anonymous Coward on October 22, 2005 11:58 PM
./configure && make && paco -lD "make install"

#

apt-get -f install

Posted by: Anonymous Coward on October 23, 2005 03:10 AM
The thing to do when you install manually a package that breaks your system is this command :

apt-get -f install

It will try to install all the necessary packages to make your system works via the net and if it can't do that, it will uninstall the package you installed causing the problem in the first place.

Either way, system unbroken.

If you still want that package that broke your system, look for the dependencies. Compile them but instead of doing a make install, do a checkinstall. It will do a fake install, check what would be done, create a<nobr> <wbr></nobr>.deb and install it for you. That way, it will be easy to uninstall it if you want to.

You will probably have to install checkinstall :

apt-get install checkinstall

#

The Hidden Power of Slackware

Posted by: Anonymous Coward on October 23, 2005 09:23 PM
Problems such as this just go to show the hidden power of Slackware. After using Debian for two years I was unsure about migrating to a distro that appeared to have very little in the way of package management tools. How wrong I was. The slackware package management tools (with the addition of checkinstall) provide the most useful, robust and flexible system that exists. Debian is a nice idea. Slackware is a better distro...

#

When apt-get fails?

Posted by: Preston St. Pierre on October 25, 2005 04:13 AM
I have to admit that while there may be some problems with apt, I've never encountered any that I couldn't fix by pointing my apt sources back to the Debian official mirrors and dist-upgrading. When I saw an article entitled "What to do when apt-get fails" my first thought was "What a needless article."

I guess some of you have had problems, but apt has always been reliable for me.

#

packages "held back"

Posted by: Randy on October 28, 2005 03:08 AM
I posted this at the original linux.com site too.

Do any of these solutions help with the "package xxx held back" message? I've tried both Mepis and Kubuntu (5.10), didn't change any of my apt sources, and did the apt-get update/upgrade thing consistently. But in both cases, within days of installing, I'd get that "package xxx was being held back" often when I knew there was a newer version available. Searching the web turned up some general info, but never a real fix.

Any pointers on this one? Thanks.

#

Nice title!

Posted by: Anonymous Coward on October 22, 2005 01:43 AM
What "do" to ?

#

apt-get update

Posted by: Anonymous Coward on October 22, 2005 01:59 AM
2. Check the broken dependencies' availability. Run apt-get update to get the latest list of packages from your sources, then retry the installation. If it still isn't working, edit<nobr> <wbr></nobr>/etc/apt/source.list by adding another source, then run apt-get install again. If the package is just announced, some mirrors may take a few days to have it and all its dependencies.




After adding a repository make sure you run apt-get update to use the new repository BEFORE running apt-get install again.




-GZ

#

No, it's easier than that usually...

Posted by: Anonymous Coward on October 22, 2005 09:55 PM
Whatever package is complaining, and whatever dependency it's complaining about,

# apt-get --purge remove (package names)

This wipes out the conflicted packages and all their config info - save any files outside of the system directories if you might need to restore a complicated bit of config.

For particularly broken situations, package names might be a dozen packagess.

Assuming you already -did- an update, if not, do one, it's back to the easy old,
# apt-get install
for the package that you needed.

Usually, this will install the package that you needed along with several packages that you just uninstalled and one that you never had before that satisfies the dependency correctly.

Typically, when apt-get fails, it's because of replaces- and provides- kinds of issues. Straight up dependencies are generally right. I've always been able to resolve these things by removing and reinstalling the dependency packages - usually just the ones mentioned in errors, but sometimes the whole depends list for a package.

With software outside of the debian project, I'll try to install their<nobr> <wbr></nobr>.deb, but if that fails (or isn't up to date in the first place) I'll just build from tarball with a<nobr> <wbr></nobr>/usr/local prefix. (Which often involves apt-get install somethinglib-dev, but so it goes.)

#

apt4rpm != apt-rpm

Posted by: Anonymous Coward on October 23, 2005 09:07 PM
Only to stress it again: apt4rpm is not the name of the apt port with the rpm backend.
Anyway the development of apt-rpm has stopped in favour for "smart" which should tacle the problems discussed in this article.
Ref:
<a href="http://labix.org/smart" title="labix.org">http://labix.org/smart</a labix.org>
<a href="https://moin.conectiva.com.br/AptRpm" title="conectiva.com.br">https://moin.conectiva.com.br/AptRpm</a conectiva.com.br>
<a href="http://apt4rpm.sourceforge.net/" title="sourceforge.net">http://apt4rpm.sourceforge.net/</a sourceforge.net>

#

What about apt-listbugs?

Posted by: Anonymous Coward on October 24, 2005 02:57 AM
apt-listbugs - Lists critical bugs before each apt installation

I skimmed the article so I don't know if apt-listbugs was mentioned. I know having that program installed has saved me from tons of frustration and grief many times. Of course it's not a panacea but it is a another tool to aid a sys admin make wise decisions in avoiding installing broken/buggy packages.

#

Re:packages "held back"

Posted by: Anonymous Coward on December 31, 2006 09:00 AM
I believe using "apt-get dist-upgrade" solves the "package held back" problem. It's held back because it depends on new packages that are not installed on your system, and the "apt-get upgrade" command only updates existing packages.

Selecting the "install all upgrades" option in Synaptic does the same thing as dist-upgrade.

#

packages "held back"

Posted by: Administrator on October 28, 2005 12:02 AM
Do any of these solutions help with the "package xxx held back" message? I've tried both Mepis and Kubuntu (5.10), didn't change any of my apt sources, and did the apt-get update/upgrade thing consistently. But in both cases, within days of installing, I'd get that "package xxx was being held back" often when I knew there was a newer version available. Searching the web turned up some general info, but never a real fix.

Any pointers on this one? Thanks.

#

ravindra mudumby--sol

Posted by: Administrator on October 22, 2005 02:36 AM
This happens from time to time, most often if you're running the unstable distribution or are mixing packages from different sources.
The brute-force method are to run:

code:

dpkg -i --force-overwrite<nobr> <wbr></nobr>/var/cache/apt/archives/kde-style-lipstik_1.0-2ub<nobr>u<wbr></nobr> ntu4_i386.deb


If it's a package that you don't really need you could also try 'apt-get remove kde-style-lipstik' which might work.

#

What to do when apt-get fails

Posted by: Anonymous [ip: 132.241.3.224] on October 03, 2007 04:40 AM
Right. Well, these all seem like great ideas... 'a simple fix'.
Unfortunately, none of them are working for me. I still
get the same error message everytime I run apt-get or synaptic:
"E: The package <pkgname> needs to be reinstalled but I can't
find a package for it"
Any new ideas? Thanks.

#

What to do when apt-get fails

Posted by: Anonymous [ip: 82.35.56.141] on November 01, 2007 10:37 PM
I fear that reinstalling with an older system seems to be the only practical solution, without manually picking through debs. It seems that dpkg -r is not smart enough.

Sid's xserver-xorg is currently broken in such a way :(. It cannot be installed, and is left in a state in which it cannot be un-installed, which breaks apt etc... There have been a lot of problems with sid recently, particularly with xorg. I am switching to lenny for new installs till things are better, and avoiding upgrading current installs of sid.

#

Re: What to do when apt-get fails

Posted by: Anonymous [ip: 130.232.134.179] on December 04, 2007 01:37 AM
I am also having serious problems with Sid's xserver-xorg packages, broken depedencies, been like already over a month.

#

What to do when apt-get fails

Posted by: Anonymous [ip: 208.69.212.143] on January 21, 2008 08:00 PM
It would help if apt-get was statically linked. I messed up my system by mixing libs:

# apt-get

apt-get: error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS32

-Frank

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya