Could not calculate the upgrade в Ubuntu: как исправить

Что значит «Could not calculate the upgrade» в Ubuntu

Ошибка «Could not calculate the upgrade» значит, что do-release-upgrade не смог составить план перехода на новый выпуск Ubuntu. Резолвер apt (часть apt, которая подбирает версии пакетов и их зависимости) не нашёл решения и остановился. Почти всегда мешают пакеты не из архива Ubuntu или пакеты, которые вы сами закрепили через apt-mark hold.

Система при этом остаётся рабочей. В отчёте Launchpad #2152142 сразу после ошибки апгрейдер печатает Restoring original system state, а затем Aborting. Он возвращает систему в исходное состояние и выходит. Значит, можно спокойно найти причину, убрать её и запустить обновление ещё раз.

Ниже разбор на примере перехода с Ubuntu 24.04 на 26.04. Та же ошибка встречается при каждом обновлении выпуска, и порядок поиска причины не меняется.

Как выглядит ошибка в консоли

Ошибке предшествует вопрос о сторонних пакетах. Апгрейдер показывает заголовок Foreign Packages Installed, строку The following unofficial packages are currently installed: и список. Для каждого пакета указан источник после слов Installed from:. Если источник определить нельзя, там стоит unknown origin. Затем идёт вопрос Do you want to continue the upgrade anyways? с ответом Continue [yN]. Ответ «нет» сразу прерывает обновление. Ответ «да» запускает расчёт, и на нём появляется сама ошибка. Текст из отчёта #2152142:

Could not calculate the upgrade

An unresolvable problem occurred while calculating the upgrade.

This may be caused by unofficial packages installed on the system.
Please try replacing the following packages with official versions
from the Ubuntu archive, and then try the upgrade again.

Под этим текстом идёт список имён пакетов. В том отчёте их было три: libopenexr-3-1-30 с источником UbuntuESMApps, lynis с источником CISOfy и syncthing с источником Syncthing.

Абзац про unofficial packages появляется не всегда. В исходном коде апгрейдера (файл DistUpgradeCache.py) он выводится, только если найдены чужие пакеты и это не частичное обновление. Если чужих пакетов нет, вместо этого абзаца апгрейдер советует отправить отчёт об ошибке через ubuntu-bug. Это полезный признак: нет списка пакетов, значит, причину надо искать в логах, а не в источниках.

Почему на русском сервере текст наполовину английский

Если на сервере стоит локаль ru_RU.UTF-8, часть сообщения переведена. В файле переводов po/ru.po проекта ubuntu-release-upgrader заголовок звучит так: «Не удалось рассчитать обновление системы». Строка про нерешаемую проблему переведена как «Во время расчёта обновлений возникла нерешаемая проблема.».

Абзац «This may be caused by unofficial packages installed on the system» в ru.po не переведён: у него пустой msgstr. Поэтому русский сервер показывает его по-английски, сразу под русским заголовком. Вопрос со строкой The following unofficial packages are currently installed: тоже не переведён. Учтите оговорку: переводы в git могут отличаться от тех, что лежат в загруженном архиве апгрейдера. Для поиска на Launchpad и в форумах используйте английский текст. По нему находятся все отчёты, а по русскому заголовку результатов мало.

Сначала снимок сервера

Перед любыми исправлениями сделайте снимок VPS. Документация Canonical по обновлению выпуска прямо говорит, что данные нужно скопировать в резервное место до начала. Мы советуем ещё и снимок диска: если вы удалите не тот пакет, откат займёт минуты. Чем снимок отличается от настоящей резервной копии и почему нужны оба, разобрано в статье снимки VPS и резервные копии: в чём разница.

Начните с логов: main.log и apt.log

Не угадывайте причину. Апгрейдер пишет логи в каталог /var/log/dist-upgrade/. При каждом запуске он создаёт новый main.log, а старые файлы *.log переносит в подкаталог с отметкой времени. Поэтому файлы в корне каталога относятся к последней попытке.

sudo ls -la /var/log/dist-upgrade/
sudo grep -n "Foreign" /var/log/dist-upgrade/main.log
sudo grep -n "generated breaks" /var/log/dist-upgrade/apt.log

В коде апгрейдера есть записи в лог с текстом Foreign (before rewriting sources) и Foreign (after rewriting sources). Это список чужих пакетов до и после того, как апгрейдер переписал источники на новый выпуск. Найдите эти строки в main.log. Если grep ничего не нашёл, откройте файл целиком через sudo less и ищите имена пакетов из сообщения об ошибке.

Файл apt.log важнее. Апгрейдер включает для него отладку резолвера: флаги Debug::pkgProblemResolver, Debug::pkgDepCache::Marker и Debug::pkgDepCache::AutoInstall. Поэтому там видно, какие пакеты резолвер пытался поставить, удалить или оставить. В отчёте Launchpad #2150319 пользователь нашёл в apt.log строку pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. Не делайте из неё поспешных выводов. Эта строка значит, что резолвер не справился, но в том случае причиной были вовсе не закреплённые пакеты. Ищите в apt.log имена пакетов, которые повторяются рядом с этой строкой.

Почему апгрейдер считает пакет «чужим»

Правило простое, и оно описано в коде. Для каждого установленного пакета апгрейдер смотрит источник версии-кандидата. Если поле Origin в Release-файле источника не равно Ubuntu или имя архива в источнике не начинается с текущего или нового выпуска (noble или resolute), пакет считается чужим.

Отсюда полезное следствие для тех, кто ставит пакеты с зеркала, например с mirror.yandex.ru. Зеркало не делает пакеты чужими. Апгрейдер проверяет поле Origin внутри Release-файла, а не адрес сервера, а зеркало копирует Release-файл Ubuntu без изменений.

Есть и второй случай. Пакет тоже считается чужим, если его установленную версию нельзя скачать ни из одного источника, а другие его версии скачать можно. Так бывает, когда PPA (Personal Package Archive, личный архив пакетов на Launchpad) поставил версию новее, чем в архиве Ubuntu. Документация Canonical говорит, что сторонние репозитории и PPA отключаются на время обновления выпуска. Значит, при расчёте у такой версии нет источника, и резолверу приходится её заменять.

Причина 1: пакеты из PPA и репозиториев производителей

Начните с этой причины. Кто-то добавил PPA ради свежего PHP или Nginx, или подключил репозиторий производителя, как у Chrome или syncthing. Сначала посмотрите, какие источники подключены и откуда пришёл пакет из сообщения об ошибке:

ls /etc/apt/sources.list.d/
apt-cache policy lynis

apt-cache policy для конкретного пакета показывает установленную версию, кандидата и источники, из которых их можно получить. Замените lynis на имя пакета из сообщения об ошибке.

Пакеты из PPA удобно откатывать утилитой ppa-purge. Она отключает PPA и возвращает его пакеты к официальным версиям Ubuntu. Ей нужны права root. Подставьте настоящее имя PPA вместо owner/name:

sudo apt install ppa-purge
sudo ppa-purge ppa:owner/name

ppa-purge работает только с PPA на Launchpad. Репозитории производителей (CISOfy, Syncthing, Google и другие) придётся разбирать вручную. Есть два пути. Если в архиве Ubuntu есть пакет с тем же именем, поставьте его версию явно. Если такого пакета нет, удалите пакет на время обновления и поставьте его снова после.

apt-cache policy syncthing
sudo apt install syncthing=<версия>
sudo apt remove syncthing

Выполните одну из двух последних команд, а не обе. Вместо <версия> подставьте версию, которую apt-cache policy показывает для архива Ubuntu. Файл репозитория в /etc/apt/sources.list.d/ можно не трогать: апгрейдер сам отключит его на время обновления. Если после работы с источниками apt update начал ругаться на дубли, поможет статья ошибка дублирующихся источников в формате deb822.

В Ubuntu есть команда ubuntu-security-status, которая умеет группировать пакеты по происхождению. Мы не нашли для неё актуальной справки, поэтому не описываем её флаги. Запустите ubuntu-security-status --help на своём сервере и посмотрите, какие варианты доступны в вашей версии.

Причина 2: закреплённые пакеты (hold)

Команда apt-mark hold запрещает apt автоматически ставить, обновлять или удалять пакет. При обычной работе это удобно. При обновлении выпуска закреплённый пакет может не дать резолверу найти решение, потому что старая версия не подходит к новым зависимостям.

apt-mark showhold
sudo apt-mark unhold <пакет>

apt-mark showhold выводит список закреплённых пакетов. Пустой вывод значит, что закреплений нет, и эта причина отпадает. Снимите закрепление перед обновлением. После обновления решите, нужно ли оно снова: старая причина закрепления на новом выпуске может уже не действовать.

Причина 3: lintian при обновлении с 24.04 на 26.04

Весной 2026 года пользователи с установленным lintian сообщали об этой ошибке при переходе с 24.04 на 26.04. Это отчёт Launchpad #2150319 с заголовком «lintian breaks upgrade from 24.04 to 26.04». В описании ошибки сказано, что резолвер не добавлял зависимость libfile-libmagic-perl. Один из участников обсуждения предполагал, что старую версию lintian ломает libyaml-libyaml-perl. Это гипотеза одного человека, а не установленная причина.

С апреля по июнь 2026 года пользователи писали, что помогает удаление lintian перед обновлением и повторная установка после. Это обходной путь из комментариев, а не официальная инструкция.

Проверьте, нужен ли он вам. Исправление уже выпущено. В версию апгрейдера 1:26.04.20 от 4 мая 2026 года добавлена поправка: если обновление идёт с noble и lintian установлен, апгрейдер сам помечает libfile-libmagic-perl к установке до расчёта. Задача для resolute получила статус Fix Released 17 июня 2026 года.

Важная деталь: do-release-upgrade на 24.04 не использует апгрейдер из вашей системы. Он скачивает архив апгрейдера для resolute из resolute-updates, и этот адрес указан в файле meta-release-lts. На 13 октября 2026 года текущая версия в этом каталоге 26.04.25 от 24 сентября 2026 года, то есть новее версии с исправлением. Поэтому на сервере с доступом к архиву удалять lintian не нужно.

Если ошибка всё же появилась, а в apt.log рядом с ней стоят lintian и libfile-libmagic-perl, используйте обходной путь:

sudo apt purge lintian
sudo do-release-upgrade
sudo apt install lintian

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

Пакеты из UbuntuESMApps: мешают или нет

ESM (Expanded Security Maintenance) означает расширенную поддержку безопасности от Canonical. Поток esm-apps закрывает пакеты из Universe в течение десяти лет после выхода LTS и входит в Ubuntu Pro. Что даёт Pro на сервере, описано в статье Ubuntu Pro на сервере простыми словами.

Пакеты из esm-apps всегда попадают в список чужих. Причина в Release-файле: у источника noble-apps-security стоит Origin: UbuntuESMApps, а не Ubuntu. Апгрейдер сравнивает только с Ubuntu, и отдельной обработки ESM в его коде нет.

Мешают ли они расчёту, однозначно сказать нельзя. Список чужих пакетов сам по себе нужен только для вопроса перед расчётом и для текста ошибки. В отчёте #2152142 пакет libopenexr-3-1-30 из UbuntuESMApps оставался в списке и после того, как автор откатил остальные пакеты. Настоящей причиной там оказалась зависимость ubuntu-desktop-raspi от piboot-try на Raspberry Pi. Разработчик Ubuntu в обсуждении советовал не трогать источник ESM и писал, что он не должен мешать обновлению. Отчёт закрыт как Invalid, поэтому это наблюдение по одному случаю, а не правило. Порядок действий такой: не отключайте ESM первым делом, сначала уберите PPA и закрепления, а затем проверьте apt.log.

Повторный запуск обновления

Когда причина устранена, обновите текущую систему до конца и запустите апгрейдер снова:

sudo apt update
sudo apt full-upgrade
sudo do-release-upgrade

Переход между LTS-выпусками открывается только после первого точечного выпуска. На 13 октября 2026 года файл meta-release-lts уже предлагает resolute как 26.04.1 LTS, поэтому путь с 24.04 открыт. Если do-release-upgrade отвечает, что нового выпуска нет, разберитесь по статье do-release-upgrade пишет No new release found. Полный порядок перехода, с подготовкой и проверкой после перезагрузки, описан в руководстве обновление Ubuntu 24.04 до 26.04.

У do-release-upgrade есть флаг -p. Он берёт апгрейдер из Ubuntu-proposed, то есть версию, которая ещё проходит проверку. Используйте его, только если разработчики в отчёте об ошибке просят проверить исправление. На рабочем сервере он не нужен.

Если обновление сломалось позже

После ошибки расчёта апгрейдер восстанавливает исходное состояние и выходит. Хуже, когда сбой случается на этапе установки, после того как часть пакетов уже заменена. Тогда восстанавливайте систему по шагам из статьи восстановление после неудачного обновления Ubuntu. Если после этого apt жалуется на неразрешённые зависимости, пригодится разбор как исправить сломанные пакеты в apt.

FAQ

Почему do-release-upgrade пишет «Could not calculate the upgrade»?

Резолвер apt не смог подобрать набор пакетов для нового выпуска. Чаще всего мешают пакеты из PPA и репозиториев производителей, которые апгрейдер отключает на время обновления, или пакеты, закреплённые через apt-mark hold. Точную причину показывают логи /var/log/dist-upgrade/main.log и /var/log/dist-upgrade/apt.log. После ошибки апгрейдер возвращает систему в исходное состояние, так что сервер остаётся рабочим.

Нужно ли удалять lintian перед обновлением с Ubuntu 24.04 на 26.04?

Обычно нет. Исправление для отчёта LP #2150319 вошло в апгрейдер 1:26.04.20, а do-release-upgrade на 24.04 скачивает свежий апгрейдер из resolute-updates, где на 13 октября 2026 года лежит версия 26.04.25. Если ошибка всё же появилась и apt.log указывает на lintian, удалите его через sudo apt purge lintian, обновитесь и поставьте lintian снова уже на 26.04.

Блокируют ли обновление пакеты с источником UbuntuESMApps?

Они всегда попадают в список чужих, потому что в Release-файле esm-apps стоит Origin: UbuntuESMApps, а апгрейдер признаёт своим только Ubuntu. Но сам список влияет лишь на вопрос перед расчётом и на текст ошибки. В разобранном отчёте #2152142 причиной была другая зависимость, а разработчик Ubuntu советовал не отключать ESM. Сначала уберите PPA и закрепления, затем смотрите apt.log.

Почему ошибка на русском сервере выводится наполовину по-английски?

В файле переводов ru.po заголовок и первая строка переведены: «Не удалось рассчитать обновление системы» и «Во время расчёта обновлений возникла нерешаемая проблема.». Абзац «This may be caused by unofficial packages installed on the system» перевода не имеет, поэтому выводится по-английски. Ищите решения по английскому тексту ошибки: по нему находится больше отчётов.