do-release-upgrade: no new release found как исправить

Почему do-release-upgrade сообщает, что новый релиз не найден

do-release-upgrade завершающаяся No new release found., почти никогда не является признаком неисправности утилиты. Запрашиваемый вами путь в данный момент закрыт, и утилита сообщает об этом максимально кратко. Этому препятствуют пять причин: настройка Prompt в /etc/update-manager/release-upgrades, ограничение на обновление между точечными релизами в LTS (long term support), сторонние репозитории, пакеты в состоянии удержания (held) или неполной конфигурации, а также релиз, срок поддержки которого истёк.

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

Что на самом деле сообщает флаг check-only

sudo do-release-upgrade -c
echo $?

-c — это режим проверки. Он считывает метаданные релиза Canonical по протоколу HTTPS (hypertext transfer protocol secure) и выводит результат. Инструмент не загружает средства обновления и не перезаписывает файлы исходных кодов. Важны два типа вывода:

Checking for a new Ubuntu release
No new release found.

Checking for a new Ubuntu release
New release '26.04.1 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Код завершения содержит тот же ответ для скриптов. Он равен 0, если доступен новый релиз, и 1, если релизов нет. Это противоречит стандартным соглашениям shell, поэтому будьте внимательны при написании проверок на основе этого кода.

Если в приветственном сообщении при входе в систему (login banner) отображается старый результат, значит, он закэширован. Эта строка выводится утилитой /etc/update-motd.d/91-release-upgrade, которая показывает сохранённый результат вместо обращения к сети. Обновите его с помощью sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd или просто доверяйте -c. Баннер лишь повторяет результат последней выполненной проверки.

Для работы проверки также необходим доступ к changelogs.ubuntu.com. Если сервер находится за строгим исходящим файрволом или прокси-сервером, инструмент не может отправить запрос и, следовательно, ничего не находит.

curl -sI https://changelogs.ubuntu.com/meta-release-lts | head -n 1

Строка HTTP/2 200 означает, что сервер видит метаданные. Сообщение curl: (28) Connection timed out указывает на то, что истинная причина кроется в ваших правилах исходящего трафика (egress rules), и никакое редактирование файлов APT (advanced package tool) не изменит результат.

Если команда отсутствует, она находится в пакете ubuntu-release-upgrader-core. В минимальных образах для облачных платформ этот пакет иногда не устанавливается.

sudo apt install ubuntu-release-upgrader-core

Прочитайте /etc/update-manager/release-upgrades перед внесением изменений

cat /etc/update-manager/release-upgrades

[DEFAULT]
Prompt=lts

Файл содержит собственную документацию в комментариях. Допустимы три значения:

• never: никогда не проверять и не разрешать обновление до нового релиза.
• normal: предлагать поддерживаемый релиз, который непосредственно следует за текущим.
• lts: предлагать первый LTS-релиз, следующий за текущим.

Prompt=never — самый простой для диагностики вариант из трех, так как утилита указывает и файл, и параметр в своем выводе:

Checking for a new Ubuntu release
In /etc/update-manager/release-upgrades Prompt is set to never so upgrading is not possible.

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

Одна деталь в этих комментариях часто сбивает пользователей с толку. Когда установлено Prompt=lts, а текущий релиз не является LTS, программа обновления интерпретирует этот параметр как normal. На машине с версией 25.10 оба значения ведут себя одинаково. На машине с 24.04 это не так, и именно этому различию посвящен весь следующий раздел.

Почему обновление с LTS на LTS ожидает первого точечного релиза

Prompt определяет, какой файл метаданных считывает программа обновления. Адреса находятся в /etc/update-manager/meta-release:

[METARELEASE]
URI = https://changelogs.ubuntu.com/meta-release
URI_LTS = https://changelogs.ubuntu.com/meta-release-lts
URI_UNSTABLE_POSTFIX = -development
URI_PROPOSED_POSTFIX = -proposed

Prompt=lts считывает meta-release-lts. Prompt=normal считывает meta-release. Оба файла описывают каждый релиз в небольшом блоке ключей, и программа обновления предлагает переход только тогда, когда флаг Supported: установлен в 1. Вы можете проверить их самостоятельно на том же сервере:

curl -s https://changelogs.ubuntu.com/meta-release-lts | grep -A 4 resolute
curl -s https://changelogs.ubuntu.com/meta-release | grep -A 4 resolute

По состоянию на 13 августа 2026 года данные в этих двух файлах для Ubuntu 26.04 различаются. В файле LTS указано:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 0

В обычном файле указано:

Dist: resolute
Name: Resolute Raccoon
Version: 26.04 LTS
Date: Thu, 23 April 2026 00:26:04 UTC
Supported: 1

Этот Supported: 0 в файле LTS и является «воротами». Сервер 24.04, использующий настройки по умолчанию в Prompt=lts, считывает этот файл, не находит более новых LTS-релизов с пометкой «доступно» и выводит No new release found.. С вашей системой всё в порядке. Canonical еще не открыла путь для обновления.

Флаг меняется на 1 после выхода первого точечного релиза. Выход Ubuntu 26.04.1 запланирован на 27 августа 2026 года, но графики релизов могут сдвигаться, поэтому ориентируйтесь на метаданные, а не на календарь. Точечный релиз — это не новая версия Ubuntu, а тот же самый релиз, в который включены все обновления, вышедшие с момента запуска, для создания свежих установочных носителей, поэтому для работающего сервера важно не само обновление носителя, а «ворота», которые оно открывает. Задержка намеренна: пользователи, которые обновляются первыми, находят критические ошибки, и их исправляют до того, как начнется массовое обновление серверов LTS.

Существует два разумных варианта действий. Первый — дождаться точечного релиза, что является верным решением для любого сервера, за которым вы не хотите следить постоянно. Второй — установить Prompt=normal, что укажет той же утилите на meta-release, где 26.04 уже помечена как поддерживаемая. Этот путь обновит вас до стабильной версии 26.04, а не до сборки для разработчиков, поэтому он допустим для машины, которую можно восстановить из снимка (snapshot). После завершения верните значение lts. Сама процедура, шаг за шагом, описана в полном руководстве по обновлению сервера с 24.04 до 26.04.

Сторонние репозитории и PPA, блокирующие обновление

Программа обновления перезаписывает ваши источники APT, чтобы они указывали на новый релиз. Она может сделать это только для репозитория, который поддерживает новый релиз, поэтому все остальные источники комментируются. Причины выводятся по одной строке на запись, они конкретны: was disabled (unknown mirror), was disabled (unknown dist) и was disabled (no Release file).

PPA (персональный архив пакетов), созданный для noble, не имеет директории для resolute на сервере, поэтому программа обновления не может получить файл Release для новой серии и отключает эту запись. Обычно это предупреждение, которое можно принять. Ситуация становится критической, когда сторонний репозиторий предоставляет пакет, который также входит в состав нового релиза, поскольку при расчете обновления возникают два кандидата, и система не может удовлетворить требования обоих.

Примите решение самостоятельно до начала процесса, вместо того чтобы позволять инструменту решать это во время длительного автоматического выполнения.

ls /etc/apt/sources.list.d/
apt policy nginx
sudo add-apt-repository --remove ppa:example/ppa

apt policy для имени пакета выводит информацию о том, из какого репозитория была установлена каждая версия. Так вы увидите, какие именно пакеты зависят от источника, который собираетесь отключить. Удаление источника не приводит к понижению версии (downgrade), поэтому пакет, установленный из PPA, останется в своей версии из PPA и может оказаться новее, чем версия в новом релизе. Если это критично, удалите пакет, а после обновления установите его заново из официального архива. Репозиторий, который вы планируете вернуть (например, Tailscale), требует обновления кодового имени до версии нового релиза, иначе пакет не установится. Именно отсюда возникают большинство ошибок установки Tailscale в Ubuntu.

Существует флаг для противоположного выбора. В руководстве --allow-third-party описан как «Попытаться выполнить обновление с включенными сторонними зеркалами и репозиториями вместо их комментирования». Используйте его только в том случае, если вы подтвердили, что репозиторий уже поддерживает целевой релиз. Если это не так, вы заставите APT разрешать граф зависимостей для серии, для которой этот репозиторий никогда не собирался.

В Ubuntu 24.04 и более поздних версиях большинство источников находятся в /etc/apt/sources.list.d/ubuntu.sources в формате deb822. Наличие одного и того же репозитория, записанного одновременно в старом и новом форматах, является отдельной ошибкой с собственным сообщением, описанной в ошибке дублирования записи источника в формате deb822.

Удержанные и частично настроенные пакеты останавливают процесс обновления

Обновление релиза требует замены почти каждого пакета в системе. Если хотя бы один пакет не удается обновить, расчет прерывается: программа обновления предпочитает остановиться заранее, чем оставлять систему в промежуточном состоянии. Две команды помогут найти причину.

apt-mark showhold
sudo dpkg --audit

apt-mark showhold выводит список удержанных пакетов (по одному на строку); если система чиста, команда ничего не выведет. Удержание — это ручная инструкция, запрещающая изменение пакета. Возможно, кто-то зафиксировал версию ядра или базы данных и забыл об этом. Снимите удержание с ненужных пакетов с помощью sudo apt-mark unhold, указав имя пакета.

dpkg --audit выводит список пакетов, которые были распакованы, но не настроены. Такое состояние возникает после прерванной установки, чаще всего из-за разрыва сессии. Программа обновления пытается исправить это самостоятельно и выводит dpkg interrupted, calling dpkg --configure -a, но если вы запустите исправление вручную, то сможете прочитать текст ошибки, а не просто наблюдать за прокруткой лога. Пакет, который утилита не может исправить, вызывает сообщение Package in inconsistent state — с ним нужно разобраться до повторной попытки.

Перед обновлением приведите текущий релиз в полностью актуальное состояние.

sudo apt update
sudo apt full-upgrade -o APT::Get::Always-Include-Phased-Updates=true
sudo apt --fix-broken install
sudo dpkg --configure -a
sudo reboot

Опция поэтапных обновлений (phased updates) важнее, чем кажется. Ubuntu распространяет некоторые обновления постепенно, охватывая лишь часть машин, поэтому обычная команда apt upgrade может оставить часть пакетов без изменений, и сервер окажется менее актуальным, чем вы предполагаете. Эта опция принудительно устанавливает их все. Перезагрузитесь, если в числе обновлений было ядро, чтобы обновление происходило из того ядра, которое фактически запущено. Сервер, который поддерживает актуальность через автоматические обновления безопасности, выполнит меньше работы, однако этот механизм по своей архитектуре никогда не переходит границы релизов.

Когда срок стандартной поддержки релиза истек

Промежуточный релиз Ubuntu поддерживается в течение девяти месяцев. Когда этот срок истекает, его флаг Supported: переходит в состояние 0, и стандартный путь обновления перестает предлагать переход с него. По состоянию на 13 августа 2026 года, meta-release сообщает следующее о 25.10:

Dist: questing
Name: Questing Quokka
Version: 25.10
Date: Thu, 09 October 2025 00:25:10 UTC
Supported: 0

Архив перемещается в то же время. Пакеты для релиза, жизненный цикл которого завершен, удаляются из archive.ubuntu.com и сохраняются в old-releases.ubuntu.com. В результате apt update начинает возвращать 404 Not Found, систему больше нельзя обновить до актуального состояния, и поскольку программа обновления требует актуальную систему, процесс не запускается. Сначала исправьте источники.

lsb_release -cs
grep -rn ubuntu.com /etc/apt/sources.list /etc/apt/sources.list.d/

Укажите в archive.ubuntu.com и security.ubuntu.com адрес old-releases.ubuntu.com, оставив кодовое имя без изменений. Меняется только имя хоста.

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

Выполните ту же команду для /etc/apt/sources.list, если ваш сервер по-прежнему хранит источники в этом единственном файле. Опция -i.bak создает резервную копию рядом с оригиналом, поэтому вы сможете восстановить его, если правки были внесены не в тот файл. Успешный apt update после этого означает, что архив снова доступен, и do-release-upgrade теперь будет отвечать на запросы.

Оценивайте ситуацию реалистично. Ubuntu поддерживает обновление только на один шаг за раз, поэтому серверу, отставшему на два или три устаревших релиза, потребуется последовательное прохождение каждого шага, и каждый из них может завершиться ошибкой из-за стороннего репозитория или удерживаемого пакета. На VPS часто быстрее развернуть новый сервер с текущим LTS, перенести сервис и оставить старый сервер до тех пор, пока вы не будете уверены в результате. Это также дает возможность отката, чего нельзя сделать при обновлении на месте. Если вы выбираете, на какой ветке остаться в дальнейшем, стоит прочитать разницу между LTS и промежуточными релизами на сервере перед принятием решения.

Что на самом деле делает флаг development release

-d или --devel-release заставляет утилиту обновления читать meta-release-development вместо файла, который выбрал Prompt. В справочной странице (man page) это описано так: «При использовании последней поддерживаемой версии обновиться до версии для разработки».

По состоянию на 13 августа 2026 года, самая новая запись в этом файле — не 26.04:

Dist: stonking
Name: Stonking Stingray
Version: 26.10
Date: Thu, 15 October 2026 00:26:10 UTC
Supported: 0

Таким образом, -d не предлагает серверу с 24.04 выпущенную версию 26.04. Флаг нацелен на 26.10 — версию, которая всё ещё находится в стадии сборки. Старые советы «просто добавьте -d» были написаны для периода до выхода LTS-релиза, и их повторение сейчас направит ваш сервер туда, куда вы не планировали. Если Prompt=lts всё ещё на месте, флаг остановит процесс с собственным сообщением:

There is no development version of an LTS available.

Документация Ubuntu по серверной части прямо говорит об этом флаге: «использование версии для разработки (или флага -d) не рекомендуется для производственных сред». Версия для разработки меняется ежедневно и не имеет гарантий безопасности, поэтому пакет, который работает утром, может нарушить работу сервиса днём. Используйте её на тестовой виртуальной машине, созданной для проверки вашей конфигурации. Не используйте её на сервере, от которого кто-либо зависит. Если вам нужна выпущенная версия 26.04 до того, как откроется путь обновления для LTS, правильным решением будет Prompt=normal.

Запуск обновления в условиях, когда разрыв SSH-сессии не может его прервать

Обновление релиза заменяет большую часть системы, включая openssh-server и systemd. Если ваша SSH-сессия (secure shell) прервется во время работы dpkg, процесс будет завершен, а пакеты останутся распакованными и не настроенными — именно это состояние блокирует следующую попытку обновления. Всегда запускайте обновление внутри терминального мультиплексора.

sudo apt install -y tmux
tmux new -s upgrade
sudo do-release-upgrade

Если соединение разорвалось, войдите в систему снова и выполните tmux attach -t upgrade. Обновление продолжило работу, так как оно является дочерним процессом сервера tmux, а не вашей SSH-сессии. screen -S upgrade и screen -r upgrade выполняют ту же задачу, если вы предпочитаете screen.

Утилита обновления имеет встроенный механизм защиты для тех, кто не использует мультиплексор. Когда она обнаруживает, что запущена через SSH, она предлагает запустить второй sshd на порту 1022, чтобы в случае разрыва основной сессии у вас остался путь для входа. Программа принимает решение, просматривая цепочку своих родительских процессов в поисках процесса с именем sshd. Внутри tmux или screen этот поиск находит сервер мультиплексора, поэтому предложение не появляется, а pid-файл /var/run/release-upgrader-sshd.pid создается только тогда, когда действительно запускается дополнительный демон. Если вы не видите этого приглашения, значит, всё в порядке. У вас уже есть более надежная защита.

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

sudo ufw allow 1022/tcp
sudo ufw delete allow 1022/tcp

Большинство провайдеров VPS используют второй межсетевой экран в своей панели управления, вне операционной системы. Порт 1022 должен быть открыт и там, иначе резервный слушатель будет запущен, но недоступен, что является худшим из вариантов.

Перед вводом команды должны быть выполнены четыре условия:

• Сделайте snapshot или полное резервное копирование. Обновление релиза «на месте» не имеет функции отмены, и это ваш единственный шанс.
• Убедитесь, что вы можете открыть консоль провайдера до того, как она вам понадобится. Если сервер не вернется в строй после перезагрузки, SSH — это именно то, чего у вас не будет. Ядро, которое не загружается, — это отдельная проблема со своими методами восстановления, описанными в VPS, который не загружается после обновления ядра.
• Проверьте свободное место с помощью df -h / /boot. Обновление загружает полный набор пакетов, и раздел /boot, содержащий несколько старых ядер, — частое место для остановки процесса.
• Прочитайте примечания к релизу для сервисов, которые вы используете. Мажорное обновление версии PostgreSQL или PHP произойдет вместе с релизом, независимо от того, планировали вы его или нет.

FAQ

Почему do-release-upgrade сообщает, что новый релиз не найден в Ubuntu 24.04?

Значение по умолчанию Prompt=lts в /etc/update-manager/release-upgrades заставляет утилиту считывать https://changelogs.ubuntu.com/meta-release-lts, а в Ubuntu 26.04 в этом файле указано Supported: 0 до выхода первого точечного релиза. Программа обновления не находит более новых LTS-релизов, помеченных как доступные, и завершает работу. Проверьте файл самостоятельно с помощью curl -s https://changelogs.ubuntu.com/meta-release-lts и прочитайте последний блок. По состоянию на 13 августа 2026 года флаг всё ещё имел значение 0, а выход Ubuntu 26.04.1 запланирован на 27 августа 2026 года.

Безопасно ли устанавливать Prompt=normal вместо ожидания точечного релиза?

Это обновит систему до выпущенной версии 26.04, а не до разрабатываемой сборки, так как Prompt=normal считывает meta-release, где для 26.04 уже установлено Supported: 1. Риск заключается в сроках. Вы обновляетесь до того, как будут исправлены ошибки, обнаруженные первыми пользователями. Выполняйте это на сервере, который можно восстановить из снимка состояния (snapshot) и к которому есть доступ через консоль провайдера на случай сбоя при перезагрузке. После завершения верните значение lts.

Обновит ли меня флаг -d до версии 26.04?

Нет. -d считывает meta-release-development, где последней записью на 13 августа 2026 года была Ubuntu 26.10 — релиз, находящийся в разработке. На машине с LTS и Prompt=lts этот флаг выводит There is no development version of an LTS available. и останавливается. Официальная документация Ubuntu по серверам не рекомендует использовать разрабатываемый релиз в продакшене, поэтому используйте Prompt=normal, если хотите получить выпущенную версию 26.04 раньше срока.

apt update возвращает ошибки 404 на старом релизе. Как его обновить?

Этот релиз достиг конца срока поддержки, поэтому его пакеты были перемещены из archive.ubuntu.com в old-releases.ubuntu.com. Измените только имена хостов в /etc/apt/sources.list.d/ubuntu.sources или в /etc/apt/sources.list для старых конфигураций, сохранив кодовое имя дистрибутива без изменений. Затем выполните sudo apt update и sudo apt full-upgrade. Как только система будет обновлена до актуального состояния, do-release-upgrade позволит перевести её на следующий релиз.

Нужно ли удалять PPA перед запуском do-release-upgrade?

Это не обязательно, так как программа обновления комментирует все источники, не публикующие пакеты для нового релиза, и выводит строку вида was disabled (no Release file) для каждого из них. Лучше сделать это самостоятельно: так вы сможете выбрать порядок действий и контролировать результат. Запустите apt policy для нужных пакетов, чтобы определить, какие из них были установлены из каждого PPA, а затем переустановите их из основного архива, если версия в PPA новее, чем в новом релизе.