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.
Also read:How to Fix Ubuntu Update Errors
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.
First, run an update to make sure there aren’t newer versions of the required packages.
sudo apt --fix-missing update
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.
sudo apt install -f
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.
Start by trying to force dpkg to reconfigure any broken or partially configured packages.
sudo dpkg --configure -a
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.
sudo dpkg -l | grep ^..r
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.
sudo dpkg --remove --force-remove-reinstreq [package name]
When dpkg is done, try to clean up with Apt.
sudo apt clean sudo apt update
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.
Also read:Ubuntu Software Center Not Working? Here Are the Fixes
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.
sudo rm /var/lib/apt/lists/lock
For good measure, delete the lock in cache.
sudo rm /var/cache/apt/archives/lock
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:
sudo 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.
sudo dnf --refresh reinstall PACKAGE_NAME
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.
Also read:How to Build a Package from Source in Linux
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:
sudo pacman -Syu
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:
sudo find /var/cache/pacman/pkg/ -iname "*.part" -delete
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:
sudo pacman -Rns [package name]
“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:
sudo fuser /var/lib/pacman/db.lck
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:
ps -p [PID#]
In my case, another pacman instance owns the lock file. The safest way to remove the lock is to first kill that process:
sudo kill [PID#]
Now that the process is dead, remove the lock file:
sudo rm /var/lib/pacman/db.lck
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:
pacman -Qo [path to the file]
If it’s owned by a user and not another package, just remove it:
sudo rm [path to the file]
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:
pacman -Syu --overwrite [file name]
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:
yay -Qo /path/to/file
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.:
sudo apt-get clean
In Fedora/CentOS/RHEL:
sudo dnf clean all
In Arch:
sudo pacman -Scc
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.
Our latest tutorials delivered straight to your inbox
