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

Сбой обновления Ubuntu: сначала определите симптомы

Неудачное обновление релиза Ubuntu с 24.04 до 26.04 оставляет сервер в одном из четырех состояний, и для каждого из них требуется свой способ исправления. Процесс обновления может все еще выполняться внутри сессии screen, связь с которой была потеряна. Утилита dpkg могла быть принудительно завершена, когда пакет был настроен лишь частично, из-за чего apt теперь отклоняет любые команды. В файлах источников apt могут быть указаны репозитории 26.04, в то время как установленные пакеты все еще относятся к 24.04. Либо сервер может вовсе не загружаться. Прежде чем вводить какие-либо команды, определите, в каком состоянии находится система, так как решение для одного случая может усугубить другой.

Одно правило применимо ко всем четырем ситуациям. Не перезагружайте сервер, пока не выясните состояние dpkg. Перезагрузка в процессе замены пакетов превращает устранимый сбой dpkg в ситуацию, когда система не загружается, что описано в конце этого руководства. Также не запускайте второй процесс apt или dpkg, пока первый может быть активен, так как одновременная запись двумя процессами приводит к повреждению базы данных пакетов.

В этом руководстве предполагается, что вы следовали руководству по обновлению с 24.04 до 26.04 и сделали снимок состояния системы (snapshot) перед началом работ. Если вы этого не сделали, учитывайте это при чтении раздела о загрузке, так как откат к снимку является решением для наихудшего сценария.

Is the upgrade still running?

Many upgrades reported as failed are still running. The SSH session dropped, the terminal went blank, and the upgrader carried on without you.

do-release-upgrade is built for this. When it runs with its text interface, which is what a server gets, it wraps itself in a GNU screen session, so the upgrade survives the loss of the terminal that started it. Separately, when it detects that it was started from an SSH session, it offers to start a second sshd on another port (1022 by default) so you can still log in if the main SSH daemon breaks during the package swap. Both facts matter now.

Reconnect over SSH and look for the screen session. The upgrader ran under sudo, so its screen session belongs to root, and a plain screen -ls as your own user will not list it.

sudo screen -ls

screen -ls marks each session as attached or detached. If one is listed, reattach to it. If it is still marked attached because the dead SSH connection never released it, -d detaches that stale attachment first.

sudo screen -d -r

If more than one session is listed, put the session name from screen -ls after -r. Running sudo do-release-upgrade again also works: the upgrader checks for its own existing screen session and reattaches instead of starting a new run. Either way you land back in the running upgrade, which is usually waiting at a prompt about a changed config file or a service restart. Answer it and let it finish.

If you started the upgrade inside tmux, as the upgrade guide recommends, reattach tmux first with tmux attach. The screen session is running inside that tmux pane, so you see the upgrade directly. If the pane holds only a shell prompt, the upgrader is no longer running there, and sudo screen -ls is the next check.

If the main SSH port refuses the connection, try the fallback port: ssh -p 1022 user@host. That daemon exists only for the life of the upgrade, so if you cannot get in on either port, use your provider's console instead. From the console, sudo ss -ltnp shows which ports an sshd process is listening on, and sudo ufw status tells you whether the firewall let the fallback port through.

When no screen session exists and nothing is waiting on the console, the upgrade really did stop. Confirm nothing is still working on the package database before you touch it:

ps -eo pid,etime,cmd | grep -iE '[u]pgrade|[d]pkg|[a]pt'

An empty result means dpkg is idle and you can move on to repairing it. A dpkg or apt process with a long elapsed time and no screen session to reattach is hung. Give it a few minutes, check the console for a debconf question nobody answered, and only then kill it. Never delete the lock files under /var/lib/dpkg/ or /var/lib/apt/lists/ while a process holds them. The lock is the only thing stopping two writers from corrupting the package database.

Процесс dpkg был прерван, и apt отказывается работать

Если процесс dpkg был завершен принудительно в промежутке между распаковкой пакета и выполнением его скрипта настройки, он фиксирует это незавершенное состояние в /var/lib/dpkg/status. Любая последующая команда apt считывает это состояние и останавливается, так как apt не может работать с базой данных, содержащей незавершенные операции. Независимо от того, какое сообщение об ошибке выдает apt, первым делом нужно выполнить следующее.

sudo dpkg --configure -a

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

Затем позвольте apt исправить зависимости, которые остались неразрешенными из-за прерывания, так как некоторые пакеты были обновлены, а пакеты, от которых они зависят — нет.

sudo apt --fix-broken install

После этого завершите обновление, которое было прервано:

sudo apt update
sudo apt full-upgrade

Используйте full-upgrade вместо upgrade, так как обновление релиза подразумевает удаление пакетов, а обычная команда upgrade отказывается что-либо удалять. Прочитайте сводку, которую выводит apt, перед подтверждением. Небольшой список удаляемых пакетов — это нормально. Если в списке присутствуют ubuntu-server, systemd, openssh-server или ваш пакет ядра, это не является нормой: откажитесь от операции и выясните, почему apt хочет их удалить, прежде чем продолжать.

Проверьте результат, прежде чем предпринимать что-либо еще:

sudo dpkg --audit
sudo apt-get check

dpkg --audit выводит список всех пакетов, которые все еще находятся в неисправном состоянии, а apt-get check сообщает о неразрешенных зависимостях. Обе команды не должны выводить ничего. Когда это условие будет выполнено, запустите sudo apt autoremove, чтобы удалить пакеты 24.04, которые больше никем не используются, затем подтвердите релиз с помощью cat /etc/os-release, выполните sudo update-initramfs -u -k all и sudo update-grub, и только после этого перезагрузитесь.

Как читать /var/log/dist-upgrade для поиска пакета, остановившего процесс

Программа обновления записывает все действия в /var/log/dist-upgrade/. Если вы запускали её более одного раза, логи предыдущей попытки перемещаются в подкаталог с отметкой времени, поэтому сначала проверьте ls -la /var/log/dist-upgrade/ и откройте каталог, соответствующий неудачному запуску.

main.log — это основной журнал программы обновления. В нем фиксируется текущий этап работы и принятые решения относительно ваших источников пакетов. Если сама программа обновления завершилась аварийно, здесь также будет указана трассировка стека Python. Читайте её с конца: последние строки укажут этап, на котором произошла остановка. Если там есть трассировка, значит, произошел сбой самого инструмента, а не пакета.

apt.log содержит логику работы механизма разрешения зависимостей. Это подробный файл, он важен, если apt вообще отказался рассчитывать обновление (это сбой до того, как был затронут какой-либо пакет). Если обновление дошло до стадии установки пакетов, этот файл обычно можно пропустить.

apt-term.log — это файл, который нужен при сбое конкретного пакета. Он содержит вывод терминала dpkg во время обновления — тот самый текст, который прокручивался перед вами. Последний пакет, упомянутый перед завершением, — это тот, который обрабатывался в момент остановки. Если произошел сбой скрипта сопровождения, жалоба dpkg на него будет находиться прямо там, а ошибка самого скрипта — непосредственно над ней.

sudo tail -n 60 /var/log/dist-upgrade/apt-term.log
sudo grep -in 'error' /var/log/dist-upgrade/apt-term.log | tail

Сверьтесь с /var/log/dpkg.log, где фиксируется каждое изменение состояния, которое dpkg вносит с отметкой времени. tail -n 30 /var/log/dpkg.log показывает последний пакет, с которым работал dpkg, и выполняемую операцию — это тот же ответ из второго источника.

Большинство сбоев на этом этапе на сервере вызваны несколькими причинами. Сервис, который пакет перезапускает в своем postinst, не может запуститься из-за измененного вами файла конфигурации; systemctl status и journalctl -xeu для этого сервиса укажут строку, которую он не принимает. Переполнение диска (чаще всего /boot старыми ядрами или /var кэшем пакетов apt), что видно в df -h / /boot /var; sudo apt clean очищает кэш, даже если apt завис, а диск, который сообщает о заполнении, хотя du показывает обратное имеет свои причины. Пакет из стороннего репозитория, который программа обновления отключила, зависит от библиотеки, которой больше нет в 26.04. Удерживаемый пакет (apt-mark showhold) заблокировал обновление зависимости. Устраните причину, затем снова запустите sudo dpkg --configure -a. Процесс продолжится с того места, где он остановился.

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

sudo dpkg --remove --force-remove-reinstreq package-name
sudo dpkg --configure -a

Используйте это только для пакета, который вы можете назвать и объяснить, но никогда не применяйте к библиотекам или чему-либо из цепочки зависимостей ubuntu-server, так как принудительное удаление пропускает проверки, которые могли бы предупредить вас о других поломках.

Источники обновлены, но пакеты — нет

Программа обновления перезаписывает ваши источники apt на раннем этапе, до загрузки пакетов. Если процесс прерван после этого шага, в источниках указана версия 26.04, а установленные пакеты представляют собой смешанную версию. Эта смесь сбивает инструменты с толку, и именно поэтому do-release-upgrade может утверждать, что новых релизов нет.

Сравните два места, в которых указано, какая версия системы у вас установлена. /etc/apt/sources.list.d/ubuntu.sources — это файл источников в формате deb822, появившийся в 24.04, и его строки Suites: содержат кодовое имя релиза. Файл /etc/os-release создается пакетом base-files и указывает, какой релиз установлен фактически.

grep -E '^(Suites|Components):' /etc/apt/sources.list.d/ubuntu.sources
grep -E '^(VERSION_ID|VERSION_CODENAME)=' /etc/os-release
apt-cache policy base-files

Важны три комбинации. В источниках указана 24.04 (кодовое имя noble), а в os-release — 24.04: обновление не прошло проверку, и вы можете запустить sudo do-release-upgrade снова, предварительно изучив main.log, чтобы понять причину остановки. В источниках указано кодовое имя 26.04, а в os-release — 24.04: замена пакетов началась и была прервана; завершить её поможет процедура восстановления dpkg из предыдущего раздела, заканчивающаяся командой apt full-upgrade. В источниках указана 26.04, и в os-release — 26.04: пакет base-files был одним из тех, что успели обновиться, и теперь система считает себя версией 26.04, даже если большая часть её компонентов — нет.

Последняя комбинация — ловушка. do-release-upgrade определяет текущий релиз на основе той же информации, что содержится в os-release. Если там уже указано 26.04, инструмент ищет что-то новее 26.04, ничего не находит и сообщает, что новых релизов нет. Инструмент отвечает на вопрос, основываясь на os-release, а os-release содержит неверные данные. Прекратите использовать программу обновления и завершите процесс через apt: sudo apt update, затем sudo apt full-upgrade, что обновит все пакеты, оставшиеся на версии 24.04, и в конце sudo apt autoremove. Стоит исключить другие причины, по которым do-release-upgrade сообщает об отсутствии новых релизов, например, настройки LTS, ожидающие первого точечного релиза, если в os-release всё ещё указана 24.04.

Программа обновления также отключает сторонние источники в /etc/apt/sources.list.d/ и сохраняет резервную копию каждого измененного файла, добавляя суффикс к исходному имени. Выполните ls -la /etc/apt/sources.list.d/ и diff для каждого исходного файла и его резервной копии, чтобы увидеть, какие именно изменения были внесены. Оставьте сторонние записи отключенными, пока пакеты Ubuntu не придут в согласованное состояние, а затем включайте их по одному, только убедившись, что поставщик выпустил пакеты для 26.04. Если apt update выдает ошибку о том, что источник настроен более одного раза, значит, старая запись sources.list и новая запись ubuntu.sources описывают один и тот же набор пакетов, и ошибка дублирования источника deb822 объясняет, какую из них следует удалить.

Сервер не загружается после обновления

Перезагрузка — это момент, когда становятся очевидны последствия незавершенного обновления. Вероятные причины на VPS: ядро установлено без initramfs, конфигурация GRUB не была пересоздана, пакет остался в полунастроенном состоянии, от которого зависит юнит автозагрузки, или диск переполнился во время записи данных процессом dpkg.

Прежде чем предпринимать какие-либо действия, откройте консоль провайдера. Она покажет, на каком этапе останавливается загрузка: меню GRUB, kernel panic, проверка файловой системы, ожидающая ввода, или emergency shell systemd, запрашивающий пароль root. Это наблюдение определит следующий шаг.

Если появляется GRUB, загрузите предыдущее ядро 24.04 из подменю дополнительных параметров. Старое ядро обычно остается в системе до тех пор, пока не будет выполнен autoremove. Как только система загрузится с использованием старого ядра, выполните sudo dpkg --configure -a и остальные действия по восстановлению из раздела выше, затем sudo update-initramfs -u -k all и sudo update-grub, прежде чем снова пробовать новое ядро. В Восстановление VPS, который не загружается после обновления ядра подробно описаны аспекты работы с GRUB и initramfs.

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

mount -o remount,rw /
dpkg --configure -a

Если система вообще не доходит до командной оболочки, загрузите rescue image вашего провайдера, примонтируйте диск VPS и выполните восстановление из chroot. Найдите корневой раздел с помощью lsblk, вместо того чтобы угадывать его имя.

lsblk
mount /dev/<root-partition> /mnt
for d in dev proc sys run; do mount --bind /$d /mnt/$d; done
chroot /mnt /bin/bash
dpkg --configure -a
apt --fix-broken install
update-initramfs -u -k all
update-grub
exit
reboot

Прежде чем тратить час в chroot, сопоставьте это время с использованием снимка (snapshot). Вы сделали его перед началом работ, и восстановление из него у большинства провайдеров занимает минуты. Затем вы повторно запускаете обновление, что на VPS занимает значительно меньше часа, и в этот раз вы заранее знаете, какой пакет требует исправления. Восстановление из снимка — более быстрый путь, если верно хотя бы одно из утверждений: вы не можете получить доступ к консоли или rescue image, вы не можете определить пакет, который остановил обновление, застряло более одного пакета, или на сервере запущены критически важные сервисы. Исправление вручную быстрее только в том случае, если вы точно знаете, что именно сломалось, и для починки достаточно одной команды.

Скопируйте /var/log/dist-upgrade/ с сервера перед восстановлением, при необходимости используя rescue image, если это единственный способ доступа. Восстановление удалит эти логи, и вторая попытка завершится тем же сбоем, если вы не выяснили причину первой. Стоит прочитать Что может и чего не может восстановить snapshot, прежде чем полагаться на него. Снимок откатывает весь диск целиком, включая любые данные, записанные после его создания, что допустимо в процессе обновления, но неприемлемо спустя неделю.

Три признака того, что систему лучше переустановить

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

Во-первых, повреждена база данных dpkg --audit. Если dpkg --audit или apt-get check не могут прочитать /var/lib/dpkg/status, а не просто сообщают о поврежденных пакетах внутри, значит, запись об установленном ПО утрачена. Ubuntu хранит ежедневные копии в /var/backups/ (ls -la /var/backups/dpkg.status*), и замена поврежденного файла на самую свежую рабочую копию иногда помогает. Однако, как только эта копия перестает соответствовать реальному состоянию диска, вы начинаете действовать наугад, и каждый последующий запуск apt будет опираться на эти догадки.

Во-вторых, инструменты, необходимые для восстановления системы, сами вышли из строя. Когда apt или dpkg не запускаются из-за удаления или частичной замены разделяемой библиотеки, или systemd не может запустить юниты, так как его собственный пакет настроен лишь частично, не остается работающего менеджера пакетов для исправления самого менеджера пакетов. ldd /usr/bin/apt позволяет проверить, все ли библиотеки apt на месте. Иногда можно выйти из этой ситуации через chroot в образе восстановления, но затраченное на это время обычно превышает время переустановки.

В-третьих, список поврежденных пакетов не сокращается. Если вы запускали dpkg --configure -a и apt --fix-broken install в цикле более часа, и каждая итерация выявляет новый пакет вместо исправления предыдущего, значит, система принесла в процесс обновления проблемы, которые не были созданы самим обновлением: файлы в /usr, отредактированные вручную, зафиксированные (pinned) или удерживаемые пакеты, сторонний репозиторий, заменивший системные библиотеки, или предыдущее обновление, которое так и не было завершено. Свежий образ не имеет этих проблем, а восстановление данных на него занимает меньше времени, чем их поиск.

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

FAQ

Можно ли запустить do-release-upgrade повторно после прерывания?

Да, это первое, что стоит сделать. Если процесс обновления всё ещё активен в сессии screen, повторный запуск подключит вас к этой сессии. Если нет, сначала выполните sudo dpkg --configure -a и sudo apt --fix-broken install, а затем снова запустите утилиту обновления. Она считает текущее состояние и продолжит работу. Единственный случай, когда это не поможет — если в /etc/os-release уже указана версия 26.04, так как система считает обновление завершённым; в этом случае завершите процесс с помощью sudo apt full-upgrade.

Почему do-release-upgrade сообщает об отсутствии новых релизов после сбоя обновления?

Потому что пакет base-files, который записывает данные в /etc/os-release, был одним из тех, что обновились до прерывания. Теперь утилита считывает этот файл, делает вывод, что у вас установлена версия 26.04, и не находит ничего более нового. Сравните grep VERSION_ID /etc/os-release с grep Suites /etc/apt/sources.list.d/ubuntu.sources, а затем завершите обновление с помощью sudo apt update && sudo apt full-upgrade.

Безопасно ли перезагружать Ubuntu server, если обновление не завершено?

Не делайте этого, пока sudo dpkg --audit не перестанет выводить данные. Перезагрузка с распакованным, но не настроенным ядром или не обновлённым GRUB — самая частая причина, по которой обновление, которое можно было исправить за десять минут, превращается в работу с rescue-образом. Завершите восстановление через dpkg и apt full-upgrade, выполните update-initramfs -u -k all и update-grub, и только после этого перезагружайтесь.

Как найти пакет, который остановил обновление?

Изучите конец файла /var/log/dist-upgrade/apt-term.log, где хранятся данные вывода терминала dpkg. Последний упомянутый пакет перед окончанием лога — это тот, который выполнялся в момент сбоя; ошибка скрипта сопровождения (maintainer script) обычно указана прямо над сообщением об ошибке dpkg. tail -n 30 /var/log/dpkg.log подтверждает это из второго источника. Если файл main.log заканчивается трассировкой Python (traceback), значит, произошёл сбой самой утилиты обновления, а не конкретного пакета.

Стоит ли восстанавливать снапшот или продолжать исправление?

Восстанавливайте снапшот, если вы не можете определить сбойный пакет, если зависло несколько пакетов, если у вас нет доступа к консоли или если сервер должен вернуться в строй как можно быстрее. Продолжайте исправление только в том случае, если вы точно знаете, что именно сломалось, и решение сводится к одной команде. Скопируйте /var/log/dist-upgrade/ с сервера перед восстановлением, иначе вторая попытка обновления завершится с той же ошибкой.