Debian/Ubuntu: APT repository does not have a Release file — как исправить ошибку

Сообщение APT repository does not have a Release file при выполнении apt update — одна из самых частых проблем после обновления системы, добавления стороннего репозитория или копирования чужой инструкции. На практике это означает не просто сбой загрузки, а то, что APT не может безопасно использовать указанный источник пакетов.

Для администратора это важный сигнал. APT не хочет слепо доверять репозиторию, если у него нет корректного файла метаданных Release для нужного выпуска Debian или Ubuntu. Это нормальное и полезное поведение: без такого файла пакетный менеджер не может корректно проверить структуру репозитория, подписи и соответствие запрошенному релизу.

Чаще всего ошибка появляется в одном из сценариев: вы обновили систему до нового релиза, а внешний репозиторий его ещё не поддерживает; указали неверный codename; используете заброшенный third-party source; ошиблись в URL; либо подключили источник, который вообще не является полноценным APT-репозиторием.

Ниже разберём, как быстро понять, какой именно источник ломает apt update, где искать запись в sources.list и deb822, и что делать дальше: исправлять адрес, менять suite, проверять signed-by или временно отключать проблемный репозиторий.

Главное правило: не пытайтесь обходить ошибку отключением проверок безопасности. Почти всегда проблема решается исправлением конкретной записи источника, а не ослаблением политики APT.

Что на самом деле означает ошибка Release file

APT работает не с произвольной папкой с пакетами, а с репозиторием определённой структуры. Для каждого дистрибутива и компонента он ожидает метаданные в каталоге dists/. Обычно там находятся файлы Release или InRelease, а также индексы пакетов.

Если вы указали, например, ветку noble, APT попытается обратиться к структуре вроде dists/noble/Release. Если такого файла нет, менеджер пакетов делает логичный вывод: этот репозиторий либо не поддерживает ваш релиз, либо URL составлен неверно, либо это вообще не APT-репозиторий в нужном формате.

Типичная формулировка выглядит так:

E: The repository '...' does not have a Release file.

Нередко рядом есть и дополнительное пояснение:

N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Если вы администрируете сервер на VDS или на продакшен-машине, это особенно важно: ошибка говорит не о капризе APT, а о том, что источник не прошёл базовую проверку пригодности.

Самые частые причины в Debian и Ubuntu

Неподдерживаемый релиз системы

Классический случай: после перехода с Ubuntu jammy на noble или с Debian bullseye на bookworm внешний репозиторий ещё не выпустил пакеты под новую ветку. В конфигурации уже указан новый codename, а на сервере поставщика каталога с таким именем пока нет.

Неверный codename в источнике

Репозиторий может поддерживать вашу систему, но в записи указан не тот выпуск: bookworm вместо bullseye, focal вместо jammy и так далее. Такое часто бывает после копирования конфигурации с другого сервера.

Устаревший или заброшенный репозиторий

Старые записи в /etc/apt/sources.list.d/ — обычная история на серверах с долгой жизнью. Приложение уже удалили, поставщик сменил структуру публикации, а источник в системе остался и продолжает ломать обновления.

Некорректный URL

Иногда проблема банальна: опечатка в адресе, лишний подкаталог, использование страницы сайта вместо корня репозитория. Внешне это выглядит так же — APT не находит Release.

Неверный тип записи для источника

Иногда в APT добавляют адрес, который не предназначен для прямого использования пакетным менеджером: страницу загрузки, каталог артефактов CI или общий раздел сайта. В таком случае нужной структуры dists/ там не будет.

Ошибки в deb822

В новых Debian и Ubuntu всё чаще используются файлы .sources в формате deb822. При миграции со старых .list чаще всего ошибаются в полях URIs, Suites, Components и Signed-By.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если APT-ошибки регулярно возникают после обновлений или ручных правок репозиториев, полезно держать такие задачи на отдельном сервере или тестовом стенде на VDS, а не экспериментировать сразу в рабочем окружении.

С чего начать диагностику

Первый шаг — внимательно посмотреть полный вывод apt update. В большинстве случаев проблемный адрес уже явно указан в ошибке. Нас интересуют строки с E:, а также URL и название выпуска рядом.

sudo apt update

Типичный пример:

Err:6 vendor repo noble Release
  404 Not Found
E: The repository 'vendor repo noble Release' does not have a Release file.

Даже если вывод кажется шумным, почти всегда достаточно выделить три вещи:

• какой URL запрашивается;
• какой выпуск или suite запрашивается;
• какой файл отсутствует — обычно Release или InRelease.

После этого нужно найти, где именно этот источник прописан в системе.

Где искать проблемный репозиторий

APT берёт источники не только из /etc/apt/sources.list, но и из каталога /etc/apt/sources.list.d/. В современных системах рядом могут сосуществовать и файлы .list, и новые .sources.

Быстрый способ просмотреть активные записи:

grep -R "^[^#].*deb " /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null
grep -R "^[^#].*URIs:\|^[^#].*Suites:\|^[^#].*Components:" /etc/apt/sources.list.d/*.sources 2>/dev/null

Если вы уже видите в ошибке домен, имя поставщика или часть URL, удобнее искать точечно:

grep -R "vendor\|repository-name\|example" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Обычно после этого быстро становится понятно, какой именно файл нужно править.

Если вы используете локальный кэширующий прокси для обновлений, проверьте и его поведение: иногда полезно свериться с практикой из статьи про кэширование APT через Squid, чтобы исключить проблемы промежуточного звена.

Проверяем версию системы и codename

Перед исправлением важно понять, какой релиз реально установлен. Очень многие проблемы здесь возникают именно из-за несоответствия между системой и записью источника.

cat /etc/os-release
lsb_release -a

Нас интересуют поля VERSION_CODENAME, UBUNTU_CODENAME и общее название дистрибутива. Например, если у вас Ubuntu 24.04 с codename noble, а репозиторий настроен на jammy или mantic, источник может либо не работать, либо давать непредсказуемые результаты.

С Debian история та же: запись для bullseye не обязана подходить системе на bookworm. Даже если пакеты формально похожи, самовольная подмена suite без проверки документации поставщика — плохая идея.

Как выглядит проблема в sources.list

В классическом формате запись обычно выглядит так:

deb [arch=amd64 signed-by=/usr/share/keyrings/vendor-archive-keyring.gpg] repo-url noble main

Здесь критичны несколько полей:

• URL репозитория;
• ветка или suite, например noble;
• компоненты, например main;
• параметры, включая signed-by.

Если указан неверный suite, APT будет искать несуществующий каталог в dists/. Если ошибочен URL, результат будет тем же. При этом параметр signed-by обычно не вызывает ошибку про отсутствующий Release напрямую, но его часто приходится проверять следующим шагом.

Как выглядит проблема в deb822

Формат deb822 удобнее для сопровождения, но требует аккуратности. Типичная запись в .sources выглядит так:

Types: deb
URIs: repo-url
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/vendor-archive-keyring.gpg

Чаще всего ошибаются в полях Suites и URIs. Если в Suites указан неподдерживаемый релиз, вы получите ту же ошибку. Если в URIs прописан общий сайт поставщика, а не корень репозитория, APT тоже не найдёт Release.

Отдельно проверьте, нет ли дублирующих подключений. Один и тот же источник может одновременно быть прописан и в .list, и в .sources. Это мешает диагностике и создаёт ощущение, будто правка не сработала.

Безопасный алгоритм исправления

1. Найдите проблемную запись

Сначала точно определите файл и строку, которые вызывают ошибку. Не редактируйте все источники подряд: так легко случайно испортить штатные репозитории системы.

2. Сверьте codename с системой

Проверьте, соответствует ли указанная ветка вашему релизу. Если поставщик действительно поддерживает нужный выпуск, исправьте запись на правильный suite.

3. Убедитесь, что репозиторий вообще существует для этой ветки

Если после обновления ОС внешний источник ещё не поддерживает новый релиз, лучше временно отключить его, чем наугад переключать на старую ветку.

4. Проверьте формат записи

Убедитесь, что источник оформлен либо как корректная строка deb в .list, либо как валидный файл .sources в формате deb822. Смешивать синтаксис нельзя.

5. Снова выполните обновление

sudo apt update

Если ошибка про Release file исчезла, но появилась ошибка подписи, переходите к проверке ключа и параметра signed-by.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Когда лучше просто отключить репозиторий

Если это старый, редко используемый или уже ненужный сторонний источник, самое практичное решение — отключить его. Это особенно полезно, если пакет был установлен давно, больше не используется, а запись осталась жить своей жизнью.

Отключение безопаснее, чем попытка подбирать похожий выпуск наугад. Репозиторий для другой версии Debian или Ubuntu может привести не только к ошибкам обновления, но и к конфликтам зависимостей.

В старом формате достаточно закомментировать строку:

sudo editor /etc/apt/sources.list.d/vendor.list

Внутри файла поставьте символ # в начале строки источника.

В формате deb822 удобно временно переименовать файл:

sudo mv /etc/apt/sources.list.d/vendor.sources /etc/apt/sources.list.d/vendor.sources.disabled

После этого снова выполните:

sudo apt update

Если ошибка исчезла, виновник найден.

Что делать после обновления Debian или Ubuntu

Отдельный класс случаев — ошибки сразу после dist-upgrade. Сама система уже перешла на новый релиз, а внешние источники остались в старом состоянии или автоматически подхватили новый codename, который поставщик ещё не поддерживает.

В такой ситуации полезно пройтись по всем сторонним файлам в /etc/apt/sources.list.d/ и ответить на три вопроса:

• нужен ли этот репозиторий вообще;
• поддерживает ли он новый выпуск системы;
• не дублируется ли он в другом файле.

На серверах с долгой историей эксплуатации это особенно важно. После нескольких миграций в конфигурации APT легко накапливаются десятки записей, из которых реально нужны две-три.

Роль signed-by и почему его часто вспоминают рядом

Параметр signed-by указывает, каким ключом доверять конкретному источнику. Это правильная современная практика вместо старого глобального keyring-подхода.

Но важно не путать разные классы ошибок: does not have a Release file и ошибка проверки подписи — не одно и то же. Сначала APT должен найти сам файл Release или InRelease. Только потом он сможет проверить подпись.

Поэтому при отсутствии Release менять ключи обычно бессмысленно до тех пор, пока не исправлены URL, suite или структура источника.

Чего делать не стоит

• Не отключайте проверки безопасности APT ради одного репозитория.
• Не подставляйте случайный codename только потому, что он похож на ваш выпуск.
• Не оставляйте в системе мёртвые источники годами.
• Не смешивайте старый подход с глобальными ключами и новый подход с signed-by без понимания различий.
• Не редактируйте штатные репозитории Debian и Ubuntu, если проблема относится к внешнему источнику.

Если сомневаетесь, временно отключите сторонний репозиторий и убедитесь, что базовые источники системы обновляются штатно. Это самый безопасный способ отделить проблему ОС от проблемы внешнего поставщика пакетов.

Практический чек-лист

1. Запустите apt update и выпишите URL и suite из ошибки.
2. Найдите запись в /etc/apt/sources.list или /etc/apt/sources.list.d/.
3. Проверьте фактический codename системы через /etc/os-release.
4. Сравните его с полем suite в записи источника.
5. Проверьте, не является ли репозиторий устаревшим или ненужным.
6. Если источник не нужен или не поддерживается, отключите его.
7. Повторно выполните apt update.
8. Если после этого появилась ошибка подписи, отдельно проверьте signed-by и keyring.

Итог

Ошибка APT repository does not have a Release file в Debian и Ubuntu почти всегда указывает на конкретный проблемный источник, а не на поломку APT в целом. Обычно виноваты неподдерживаемый релиз, неверный sources.list, ошибка в deb822, устаревший сторонний репозиторий или просто неправильный URL.

Рабочий подход всегда один: определить проблемную запись, сверить выпуск системы, проверить корректность источника и либо исправить его, либо отключить. Это и быстрее, и безопаснее, чем искать сомнительные обходы.

Если держать список APT-источников в порядке, удалять неиспользуемые репозитории и аккуратно проверять их после перехода между релизами Debian и Ubuntu, подобные ошибки обычно решаются за несколько минут.