What to Do When apt update / apt install Fails on a VPS (2026): Troubleshooting dpkg Locks, GPG Keys, Dead Repositories, and Dependency Conflicts

Run:

sudo apt update

Don't just look at the last line. Sort the errors into categories:

Classify first, then act. The worst thing with apt problems is "not looking at all and just deleting locks, switching sources, and force-removing packages."

If you see:

Temporary failure resolving 'archive.ubuntu.com'

First confirm whether it's DNS:

ping -c 3 1.1.1.1
ping -c 3 archive.ubuntu.com

If the IP is reachable but the domain name isn't, fix DNS first instead of continuing to fiddle with apt. You can temporarily test a public DNS:

dig @1.1.1.1 archive.ubuntu.com

You can also check the local resolver:

resolvectl status
cat /etc/resolv.conf

If you just read the previous article on DNS resolution, you know this kind of problem should be investigated starting from systemd-resolved, /etc/resolv.conf, and the DNS settings pushed by the cloud provider.

If DNS is fine but apt downloads are slow or failing, try IPv4:

sudo apt -o Acquire::ForceIPv4=true update

Some VPSs have an IPv6 address configured but no working route, so apt hangs on IPv6. The long-term fix is to handle IPv6 routing or the software source configuration; using a temporary flag to paper over it is not recommended.

If you see:

404 Not Found
The repository does not have a Release file

First check the OS version:

lsb_release -a
cat /etc/os-release

Then look at the source files:

cat /etc/apt/sources.list
ls /etc/apt/sources.list.d/

Once an Ubuntu version reaches EOL, the default repositories may no longer provide the corresponding paths. For example, older Ubuntu versions need to switch to old-releases, or better yet, upgrade to a supported version.

Don't blindly copy jammy, noble, and focal from the internet and mix them together. Ubuntu 22.04 is jammy, and 24.04 is noble. If the OS version and the source codename don't match, you'll get a pile of dependency conflicts.

You can quickly check which codenames are used in your sources:

grep -R "^deb" /etc/apt/sources.list /etc/apt/sources.list.d/*.list

If multiple distribution codenames are mixed on the same machine, stop. Mixed sources are a major cause of apt disasters.

A common error:

NO_PUBKEY ABCD1234EFGH5678
The following signatures couldn't be verified

This usually means the signing key for a third-party repository isn't installed properly, has expired, or an old tutorial is still using the deprecated apt-key.

First find which source it is:

grep -R "第三方域名或仓库名" /etc/apt/sources.list.d/ /etc/apt/sources.list

The modern approach is usually to put the key in:

/etc/apt/keyrings/

Then in the source file use:

signed-by=/etc/apt/keyrings/example.gpg

For example, the official Docker repository roughly uses this structure. The official installation documentation for each piece of software will give the corresponding commands. Don't casually copy a keyserver command from a forum here, because you are trusting this repository to install software on your system.

After fixing it, run again:

sudo apt update

Many people encounter:

Could not get lock /var/lib/dpkg/lock-frontend

and immediately do:

sudo rm /var/lib/dpkg/lock-frontend

Not recommended.

First check whether an automatic system update is running:

ps aux | grep -E "apt|dpkg|unattended"
systemctl status apt-daily.service apt-daily-upgrade.service --no-pager

Then check who is holding the lock:

sudo lsof /var/lib/dpkg/lock-frontend
sudo lsof /var/lib/dpkg/lock

If apt.systemd.daily or unattended-upgrades is running, it's usually safer to wait for it to finish.

Only if you confirm the process is truly stuck should you consider terminating the related process. Before terminating, confirm that no important package is being installed:

sudo fuser -v /var/lib/dpkg/lock-frontend

Don't kill things randomly just to go faster. After dpkg is interrupted, you'll still have to fix the half-installed state.

If you see:

dpkg was interrupted, you must manually run 'sudo dpkg --configure -a'

Then do what it says:

sudo dpkg --configure -a

This command continues configuring packages whose installation was interrupted last time.

After it finishes, run:

sudo apt --fix-broken install
sudo apt update

The Ubuntu community and official troubleshooting workflows also commonly use commands like dpkg --configure -a and apt --fix-broken install to repair the interrupted state. Order matters: first let dpkg finish the incomplete configuration, then handle dependencies.

If you see:

You have held broken packages

First check whether any packages are held:

apt-mark showhold

If some packages really are held, figure out why. Don't blindly unhold them; they may have been held earlier to pin the database, PHP, or Nginx version.

Check the package policy:

apt-cache policy 包名

Simulate the installation without actually executing it:

sudo apt install -s 包名

-s is a simulation, good for first seeing what apt plans to install and remove.

If dependencies are missing:

sudo apt --fix-broken install

If mixed sources are causing versions to fight each other, prioritize cleaning up the wrong sources rather than forcing an installation.

You can audit with dpkg:

sudo dpkg --audit

You can also look at abnormal states:

dpkg -l | grep -E "^(..r|..U|..F|..H|iF|iU|iH)"

Common states:

• iU: package unpacked but not configured
• iF: configuration failed
• rc: package removed but configuration files remain

For iU and iF, usually first:

sudo dpkg --configure -a
sudo apt --fix-broken install

If a package keeps failing to configure, look at its postinst errors, service startup logs, and disk space instead of force-removing it directly.

apt/dpkg needs to write cache, unpack, and write configuration files. If the disk or inode table is full, it will also fail.

First check:

df -h
df -i

Then clean the apt cache:

sudo apt clean

If /boot is full, the common cause is too many old kernels. First check the currently running kernel:

uname -r

Then check installed kernels:

dpkg -l 'linux-image*' | grep '^ii'

Don't delete the currently running kernel. For cleaning old kernels, it's recommended to use apt's autoremove mechanism:

sudo apt autoremove

Before executing, look carefully at what it plans to delete.

apt update only refreshes the package index. During the actual installation, you may still run into dependencies, conflicts, disk, or service startup failures.

It's recommended to simulate first:

sudo apt install -s nginx

After confirming it won't remove anything strange, execute:

sudo apt install nginx

If installing a service fails, such as MySQL, Nginx, or Docker, continue by checking the corresponding service logs:

systemctl status nginx --no-pager
journalctl -u nginx --since "30 minutes ago" --no-pager

Some package installation failures aren't because apt itself is broken, but because the service fails to start after installation and dpkg's postinst script returns an error.

When I encounter apt/dpkg errors, I generally follow this order:

sudo apt update

First look at the error type. If it's DNS, fix DNS first. If it's a lock:

ps aux | grep -E "apt|dpkg|unattended"
sudo lsof /var/lib/dpkg/lock-frontend

If it's an interruption:

sudo dpkg --configure -a

Then fix dependencies:

sudo apt --fix-broken install

Clean the cache and update:

sudo apt clean
sudo apt update

Check for bad states:

sudo dpkg --audit
apt-mark showhold

Finally install the target software:

sudo apt install -s 包名
sudo apt install 包名

This workflow is much more stable than "delete the lock + force install."

Switching sources isn't a cure-all, but there are several situations where you can consider it:

• The current mirror source has been returning 404 or timing out for a long time
• The region where the VPS is located has very slow access to the official sources
• The cloud provider's internal mirror is more stable
• The current source doesn't support your OS version

Back up before switching sources:

sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak

Then confirm the system codename:

. /etc/os-release
echo "$VERSION_CODENAME"

The codename in the sources must match the system. Don't use 24.04 sources on Ubuntu 22.04, and don't mix Ubuntu sources into Debian 12.

After switching:

sudo apt update

If you get GPG, Release file, or dependency conflict errors, it means the sources still aren't matched correctly.

In some situations, continuing to force repairs carries high risk:

• A production database is running and apt wants to remove database-related packages
• The system sources mix multiple distribution codenames
• /boot and / are already full
• dpkg state is abnormal in many places
• You don't know why a held package is held
• The cloud provider's image is too old and the OS is already EOL

At this point, take a snapshot or back up first, then continue. The package manager is at the system's foundation; one force-removal can take down SSH, networking, and the database together.

• Read the full apt error, not just the last line
• Rule out DNS / network issues first with ping, dig, resolvectl
• Source codenames match the OS version
• Third-party sources use the correct GPG key and signed-by
• For dpkg locks, check processes first; don't just delete the lock file
• For dpkg was interrupted, run dpkg --configure -a first
• For dependency issues, then run apt --fix-broken install
• Use dpkg --audit to check half-installed packages
• Use apt-mark showhold to check held packages
• Check df -h and df -i
• Simulate with apt install -s before installing
• Take a snapshot/backup before major source changes or force-removing packages

apt/dpkg failures look like a pile of English error messages, but most can be categorized: network resolution, source configuration, signatures, locks, interruptions, dependencies, disk. Categorize first, then fix in order. As long as you don't start by randomly deleting locks, switching sources, and force-removing packages, most VPS apt problems can be rescued.