do-release-upgrade: обновление Ubuntu до нового релиза без потери сервера

apt upgrade обновляет пакеты внутри текущего релиза, но перевести систему с 22.04 на 24.04 он не может — для этого есть отдельная утилита do-release-upgrade. Она меняет источники пакетов, разрешает конфликты зависимостей и проводит систему через смену версий системных компонентов. Разбираем, как сделать это на боевом сервере и не остаться с неработающей машиной.

Когда обновляться, а когда нет

Ubuntu поддерживает переход только на следующий релиз: с 22.04 на 24.04, но не сразу на 26.04. Чтобы попасть через две версии, обновление запускают дважды.

Осмысленные поводы для перехода:

• приближается конец поддержки текущего релиза (см. сроки поддержки Ubuntu LTS);
• нужны версии пакетов, которых в текущем релизе нет;
• вендор ПО требует более свежую систему.

Когда обновление лучше отложить: сразу после выхода нового LTS (первые недели ловят чужие баги), в разгар рабочей нагрузки на сервисе, а также если на сервере стоят пакеты из сторонних PPA, у которых ещё нет сборки под новый релиз.

Отдельно стоит помнить: на LTS-релизах do-release-upgrade по умолчанию предлагает переход только на следующий LTS. Это правильное поведение для сервера — промежуточные релизы живут девять месяцев.

Готовимся: бэкап и проверка

Обновление релиза меняет тысячи пакетов. Откатить его штатными средствами нельзя — только восстановить из копии. Поэтому подготовка обязательна.

Полностью обновляем текущий релиз:

sudo apt update
sudo apt upgrade -y
sudo apt full-upgrade -y
sudo apt autoremove -y

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

Проверяем свободное место — процессу нужно несколько гигабайт:

df -h /
df -h /boot

Особое внимание на /boot: если он забит старыми ядрами, обновление упадёт на середине. Почистить:

sudo apt autoremove --purge

Делаем копию конфигов и списка пакетов:

sudo tar czf ~/etc-backup-$(date +%F).tar.gz /etc
dpkg --get-selections > ~/packages-$(date +%F).txt

Про архивирование подробнее — в статье про tar.gz, про вывоз копий на другую машину — в статье про rsync.

Если сервер виртуальный — сделайте снапшот гипервизора. Это единственный по-настоящему быстрый способ отката.

Отдельно снимаем дампы баз, если они есть:

sudo -u postgres pg_dumpall > ~/pg-full-$(date +%F).sql

Проверяем, какие сторонние репозитории подключены:

grep -rh "^deb " /etc/apt/sources.list /etc/apt/sources.list.d/ | grep -v ubuntu.com

do-release-upgrade отключит их автоматически, но после обновления их нужно будет включить заново — уже с новым кодовым именем релиза.

Запускаем обновление

Обязательно через screen или tmux. Если обновление идёт по SSH и связь оборвётся, процесс прервётся на середине — это самый частый способ получить сломанную систему.

sudo apt install -y screen
screen -S upgrade
sudo do-release-upgrade

Отключиться от сессии — Ctrl+A, затем D. Вернуться после переподключения:

screen -r upgrade

Утилита сама предупредит про SSH: она поднимает дополнительный sshd на порту 1022 как страховку на случай обрыва. Если фаервол закрыт, стоит заранее разрешить этот порт:

sudo ufw allow 1022/tcp

После обновления правило убирают: sudo ufw delete allow 1022/tcp. Про фаервол — в статье про UFW.

Полезные флаги:

sudo do-release-upgrade -c    # только проверить, доступен ли новый релиз
sudo do-release-upgrade -d    # обновиться до промежуточного релиза или беты
sudo do-release-upgrade -f DistUpgradeViewNonInteractive   # без вопросов, для автоматизации

Флаг -d нужен, когда LTS не предлагает обновление до промежуточной версии. На сервере им лучше не пользоваться без веской причины: промежуточные релизы поддерживаются девять месяцев, после чего придётся обновляться снова.

Неинтерактивный режим на боевом сервере тоже рискован — все спорные решения о конфигах будут приняты за вас.

Что отвечать на вопросы про конфиги

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

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?
    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

Практическое правило: сначала D, посмотреть различия, и только потом решать.

• N (оставить свою версию) — выбор по умолчанию и обычно правильный для конфигов, которые вы осознанно настраивали: sshd_config, конфиги nginx, fstab.
• Y (взять версию из пакета) — когда свои правки не помните или они были незначительными. Новая версия может содержать важные изменения формата.

Особая осторожность с sshd_config: если взять версию мейнтейнера, может вернуться PermitRootLogin или отключиться аутентификация по ключам — и после перезагрузки вы не попадёте на сервер. Здесь почти всегда N, а различия стоит просмотреть внимательно.

Ваша версия при выборе Y не пропадает — она сохраняется рядом с расширением .dpkg-old. Найти такие файлы после обновления:

sudo find /etc -name "*.dpkg-old" -o -name "*.dpkg-dist" | sort

.dpkg-dist — наоборот, версия из пакета, отложенная в сторону, когда вы выбрали N. Просмотреть эти пары полезно: иногда в новой версии появляются нужные параметры.

После перезагрузки

Обновление завершится предложением перезагрузиться. После старта проверяем систему:

lsb_release -a                    # версия релиза
uname -r                          # версия ядра
systemctl --failed                # упавшие сервисы
sudo journalctl -p err -b --no-pager | head -40   # ошибки с этой загрузки

Команда systemctl --failed — первое, что нужно смотреть: она сразу покажет сервисы, которые не поднялись после смены версий. Разбор их логов — в шпаргалке по journalctl.

Проверяем ключевые сервисы:

systemctl is-active nginx postgresql docker ssh
sudo nginx -t
curl -I https://example.com

Возвращаем сторонние репозитории. Файлы в /etc/apt/sources.list.d/ при обновлении получают расширение .distUpgrade или закомментированные строки:

ls /etc/apt/sources.list.d/

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

Убираем то, что осталось от старого релиза:

sudo apt update
sudo apt full-upgrade
sudo apt autoremove --purge

Когда что-то пошло не так

Обновление прервалось на середине. Система в промежуточном состоянии, часть пакетов новая, часть старая. Первым делом:

sudo dpkg --configure -a
sudo apt install -f
sudo apt full-upgrade

Эти три команды достраивают прерванный процесс: досконфигурируют распакованные пакеты, чинят сломанные зависимости и доводят обновление до конца.

Сервер не поднялся после перезагрузки. Нужен доступ к консоли — через панель управления хостера, IPMI или гипервизор. В меню GRUB (удерживать Shift или Esc при загрузке) выберите предыдущее ядро в разделе Advanced options: старое ядро часто загружается там, где новое падает.

Не работает сеть. На старых системах виновником бывает переименование интерфейсов. Смотрим фактические имена и правим конфиг:

ip a
sudo nano /etc/netplan/*.yaml
sudo netplan try

netplan try применяет конфигурацию с автоматическим откатом через две минуты, если не подтвердить — это спасает от потери связи с сервером. Подробно — в статье про netplan.

Не пускает по SSH. Проверьте /etc/ssh/sshd_config через консоль: если при обновлении была выбрана версия мейнтейнера, ваши настройки портов и ключей могли смениться. Восстановить свою версию:

sudo cp /etc/ssh/sshd_config.dpkg-old /etc/ssh/sshd_config
sudo systemctl restart ssh

Ничего не помогло. Разворачиваем систему заново и восстанавливаем из бэкапа — именно поэтому копия конфигов и снапшот делаются до начала.

Альтернатива: переустановка вместо обновления

Для серверов, чья конфигурация описана в скриптах или Ansible, чистая установка нового релиза часто быстрее и предсказуемее обновления. Вы получаете систему без наследия старых конфигов, .dpkg-old файлов и отключённых репозиториев.

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

Обновление на месте выигрывает, когда сервер настраивали руками годами и повторить эту настройку с нуля дороже, чем провести систему через do-release-upgrade.

Частые вопросы

Чем do-release-upgrade отличается от apt upgrade?

apt upgrade обновляет пакеты внутри текущего релиза — версия системы при этом не меняется. do-release-upgrade переводит систему на следующий релиз: меняет источники пакетов, разрешает конфликты и обновляет системные компоненты.

Просто заменить кодовое имя в sources.list и выполнить apt full-upgrade — плохая идея: утилита делает много дополнительной работы, включая обработку устаревших пакетов и защиту SSH-сессии.

Почему do-release-upgrade не видит новый релиз?

На LTS-системах по умолчанию предлагается только следующий LTS, а он появляется в предложениях не сразу после релиза, а после выхода первого корректирующего выпуска (.1) — обычно через несколько месяцев. Это защита от ранних багов.

Проверить настройку: grep Prompt /etc/update-manager/release-upgrades. Значение lts означает «только LTS», normal — любой следующий релиз. Обновиться раньше срока можно флагом -d.

Можно ли обновиться сразу с 20.04 на 24.04?

Нет, только последовательно: 20.04 → 22.04 → 24.04. Каждый шаг — отдельный запуск do-release-upgrade с перезагрузкой между ними.

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

Что делать, если обновление прервалось?

Выполнить по порядку sudo dpkg --configure -a, sudo apt install -f и sudo apt full-upgrade. Эти команды доводят прерванный процесс до конца в большинстве случаев.

Чтобы такого не происходило, обновление всегда запускают внутри screen или tmux — тогда обрыв SSH-соединения не убивает процесс.

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

Нет. Разумная практика для сервера — подождать выхода корректирующего выпуска .1 (примерно полгода после релиза) или хотя бы пары месяцев. К этому времени исправляют основные проблемы, а сторонние репозитории успевают выпустить сборки под новый релиз.

Спешить стоит только если текущий релиз близок к концу поддержки и перестаёт получать обновления безопасности.

Что запомнить

• do-release-upgrade переводит систему на следующий релиз; через две версии — только двумя последовательными запусками.
• Запускать строго в screen или tmux: обрыв SSH посреди обновления оставляет систему в промежуточном состоянии.
• Бэкап /etc, дампы баз и снапшот виртуалки делаются до старта — штатного отката у обновления нет.
• На вопрос про изменённый конфиг сначала жмите D и смотрите различия; для sshd_config почти всегда правильный ответ — N.
• После перезагрузки проверьте systemctl --failed и верните сторонние репозитории с новым кодовым именем релиза.