Fix dpkg Dependency Errors on Ubuntu Safely

dpkg -i can unpack a local Debian package, but dpkg does not fetch missing dependencies from configured repositories. Modern Ubuntu users should normally give the local .deb to APT instead; APT can calculate dependencies and then ask dpkg to perform the install.

Quick answer

$ sudo apt update
sudo apt install ./mypackage.deb

Why this is the preferred path

• The ./ prefix tells APT that the argument is a local file path rather than a repository package name.

• APT reads the local package metadata, resolves satisfiable dependencies from enabled sources, and shows the complete install/upgrade/removal plan.

• apt update refreshes metadata; it does not upgrade installed packages. Stop and fix repository signature/network errors before installing.

• Do not add -y while troubleshooting. Read download size, disk use, new packages, upgrades, downgrades and removals interactively.

• A local package remains third-party code executed with system privilege. Dependency resolution does not establish provenance or security.

How APT and dpkg divide the work

local vendor package.deb
        │ inspect control metadata
        ▼
APT dependency solver ← package indexes / configured signed repositories
        │ proposes install, upgrade, downgrade, remove
        │ user reviews and confirms
        ▼
dpkg unpack → pre/post maintainer scripts → configure
        │
        ├── success: installed/configured
        └── failure: unpacked / half-configured / triggers pending
                         │
                         └── diagnose exact cause before repair

State-model takeaways

• A package can be unpacked but not configured; “files exist” does not mean installation completed.

• Dependencies include exact versions, alternatives, conflicts, breaks, pre-dependencies and architecture qualifiers. Installing a named missing library manually may create another conflict.

• Maintainer scripts run as root and can fail for service, configuration, filesystem or application reasons unrelated to dependency solving.

• APT policy selects candidate versions from configured sources, priorities, holds and the current Ubuntu release.

1. Confirm Ubuntu release, architecture and free space

$ . /etc/os-release
printf 'Ubuntu: %s (%s)\n' "$PRETTY_NAME" "$VERSION_CODENAME"
dpkg --print-architecture
dpkg --print-foreign-architectures
df -h / /var
df -i / /var

Preflight takeaways

• Package dependencies are release-specific. A .deb for Debian, another Ubuntu series, or a newer libc baseline may be unsatisfiable.

• dpkg --print-architecture reports the native package architecture; foreign architectures are intentional multiarch additions.

• Disk-block and inode exhaustion can interrupt unpack/configuration and masquerade as a package-manager failure.

• Production systems should have a tested backup/snapshot and change window before modifying core libraries or services.

2. Inspect the .deb before privileged installation

$ file -- ./mypackage.deb
dpkg-deb --info ./mypackage.deb
dpkg-deb --contents ./mypackage.deb | less

Package-inspection takeaways

• dpkg-deb --info shows package name, version, architecture, dependencies, conflicts and maintainer metadata without installing.

• --contents lists archived paths; it does not reveal every action performed by maintainer scripts.

• Verify the download’s checksum/signature using values obtained from an authenticated vendor channel. A checksum from the same compromised download page is weaker evidence.

• Inspect scripts/source or use an isolated test machine when the package’s trust level does not justify root execution.

• Do not install a package merely because its filename contains amd64; the control metadata is authoritative.

3. Check repository health and candidates

$ sudo apt update
apt-cache policy
apt-mark showhold

Repository takeaways

• Every enabled source should complete with valid signatures. Expired repositories, wrong suites, missing Release files and TLS/DNS failures must be resolved first.

• apt-cache policy exposes configured sources and priorities; mixing releases or unscoped third-party repositories can select incompatible versions.

• Held packages can prevent required upgrades. Do not unhold them until you understand why the hold exists.

• Ubuntu 24.04 and newer commonly use deb822 .sources files; older installations commonly use .list. Do not copy repository lines for another release.

4. Simulate the local package transaction

$ apt install --simulate ./mypackage.deb

Simulation takeaways

• Simulation prints the solver’s proposed actions without applying them. It cannot predict maintainer-script success or all runtime effects.

• Review packages marked NEW, upgraded, downgraded, removed or kept back. Core desktop, boot, SSH, networking and database removals are stop signs.

• An “Unable to correct problems” result needs cause analysis; repeated fix commands will not invent missing repository versions.

• Use the same package indexes, sources, holds and architecture configuration that the real transaction will use.

5. Install through APT

$ sudo apt install ./mypackage.deb

Install-stage takeaways

• Confirm only the reviewed transaction. Save complete output and exit status for production changes.

• APT can download repository dependencies, but it does not automatically provide vendor updates for a standalone .deb. Determine the supported update channel.

• Configuration prompts may require an operator. Noninteractive automation needs package-specific policy and testing—not a blanket DEBIAN_FRONTEND workaround.

• If installation fails, preserve the first error and logs; the last cascading error is often not the root cause.

Repair a system already broken by dpkg -i

1. Audit pending package state

$ sudo dpkg --audit
sudo apt-get check
grep -E '^(Start-Date|Commandline|Error:|End-Date)' /var/log/apt/term.log | tail -n 40

Audit takeaways

• dpkg --audit reports partially installed packages or missing control data.

• apt-get check updates no packages; it diagnoses broken dependencies using current package metadata.

• APT history/terminal and /var/log/dpkg.log can show the original transaction and first failing package. Logs may rotate.

• Do not delete /var/lib/dpkg/status, lock files or package database directories. Locks normally indicate another legitimate package process; identify it instead of corrupting state.

2. Finish interrupted configurations

$ sudo dpkg --configure -a

Configure-stage takeaways

• --configure -a asks dpkg to configure every unpacked-but-unconfigured package. It does not download missing dependencies.

• Read the first maintainer-script failure. Repeatedly rerunning without fixing service/config/filesystem conditions only reproduces it.

• Configuration may start/restart services or regenerate boot/initramfs data; use an appropriate maintenance window.

• If the error is solely unsatisfied dependencies, continue to APT’s repair plan.

3. Preview the fix-broken plan

$ apt --fix-broken install --simulate

Repair-preview takeaways

• --fix-broken lets APT deduce a consistency-restoring transaction when dependencies are broken.

• The plan may remove the local package if its dependencies cannot be satisfied; that can be the correct safe outcome.

• Unexpected downgrades/removals suggest mixed sources, pinning, holds or an incompatible .deb; investigate instead of forcing.

• Simulation does not run package scripts, so it cannot guarantee the applied repair will complete.

4. Apply only the reviewed repair

$ sudo apt --fix-broken install

Repair takeaways

• Confirm the transaction interactively. Do not use -y to hide a removal you did not intend.

• APT downloads satisfiable dependencies, configures pending packages, or removes the unsatisfiable package to restore consistency.

• If it fails, return to the earliest error. Network, repository, disk, maintainer-script and dependency-version failures require different fixes.

• Running the original dpkg -i again is usually unnecessary after APT successfully configures the package; verify state instead.

Verify package database and application state

$ sudo dpkg --audit
sudo apt-get check
dpkg-query --show --showformat='${binary:Package} ${db:Status-Status} ${Version}\n' mypackage
systemctl --failed --no-pager

Verification takeaways

• A clean audit and dependency check prove package-database consistency, not application correctness.

• Replace mypackage with the control-file package name, not necessarily the .deb filename.

• installed status confirms dpkg state. Validate executable version, configuration, service health and application tests separately.

• systemctl --failed is relevant on systemd hosts; containers/chroots may not run systemd.

• Review /var/log/apt/history.log, /var/log/apt/term.log and /var/log/dpkg.log for the applied change.

Diagnose common root causes

• Package has no installation candidate: required repository/component is disabled, unsupported, unavailable for this release/architecture, or metadata failed.

• Depends: X but Y is to be installed: exact-version conflict, pin/hold, mixed suite or third-party repository preference.

• Wrong architecture: download the vendor build matching dpkg --print-architecture or use supported multiarch only when designed for it.

• Package requires newer libc/system library: use a build for this Ubuntu release; never replace core libraries manually from random archives.

• Maintainer script returned error: inspect the named script/service/config failure; dependency repair alone will not solve it.

• Could not get lock: another apt/dpkg/unattended-upgrades process is active or crashed; inspect process and logs, then let it finish.

• No space/inodes: free space safely and understand partial state before configuration resumes.

• Hash/signature/download failure: stop; fix mirror, proxy, clock, CA, repository authenticity or cache corruption using documented procedures.

• Held package blocks solution: determine ownership/change reason before deliberately changing the hold.

What not to do

• Do not download each named dependency from arbitrary package sites; dependencies have transitive versions and trust requirements.

• Do not use dpkg --force-depends, edit the status database, or remove lock files as a generic fix.

• Do not mix Debian packages or Ubuntu release archives to satisfy one application.

• Do not purge broad package groups until the solver appears quiet; that can remove the desktop, kernel, SSH or data services.

• Do not run apt autoremove during an unresolved incident. Review auto-removable packages only after consistency and service validation.

• Do not assume a successful install makes an unsupported third-party package maintainable or automatically updated.

Safer operational workflow

1. Prefer an official Ubuntu package/snap or vendor repository with scoped signing and update support over a one-off .deb.

1. Verify vendor, checksum/signature, Ubuntu release, architecture and support lifecycle.

1. Snapshot/backup production systems and test the package on an equivalent non-production host.

1. Update indexes, inspect policy/holds, then simulate apt install ./file.deb.

1. Apply only a reviewed transaction and retain logs.

1. Audit dpkg/APT consistency, test services and define rollback/update ownership.

Related Ubuntu package guides

• Repair repository metadata with Ubuntu apt update errors explained.

• Understand packages with APT, dpkg and Snap differences.

• Diagnose interrupted upgrades with dpkg was interrupted recovery.

Primary references

• Ubuntu’s current package-management tutorial recommends APT for local .deb files so repository dependencies can be resolved.

• Ubuntu documents APT and dpkg responsibilities, package states, repositories and logs.

• The Ubuntu `apt-get(8)` manual defines --fix-broken, simulation and dependency checks.

• Ubuntu’s third-party repository guidance explains trust, integrity and dependency-conflict risks.