This article covers how to fix broken packages in Linux. These fixes should help you get unstuck in most instances.
Fixing Broken Packages in Ubuntu/Mint/Debian
Apt has a couple of flags 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 it can’t resolve dependencies. In any case, you can try the following steps: Note: learn how Apt works before attempting any of the fixes below.
Fixing DPKG Configuration Issues
Another place where an error can pop up in package installations is the configuration process. Behind the scenes, dpkg takes care of this part, so when a package fails during configuration, dpkg is the tool to fix it. The above command will show you the packages that cause problems. For this next step, check and make sure that the packages marked for reinstall are really broken. Do a sudo apt reinstall and pay attention to which packages fail to reinstall. 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 you were originally trying to install 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 is already using it … when it isn’t. It’s 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 the cache. Warning: Before removing this lock, make sure that it’s not being used. In Ubuntu, there’s an updater that starts up together with the system that locks DPKG/APT when it’s searching for updates. If you’re unsure whether the updater is running, press your Win key to bring up the Activity Center and type “Software Updater,” then press Enter to open it. If the updater says that it can’t run, and you have no terminals open with package managers running in the background, go ahead with the above instructions. If instead of the broken packages issue you are facing an issue with the Software Center not working, we have the fixes.
Fixing Broken Packages in Fedora/CentOS/RHEL
Fixing broken packages in Fedora/CentOS/RHEL is a less common affair. dnf does really great work making sure packages are installed correctly. That said, it’s still not perfect, and things will sometimes get mixed up in package management. Note: learn the differences between Fedora, CentOS and RHEL.
1. List Troublesome Packages
The command to sort this out on RHEL-based systems like Fedora is: The -V option is to verify, meaning it will go through and compare information on the installed files with the information stored in the rpm database. Attaching -a to this just verifies all core packages. 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. For example, seeing something marked as “missing” in your terminal will tell you that there are missing files in that particular package.
2. Attempt a Reinstall
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 will just skip that package entirely and let you update your system normally.
3. The Last Resort – Remove Packages
If you’ve reached the point where you have to use –skip-broken to complete your updates, it’s more hygienic for your system to remove it entirely. Remembering the name of the package you failed to properly reinstall, uninstall it: The worst that could happen here is that you end up removing a core part of your daily flow, such as your browser, forcing you to find an alternative. Tip: learn how to use flatpak in Fedora to better manage your packages.
Fixing Broken Packages in Arch
Although Arch’s package manager has some similarities to the others listed here (i.e, it has a database lock file and pulls dependencies in a similar way), it’s an entirely different beast of its own when it comes to how its logic is structured. The first step in diagnosing your issue is to make 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: Note: learn how pacman works before you attempt to fix it.
“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’s package manager. 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 and couldn’t remove the lock, it’s very likely to leave behind a lock file. First, find out if some process on your computer is still using the file: 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: 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 of ownership. Before fixing anything, pay attention to the path to the file that the package manager is complaining about. To find out 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 to 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 a backup 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. Alternatively, you could also just tell pacman to overwrite everything it needs to:
“Invalid or Corrupted Package (PGP Signature)”
In some packages that are poorly maintained, the developer may not have the time or willingness to properly update the digital signature that certifies their package. This will eventually result in a message in your terminal while trying to install it, such as, “signature from [someone] is marginal trust,” followed by the package manager asking if you’d like to delete the file. Because signature updates depend entirely on the maintainer, there’s nothing you can realistically do to fix the situation from your terminal. If you’re doing an update and want to keep the package, use the –ignore flag for that package in particular: If you get this for many packages, your keyring might be out of date. Update it with: Image credit: Flickr. All screenshots by Miguel Leiva-Gomez.
