Как обновить Ubuntu 24.04 до 26.04 на сервере

Когда можно обновить Ubuntu 24.04 до 26.04?

Вы можете обновить Ubuntu 24.04 до 26.04 на VPS после выхода корректирующего релиза 26.04.1, запланированного на 27 августа 2026 года. До этого момента сервер с 24.04 намеренно не будет видеть новую версию. Ubuntu 26.04 LTS (Resolute Raccoon) вышла 23 апреля 2026 года, но Canonical открывает путь обновления между LTS-версиями только с выходом первого корректирующего релиза. Это связано с тем, что в него включаются исправления ошибок установки и обновления, выявленные за первые месяцы. Если нумерация для вас в новинку, 26.04.1 — это не другая Ubuntu, а та же 26.04 с интегрированными исправлениями за четыре месяца, что и делает её первой версией, которую Canonical предлагает для уже работающего сервера.

Запустите проверку на системе с 24.04 в начале августа 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 могут сдвигаться, поэтому проверьте статус повторно, если указанный день пройдёт без изменений.

Каждую команду ниже вы выполняете самостоятельно на своём сервере в указанном порядке. Обновление релиза невозможно протестировать на той же машине, которую вы обновляете. Процесс заменяет ядро и библиотеку C, а для завершения требуется перезагрузка.

Стоит ли вообще обновляться?

Ubuntu 24.04 получает стандартные обновления безопасности до 2029 года, поэтому работающий промышленный сервер не ограничен жесткими сроками. Обновляйтесь, если вам нужны возможности, которые несет в себе 26.04: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 или ядро 7.0. Аргумент «номер версии стал больше» не является поводом для вмешательства в работу машины, обслуживающей клиентов.

Не выполняйте обновление «на месте» (in-place), если верно хотя бы одно из следующих утверждений:

• Вы никогда не открывали консоль вашего провайдера (VNC или последовательный порт) и не входили через неё в систему. Эта консоль — единственный способ вернуться в систему, если SSH перестанет работать, и выяснить, что она не функционирует, когда вы уже потеряли доступ — слишком поздно.
• Вы не можете позволить себе час простоя и у вас нет плана отката.
• Ваш стек зависит от стороннего репозитория, который еще не выпустил версию для resolute.
• Сервер настраивался вручную в течение двух лет, и никто не знает, что на нем установлено.

Альтернативный вариант часто лучше: создайте новый VPS с 26.04, установите свой стек и восстановите данные, а затем переключите DNS, когда убедитесь в корректной работе. Старый сервер остается запущенным, пока новый не докажет свою работоспособность, а откат сводится к изменению DNS вместо восстановления из резервной копии. Если вы выберете этот путь, начните с первых десяти минут на новом VPS и настройте новую машину должным образом.

Шаг 1: создайте резервную копию, из которой можно восстановиться

Используйте два уровня резервного копирования, так как они выходят из строя по разным причинам. Снапшот от провайдера охватывает весь диск и восстанавливается за минуты, но он создается в процессе записи данных в базы, поэтому он обеспечивает лишь crash consistency, а не целостность на уровне приложения. Файловое резервное копирование с помощью 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 ничего не выводит, значит, нет пакетов, зафиксированных (pinned) на версии, которая могла бы заблокировать обновление. Снимите фиксацию с любого пакета из списка с помощью sudo apt-mark unhold и имени пакета, либо признайте, что фиксация установлена не просто так, и остановитесь на этом этапе.

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

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

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

df -h / /boot

При свободном месте менее 5 ГБ на / процесс может завершиться ошибкой. Раздел /boot размером менее 300 МБ приведет к сбою позже, во время установки ядра, с ошибкой 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/ является фиксацией (pin), и фиксация, написанная для noble, продолжит выбирать старую версию пакета в новом релизе.

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

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

Оставьте такой источник отключенным, пока поставщик не выпустит обновление. Изменение кодового имени на то, для которого поставщик не выполнял сборку, — это прямой путь к установке пакетов, скомпилированных с несовместимыми системными библиотеками.

Шаг 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-демон на порту 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.

Она не открывает этот порт в вашем межсетевом экране, так как автоматическое создание дыр в безопасности без запроса пользователя является плохой практикой. Откройте порт 1022 самостоятельно перед началом работы и закройте его после завершения sudo ufw delete allow 1022/tcp. Помните, что ваш провайдер может использовать дополнительный межсетевой экран в панели управления, работающий вне самого сервера.

Если соединение всё же разорвётся, снова подключитесь к серверу и выполните tmux attach -t upgrade. Обновление продолжало выполняться, пока вас не было. Если этого не произошло и после повторного подключения вы обнаружили наполовину настроенный dpkg или источники apt, которые частично относятся к noble, а частично к resolute, в разделе восстановление после неудачного обновления релиза описано, как исправить состояние пакетов и понять, когда нужно прекратить восстановление и вместо этого восстановить snapshot.

Шаг 5: осознанно отвечайте на запросы конфигурационных файлов

dpkg запрашивает подтверждение только для тех файлов, которые изменили вы или скрипт. Каждый такой запрос означает, что файл был отредактирован намеренно, и нажатие клавиши Enter для быстрого пропуска — это путь, по которому защищенный сервер незаметно превращается в сервер с настройками по умолчанию.

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 должен отображать отсутствие активных юнитов с ошибками; всё, что будет выведено, требует вашего внимания. Финальная команда apt update загружает обновления, выпущенные после создания образов релиза.

PostgreSQL 16 и 18: кластер, который незаметно остался в стороне

В Ubuntu 24.04 поставляется PostgreSQL 16, а в 26.04 — PostgreSQL 18. Обновление устанавливает версию 18 параллельно с 16 и не переносит ваши данные. Уровень абстракции postgresql-common в Debian создает новый пустой кластер для новой мажорной версии на следующем свободном порту. Таким образом, версия 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, а старый останется в остановленном состоянии. Запустите этап анализа (analyze) самостоятельно, так как в только что загруженном кластере отсутствуют статистические данные, и первые запросы будут выполняться медленно.

Протестируйте приложение с новым кластером в течение нескольких дней. Только после этого удаляйте старый:

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 указывают на несуществующий сокет

В 24.04 поставляется PHP 8.3, а в 26.04 — PHP 8.5. Пакеты устанавливаются в версионированные пути, и конфигурация веб-сервера не обновляется автоматически. Nginx vhost, содержащий fastcgi_pass unix:/run/php/php8.3-fpm.sock;, теперь указывает на сокет, который не создается ни одним процессом, поэтому каждый PHP-запрос возвращает 502, а в error log nginx появляется запись:

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

Укажите новый путь к сокету, протестируйте конфигурацию и перезагрузите сервис:

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 из-за отсутствия файла. Включенный модуль является символической ссылкой на пакет, который был удален.

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

Если вы настраивали сервер по руководству LAMP stack on Ubuntu 24.04, стоит проверить оба этих пути, так как в руководстве используются версионированные имена модулей и сокетов.

Ваши настройки php.ini также не переносятся автоматически. memory_limit, upload_max_filesize и другие параметры находятся в /etc/php/8.3/, а новое дерево конфигурации использует значения по умолчанию. Сравните два файла через diff и перенесите значения вручную. Прямое копирование старого файла поверх нового приведет к использованию настроек 8.3 в установке 8.5. Затем выполните php -m и сравните результаты: расширение, установленное как php8.3-redis, требует наличия пакета php8.5-, а если оно было установлено из PPA, то при обновлении этот источник был отключен, и расширение просто отсутствует.

Сертификаты требуют отдельной проверки. После обновления выполните sudo certbot renew --dry-run. Эта команда имитирует полный процесс продления, включая хук перезагрузки веб-сервера, не затрагивая активный сертификат. Хук, вызывающий имя сервиса или бинарный файл, который изменился, выдаст ошибку здесь, на ваших глазах, а не через 60 дней. В статье Certbot with Let's Encrypt on nginx описано, как должны выглядеть эти хуки.

SSH: сбой, прерывающий текущий сеанс

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

Предотвратите это до начала обновления. /etc/ssh/sshd_config в 24.04 начинается с Include /etc/ssh/sshd_config.d/*.conf, а OpenSSH использует первое найденное значение для каждой настройки, поэтому файл конфигурации, подключенный в начале, имеет приоритет над всеми последующими. Перенесите свои настройки в файл, который не принадлежит пакетному менеджеру 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 может не давать результата. Установите порт в юните сокета с помощью 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 содержит описание настроек, которые стоит сохранить в этом дополнительном файле.

Если уже слишком поздно, используйте веб-консоль вашего провайдера, которая предоставляет доступ без использования SSH. Войдите через неё, исправьте конфигурацию, выполните sudo sshd -t и перезапустите службу. Именно для таких случаев необходимо проверять доступ к консоли до начала обновления, а не во время него.

FAQ

Почему do-release-upgrade сообщает "No new release found" на Ubuntu 24.04?

Потому что /etc/update-manager/release-upgrades содержит Prompt=lts в Ubuntu Server, а эта настройка предлагает следующий релиз с долгосрочной поддержкой (LTS) только после выхода его первого корректирующего выпуска. Ubuntu 26.04 LTS вышла 23 апреля 2026 года, а выпуск 26.04.1 запланирован на 27 августа 2026 года. До этой даты сервер 24.04 не увидит обновлений. Не меняйте эту настройку на Prompt=normal, так как это переключит вас на промежуточные релизы.

Нужно ли перезагружать сервер для завершения обновления?

Да. Обновление устанавливает новое ядро, новую библиотеку C и новую систему инициализации, а работающая система продолжает использовать старые версии до перезагрузки. do-release-upgrade запрашивает перезагрузку в конце процесса, и машина, оставленная включенной до «потом», работает на смеси двух релизов. После перезагрузки проверьте uname -r для подтверждения версии ядра и systemctl --failed для поиска сервисов, которые не запустились.

Что лучше: обновление на месте или создание нового сервера 26.04?

По возможности создавайте новый сервер. Новый VPS позволяет установить стек, восстановить данные и протестировать всё, пока старый сервер продолжает обрабатывать трафик. В этом случае откат — это просто изменение DNS, а не восстановление из бэкапа. Обновляйте на месте, если сервер содержит данные, которые сложно перенести, если провайдер берет плату за каждый инстанс или если у вас есть снапшот и надежный доступ через консоль. Путь обновления на месте хорошо изучен, но в течение часа работы это «билет в один конец».

Что произойдет, если SSH-соединение разорвется во время обновления?

В обычной оболочке входа процесс получает сигнал SIGHUP и завершается, оставляя пакеты dpkg в частично настроенном состоянии. Запускайте обновление внутри tmux или screen, тогда процесс продолжит работу, и вы сможете переподключиться и выполнить tmux attach -t upgrade для возобновления. Утилита обновления также запускает дополнительный SSH-демон на порту 1022 как запасной вариант входа, но она не открывает этот порт в файрволе, поэтому откройте 1022 самостоятельно заранее и закройте его после завершения.

Мой PHP-сайт выдает 502 после обновления. Что сломалось?

Путь к сокету PHP FPM изменился вместе с версией. Ubuntu 24.04 использует PHP 8.3, а 26.04 — PHP 8.5, поэтому /run/php/php8.3-fpm.sock больше не существует, хотя ваш vhost в nginx всё еще ссылается на него. Лог ошибок 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 и перезапуск сервиса.