do-release-upgrade: новий випуск не знайдено

Чому do-release-upgrade повідомляє, що новий випуск не знайдено

do-release-upgrade, що завершується на No new release found., майже ніколи не означає несправність інструмента. Шлях оновлення, який ви запросили, у цей момент закритий, і інструмент повідомляє про це найкоротшим можливим способом. Його можуть закривати п’ять причин: параметр Prompt у /etc/update-manager/release-upgrades, обмеження point release для оновлень LTS (довгострокова підтримка), сторонні репозиторії, пакети зі статусом hold або частково налаштовані пакети, а також випуск, для якого завершився період підтримки.

Перевіряйте їх у такому порядку. Для кожної причини є команда, яка підтверджує, чи стосується вона вашого сервера. Тому вам не доведеться здогадуватися, з якою саме з п’яти причин ви зіткнулися.

Що насправді повідомляє прапорець перевірки

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, тому уважно перевірте код, перш ніж будувати на ньому перевірку.

Якщо у вітальному повідомленні під час входу досі показано старий результат, його взято з кешу. Цей рядок надходить із /etc/update-motd.d/91-release-upgrade, який виводить збережений результат, не звертаючись до мережі. Оновіть його за допомогою sudo /usr/lib/ubuntu-release-upgrader/release-upgrade-motd або просто довіртеся -c. Вітальне повідомлення лише повторює результат останньої виконаної перевірки.

Перевірка також потребує доступу до changelogs.ubuntu.com. На сервері за суворим вихідним firewall або через proxy інструмент не може виконати запит, тому він не може знайти доступні випуски.

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. У мінімальних cloud-образах цей пакет іноді не встановлено.

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 очікує на перший point release

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 August 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 після виходу першого point release. Випуск Ubuntu 26.04.1 заплановано на 27 August 2026, але графік випусків може змінитися, тому перевіряйте метадані, а не календар. Затримка є навмисною: користувачі, які оновлюються першими, виявляють проблеми, а їх виправляють до того, як оновлення починає значно більша кількість LTS-серверів.

Є два обґрунтовані варіанти. Дочекатися point release. Це правильний вибір для сервера, за яким ви не хочете постійно стежити. Або встановити Prompt=normal, що спрямовує той самий засіб до meta-release, де 26.04 уже позначено як підтримуваний випуск. Другий варіант оновлює систему до випущеного 26.04, а не до development build, тому його можна застосувати на машині, яку можна відновити зі 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 для нової серії й вимикає цей запис. Зазвичай це попередження, яке можна прийняти. Проблема стає блокувальною, коли сторонній репозиторій постачає пакет, який також входить до нового релізу. Тоді під час розрахунку оновлення з’являються два кандидати, і APT не може задовольнити обидві вимоги.

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

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

apt policy для імені пакета показує, з якого репозиторію походить кожна встановлена версія. Так можна точно визначити, які пакети залежать від джерела, яке ви збираєтеся вимкнути. Видалення джерела не знижує версію пакетів. Тому пакет, встановлений із 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 виводить утримувані пакети по одному в рядку. У системі без таких пакетів команда нічого не виводить. Утримання — це ручна вказівка ніколи не змінювати цей пакет. Хтось міг зафіксувати версію kernel або database, а потім забути про це. Скасуйте утримання пакетів, які більше не потрібно фіксувати, за допомогою 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 може коректно залишити частину пакетів без оновлення. У такому разі сервер буде менш актуальним, ніж ви вважаєте. Цей параметр встановлює всі такі оновлення. Після цього перезавантажте сервер, якщо разом з оновленнями було встановлено kernel. Так ви виконуватимете оновлення з kernel, який фактично запущений. Якщо сервер уже автоматично підтримує актуальний стан за допомогою автоматичного встановлення оновлень безпеки, роботи буде менше. Водночас цей механізм навмисно не переходить між випусками.

Коли випуск уже вийшов за межі стандартної підтримки

Проміжний випуск Ubuntu підтримується протягом дев’яти місяців. Коли цей період підтримки завершується, його прапорець Supported: набуває значення 0, а стандартний шлях не пропонує оновлення з нього. Станом на 13 August 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. На сторінці довідки це описано так: «Якщо використовується останній підтримуваний реліз, оновити систему до development release».

Станом на 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 для серверів прямо зазначено про цей прапорець: «використовувати development release (або прапорець -d) у production-середовищах не рекомендовано». Development release змінюється щодня і не має гарантованої security support. Тому пакет, який працював уранці, може зламати сервіс удень. Використовуйте його на тимчасовій віртуальній машині, створеній для тестування власної конфігурації. Не використовуйте його на сервері, від якого залежать користувачі або сервіси. Якщо потрібен випущений 26.04 до відкриття LTS gate, правильний спосіб — Prompt=normal.

Запускайте оновлення так, щоб розрив SSH-сеансу не міг його перервати

Оновлення релізу замінює більшу частину системи, зокрема openssh-server і systemd. Якщо SSH-сеанс перерветься під час роботи 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 запускають другий firewall у панелі керування, за межами операційної системи. Порт 1022 потрібно відкрити і там. Інакше резервний listener працюватиме, але буде недоступним, що є найгіршим варіантом.

До введення команди потрібно підготувати чотири речі:

• Створіть 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 до виходу першого point release. Засіб оновлення не знаходить новішого доступного LTS-випуску й завершує роботу. Перевірте файл самостійно за допомогою curl -s https://changelogs.ubuntu.com/meta-release-lts і прочитайте останній блок. Станом на 13 August 2026 прапорець усе ще мав значення 0, а випуск Ubuntu 26.04.1 було заплановано на 27 August 2026.

Чи безпечно встановити Prompt=normal замість очікування point release?

Це оновить систему до випущеної версії 26.04, а не до development build, оскільки Prompt=normal читає meta-release, де 26.04 уже має значення Supported: 1. Ризик пов’язаний із часом оновлення. Ви виконуєте його до того, як буде виправлено проблеми, виявлені першими користувачами. Робіть це на сервері, який можна відновити зі snapshot і до якого можна підключитися через консоль провайдера, якщо після перезавантаження виникне проблема. Після завершення поверніть значення lts.

Чи оновить прапорець -d мою систему до 26.04?

Ні. -d читає meta-release-development, де найновішим записом станом на 13 August 2026 була Ubuntu 26.10 — випуск, який усе ще перебуває в розробці. На LTS-системі зі значенням Prompt=lts цей прапорець виводить There is no development version of an LTS available. і завершує роботу. В офіційній документації Ubuntu для серверів зазначено, що development release не рекомендовано для production, тому використовуйте 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 для старіших структур і залиште codename без змін. Потім виконайте sudo apt update і sudo apt full-upgrade. Коли систему буде знову оновлено, do-release-upgrade зможе переміщати її вперед по одному випуску за раз.

Чи потрібно видаляти мої PPA перед запуском do-release-upgrade?

Ні, це не обов’язково, оскільки засіб оновлення коментує кожне джерело, яке не публікує пакети для нового випуску, і виводить для нього рядок на зразок was disabled (no Release file). Проте краще зробити це самостійно заздалегідь: так ви контролюєте порядок і бачите результат. Виконайте apt policy для потрібних пакетів, щоб визначити, з якого PPA вони походять, а потім повторно встановіть їх з archive, якщо версія з PPA новіша за ту, що доступна в новому випуску.