We have all been there. You run an update, the progress bar crawls to a finish, and everything looks green. But five minutes later, your application is throwing file not found errors for binaries that clearly exist in the filesystem. I once spent three hours debugging a production deploy only to find out that a rogue symlink, created during a botched manual patch six months prior, was confusing the package manager’s post-install scripts. The system thought it had successfully replaced a shared library, but it was just updating a dangling pointer.

Why dpkg loses its mind over directory swaps

The issue usually stems from the transition between files and symlinks. If a package maintainer decides to move a directory to a symlink—or vice versa—dpkg can get stuck if there is a leftover file or dead link from a previous state. It isn’t just about disk space; it is about the internal state machine of the package manager failing to reconcile what it expects to see with what the kernel actually reports. When the database entry mismatches reality, you end up with phantom files that won’t go away.

find /usr/lib/ -xtype l -print

• Broken symlinks in /usr/lib or /usr/local/lib often mask real library paths during linker resolution
• The package manager skips replacing files if it incorrectly thinks they are user-modified, even if they are just stale artifacts
• Running find with the -xtype l flag helps you identify these ghosts before they break your next library upgrade

Fixing the mess before the next install

Don’t just delete these links blindly. Check if they belong to a package using dpkg -S before you rm them. If they return an error about not being found, that is your confirmation that the package manager has lost track of the file. Go ahead and clean them out, then reconfigure the packages that were struggling to unpack. Next time you notice a weird file access error during a version jump, start your investigation with the symlink map rather than assuming the vendor shipped broken code.