Fix: E: Unable to locate package / could not get lock /var/lib/dpkg/lock

E: Unable to locate package docker-ce
E: Package 'python-pip' has no installation candidate

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 2187 (apt-get)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

The first group means apt does not know a package by that name in the repositories it has lists for. The second group means apt or dpkg is already running (or was killed halfway) and the database lock protects you from two installers writing at once.

Unable to locate package, cause 1: package lists not updated

A fresh system, a fresh container, or any machine that has not run apt update has no idea what exists. This is the most common cause, especially in Dockerfiles.

sudo apt update
sudo apt install docker-ce

# In a Dockerfile, always in one RUN so the lists are fresh
RUN apt-get update && apt-get install -y --no-install-recommends curl && rm -rf /var/lib/apt/lists/*

Unable to locate package, cause 2: the repository is not configured

Packages such as docker-ce, kubectl, code and google-chrome-stable come from the vendor’s repository, not from Debian or Ubuntu. Follow the vendor’s instructions to add their signed source and key, then apt update again. On Ubuntu, some packages live in the universe component, enabled with sudo add-apt-repository universe.

apt-cache policy docker-ce         # shows the candidate and which source it comes from
grep -r '' /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Unable to locate package, cause 3: wrong or renamed name

apt search '^python3.*pip'
apt-cache search --names-only ripgrep

# Debian and Ubuntu renames to remember
# python-pip   -> python3-pip
# fd           -> fd-find (binary is fdfind)
# docker.io    is Ubuntu's build; docker-ce is Docker's own repo

has no installation candidate with a known name usually means the package exists in the lists but not for your release or architecture (arm64 versus amd64), or it was dropped from your old release. Check packages.debian.org or packages.ubuntu.com for your release.

Could not get lock, cause 1: another apt is running

Right after boot, Ubuntu’s unattended-upgrades or the GUI updater often runs for several minutes. The message names the PID. Let it finish.

ps -p 2187 -o pid,etime,cmd            # what holds it and for how long
sudo fuser -v /var/lib/dpkg/lock-frontend /var/lib/apt/lists/lock
systemctl status apt-daily.service apt-daily-upgrade.service unattended-upgrades

Wait, or watch it with sudo tail -f /var/log/apt/term.log. On servers where you want control over when updates run, disable the timers: sudo systemctl disable --now apt-daily.timer apt-daily-upgrade.timer and run updates yourself.

Could not get lock, cause 2: a dead or interrupted install

If no process holds the lock (fuser prints nothing) and apt still refuses, a previous run was killed, the machine lost power, or an SSH session dropped during an install. Finish the interrupted configuration first.

sudo dpkg --configure -a
sudo apt install -f

Careful: deleting /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock by hand is only safe when fuser shows no process holding them. Removing a lock under a running apt corrupts the package database. Run installs in tmux or screen over SSH so a dropped connection does not interrupt them.

Check that it is fixed

sudo apt update && apt-cache policy docker-ce    # candidate is no longer (none)
sudo apt install docker-ce                        # installs
sudo apt install --dry-run htop                   # no lock error

When it is not what you think

• The repository ... does not have a Release file or NO_PUBKEY during apt update: a source line or key is broken; fix that source before anything will install.
• Unable to locate package on a Raspberry Pi or ARM server can simply mean the vendor does not build for that architecture.
• On RHEL, Fedora, Alma or Rocky the equivalent messages come from dnf and the lock is /var/run/dnf.pid; the same rule applies: wait for the other process, do not delete the file while it runs.
• apt is not apt-get in scripts: use apt-get with -y and DEBIAN_FRONTEND=noninteractive in automation; apt itself warns that its CLI is not stable for scripts.

Official documentation

• apt-get(8) manual page
• dpkg(1): –configure -a
• Debian wiki: SourcesList