How to fix dpkg: warning: ignoring request to remove package-name which isn't installed in APT

APTBEGINNERLOWUpdated Dec 29, 2025· 230 views

This warning appears when dpkg tries to remove a package it doesn't recognize as installed. Usually harmless, but indicates a package state mismatch between apt and dpkg.

Quick fix

Fixes dpkg: warning: ignoring request to remove package-name which isn't installed

dpkg-query --showformat='${Status} ${Package} ${Version}\n' -W package-name
  1. Check the actual package status
  2. Try using dpkg --purge directly
  3. Update package cache and retry
  4. Fix dpkg configuration if interrupted
apt — error
dpkg-query --showformat='${Status} ${Package} ${Version}\n' -W package-name
dpkg: warning: ignoring request to remove package-name which isn't installed

What this error means

The "dpkg: warning: ignoring request to remove package-name which isn't installed" warning occurs when the apt or aptitude package manager attempts to remove a package, but dpkg—the underlying Debian package database—doesn't have a record of that package being installed. This is typically a non-fatal warning and doesn't prevent system operations from completing. However, it indicates that there's a mismatch between what apt thinks is installed and what dpkg's database actually contains. This can happen when packages are in an inconsistent state or when package management records get out of sync.

Typical symptoms

  • Warning message appears during apt-get remove, apt-get purge, or aptitude commands
  • Package removal completes despite the warning
  • System continues to function normally
  • The same warning may appear for multiple packages in one operation

Common causes

  1. Package has already been removed or purged, but apt/aptitude's cache hasn't been updated
  2. State mismatch between aptitude's package database and dpkg's database
  3. Package configuration files remain even after removal (marked as purged in dpkg)
  4. Multi-architecture package state confusion (on systems with foreign architectures)
  5. Previous interrupted package management operations left incomplete

How to fix "dpkg: warning: ignoring request to remove package-name which isn't installed"

1Check the actual package status

First, verify whether the package is actually installed on your system:

bash
dpkg-query --showformat='${Status} ${Package} ${Version}\n' -W package-name

This shows the actual status dpkg has for the package. Common outputs:
- install ok installed - Package is installed
- deinstall ok config-files - Package removed but config files remain
- not-installed - Package doesn't exist in dpkg database

If the output shows "deinstall ok config-files", the package is only partially installed (configuration files remain).

2Try using dpkg --purge directly

If apt-get fails but you want to remove the package completely, try using dpkg directly:

bash
sudo dpkg --purge package-name

The --purge flag removes the package and its configuration files, which is more forceful than --remove. This often works where apt-get fails due to state mismatches.

3Update package cache and retry

Sometimes updating apt's package cache resolves the issue:

bash
sudo apt-get update
sudo apt-get autoremove
sudo apt-get clean

Then try removing the package again:

bash
sudo apt-get remove package-name
4Fix dpkg configuration if interrupted

If dpkg was interrupted during a previous operation, run:

bash
sudo dpkg --configure -a

This tells dpkg to finish configuring any packages that are in an incomplete state. After this, retry your package removal:

bash
sudo apt-get remove package-name
5Reinstall before removing (for broken packages)

If the package is in a severely broken state, reinstall it first:

bash
sudo apt-get install --reinstall package-name

Then attempt removal:

bash
sudo apt-get remove package-name

This puts the package back into a known good state before attempting removal.

Advanced notes

On systems with multi-architecture support (e.g., both amd64 and i386 packages), this warning can occur when apt/aptitude's package state tracking gets out of sync with dpkg's knowledge of which architectures are installed. Aptitude's "~c" pattern is designed to match only removed (not purged) packages, but in some versions this matching may be incorrect.

If this warning persists after trying the above steps, you can manually reset aptitude's package state database:

bash
sudo rm /var/lib/aptitude/pkgstates

Note: This removes all of aptitude's cached state, so you'll lose action history and marked packages. Aptitude will regenerate this file on next run.

The warning itself is harmless and doesn't prevent your system from functioning. Package removal typically succeeds despite the warning. However, the mismatch it indicates should be resolved to keep your package database clean.

Frequently asked questions

What does "dpkg: warning: ignoring request to remove package-name which isn't ins" mean?
The "dpkg: warning: ignoring request to remove package-name which isn't installed" warning occurs when the apt or aptitude package manager attempts to remove a package, but dpkg—the underlying Debian package database—doesn't have a record of that package being installed. This is typically a non-fatal warning and doesn't prevent system operations from completing. However, it indicates that there's a mismatch between what apt thinks is installed and what dpkg's database actually contains.
How do I fix "dpkg: warning: ignoring request to remove package-name which isn't ins"?
This warning appears when dpkg tries to remove a package it doesn't recognize as installed. Usually harmless, but indicates a package state mismatch between apt and dpkg.
What causes "dpkg: warning: ignoring request to remove package-name which isn't ins"?
Package has already been removed or purged, but apt/aptitude's cache hasn't been updated State mismatch between aptitude's package database and dpkg's database Package configuration files remain even after removal (marked as purged in dpkg)
Is the "dpkg: warning: ignoring request to remove package-name which isn't ins" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading