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

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

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

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

Що насправді показує прапорець, який виконує лише перевірку

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.

У випуску LTS із Prompt=lts перша відповідь має інше формулювання. Вихідний код засобу оновлення виводить There is no development version of an LTS available., коли встановлено Prompt=lts і нічого не знайдено, навіть якщо ви не передавали -d. Це означає те саме, що й No new release found.

Код завершення передає ту саму відповідь скриптам. Він дорівнює 0, якщо доступний новий випуск, і 1, якщо доступних випусків немає. Це відповідає стандартній конвенції shell, за якою нуль означає успішне виконання. Тому скрипт може трактувати нульовий код завершення як ознаку доступності нового випуску.

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

Перевірка також потребує доступу до changelogs.ubuntu.com. Якщо сервер працює за суворим firewall для вихідного трафіку або через proxy, засіб не зможе виконати запит і не знайде доступних випусків.

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

Рядок HTTP/2 200 означає, що сервер бачить метадані. Повна відсутність виводу означає, що запит завершився помилкою, оскільки -s також приховує повідомлення про помилку curl. Тому одразу після цього виконайте echo $?. Код завершення 6 означає, що ім’я не вдалося розв’язати. Код завершення 7 (не вдалося підключитися) або 28 (перевищено час очікування) зазвичай вказує на правила вихідного трафіку або proxy. Водночас повільний DNS-запит також може перевищити тайм-аут підключення curl. У будь-якому разі редагування файлів 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 для сервера, який має залишатися на гілці long-term support, а після цього поверніть попереднє значення, якщо цього очікує ваша автоматизація.

Один момент у цих коментарях часто спричиняє помилки. Якщо встановлено 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

Станом на 21 October 2026 обидва файли містять однакові дані про Ubuntu 26.04. Файл LTS містить:

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

Звичайний файл містить:

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

Раніше вони не завжди збігалися. 13 August 2026 файл LTS усе ще містив Version: 26.04 LTS зі значенням Supported: 0, тоді як звичайний файл уже містив Supported: 1. Саме це 0 у файлі LTS було блокувальним механізмом. Сервер 24.04 зі стандартним значенням Prompt=lts читав цей файл, не знаходив новішого LTS-релізу, позначеного як доступний, і повідомляв, що оновлюватися нікуди. На сервері не було проблем. Canonical ще не відкрила цей шлях.

Прапорець набуває значення 1, коли Canonical вмикає оновлення LTS. Це відбувається після першого point release, а не в день його випуску. Для 26.04 це вже сталося. Ubuntu 26.04.1 випущено 27 August 2026, а 29 September 2026 Canonical оголосила, що оновлення з 24.04 "are now enabled". Файл LTS тепер позначає 26.04.1 як підтримуваний, тому сервер 24.04 зі значенням Prompt=lts отримує пропозицію оновитися до 26.04.1, і цей блокувальний механізм більше не є причиною порожньої відповіді. Якщо ваш сервер 24.04 усе ще не знаходить доступних оновлень, причина в іншому місці на цій сторінці: кешованому банері входу, заблокованому доступі до changelogs.ubuntu.com або Prompt=never. Point release — це не нова версія Ubuntu, а лише той самий реліз із усіма оновленнями від моменту випуску, доданими до нових інсталяційних образів, тому для вже запущеного сервера важливий блокувальний механізм, який відкривається після цього випуску, а не самі образи. Затримка є навмисною: користувачі, які оновлюються першими, виявляють проблеми, а їх виправляють до того, як оновлення почне значно більша кількість LTS-серверів. В оголошенні Canonical про 26.04.1 зазначено, що автоматична пропозиція через Update Manager з’явиться "a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils". Докладніше про це розповідає матеріал що ввійшло до 26.04.1 і що це означає для сервера 24.04.

Після відкриття цього механізму старий вибір між очікуванням і перемиканням на Prompt=normal більше не стосується цього оновлення. Залиште Prompt=lts без змін і виконайте sudo do-release-upgrade, оскільки тепер команда націлена на випущений 26.04.1. Якщо під час блокування механізму ви перемкнулися на normal, поверніть значення lts, щоб сервер залишався на треку довгострокової підтримки. Покрокову процедуру наведено в повному посібнику з оновлення сервера з 24.04 до 26.04. Серверу на 22.04 потрібно виконати додатковий перехід, оскільки Prompt=lts завжди пропонує лише наступний LTS-реліз. Тому перехід із 22.04 до 26.04 спочатку проходить через 24.04.

Сторонні репозиторії та PPA, які блокують оновлення

Програма оновлення переписує джерела APT, щоб вони вказували на новий випуск. За замовчуванням вона залишає власний архів Ubuntu та дзеркала, а сторонні репозиторії коментує, навіть якщо вони вже публікують пакети для нового випуску. Запис, який програма залишає, усе одно вимикається, якщо для нової серії немає файлу Release. Причини записуються до журналу програми оновлення, по одному рядку для кожного запису, а не виводяться на екран. Серед них: was disabled (unknown mirror), was disabled (unknown dist) і was disabled (no Release file).

PPA (personal package archive), зібраний для noble, не має на сервері каталогу для resolute. Тому навіть із дозволеними сторонніми джерелами програма оновлення не може отримати файл Release для нової серії та вимикає цей запис. Зазвичай це попередження, яке можна прийняти. Воно перетворюється на блокувальну помилку, якщо пакет, встановлений із цього репозиторію, не може оновитися разом з рештою системи. APT зберігає одну версію кожного пакета. Вона вибирається за пріоритетом з урахуванням обмежень залежностей. За замовчуванням встановлений пакет не знижується до старішої версії. Тому версія з PPA, новіша за версію в новому випуску, залишається встановленою. Якщо вона залежить від версій бібліотек, яких у новому випуску вже немає, розрахунок оновлення завершується помилкою.

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

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

apt policy із назвою пакета показує, з якого репозиторію походить кожна встановлена версія. Так можна точно визначити, які пакети залежать від джерела, яке ви збираєтеся вимкнути. Видалення джерела нічого не знижує, тому пакет, встановлений із PPA, залишається у версії PPA і може бути новішим за версію, доступну в новому випуску. Якщо це має значення, видаліть також пакет, а після оновлення встановіть його з архіву. Репозиторій, який ви плануєте повернути, наприклад репозиторій Tailscale, потрібно перевести на codename нового випуску, перш ніж пакет знову можна буде встановити. Саме звідси походить більшість помилок встановлення Tailscale в Ubuntu.

Існує прапорець для протилежного рішення. На сторінці довідки зазначено, що --allow-third-party означає: «Спробувати оновлення з увімкненими сторонніми дзеркалами та репозиторіями замість їх коментування». Використовуйте його лише після перевірки, що репозиторій уже публікує пакети для цільового випуску. Якщо це не так, прапорець або нічого не дасть, оскільки запис без файлу Release для нової серії все одно буде вимкнено, або залишить увімкненими пакети, які ніколи не збиралися для цього випуску.

В 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, але це саме по собі не закриває шлях оновлення. Засіб оновлення пропускає непідтримувані випуски лише як цільові версії, а в повідомленні Canonical про завершення життєвого циклу 25.10 9 липня 2026 року зазначено: «Підтримуваний шлях оновлення з Ubuntu 25.10 веде до Ubuntu 26.04 LTS». Станом на 21 жовтня 2026 року meta-release повідомляє про 25.10 таке:

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

Шлях закриває архів, і це відбувається пізніше за дату завершення життєвого циклу. У тому самому повідомленні зазначено, що 25.10 буде переміщено до old-releases.ubuntu.com «у найближчі тижні». Станом на 21 жовтня 2026 року questing усе ще вказував на archive.ubuntu.com, а не на old-releases.ubuntu.com, тому сервер 25.10 ще може оновити пакети й безпосередньо перейти на 26.04 LTS. Після переміщення випуску його пакети видаляються з 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 додає -development до адреси файлу, який вибрав Prompt. Тому засіб оновлення читає meta-release-development через Prompt=normal, а meta-release-lts-development — через Prompt=lts. Він також дає змогу засобу оновлення вибрати випуск, у якого прапорець Supported: ще має значення 0. На сторінці довідки це описано так: «Якщо використовується останній підтримуваний випуск, оновити до development release».

Станом на 21 October 2026 найновіший запис у meta-release-development — не 26.04:

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

Але засіб оновлення не обирає найновіший запис. Він послідовно переглядає файл і вибирає перший випуск, дата якого пізніша за дату поточного випуску. На сервері з 24.04 цей запис — resolute в обох файлах development. Тому -d на 24.04 переходить на випущений 26.04.1, а у власному оголошенні Canonical про 26.04.1 користувачам 24.04, які «прагнуть перейти», рекомендується виконати do-release-upgrade -d. Тепер, коли обмеження для LTS знято, звичайна команда do-release-upgrade переходить на той самий випуск без цього прапорця. На сервері з 26.04 першим новішим записом є 26.10. Ubuntu випустила 26.10 15 October 2026, але станом на 21 October 2026 meta-release усе ще завершується на resolute. Тому сервер з 26.04 на Prompt=normal отримує No new release found. під час звичайної перевірки. В оголошенні Canonical про 26.10 зазначено, що користувачам 26.04 «буде запропоновано автоматичне оновлення до 26.10», якщо вони вибрали сповіщення про всі випуски, але дату не вказано. Поки цей запис не з’явиться, -d на 26.04 переходить на випущений 26.10 лише через файл development, де цей випуск усе ще позначено як Supported: 0, випереджаючи шлях, який Canonical уже відкрила. У примітках до випуску 26.10 також зазначено, що системи з повним шифруванням диска на основі TPM не можуть оновитися з 26.04 до 26.10 одразу після його випуску. Якщо на 26.04 налаштовано Prompt=lts, команда meta-release-lts-development не знаходить нічого після resolute, а прапорець завершується власним повідомленням:

There is no development version of an LTS available.

У документації Ubuntu Server прямо сказано про цей прапорець: «використання development release (або прапорця -d) не рекомендується в production environments». Development release змінюється щодня і не має гарантії security support, тому пакет, який працює вранці, може зламати сервіс після обіду. Якщо -d вказує на development release, використовуйте його на тимчасовій віртуальній машині, створеній для тестування власної конфігурації. Не використовуйте його на сервері, від якого хтось залежить. Якщо потрібно встановити випущений 26.04 на сервері з 24.04, тепер достатньо звичайної команди do-release-upgrade із Prompt=lts.

Запускайте оновлення так, щоб обрив 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 цей пошук знаходить сервер мультиплексора, тому пропозиція не з’являється, а файл ідентифікатора процесу /var/run/release-upgrader-sshd.pid створюється лише тоді, коли додатковий daemon справді запускається. Якщо запит не відображається, це нормально. У вас уже є кращий захист.

Якщо ви погодитеся, порт не буде відкрито автоматично. Інструмент прямо повідомляє про це, оскільки відкриття порту є рішенням щодо безпеки, яке він не має права ухвалювати за вас. Відкрийте порт на час оновлення, а потім знову закрийте його.

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

Більшість VPS-провайдерів використовує додатковий firewall у панелі керування, поза межами операційної системи. Порт 1022 потрібно також відкрити там. Інакше fallback listener працюватиме, але буде недоступним, що є найгіршим варіантом.

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

• Створіть snapshot або повну резервну копію. Оновлення релізу на місці не можна скасувати, і це єдина спроба.
• Переконайтеся, що можете відкрити консоль провайдера до виникнення проблеми. Якщо сервер не запуститься після перезавантаження, SSH буде саме тим доступом, якого у вас не буде. Ядро, яке не завантажується, є окремою проблемою з власними процедурами відновлення. Їх описано в матеріалі про VPS, який не завантажується після оновлення ядра.
• Перевірте вільне місце за допомогою df -h / /boot. Оновлення завантажує повний набір пакетів, а розділ /boot, на якому зберігається кілька старих ядер, часто стає причиною зупинки процесу.
• Ознайомтеся з примітками до релізу для сервісів, які ви використовуєте. Перехід на нову major version PostgreSQL або PHP відбувається разом із релізом, незалежно від того, чи планували ви його.

FAQ

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

Причина більше не полягає в обмеженні для LTS point release. Поки Canonical не ввімкнула оновлення LTS 29 September 2026, приблизно через місяць після виходу Ubuntu 26.04.1 27 August 2026, у 26.04 у Supported: 0 містилося значення https://changelogs.ubuntu.com/meta-release-lts. Це файл, який читає типовий Prompt=lts, тому інструмент нічого не знаходив. Станом на 21 October 2026 цей параметр має значення 1, і сервер 24.04 пропонує оновлення до 26.04.1. Якщо у вашій системі досі нічого не знайдено, виконайте sudo do-release-upgrade -c замість того, щоб покладатися на банер під час входу, переконайтеся, що сервер може підключитися до changelogs.ubuntu.com, і перевірте, що Prompt не має значення never. У разі Prompt=lts порожня відповідь має вигляд There is no development version of an LTS available., що означає те саме.

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

Для переходу з 24.04 на 26.04 більше немає чого чекати. Canonical увімкнула оновлення 29 September 2026 після виходу point release 27 August 2026. Станом на 21 October 2026 і meta-release, і meta-release-lts позначають 26.04 значенням Supported: 1, тому Prompt=lts уже пропонує це оновлення, а зміна параметра нічого не дає. До ввімкнення оновлень Prompt=normal оновлював систему до випущеної версії 26.04, а не до development build. Водночас оновлення виконувалося до виправлення проблем, виявлених першими користувачами. Якщо ви змінили параметр під час очікування, поверніть йому значення lts.

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

Для переходу з 24.04 — так. -d вибирає перший випуск, датований пізніше за встановлений у системі, а в обох development files ним є 26.04, тепер 26.04.1. Саме тому в оголошенні Canonical про 26.04.1 користувачам 24.04, які хочуть оновитися одразу, рекомендовано виконати do-release-upgrade -d. Найновішим записом у meta-release-development, перевіреним 21 October 2026, є Ubuntu 26.10, випущена 15 October 2026. Однак там вона все ще має позначку Supported: 0 і ще не зазначена в meta-release. Саме на неї вказує -d із сервера 26.04. В офіційній документації Ubuntu для серверів зазначено, що development release або прапорець -d не рекомендовані для production. Тепер, коли обмеження для LTS знято, звичайний do-release-upgrade оновлює систему до 26.04.1 без цього прапорця.

apt update повертає помилки 404 у старому випуску. Як його оновити?

Цей випуск досяг end of life, тому його пакети перенесено з 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?

Це необов’язково, оскільки за замовчуванням засіб оновлення закоментовує сторонні джерела, а також будь-яке джерело, для якого немає файлу Release для нового випуску. Для кожного такого джерела він записує рядок на зразок was disabled (unknown mirror). Краще зробити це самостійно заздалегідь, оскільки тоді ви контролюєте порядок дій і бачите результат. Виконайте apt policy для потрібних пакетів, щоб визначити, з якого PPA походить кожен із них. Потім повторно встановіть ці пакети з archive, якщо версія з PPA новіша за ту, яку містить новий випуск.