How to Fix `apt update` Errors on an End-of-Life Debian Release Like Bullseye
When apt update fails on Debian 11 Bullseye, APT, Debian’s package manager, may be unable to reach repositories at their usual locations…
On Debian, package-manager logs usually show when a package was installed or upgraded. Finding which APT repository supplied the installed version is harder because the installed-package database usually does not record that history.
APT is Debian’s tool for managing software packages. A repository is a source of packages and package information, such as a Debian archive or a third-party server you configured. The command apt-cache policy shows which sources currently offer a package version. It does not show which source supplied that version in the past. To find the date, check the timestamped records in dpkg’s logs. APT’s history logs can help identify the transaction.
First, confirm the package’s installed version and status:
dpkg-query -W -f='${binary:Package}\t${Version}\t${db:Status-Status}\n' PACKAGE
Replace PACKAGE with the package name. The output reports the package name, installed version, and status. The dpkg-query manual describes these fields; this command does not report the installation date or the repository used.
Next, ask APT which versions and sources it currently knows about:
apt-cache policy PACKAGE
The output shows version and priority information. If APT’s current package lists link the installed version to a configured repository, the output shows that link. It shows where APT currently makes the version available, but it cannot establish where the installed copy came from. The package may have come from a different repository. It may also have come from a local .deb file or a repository that is no longer configured. APT’s documentation for apt-cache also warns that its cached package information can be outdated.
The current source configuration has the same limitation. /etc/apt/sources.list and files under /etc/apt/sources.list.d/ show which sources are configured now. They do not show which sources were configured when the package was installed. For scripts, prefer dedicated tools such as apt-cache; the apt manual notes that its command-line output is intended for users and may change.
Search the current dpkg log and older copies that have been rotated and compressed:
zgrep -hE ' (install|upgrade) PACKAGE(:[^ ]+)? ' /var/log/dpkg.log*
Replace PACKAGE with the package name. The matching lines include timestamps and action names. An install entry records an installation action; an upgrade entry records a later package change. The dpkg manual documents timestamped package actions in the log.
For example, if the log shows an upgrade entry but no earlier install entry, you have evidence for when the package changed, but not when it was first installed. A missing entry does not prove that no installation occurred: logs may have been rotated out or removed.
APT’s history log can show which transaction and command accompanied a package change:
zgrep -hE '^(Start-Date|End-Date|Commandline|Install|Upgrade):' \
/var/log/apt/history.log*
Find the relevant transaction and check its Install: or Upgrade: line for the package. APT history provides context for the transaction. The dpkg log directly records when package actions took place. Debian documents these package-management records in its release notes and its package-management reference.
APT’s current policy output answers, “Where does APT currently see this version?” It does not answer, “Which repository supplied this installed copy?” Current metadata and configured sources can change after installation, and the installed-package database reports package state rather than the original download source.
Preserved APT history, a saved .deb file, or other records from the time of installation can provide clues. Check what each record identifies before drawing a conclusion. A transaction entry that names a package and version does not, on its own, identify the repository URL that supplied it. Debian’s APT configuration documentation also distinguishes repository-origin information from other source details, such as a server location.
Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.
Take a look at vroni.com