Overview

apt update aborts because one of your configured repositories does not publish a signed Release file for the suite (codename) you asked for:

E: The repository 'http://apt.example.net/debian bookworm Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

On Debian/Ubuntu this almost never means apt is broken. It means the URL/suite combination you pointed at has no Release (or InRelease) index — usually because the codename is wrong, the release reached end-of-life and was moved to archive, or the third-party repo simply doesn’t ship a top-level Release file. Apt refuses it because it can’t verify what it can’t index.

Symptoms

apt-get update prints E: The repository '<url> <suite> Release' does not have a Release file.
A follow-up note: Updating from such a repository can't be done securely, and is therefore disabled by default.
The failing line names a specific host and suite, e.g. ... focal Release or ... stable Release.
Other repositories update fine; only one source in sources.list.d/ fails.
Common right after an OS upgrade, after copy-pasting a third-party install snippet, or once a distro release goes EOL.

Common Root Causes

The most common production cause is a wrong or end-of-life suite/codename — the mirror stopped publishing indexes for that release, or you typed a codename the repo never served. Other causes:

A distro release reached EOL and was moved to old-releases.ubuntu.com / archive.debian.org, so the live mirror no longer has it.
A third-party repo that only publishes a Packages file (a flat repo) but was added as a normal deb <url> <suite> <component> line.
A typo in the codename (bookwrom), or reusing a focal line on a jammy host after an upgrade.
The repo host is up but the specific dists/<suite>/ path returns 404.
A vendor decommissioned the repo entirely and left a dangling .list file behind.

How to diagnose

Read which source is failing. The error line names the URL and suite verbatim — note both:
```
sudo apt-get update
```

List every configured source so you can find that line:

grep -R "" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null
# Newer deb822 format:
grep -R "" /etc/apt/sources.list.d/*.sources 2>/dev/null

Confirm your actual release codename and compare it to the failing suite:
```
lsb_release -cs
cat /etc/os-release
```
Check whether the repo actually publishes a Release file for that suite:
```
curl -sSI http://apt.example.net/debian/dists/bookworm/Release
curl -sSI http://apt.example.net/debian/dists/bookworm/InRelease
```
A 200 OK means it exists; a 404/403 confirms the suite path is wrong or gone.

See if the release went EOL by testing the archive host:

curl -sSI http://old-releases.ubuntu.com/ubuntu/dists/$(lsb_release -cs)/Release

Fixes

Correct the suite/codename to match a suite the repo actually serves. Edit the offending file in /etc/apt/sources.list.d/, then:
```
sudo apt-get update
```

Repoint an EOL Ubuntu release to old-releases (only to drain remaining packages off a legacy host you can’t upgrade yet):

sudo sed -i -e 's|archive.ubuntu.com|old-releases.ubuntu.com|g' \
            -e 's|security.ubuntu.com|old-releases.ubuntu.com|g' \
            /etc/apt/sources.list
sudo apt-get update

For Debian the archive host is archive.debian.org. Treat this as a bridge — plan the real upgrade.

Remove a decommissioned or dangling third-party repo rather than fighting it:

sudo rm /etc/apt/sources.list.d/example-vendor.list
sudo apt-get update

Fix a flat repo that has no dists/<suite>/Release. Flat repos need the trailing-slash form, not a suite/component:

# Wrong (expects dists/bookworm/Release):
# deb http://apt.example.net/debian bookworm main
# Right (flat repo):
sudo tee /etc/apt/sources.list.d/example.list <<'EOF'
deb [signed-by=/usr/share/keyrings/example.gpg] http://apt.example.net/debian/ ./
EOF
sudo apt-get update

Use [trusted=yes] only for a repo you genuinely control and cannot sign — for example an internal build host on a private network:
```
# /etc/apt/sources.list.d/internal.list
deb [trusted=yes] http://packages.internal.example/ jammy main
```
This disables signature verification for that source, so scope it to trusted internal hosts only — never a public mirror.

Warning: [trusted=yes] and Acquire::AllowInsecureRepositories "true" silence the error by turning off the exact security check apt is enforcing. Reach for them only on repos you own on a trusted network; on anything public, fix the suite or remove the repo instead.

What to watch out for

After a release upgrade, third-party .list files still reference the old codename — audit sources.list.d/ as part of every upgrade.
old-releases/archive is a migration aid, not a destination; EOL releases get no security updates.
Flat repos (./) and suite-based repos (bookworm main) are not interchangeable — using the wrong form produces this exact error.
On RHEL/Rocky/Alma the analog is dnf’s Error: Failed to download metadata for repo / repomd.xml not found; the same wrong-baseurl and EOL-mirror causes apply.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.

Linux Error: 'The repository does not have a Release file' — Cause, Fix, and Troubleshooting Guide

Fixing errors like this? Get 500 free DevOps AI prompts