Как обновить Ubuntu 24.04 до 26.04 на VPS

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

Запустите проверку на системе 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. «Увеличение версии» — не повод трогать машину, которая обслуживает клиентов.

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

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

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

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

Используйте два уровня защиты, так как они выходят из строя по разным причинам. Снапшот от провайдера охватывает весь диск и восстанавливается за считанные минуты, но он создаётся в момент записи данных в базы, поэтому является 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 — это то, что вам действительно понадобится, так как он содержит все конфигурационные файлы, по которым система будет задавать вопросы во время обновления.

Резервная копия, которую вы ни разу не восстанавливали, — это лишь предположение. Извлеките из неё один файл прямо сейчас, пока вам не потребовалось делать это в экстренной ситуации.

Шаг 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 ГБ свободного места. Если размер /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. Обновление продолжало выполняться, пока вас не было.

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