do-release-upgrade: новый релиз не найден — что делать

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

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

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

Что на самом деле сообщает флаг 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 указывает на то, что реальная причина кроется в ваших правилах исходящего трафика, и никакое редактирование файлов 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 для сервера, который должен находиться на ветке долгосрочной поддержки (LTS), и верните обратно, если ваша система автоматизации ожидает старое значение.

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

Почему обновление с одного 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 года, но графики релизов могут сдвигаться, поэтому ориентируйтесь на метаданные, а не на календарь. Эта задержка намеренна: пользователи, которые обновляются первыми, находят критические ошибки, и их исправляют до того, как на новую версию перейдёт основная масса 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 Server прямо говорит об этом флаге: «использование версии для разработки (или флага -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 новее той, что предлагается в новом релизе.