How to Fix Broken Packages in Linux

Linux installation packages can be broken at times, but luckily, there are multiple ways to fix it.

Linuxpackages Broken

Linux package managers, like Apt and DNF, are extremely powerful and intuitive, but that doesn’t mean things can’t go wrong. Occasionally, a package install goes wrong, and you’re left to pick up the pieces. Package managers have the ability to fix broken packages and skip broken updates to get your system working again and avoid troubles in the future. This article covers how to fix broken packages in Linux.

These tips and tricks should help you get unstuck in most instances. They’re all fairly universal, but every situation is different, so keep that in mind when trying to debug your own situation.

Fixing Broken Packages in Ubuntu/Mint/Debian

Apt has a couple of flags you can use to fix missing dependencies or packages that broke for one reason or another during install. A common use here would be installing a third-party .deb and finding that it had dependencies you didn’t know about. Those dependencies probably won’t be pulled in on their own, and dpkg will complain that the package is missing in them. In any case, you can try the following steps.

Ubuntu Apt Fix Missing

First, run an update to make sure there aren’t newer versions of the required packages.

Next, you can try forcing Apt to look for and correct any missing dependencies or broken packages when you attempt to install the offending package again. This will actually install any missing dependencies and repair existing installs.

Another place where error can pop up in package installations is the configuration process. Behind the scenes, dpkg is taking care of this part, not Apt, so it would stand to reason that when a package fails during configuration, dpkg is the tool to turn to in order to fix it.

Ubuntu DPKG Reconfigure

Start by trying to force dpkg to reconfigure any broken or partially configured packages.

If that doesn’t solve the problem, you can take a more forceful approach. Start by listing any packages that dpkg marked as requiring a reinstall.

You should see the problematic package(s) there. As long as there isn’t anything that doesn’t seem to belong there, you can force-remove the broken packages.

When dpkg is done, try to clean up with Apt.

With any luck, that’ll get you back to where you started. It won’t get you the broken packages that you tried to install, but at least Apt will be functional again, and you can go back to using it to attempt to install the package and its dependencies.

Permanent DPKG Lock

There’s a less common issue with dpkg locks preventing you from doing anything. Every time you try to use Apt or dpkg, you get an error saying another application already is … when it isn’t.

It’s actually easy to delete the lock file preventing you from using Apt and getting back to doing what you need to. Sometimes these lock files remain in place after an install error or power outage, derailing the process and preventing the file from being removed automatically. In this case, you’ll need to do it yourself.

For good measure, delete the lock in cache.

Fixing Broken Packages in Fedora/CentOS/RHEL

Fixing broken packages in Fedora/CentOS/RHEL is less common, as yum and dnf do really great work in making sure packages are installed correctly. However, sometimes things get mixed up in package use. The command to do that on rpm-based systems is:

Fix Broken Packages Linux Rpm Va

The -V option is for verify, meaning it will go through and compare information on the installed files with the information stored in the rpm database. This is slightly unhelpful, as it will usually give you a long list of files, but it can give you somewhere to start if you’re having issues with a particular application. You can run a dnf reinstall on any packages you see in that list that might be giving you trouble.

That will set all metadata as expired, so it will crawl through every repository you have enabled and look for a new version of that package. If you find that there are broken dependencies with that package, DNF will probably complain and tell you to use the --skip-broken flag. This can also mean that you don’t have a particular repository enabled to pull in a dependency, so you may have to do some research there.

Fixing Broken Packages in Arch

Although Arch’s package manager has many similarities to Debian’s, it’s an entirely different beast. The first step in diagnosing your issue is making sure that the repositories are up to date and attempt a full upgrade:

If your attempts to install your package or do a system upgrade are still ending in failure, we have to isolate the cause according to what the terminal told you:

“Invalid or Corrupted Package”

Making changes to “pacman.conf” in any manner can cause issues that cause pacman to incorrectly label packages as corrupt. The most likely culprit here is a partial (“.part”) file in the package manager cache, and your solution is to remove it:

There’s always a chance that the package you’re trying to install is indeed corrupt and doesn’t provide valid metadata to Arch. In that case, you’ll have to wait for the package maintainer to update it. If the package is installed on your system and causing problems during an upgrade, remove it with:

“Unable to Lock Database”

Like Debian’s apt, Arch’s package manager makes a lock file during operations. If you experienced a power outage or pacman experienced a hard interrupt it couldn’t remove the lock from, it’s very likely to leave behind a lock file.

First, find out if some process on your computer is still using the file:

Linuxpackages Lockpid

In the image above, a process with ID 121497 is using the file lock. If you’re curious about the process and want more information, use ps:

Linuxpackages Pspid

In my case, another pacman instance owns the lock file. The safest way to remove the lock is to first kill that process:

Now that the process is dead, remove the lock file:

You’re good to go now!

“Conflicting Files/File Exists in Filesystem”

This happens during upgrades where pacman detects a conflict. Before fixing anything, pay attention to the path to the file that the package manager is complaining about.

The first thing we have to find out is who owns the file:

If it’s owned by a user and not another package, just remove it:

If it’s owned by another package, the safest thing you can do is wait for the package’s maintainer to fix this conflict themselves. Sometimes that’s not an option, though, and you want to get things done now.

The simplest way to accomplish this is using the --overwrite flag in pacman. Just know that this is generally unsafe and could lead to some applications not working correctly in your system. I suggest making backups prior to running this.

The --overwrite flag allows Arch’s package manager to ignore ownership rules for a particular file and just steamroll through the update. Example:

If the above command doesn’t work, replace the file name with its absolute path. Some users have reported that removing the leading slash (“/”) in front of the path makes the command work when it’s being stubborn.

Frequently Asked Questions

1. Can I apply the Arch Fixes with an AUR helper?

Generally, yes. Replace “pacman” with your AUR helper in the commands in this guide. Example:

2. Are these instructions safe?

For the most part, every instruction here is about as safe as any other package management operation. The major exception is when you’re removing lock files. If you have a way to do so, it’s always important to kill any processes that may be using those files before removing them. Remain aware of what your system is doing. You might have forgotten an instance of apt or pacman running somewhere!

The best practice would be to always back up your system before any upgrade.

3. What should I do if I interrupt an update?

Breaking an update process either by pressing Ctrl + C , killing the package manager’s process, or closing the terminal prematurely will result in some level of corruption in your package database that could complicate things for you when you try to install something else. To fix this, clear the cache and repeat the update.

In Debian/Ubuntu/Mint/Pop!_OS/etc.:

In Fedora/CentOS/RHEL:

In Arch:

Wrapping Up

Hopefully, one of these fixes worked for you, and you’re back working on your Linux system normally. Remember that the best way to handle a totally out-of-hand situation is to try to return to the way it was before. Don’t try to power through and add more things to solve a breakage by adding more things unless you know exactly what you’re doing. Chances are you’ll end up with a tangled mess of broken things that’ll be harder to sort out.

You may also need to clean up your Linux system to get rid of unnecessary and broken packages. If the cause is an old PC unable to support newer software, you can also make use of these three ways to put your old PC to good use.

Subscribe to our newsletter!

Our latest tutorials delivered straight to your inbox