Вопрос или проблема
Я только что обновил сервер с 14.04 до 16.04, используя стандартный процесс do-release-upgrade. Теперь я получаю “No new release found”, когда пытаюсь запустить его снова для обновления до 18.04.
Попробованные действия:
sudo apt updatesudo apt upgradesudo apt dist-upgradesudo apt full-upgradesudo do-release-upgrade(“No new release found.”)sudo do-release-upgrade -d(“Upgrades to the development release are only available from the latest supported release.”)sudo do-release-upgrade -p(“No new release found.”)wget http://changelogs.ubuntu.com/meta-release(успешно получает файл, показывает корректные данные, включая информацию о 18.04)sudo apt install update-manager-core(“update-manager-core is already the newest version (1:16.04.17).”)vim /etc/update-manager/release-upgrades(prompt настроен на “lts”, как и ожидалось)
Вопросы:
- Почему 18.04 не находится и не предлагается для обновления? Я не понимаю, как
do-release-upgradeработает за кулисами и почему оно выдает “no new release found”, когда успешно получает доступ к файлу meta-release, файл содержит правильные данные и есть новая версия LTS с точечной версией. - Как мне обновить эту машину? Какой лучший и самый безопасный обходной путь?
Попробуйте установить пакет ca-certificates и затем запустить ‘do-release-upgrade’. Исправление этой проблемы находится в процессе, вы можете следить за ним по ссылке https://launchpad.net/bugs/1796940.
Возможно, это поможет кому-то:
В моем конкретном случае, когда я пытался обновить с Xenial до Bionic и использовал свой собственный apt-mirror с репозиториями Bionic, я столкнулся с проблемой, что do-release-upgrade не может найти никаких новых версий:
root@<my_host>:~# do-release-upgrade -c
Checking for a new Ubuntu release
No new release found.
Я нашел исходный код, чтобы включить режим отладки:
root@<my_host>:/root# export DEBUG_UPDATE_MANAGER=True
и определил свою корневую причину, истекший сертификат на хосте apt-mirror:
root@<my_host>:/usr/bin# do-release-upgrade -c
Checking for a new Ubuntu release
MetaRelease.__init__() useDevel=False useProposed=False
/etc/update-manager/meta-release: https://<my-apt-mirror>/meta-release
/etc/update-manager/meta-release: https://<my-apt-mirror>/meta-release-lts
/etc/update-manager/meta-release: -development
/etc/update-manager/meta-release: -proposed
metarelease-uri: https://<my-apt-mirror>/meta-release-lts
MetaRelease.download()
result of meta-release download: '<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)>'
NO self.metarelease_information
No new release found.
Вероятно, это ошибка загрузки файла мета-релиза, из-за брандмауэра, конфигурации TLS, сертификатов CA и т. д.
Самое простое исправление, которое я нашел, это открыть файл /etc/update-manager/meta-release, вручную загрузить файл для URI_LTS и разместить его где-то еще, предпочтительно там, где к нему можно получить доступ без https, и ввести этот новый URL в этот файл:
URI_LTS = http://my.own.server.example.com/copy-of-meta-release-lts
После этого обновление у меня прошло успешно.
если ca-certificates уже установлены и обновлены.
Вы можете попробовать вручную получить необходимые сертификаты с URL.
1.
# openssl s_client -showcerts -connect changelogs.ubuntu.com:443 |tee /usr/local/share/ca-certificates/changelogs.ubuntu.com.crt
-
удалите мусор из файла:
vi /usr/local/share/ca-certificates/changelogs.ubuntu.com.crt
он должен выглядеть так:
-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
...
...
-----END CERTIFICATE-----
или это может быть не нужно)
-
выполните
# update-ca-certificates --fresh -
добавьте строки
import ssl
import json
ssl._create_default_https_context = ssl._create_unverified_context
в /usr/bin/do-release-upgrade сразу после секции import
пример:
...
from UpdateManager.Core.utils import init_proxy
import ssl
import json
ssl._create_default_https_context = ssl._create_unverified_context
RELEASE_AVAILABLE=0
NO_RELEASE_AVAILABLE=1
...
do-release-upgrade
Ответ или решение
Когда вы сталкиваетесь с проблемой "No new release found" при попытке обновления Ubuntu с версий 16.04 до 18.04.4, важно понимать механизм, через который работает утилита do-release-upgrade.
Теория:
Утилита do-release-upgrade предназначена для обновления версии Ubuntu на сервере или десктопе. Она осуществляет это, обращаясь к серверу с метаданными, которые описывают доступные версии и возможные пути обновления. Если связь с сервером, где хранятся эти метаданные, нарушена (например, из-за проблем с SSL-сертификатами или настройки доступа), утилита не сможет обнаружить доступную версию для обновления.
Пример:
В вашем случае, несмотря на успешное получение файла meta-release с changelogs.ubuntu.com, утилита не может предложить обновление. Это может происходить по нескольким причинам, включая проблемы с SSL-сертификатами или конфигурацией клиента. Один из пользователей обнаружил, что проблема крылась в сертификате, истекшем на стороне зеркала apt.
Применение:
-
Проверка сертификатов: Убедитесь, что у вас установлены и обновлены все необходимые сертификаты. Это можно сделать, обновив пакет
ca-certificates:sudo apt-get install --reinstall ca-certificates -
Диагностика ошибки: Активируйте режим отладки для
do-release-upgrade:export DEBUG_UPDATE_MANAGER=True sudo do-release-upgrade -
Исправление сертификатов вручную: Если сертификаты по-прежнему вызывают проблемы, используйте команду OpenSSL для получения последних:
openssl s_client -showcerts -connect changelogs.ubuntu.com:443 | sudo tee /usr/local/share/ca-certificates/changelogs.ubuntu.com.crt sudo update-ca-certificates --fresh -
Обход проблем с SSL: Временно отключите проверку SSL в скрипте /usr/bin/do-release-upgrade, добавив следующие строки после раздела import:
import ssl ssl._create_default_https_context = ssl._create_unverified_context
После применения этих шагов заново попробуйте выполнить do-release-upgrade. Эти действия должны помочь устранить проблему и позволить вашему серверу успешно выполнить обновление до следующей версии LTS. Если проблемы сохраняются, возможно, стоит рассмотреть процедуру ручного обновления через установочные образы, чтобы точно воспроизвести состояние, требуемое для перехода на 18.04.