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

Прямого обновления с Ubuntu 22.04 до 26.04 нет

Прямого обновления с Ubuntu 22.04 LTS до 26.04 LTS нет. do-release-upgrade выполняет обновление только между соседними версиями LTS, поэтому путь выглядит так: 22.04 → 24.04, затем 24.04 → 26.04. Между этими этапами нужно перезагрузить систему и полностью проверить её. В примечаниях к выпуску 26.04 это сформулировано однозначно: «Если сейчас используется более старая версия Ubuntu LTS или промежуточный выпуск, например Ubuntu 22.04 LTS или 25.04, сначала необходимо обновиться до Ubuntu 24.04 LTS или 25.10, и только после этого можно перейти к 26.04 LTS».

Для второго перехода есть условие, и теперь оно выполнено. Canonical предлагает обновление LTS-to-LTS только после выпуска первого точечного обновления целевой версии и пометки записи о ней в meta-release как поддерживаемой. Версия 26.04.1 вышла 27 August 2026, а по состоянию на 27 October 2026 файл do-release-upgrade читает https://changelogs.ubuntu.com/meta-release-lts, где указана 26.04.1 LTS с Supported: 1. Поэтому полностью обновлённая система 24.04 получает предложение обновиться до 26.04.1 через обычный do-release-upgrade и больше не выводит No new release found. Открытие этого перехода ожидало backports для исправления регрессии в rust-coreutils. Эти backports уже добавлены, поэтому флаг -d, упомянутый в объявлении о выпуске 26.04.1, больше не требуется. Всё же проверьте это на своей системе с помощью do-release-upgrade -c, а не полагайтесь только на дату. В разделе Почему обновления LTS ожидают точечного выпуска .1 объясняется причина такого условия.

Два перехода означают две перезагрузки и два этапа отключения сторонних репозиториев. При этом на одном сервере применяются изменения основных версий PHP, Python, PostgreSQL и kernel за четыре года. Именно этому посвящена большая часть руководства. Сам второй переход пошагово описан в руководстве по обновлению с 24.04 до 26.04, поэтому здесь он не повторяется. Начать сейчас стоит по следующей причине: стандартная поддержка 22.04 заканчивается в 2027 году. После этого обновления для неё будут предоставляться только через расширенную поддержку безопасности Ubuntu Pro или платную стороннюю службу расширенной поддержки.

Почему upgrader отказывается пропускать выпуск

do-release-upgrade не содержит логику обновления. Он загружает tarball, имя которого указано в строке UpgradeTool файла meta-release: noble.tar.gz для 24.04 и resolute.tar.gz для 26.04. Этот tarball содержит скрипт, рассчитанный только на фиксированный список исходных выпусков. Этот список находится в строке From= файла DistUpgrade.cfg upgrader. При последней проверке 20 October 2026 для 26.04 в ней были указаны noble,oracular,plucky,questing: 24.04 LTS и три следующих interim release — 24.10, 25.04 и 25.10. Срок поддержки этих interim release истёк, но upgrader по-прежнему принимал их как исходные системы. jammy в этом списке нет, поэтому upgrader для 26.04 завершает работу с ошибкой на системе 22.04, не начиная обновление. Скрипты maintainer для каждого пакета, а также хуки preinst и postinst, которые переносят файлы конфигурации, тестируются для этих путей обновления и не для других. Переход с 22.04 на 26.04 запустил бы скрипты 26.04 для состояний конфигурации, с которыми они никогда не работали, и dpkg остановился бы на полпути, оставив систему в нерабочем состоянии.

Переход на Prompt=normal в /etc/update-manager/release-upgrades также не помогает обойти это ограничение. В комментарии Ubuntu в этом файле сказано, что normal предназначен для "the supported release that immediately succeeds the currently-running release", а проверка обновления пропускает каждый выпуск, который файл meta-release помечает как неподдерживаемый. 22.10, 23.04 и 23.10 имеют там статус Supported: 0 (проверено 27 October 2026), поэтому для 22.04 normal предлагает 24.04 — ту же целевую систему, что и lts. Оставьте Prompt=lts. Теперь, когда ограничение снято, локальная причина есть у системы 24.04, которая по-прежнему сообщает No new release found. Почти всегда это связано с этим файлом или с удерживаемым metapackage. Причины, по которым do-release-upgrade ничего не находит, описаны в причинах, по которым do-release-upgrade ничего не находит.

Обновление на месте или новый VPS с 26.04?

Обновление на месте сохраняет данные и конфигурацию, но требует двух окон технического обслуживания. Новый VPS с 26.04 и миграция требуют больше работы на начальном этапе, зато вы получаете чистую систему. Выбирайте миграцию, если выполняется хотя бы одно из следующих условий.

• Сервер уже обновлялся на месте — с версии 20.04 или более ранней. После каждого перехода остаются устаревшие пакеты и старая конфигурация. Три слоя таких остатков сложно диагностировать.
• Включено более двух или трёх сторонних репозиториев или PPA. Каждый из них отключается при каждом переходе. Для каждого нужно проверить наличие сборки под новым кодовым именем выпуска.
• Установлена панель управления или модуль ядра, собранный вне основного дерева исходного кода. Такие компоненты не работают после перехода на новое ядро. do-release-upgrade не может исправить проблемы с ними.
• Невозможно создать snapshot. Без точки отката обновление рабочей системы на месте создаёт риск, который нельзя отменить.

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

Перед первым переходом: снимок, свободное место и чистая 22.04

Сначала полностью обновите 22.04. В противном случае программа обновления не запустится и выведет Please install all available updates for your release before upgrading.

lsb_release -a
sudo apt update && sudo apt full-upgrade -y
sudo apt autoremove --purge -y
sudo reboot

После перезагрузки команда lsb_release -rs должна вывести 22.04, а uname -r должна показать ожидаемую версию ядра: 5.15.x для серии GA или 6.8.x для серии HWE. Если вы не уверены, какую серию используете, в материале о различиях ядер GA и HWE показано, как это определить и почему это важно для обновления.

Проверьте свободное место на диске. Программа обновления сначала загружает все пакеты и только затем устанавливает их. Чаще всего место заканчивается на отдельном разделе /boot, где хранятся несколько старых ядер.

df -h / /boot
dpkg -l 'linux-image-*' | grep ^ii

На / должно быть не менее 5 GB свободного места. Если на /boot свободно менее 200 MB, удалите старые ядра до начала обновления, а не после аварийного завершения программы обновления.

Теперь создайте снимок в панели управления провайдера и дождитесь его завершения. Снимок — это точка отката всего диска. Именно она нужна при неудачном обновлении выпуска. Снимок не является резервной копией, и разница между снимком и резервной копией здесь важна: продолжайте выполнять обычное резервное копирование. Затем зафиксируйте исходное состояние системы.

apt-mark showmanual > ~/manual-packages-22.04.txt
apt-cache policy | grep -oE 'https?://[^ ]+' | sort -u > ~/apt-sources-22.04.txt
ls /etc/apt/sources.list.d/
php -v; python3 --version; node -v; psql --version; mysql --version
sudo iptables-save > ~/iptables-22.04.rules
sudo cp -a /etc/netplan ~/netplan-22.04

Некоторые из этих команд выводят command not found, если соответствующий стек не установлен. Это нормально. Важно сохранить запись о том, что использовалось в 22.04. После двух переходов вы уже не вспомните, какая версия PHP требовалась старому сайту.

Наконец, убедитесь, что /etc/update-manager/release-upgrades содержит Prompt=lts, и откройте в системе второй сеанс SSH. Не закрывайте его до полного завершения обновления.

Переход с 22.04 на 24.04

sudo do-release-upgrade -c

Ожидаемый вывод:

Checking for a new Ubuntu release
New release '24.04.5 LTS' available.
Run 'do-release-upgrade' to upgrade to it.

Начните с sudo do-release-upgrade. При подключении по SSH сначала появится такой запрос:

This session appears to be running under ssh. It is not recommended
to perform a upgrade over ssh currently because in case of failure it
is harder to recover.

If you continue, an additional ssh daemon will be started at port
'1022'.
Do you want to continue?

Ответьте yes, затем откройте этот порт во второй сессии, поскольку программа обновления сообщает, что не сделает это за вас:

sudo ufw allow 1022/tcp

Если вместо ufw вы используете nftables или обычный iptables, добавьте эквивалентное правило. Также откройте порт 1022 в сетевом firewall вашего провайдера, если он его предоставляет. Это отдельный от сервера уровень управления.

Программа обновления работает внутри сессии screen, поэтому разрыв соединения не остановит её. Подключитесь снова и присоединитесь к сессии с помощью sudo screen -ls, а затем sudo screen -r. После этого программа считывает списки пакетов и показывает сводку: сколько пакетов будет установлено и удалено и сколько времени займёт загрузка. Обратите внимание на число удаляемых пакетов. Если на обычном сервере их больше нескольких десятков, перед продолжением стоит нажать d и просмотреть подробности.

Во время обновления важны три запроса.

Сторонние источники отключены. Программа обновления комментирует каждый apt source, который не распознаёт как собственный источник Ubuntu, и помечает каждую строку как # disabled on upgrade to noble. Это необходимо, поскольку строка со значением jammy указывает на пакеты, собранные для старого релиза. На контрольном этапе вы включите эти источники по одному.

Запросы о конфигурационных файлах. Для изменённого конфигурационного файла, который dpkg отслеживает как conffile, dpkg спрашивает, установить ли версию сопровождающего пакета. Значение по умолчанию, N, сохраняет вашу версию. С /etc/ssh/sshd_config, который вы, скорее всего, редактировали, всё устроено иначе: openssh-server управляет им через ucf, а не через механизм conffile в dpkg. Поэтому запрос имеет вид What do you want to do about modified configuration file sshd_config? и предлагает варианты install the package maintainer's version или keep the local version currently installed. Сохраните локальную версию, которая используется по умолчанию в ucf, если у вас нет веской причины поступить иначе. Версия сопровождающего пакета сбрасывает PasswordAuthentication и Port, а подключение выполняется через этот daemon.

Удалить устаревшие пакеты? Эта операция удаляет пакеты, которые есть в 22.04, но отсутствуют в 24.04. Если вы используете PostgreSQL, postgresql-14 не входит в этот список: denylist удаляемых пакетов в программе обновления защищает все версионированные пакеты PostgreSQL, поскольку их очистка может удалить кластер, а pg_upgradecluster нужны их бинарные файлы для переноса данных. Если в списке есть пакет, который вам ещё нужен, ответьте N. После контрольного этапа устаревшие пакеты можно удалить с помощью sudo apt autoremove --purge. При этом версия PostgreSQL, для которой всё ещё существует кластер, не будет удалена.

На небольшом VPS обновление обычно занимает от 30 до 60 минут. Большая часть времени уходит на распаковку пакетов dpkg, а не на загрузку. После завершения программа предложит перезагрузить систему. Ответьте yes.

Контрольная точка между этапами

Не начинайте второй этап, пока этот список не будет выполнен полностью. Два наложившихся сбоя намного сложнее отлаживать, чем один. Для 24.04 стандартная поддержка действует до 2029, поэтому недельная пауза ничего не стоит.

lsb_release -rs
uname -r
systemctl --failed
sudo apt update && sudo apt full-upgrade -y

lsb_release -rs должен вывести 24.04, а uname -r должен начинаться с 6.8 — ядра GA для 24.04, если только на сервере не используется дополнительная серия ядер 24.04 HWE, которая сейчас имеет версию 7.0. systemctl --failed должен вывести 0 loaded units listed. Любой перечисленный им юнит — ваша первая задача.

Затем проверьте источники apt. Обновляющая программа noble преобразует /etc/apt/sources.list в /etc/apt/sources.list.d/ubuntu.sources — формат deb822 — и оставляет в старом файле комментарий со ссылкой на новый файл. Если позже вставить строку deb http://... старого формата для того же архива, набора и компонента обратно в sources.list, apt увидит один и тот же репозиторий в обоих файлах и выведет is configured multiple times. Эта ошибка дублирования источника исчезнет, если удалить строку старого формата или закомментировать её.

grep -r 'disabled on upgrade' /etc/apt/sources.list /etc/apt/sources.list.d/

Для каждой отключённой строки примите решение. Если поставщик публикует набор noble, измените jammy на noble, удалите маркер комментария и выполните sudo apt update. Если команда выведет E: The repository '... noble Release' does not have a Release file., у поставщика нет сборки для 24.04. Оставьте строку отключённой или найдите другой источник. То же самое сделайте для PPA. Затем проверьте каждый подходящий к вашему серверу пункт в следующем разделе, ещё раз перезагрузите сервер, убедитесь, что все нужные вам сервисы отвечают, и создайте новый снимок. Назовите его так, чтобы отличать от снимка 22.04, и храните оба снимка, пока не убедитесь в работоспособности 26.04.

Что ломается при двух переходах

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

Сторонние репозитории и PPA отключаются дважды

Каждый источник, не относящийся к Ubuntu, комментируется при первом переходе и ещё раз при втором, где marker reads # disabled on upgrade to resolute. У PPA, собранного только для jammy и noble, в первый день не будет набора resolute, а ошибка does not have a Release file указывает на это. На веб-сервере чаще всего встречаются Docker CE из download.docker.com, NodeSource, ppa:ondrej/php и репозиторий Tailscale. Все они, кроме NodeSource, указывают codename выпуска в строке apt. Текущая настройка NodeSource записывает nodistro как suite, поэтому она без изменений переживает оба перехода. Репозиторий Docker требует исправления codename дважды. Кроме того, пакет docker.io в архиве 26.04 имеет версию 29. Она достаточно новая, поэтому vendor repository многим серверам больше не нужен. Если строка Tailscale используется у вас, ошибки установки Tailscale в Ubuntu — это именно те ошибки, которые вызывает устаревший codename.

PHP переходит через две основные версии: 8.1, затем 8.3 и 8.5

В Ubuntu 22.04 поставляется PHP 8.1, в 24.04 — 8.3, а в 26.04 — 8.5. Если вы установили php-fpm через metapackage без номера версии, первый переход устанавливает php8.3-fpm рядом с php8.1-fpm и запускает оба. Ничто не переключает веб-сервер на новую версию, поэтому nginx продолжает обращаться к сокету 8.1 и работает дальше. Это продолжается до удаления устаревших пакетов, после чего журнал ошибок заполняется следующим:

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

Чтобы исправить проблему, укажите для fastcgi_pass значение unix:/run/php/php8.3-fpm.sock, выполните sudo nginx -t и перезагрузите конфигурацию. В Apache с mod_php выполните sudo a2dismod php8.1 && sudo a2enmod php8.3 && sudo systemctl restart apache2. Сделайте это на контрольной точке для 8.3 и запустите тесты приложения. После второго перехода повторите процедуру для 8.5. Если приложение пока не работает с 8.5, это единственная веская причина повторно включить ppa:ondrej/php в 26.04: этот PPA содержит все версии PHP для каждого текущего выпуска Ubuntu. Те же действия применяются к LAMP stack на базе 24.04, который проходит только вторую часть этого перехода.

Python: с 3.10 на 3.12 и 3.14, а pip перестаёт записывать данные в систему

Системная версия Python при первом переходе меняется с 3.10 на 3.12, а при втором — на 3.14. Ломаются две вещи. Во-первых, в каждом virtualenv, созданном в 22.04, bin/python является символической ссылкой на /usr/bin/python3.10. Вместе с устаревшими пакетами удаляется цель этой ссылки, поэтому venv завершается с ошибкой No such file or directory. Пересоздайте каждый venv с помощью python3 -m venv --clear .venv и установите его зависимости заново. Во-вторых, начиная с 24.04, pip install вне venv отказывается выполнять операцию и выводит:

error: externally-managed-environment

Это PEP 668. Он защищает пакеты Python, которыми управляет apt, от перезаписи. Используйте venv или apt install python3-<name> вместо флага --break-system-packages, упомянутого в сообщении об ошибке.

Node: с 12 на 18 из архива или через NodeSource

Пакет nodejs в архиве имеет версию 12.22 в 22.04 и 18.19 в 24.04. Поэтому приложение, созданное для Node 12, сразу сталкивается с четырьмя годами удалённых API. На большинстве production-серверов вместо этого используется NodeSource. NodeSource фиксирует определённую major version, поэтому версия не меняется ни при одном переходе. Нужно только повторно включить строку репозитория.

Базы данных: PostgreSQL 14, 16 и 18, а MySQL 8.4 блокирует учётные записи

При первом переходе устанавливается PostgreSQL 16 рядом с кластером 14. Новый пустой кластер получает порт 5433. pg_lsclusters показывает оба кластера. Ваши данные по-прежнему находятся в 14 на порту 5432. Перенесите их на контрольной точке:

pg_lsclusters
sudo pg_dropcluster --stop 16 main
sudo pg_upgradecluster 14 main
pg_lsclusters

pg_upgradecluster выгружает данные из 14 и загружает их в новый кластер 16 на порту 5432, после чего оставляет 14 остановленным на 5433. Проверьте приложение, затем выполните sudo pg_dropcluster 14 main. После второго перехода в архиве поставляется PostgreSQL 18. Повторите те же четыре команды для 16 и 18. Поэтому upgrader не удаляет postgresql-14 как устаревший и apt autoremove не трогает его, пока существует его кластер: pg_upgradecluster запускает бинарные файлы старого сервера для чтения старых данных.

В Ubuntu 22.04 и 24.04 используется MySQL 8.0, поэтому первый переход ничего не меняет. Второй переход выполняется на 8.4. Эта версия отключает plugin mysql_native_password, а в release notes сказано, что учётные записи, использующие его, «will be locked out by default». Клиент получает ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded. Найдите такие учётные записи на контрольной точке, пока используется 8.0:

SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';
ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'the-same-password';

Старые драйверы PHP и Python, которые не поддерживают caching_sha2_password, — причина существования этих учётных записей. Поэтому тестируйте приложение после каждого ALTER USER.

Файлы netplan эпохи 22.04

Многие образы VPS эпохи 22.04 поставляли /etc/netplan/50-cloud-init.yaml с gateway4: и разрешениями, доступными для чтения всем пользователям. Netplan 1.0 в 24.04 и 1.2 в 26.04 по-прежнему принимает оба варианта, но выводит предупреждения при первом запуске sudo netplan generate:

** (generate:1234): WARNING **: 10:21:07.512: Permissions for /etc/netplan/50-cloud-init.yaml are too open. Netplan configuration should NOT be accessible by others.
** (generate:1234): WARNING **: 10:21:07.513: `gateway4` has been deprecated, use default routes instead.

Исправьте разрешения с помощью sudo chmod 600 /etc/netplan/*.yaml. Замените gateway4: 203.0.113.1 маршрутом по умолчанию:

routes:
  - to: default
    via: 203.0.113.1

Для проверки используйте sudo netplan try, а не netplan apply. try применяет изменение и отменяет его через 120 секунд, если не нажать Enter. Поэтому ошибка, из-за которой пропадает SSH-сеанс, будет исправлена автоматически. Выполните это на контрольной точке в 24.04, поскольку ошибка netplan, обнаруженная после второго перехода, выглядит точно как проблема второго перехода.

iptables-legacy сохраняется после обоих переходов

Ubuntu использует backend nftables для iptables начиная с 20.10. Если на сервере с 22.04 для старого Docker или скрипта firewall был выбран legacy с помощью update-alternatives --set iptables /usr/sbin/iptables-legacy, этот выбор сохраняется после обоих обновлений, потому что update-alternatives никогда не переопределяет ручной выбор. Проверьте его:

sudo iptables -V
sudo update-alternatives --display iptables | head -3
sudo nft list ruleset | head

iptables v1.8.x (legacy) означает legacy backend. Он продолжает работать, и в этом заключается проблема: правила, загруженные через legacy tools, и правила, загруженные через nftables, выполняются в kernel. Ни один из инструментов не показывает правила другого. Поэтому nft list ruleset возвращает почти пустой результат, а legacy rules по-прежнему отбрасывают пакеты. В Docker 29 на 26.04 можно переключиться на backend nftables. ufw использует выбранную alternative. Поэтому на смешанном сервере появляются два набора правил, которые нельзя просмотреть в одном месте. На контрольной точке перейдите на iptables-nft с помощью sudo update-alternatives --set iptables /usr/sbin/iptables-nft, загрузите сохранённые правила и убедитесь, что sudo nft list ruleset теперь показывает их.

Kernel 5.15, 6.8 и 7.0, а также новый инструмент initramfs

GA kernel при первом переходе меняется с 5.15 на 6.8, а при втором — на 7.0. Старые kernel не удаляются во время обновления, поэтому /boot заполняется. Если VPS не загружается после смены kernel, это как раз тот случай, для которого нужен snapshot. В разделе Восстановление VPS, который не загружается после обновления kernel описаны console и меню GRUB. В новых установках 26.04 initramfs создаётся с помощью dracut, а не initramfs-tools. На обновлённом сервере может сохраниться initramfs-tools. Проверьте это с помощью dpkg -l initramfs-tools dracut и оставьте установленный инструмент без изменений.

При втором переходе появляются ещё два изменения 26.04. Перед началом обновления их нужно изучить. Теперь sudo — это sudo-rs, а раздел что меняется с sudo-rs важен, если у вас сложный sudoers. coreutils переписаны на Rust, а в разделе объяснение Rust coreutils описаны отличающиеся флаги. Кроме того, systemd 259 больше не поддерживает cgroup v1. Если /proc/cmdline содержит systemd.unified_cgroup_hierarchy=0 из старой настройки контейнеров, удалите его из GRUB до второго перехода, поскольку в 26.04 он больше не может выполнять предназначенную для него задачу.

Переход 2: с 24.04 на 26.04

Проверьте условие допуска непосредственно на сервере:

sudo do-release-upgrade -c

New release '26.04.1 LTS' available. означает, что запись meta-release отмечена как поддерживаемая. Это так с момента, когда Canonical открыл обновление (проверено 27 October 2026). Выполните sudo do-release-upgrade точно так же, как на первом переходе, используя второй sshd на порту 1022 и те же запросы. На этот раз маркер стороннего ПО имеет значение # disabled on upgrade to resolute. Если полностью обновлённый сервер 24.04 по-прежнему выводит No new release found, причина теперь локальная: ожидающие установки обновления, строка Prompt= со значением, отличным от lts, или заблокированный metapackage. Не используйте do-release-upgrade -d. Эта команда читает файл development meta-release. После выхода rust-coreutils backports и открытия штатного пути использовать её на сервере нет причин. О содержимом point release и о том, как читать запись meta-release, которая определяет это условие, см. разбор 26.04.1. Полная процедура с запросами, специфичными для 26.04, и проверками после обновления приведена в руководстве по переходу с 24.04 на 26.04. Начните с шага создания snapshot, поскольку checkpoint snapshot у вас уже есть.

Если переход завершился ошибкой

Средство обновления записывает журнал в /var/log/dist-upgrade/. В main.log содержатся собственные решения средства обновления, а в term.log — все строки dpkg; apt.log показывает состояние с точки зрения средства разрешения зависимостей. Если переход останавливается на полпути, apt обычно остаётся в состоянии, которое можно исправить с помощью sudo dpkg --configure -a, а затем завершить с помощью sudo apt -f install. Если это не помогает, в разделе восстановление после неудачного обновления выпуска описан аварийный сценарий, а созданный перед переходом снимок остаётся крайним средством. После неудачного второго перехода восстановите снимок 24.04 — вы потеряете только время. После неудачного первого перехода восстановите снимок 22.04 и вернитесь в исходное состояние со списком исправлений, которые нужно внести перед новой попыткой.

FAQ

Можно ли напрямую обновить Ubuntu 22.04 до 26.04?

Нет. do-release-upgrade выполняет обновление только между соседними LTS-версиями, а в примечаниях к выпуску 26.04 указано, что сервер с 22.04 сначала нужно обновить до 24.04. При последней проверке 20 October 2026 загружаемый им обновлятор 26.04 принимал в качестве исходных только Ubuntu 24.04 LTS и промежуточные версии после неё (24.10, 25.04 и 25.10), а 22.04 в этом списке не было. Поддерживаемый путь с 22.04 только один: 22.04 → 24.04, затем 24.04 → 26.04. Установка Prompt=normal не меняет этот путь: обновлятор пропускает версии, которые файл meta-release помечает как неподдерживаемые. 22.10, 23.04 и 23.10 относятся к таким версиям, поэтому с 22.04 он в любом случае предлагает 24.04.

Почему do-release-upgrade в 24.04 сообщает «No new release found»?

Canonical открывает обновление LTS до LTS только после выпуска первого point release целевой версии и только когда файл meta-release-lts помечает её как Supported: 1. Ubuntu 26.04.1 была выпущена 27 August 2026. По состоянию на 27 October 2026 запись имеет значение Supported: 1, поскольку исправления регрессий rust-coreutils уже были включены обратно. Поэтому на полностью обновлённом сервере с 24.04 должна появиться New release '26.04.1 LTS' available. Если этого не произошло, сначала выполните sudo apt update && sudo apt full-upgrade, затем убедитесь, что /etc/update-manager/release-upgrades имеет значение Prompt=lts, а не never.

Обновить систему на месте или развернуть новый 26.04 VPS?

Обновляйте систему на месте, если сервер выполняет одну задачу, содержит мало сторонних репозиториев и перед каждым переходом можно создать snapshot. Разверните новый 26.04 VPS и перенесите службы, если сервер уже обновлялся на месте, использует control panel или custom kernel либо зависит от нескольких PPA. Каждая из этих особенностей увеличивает объём работ на обоих переходах.

Сколько занимает обновление с 22.04 до 26.04?

Запланируйте два окна обслуживания по 30–60 минут каждое для небольшого VPS и дополнительное время между ними на выполнение промежуточных действий. Основное время уходит на этот промежуточный этап: во время него нужно перенести PostgreSQL, переключить PHP sockets, пересобрать Python virtualenvs и снова включить репозитории. Между переходами можно оставить несколько недель: стандартная поддержка 24.04 действует до 2029.

Что произойдёт с моими PPA во время обновления?

Обновлятор закомментирует каждый источник, не относящийся к Ubuntu, и пометит каждую строку как # disabled on upgrade to noble. На втором переходе он повторит это с resolute. В строке PPA указано codename выпуска, поэтому для повторного включения измените codename и выполните sudo apt update. Если apt выведет does not have a Release file, значит, для этого выпуска в PPA ещё нет сборки. В таком случае подождите или найдите другой источник.