Як оновити 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 лише після першого point release. До нього входять виправлення помилок інсталяції та оновлення, виявлених протягом перших місяців. Якщо така нумерація для вас нова, 26.04.1 — це не інша Ubuntu, а та сама 26.04 із чотирма місяцями виправлень, доданими до інсталяційного носія, і саме тому це перша версія, яку Canonical запропонує наявному серверу.

Виконайте перевірку на сервері з 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, а це означає, що інструмент пропонує лише наступний long term support release і лише після виходу його .1 point release. Якщо встановити Prompt=normal, інструмент послідовно проведе вас через 24.10, 25.04 і 25.10 — проміжні релізи, термін підтримки яких уже завершився. Залиште lts і зачекайте. Дати в розкладі Canonical можуть змінюватися, тому повторіть перевірку, якщо зазначений день мине без змін.

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

Оновлення взагалі потрібне?

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 перестане працювати. Виявити, що консоль не працює, уже після блокування доступу буде запізно.
• Ви не можете дозволити собі годину простою і не маєте rollback.
• Ваш stack залежить від стороннього repository, який ще не випустив пакет для resolute.
• Сервер налаштовували вручну понад два роки, і ніхто не знає, що на ньому встановлено.

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

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

Використовуйте два рівні резервного копіювання, оскільки вони мають різні сценарії відмови. Snapshot у провайдера охоплює весь диск і відновлюється за кілька хвилин, але створюється під час запису даних у бази, тому є crash-consistent, а не application-consistent. Резервна копія на рівні файлів за допомогою 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 tarball — це те, до чого ви фактично звернетеся, оскільки він містить усі конфігураційні файли, про які upgrade незабаром запитає вас.

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

Крок 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. Засіб оновлення випуску завершить роботу з повідомленням 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, і надалі вибиратиме стару версію пакета в новому випуску.

Для кожного стороннього репозиторію перед початком роботи переконайтеся, що постачальник опублікував репозиторій для нового codename. Списки 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.

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

Крок 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 server до налаштувань за замовчуванням.

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'

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

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

Крок 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 завантажує оновлення, опубліковані після створення release images.

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

Ubuntu 24.04 постачається з PostgreSQL 16, а Ubuntu 26.04 — з PostgreSQL 18. Оновлення встановлює 18 поруч із 16 і не переносить ваші дані. Рівень Debian postgresql-common створює новий порожній кластер для нової основної версії на наступному вільному порту. Тому 16 продовжує використовувати порт 5432 з усіма вашими даними, а 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

Спочатку видаліть порожній кластер 18, оскільки pg_upgradecluster не записуватиме дані в цільовий кластер, який уже існує. Стандартний метод створює дамп кластера 16 і завантажує його в кластер 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: ваші vhosts вказують на socket, якого більше немає

24.04 постачається з PHP 8.3, а 26.04 — з PHP 8.5. Пакети встановлюються у versioned paths, і жоден компонент не переписує конфігурацію вебсервера. vhost nginx, у якому вказано 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, оскільки файл не існує. Увімкнений модуль є 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 і порівняйте результати: для розширення, встановленого як php8.3-redis, потрібен пакет php8.5-, а якщо розширення надходило з PPA, засіб оновлення вимкнув це джерело, і розширення просто відсутнє.

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

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-файлі.

Якщо вже запізно, вебконсоль провайдера надає вхід, який не використовує 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, щоб продовжити операцію. Upgrader також запускає резервний SSH daemon на порту 1022 як додатковий спосіб доступу, але не відкриває цей порт у firewall. Тому спочатку самостійно дозвольте підключення до 1022, а після завершення закрийте його.

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

З версією змінюється шлях до PHP FPM socket. В 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, указавши socket для 8.5, виконайте sudo nginx -t, а потім перезавантажте nginx. В Apache з mod_php еквівалентне виправлення — це sudo a2dismod php8.3, після чого потрібно виконати sudo a2enmod php8.5 і перезапустити Apache.