Як оновити Ubuntu 24.04 до 26.04 на VPS

Коли можна оновити Ubuntu 24.04 до 26.04?

Ви можете оновити Ubuntu 24.04 до 26.04 на VPS після виходу точкового релізу 26.04.1, запланованого на 27 August 2026. До цього сервер на 24.04 навмисно не побачить нового релізу. Ubuntu 26.04 LTS (Resolute Raccoon) вийшла 23 April 2026, але Canonical відкриває шлях оновлення з LTS до LTS лише після першого точкового релізу. До нього входять виправлення помилок інсталяції та оновлення, виявлених у перші місяці.

Запустіть перевірку на сервері з 24.04 на початку August 2026. Ви побачите таке:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Це не помилка на вашому сервері. /etc/update-manager/release-upgrades містить Prompt=lts в Ubuntu Server. Це означає, що інструмент пропонує лише наступний реліз із довгостроковою підтримкою та лише після виходу його точкового релізу .1. Якщо встановити Prompt=normal, інструмент послідовно проведе вас через 24.10, 25.04 і 25.10. Усі ці проміжні релізи вже завершили життєвий цикл. Залиште значення lts і зачекайте. Дати в розкладі Canonical можуть змінюватися, тому повторіть перевірку, якщо зазначений день мине без змін.

Кожну наведену нижче команду ви запускаєте самостійно на власному сервері в указаному порядку. Оновлення релізу не можна попередньо перевірити на машині, яку ви оновлюєте. Воно замінює kernel і C library, а для завершення потребує перезавантаження.

Чи варто взагалі оновлюватися?

Ubuntu 24.04 отримує стандартні оновлення безпеки до 2029 року, тому для справного production-сервера немає нагальної потреби в оновленні. Оновлюйтеся, якщо вам потрібні можливості, які має 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 або kernel 7.0. Сам факт, що номер версії збільшився, не є причиною втручатися в роботу сервера, який обслуговує клієнтів.

Не виконуйте оновлення на місці, якщо виконується хоча б одна з таких умов:

• Ви жодного разу не відкривали консоль свого провайдера (VNC або serial) і не входили через неї. Ця консоль є єдиним способом отримати доступ до сервера, якщо SSH перестане працювати. З’ясовувати, що консоль не працює, після втрати доступу буде запізно.
• Ви не можете дозволити собі годину простою і не маєте способу відкотити зміни.
• Ваш стек залежить від стороннього репозиторію, який ще не опублікував пакети для resolute.
• Сервер налаштовували вручну понад два роки, і ніхто не знає, що саме на ньому встановлено.

Часто кращою альтернативою є створення нового VPS з 26.04, встановлення вашого стека та відновлення даних, а потім перемикання DNS після перевірки коректної роботи сервера. Старий сервер можна залишити запущеним, доки новий не підтвердить свою надійність. У такому разі rollback зводиться до зміни DNS, а не до відновлення з резервної копії. Якщо ви обираєте цей варіант, почніть із перших десяти хвилин на новому VPS і належно налаштуйте новий сервер.

Крок 1: створіть резервну копію, з якої можна відновитися

Використовуйте два рівні, оскільки вони виходять з ладу з різних причин. Snapshot у провайдера охоплює весь диск і дає змогу відновити його за лічені хвилини, але створюється під час запису даних у бази даних. Тому він забезпечує узгодженість після збою, а не узгодженість на рівні застосунку. Резервна копія на рівні файлів за допомогою restic, зі зберіганням за межами сервера дає змогу відновлювати окремі файли та містить копію, яка збережеться навіть у разі блокування вашого облікового запису.

Спочатку вручну створіть дампи баз даних. Дамп — єдина резервна копія бази даних, якій можна довіряти без її зупинки.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction створює узгоджений дамп лише для таблиць InnoDB. Таблиці MyISAM потребують зупинки бази даних. Архів /etc — це той файл, до якого ви фактично звернетеся, оскільки він містить усі конфігураційні файли, про які оновлення незабаром запитуватиме.

Резервна копія, з якої ви ніколи не виконували відновлення, — це лише припущення. Витягніть із неї один файл зараз, до того як він знадобиться під тиском.

Крок 2: спочатку повністю оновіть 24.04

do-release-upgrade відмовляється запускатися в системі з пошкодженим станом пакетів, а частково оновлена 24.04 ускладнює аналіз усіх подальших помилок.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Відсутність виводу dpkg --audit означає, що жоден пакет не залишився в наполовину налаштованому стані. Відсутність виводу apt-mark showhold означає, що жоден пакет не зафіксований на версії, яка блокувала б оновлення. Зніміть блокування з усіх пакетів, перелічених цією командою, за допомогою sudo apt-mark unhold і назви пакета. Або врахуйте, що блокування встановлено навмисно, і зупиніться на цьому етапі.

Перезавантажте систему, якщо змінювалося ядро. Так ви виконуватимете оновлення в системі, яка працює на коді, що відповідає її поточному стану.

[ -f /var/run/reboot-required ] && sudo reboot

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

df -h / /boot

Проблеми зазвичай починаються, коли на / залишається менше приблизно 5 GB вільного місця. Якщо в /boot вільно менше 300 MB, збій виникає пізніше, під час встановлення ядра, з помилкою No space left on device. Зазвичай причиною є старі ядра. Команда sudo apt --purge autoremove видаляє їх.

Перед початком потрібно зупинити ще один процес: якщо автоматичні оновлення безпеки запустяться під час оновлення, вони заблокують dpkg lock, і програма оновлення випуску завершить роботу з помилкою Could not get lock /var/lib/dpkg/lock-frontend. Спочатку виконайте sudo systemctl stop unattended-upgrades, а потім повторіть запуск після завершення цього процесу.

Крок 3: перевірте сторонні репозиторії та пакети з фіксованими версіями

do-release-upgrade вимикає кожне джерело apt, яке не належить Ubuntu, оскільки пакет, зібраний для noble, може порушити роботу системи resolute. Після цього він знову вмикає розпізнані джерела, а решту залишає закоментованими. Перш ніж інструмент вирішить за вас, з’ясуйте, які сторонні компоненти вже встановлено.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 використовує в цьому каталозі два формати: старі однорядкові файли .list і файли deb822 .sources з полями Types: та Suites:. Під час оновлення обидва формати вимикаються. ubuntu-security-status --thirdparty містить перелік встановлених пакетів, які не надає жоден архів Ubuntu. Це точна кількість додаткових пакетів, встановлених вручну. Усе, що міститься в /etc/apt/preferences.d/, є правилом фіксації версії, а правило, створене для noble, і надалі вибиратиме стару версію пакета в новому випуску.

Для кожного стороннього репозиторію перед початком перевірте, чи опублікував постачальник репозиторій для нового кодового імені. Списки suite для Docker наведено в https://download.docker.com/linux/ubuntu/dists/. Інші постачальники використовують такий самий каталог. Якщо джерело вказує на suite, якого не існує, під час першого apt update після оновлення з’явиться таке повідомлення:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Залиште це джерело вимкненим, доки постачальник не опублікує потрібний suite. Заміна кодового імені на те, для якого постачальник справді зібрав пакети, може призвести до встановлення пакетів, пов’язаних із неправильними системними бібліотеками.

Крок 4: запускайте оновлення в tmux, а не у звичайній SSH-оболонці

Якщо з’єднання розірветься, поки do-release-upgrade працює у звичайній оболонці входу, процес отримає SIGHUP і завершиться під час розпакування. У результаті dpkg залишиться налаштованим лише частково, а сервер може втратити працездатний мережевий стек, через що повторне підключення буде неможливим. Запускайте процес у термінальному мультиплексорі. Тоді після розриву з’єднання з клієнтом процес продовжить працювати на сервері.

sudo apt install -y tmux
tmux new -s upgrade

У цій сесії:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

Перед внесенням будь-яких змін засіб оновлення запускає другий SSH daemon на порту 1022 і повідомляє про це:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

Він не відкриває цей порт у firewall, оскільки несанкціоноване відкриття порту було б небезпечно. Відкрийте порт 1022 самостійно перед початком роботи та закрийте його після завершення роботи з sudo ufw delete allow 1022/tcp. Пам’ятайте, що ваш провайдер може використовувати додатковий firewall у своїй панелі керування, окремо від сервера.

Якщо з’єднання все одно розірветься, увійдіть знову та виконайте tmux attach -t upgrade. Оновлення продовжувало працювати, поки ви були від’єднані.

Крок 5: обдумано відповідайте на запити щодо конфігураційних файлів

dpkg запитує лише про файли, які ви або скрипт змінювали. Отже, кожен такий запит стосується файлу, який ви навмисно редагували. Натискання Enter, щоб закрити запит, може непомітно повернути hardened-сервер до стандартної конфігурації.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Щоразу спочатку натискайте D. Перегляньте зміни, а потім залиште свою версію за допомогою N. За замовчуванням уже вибрано N. Це безпечний варіант, оскільки ваш файл працює зараз, а пакетну версію на цій машині ще не запускали.

Збереження вашого файлу має наслідки: ви не отримаєте нових стандартних параметрів. Узгодьте конфігурації пізніше, коли сервер уже працюватиме і ви не будете обмежені в часі.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Кожен файл, для якого відображається цей запит, є версією супровідника пакета, збереженою поруч із вашою версією. Порівнюйте їх по одному та переносьте важливі параметри. Два файли потребують особливої уваги: /etc/ssh/sshd_config, оскільки неправильна відповідь завершить вашу сесію, і конфігурація веб-сервера, оскільки неправильна відповідь зупинить сайти.

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

Крок 6: перезавантажте систему, потім перевірте сервер

sudo reboot

Після запуску системи:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a має вивести Release: 26.04 і Codename: resolute. uname -r має показати ядро версії 7.0. systemctl --failed має вивести нуль unit-файлів. Якщо команда щось виведе, це буде вашим наступним завданням. Остання команда apt update завантажує оновлення, опубліковані після створення образів релізу.

PostgreSQL 16 до 18: кластер, який непомітно залишається позаду

Ubuntu 24.04 постачається з PostgreSQL 16, а Ubuntu 26.04 — з PostgreSQL 18. Під час оновлення PostgreSQL 18 встановлюється поруч із PostgreSQL 16, але дані не переносяться. Рівень Debian postgresql-common створює новий порожній кластер для нової основної версії на наступному вільному порту. Тому PostgreSQL 16 продовжує використовувати порт 5432 із усіма даними, а PostgreSQL 18 залишається порожнім і працює на порту 5433. Застосунок і далі підключається до порту 5432, тому нічого не виглядає неправильно. Саме тому цю проблему часто виявляють лише через кілька місяців.

pg_lsclusters

Якщо у списку є два кластери, міграцію ще не виконано. Виконайте її, коли зможете зупинити застосунок:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Спочатку видаліть порожній кластер PostgreSQL 18, оскільки pg_upgradecluster не записує дані в цільовий кластер, який уже існує. Стандартний метод створює дамп PostgreSQL 16 і завантажує його в PostgreSQL 18, тому потрібно мати вільне місце на диску приблизно розміром із базу даних. -m upgrade натомість використовує pg_upgrade, що значно швидше для великої бази даних. Після завершення перевірте стовпець Port: новий кластер почне використовувати порт 5432, а старий кластер залишиться зупиненим. Запустіть аналіз самостійно, оскільки щойно завантажений кластер не має статистики, і перші запити виконуватимуться повільно.

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

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

Каталог даних старого кластера — найшвидший спосіб відкотити зміни. Не видаляйте його в день оновлення.

MySQL 8.0 до 8.4: вилучена опція, через яку сервер не запускається

26.04 оновлює MySQL з 8.0 до 8.4 LTS, і дві зміни можуть зупинити сервери.

По-перше, mysqld відмовляється запускатися, якщо його конфігурація містить опцію, яку вилучено з нової версії. default_authentication_plugin є типовим прикладом, оскільки в багатьох старих інструкціях рекомендують її встановлювати. Сервіс не запускається, а journalctl -u mysql -n 50 безпосередньо вказує на невідому змінну. Видаліть цей рядок із файлу в /etc/mysql/mysql.conf.d/, потім виконайте sudo systemctl start mysql.

По-друге, плагін mysql_native_password більше не ввімкнений за замовчуванням у 8.4, тому обліковий запис, який досі його використовує, не може ввійти взагалі. Перевірте це, поки ще працюєте на 8.0:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

До оновлення перенесіть усі облікові записи, для яких показано mysql_native_password, а потім оновіть пароль у конфігурації застосунку:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Якщо бібліотека клієнта надто стара й не підтримує caching_sha2_password, у 8.4 можна знову ввімкнути старий плагін, додавши mysql_native_password=ON у [mysqld]. Використовуйте це лише як тимчасовий перехідний варіант із визначеним кінцевим строком, оскільки плагін повністю вилучатимуть.

PHP 8.3 до 8.5: ваші vhost вказують на socket, якого більше немає

24.04 постачається з PHP 8.3, а 26.04 — з PHP 8.5. Пакети встановлюються у версійні шляхи, і жоден із них не змінює конфігурацію web server. Конфігурація nginx vhost, у якій зазначено fastcgi_pass unix:/run/php/php8.3-fpm.sock;, тепер вказує на socket, який не створює жоден процес. Тому кожен PHP-запит повертає 502, а error log nginx містить:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Вкажіть новий socket, перевірте конфігурацію та перезавантажте її:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

В Apache з mod_php симптом інший: Apache взагалі не запускається, а sudo apache2ctl -t повідомляє, що не може завантажити libphp8.3.so, оскільки файл не існує. Увімкнений module є symlink на пакет, якого більше немає.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Якщо ви створювали сервер за інструкцією зі стеку LAMP на Ubuntu 24.04, варто перевірити обидва шляхи, оскільки в результаті інструкції використовуються versioned module name і versioned socket.

Налаштування php.ini також не переносяться автоматично. memory_limit, upload_max_filesize та всі інші задані вами параметри містяться у /etc/php/8.3/, а нове дерево починається зі значень за замовчуванням. Порівняйте два файли та вручну перенесіть потрібні значення. Якщо повністю скопіювати старий файл поверх нового, до інсталяції 8.5 потраплять значення за замовчуванням від 8.3. Потім виконайте php -m і порівняйте результати: extension, встановленому як php8.3-redis, потрібен його php8.5- package. Якщо extension походив із PPA, upgrader вимкнув це джерело, і extension просто відсутній.

Сертифікати потребують окремої перевірки. Після оновлення виконайте sudo certbot renew --dry-run. Команда перевіряє весь шлях поновлення, зокрема hook для reload web server, але не змінює чинний сертифікат. Якщо hook викликає назву service або binary, яку було змінено, помилка виникне під час цієї перевірки, а не непомітно через 60 днів. У матеріалі Certbot із Let's Encrypt на nginx описано, як мають виглядати такі hook.

SSH: помилка, яка завершує поточний сеанс

У запиті sshd_config користувачі найчастіше втрачають доступ до сервера. Відповідь Y встановлює файл супровідника пакета. Вона видаляє ваші PermitRootLogin, PasswordAuthentication, AllowUsers, Port та всі інші додані вами рядки. Якщо firewall дозволяє лише нестандартний порт, а конфігурація з пакета слухає порт 22, наступне підключення буде відхилено. Поточний сеанс стане останнім доступним сеансом.

Запобігайте цьому до оновлення. /etc/ssh/sshd_config в 24.04 починається з Include /etc/ssh/sshd_config.d/*.conf. OpenSSH використовує перше прочитане значення кожного параметра, тому drop-in-файл, підключений на початку, має пріоритет над усіма наступними значеннями. Перенесіть свої налаштування у файл, яким не керує dpkg:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Коли в /etc/ssh/sshd_config більше немає ваших налаштувань, цей запит втрачає значення. Незалежно від відповіді ваші налаштування збережуться, оскільки вони містяться в іншому файлі.

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

systemctl is-enabled ssh.socket

Якщо команда виводить enabled, порт для прослуховування належить systemd, а рядок Port у sshd_config ігнорується. Ubuntu використовує активацію сокета для sshd з версії 22.10. Саме тому зміна Port 2222 може не давати результату. Задайте порт у socket unit за допомогою sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

Порожнє ListenStream= є обов’язковим. Воно очищає успадковане значення. Без нього сокет слухатиме порт 22, а також порт 2222. Застосуйте зміни командою sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Після оновлення, перш ніж закривати поточний сеанс:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Потім відкрийте другий термінал на власному комп’ютері та знову підключіться. Працююча оболонка в цьому другому терміналі є єдиним підтвердженням, яке має значення. Не закривайте перший сеанс, доки не перевірите другий. У матеріалі Посилення захисту SSH на VPS наведено налаштування, які варто зберегти в цьому drop-in-файлі.

Якщо вже запізно, web-консоль вашого провайдера дає змогу увійти без SSH. Увійдіть через неї, виправте конфігурацію, виконайте sudo sshd -t і перезапустіть сервіс. Саме для цього потрібно перевіряти доступ до консолі перед оновленням, а не під час нього.

FAQ

Чому do-release-upgrade повідомляє "No new release found" в Ubuntu 24.04?

Тому що /etc/update-manager/release-upgrades містить Prompt=lts на Ubuntu Server, а цей параметр пропонує наступний випуск із довгостроковою підтримкою лише після появи його першого point release. Ubuntu 26.04 LTS випущено 23 April 2026, а випуск 26.04.1 заплановано на 27 August 2026. До цієї дати сервер 24.04 не бачить нового випуску. Не змінюйте цей параметр на Prompt=normal, оскільки тоді оновлення проходитиме через проміжні випуски.

Чи потрібно перезавантажувати сервер, щоб завершити оновлення?

Так. Оновлення встановлює нове ядро, нову C library і нову init system, але запущена система продовжує використовувати старі версії, доки не буде перезапущена. do-release-upgrade пропонує перезавантажити сервер наприкінці, а система, яку залишили працювати "пізніше", використовує компоненти з двох різних випусків. Після запуску перевірте uname -r, щоб побачити нове ядро, і systemctl --failed, щоб знайти сервіси, які не запустилися.

Краще оновити сервер на місці чи створити новий сервер 26.04?

За можливості створіть новий сервер. Новий VPS дає змогу встановити стек, відновити дані й перевірити все, поки старий сервер продовжує обслуговувати мережевий трафік. У такому разі відкатом буде зміна DNS, а не відновлення з резервної копії. Оновлюйте сервер на місці, якщо на ньому зберігається стан, який складно перенести, якщо провайдер стягує плату за кожну машину або якщо у вас є snapshot і перевірений доступ до консолі. Оновлення на місці є поширеним підходом, але протягом часу його виконання воно фактично незворотне.

Що станеться, якщо SSH-з’єднання перерветься під час оновлення?

У звичайній login shell процес отримує SIGHUP і завершується на півдорозі, через що dpkg залишається частково налаштованим. Запустіть оновлення всередині tmux або screen. Тоді процес продовжить працювати, ви зможете підключитися повторно й виконати tmux attach -t upgrade, щоб продовжити оновлення. Програма оновлення також запускає резервний SSH daemon на порту 1022 як додатковий спосіб підключення. Однак вона не відкриває цей порт у firewall, тому спочатку самостійно дозвольте вхід на порт 1022, а після завершення закрийте його.

Мій PHP-сайт після оновлення повертає 502. Що зламалося?

Версія змінила шлях до сокета PHP FPM. Ubuntu 24.04 використовує PHP 8.3, а 26.04 — PHP 8.5, тому /run/php/php8.3-fpm.sock більше не існує, тоді як ваш nginx vhost усе ще посилається на нього. У журналі помилок nginx з’являється connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Змініть fastcgi_pass на шлях до сокета версії 8.5, виконайте sudo nginx -t, а потім перезавантажте nginx. В Apache з mod_php аналогічне виправлення полягає у виконанні sudo a2dismod php8.3, потім sudo a2enmod php8.5 і перезапуску.