Перейти к основному содержимому

Переход с версии 4.x на 11.x

Эта страница посвящена помощи в миграции экземпляра с YunoHost 4.4.x (работающего на Debian Buster/10.x) на YunoHost 11.x (работающего на Debian Bullseye/11.x). Примечание: мы решили пропустить номера версий от 5 до 10, чтобы следовать номерам версий Debian.

Важные примечания​

  • Команда YunoHost приложила все усилия, чтобы миграция прошла максимально гладко, и в течение нескольких месяцев проводила тестирование в различных конфигурациях.

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

— Пожалуйста, не спешите думать, что вам нужно переустанавливать систему с нуля, считая это «проще» (вздох). (Распространённое мнение — готовность переустановить сервер при малейших сложностях...). Вместо этого, если у вас возникнут проблемы, мы рекомендуем вам попытаться разобраться в ситуации и обратиться за помощью в чат и на форум.

  • Чтобы убедиться в корректной работе миграции, следите за известными проблемами внизу этой страницы.

Процедура миграции​

Из веб-админки​

После обновления до версии 4.4.x перейдите в меню Инструменты > Миграции (Tools > Migrations), чтобы получить доступ к интерфейсу миграций. Вам необходимо внимательно прочитать и принять условия отказа от ответственности, после чего запустить миграцию.

Из командной строки​

После обновления до версии 4.4.x выполните следующую команду:

sudo yunohost tools migrations run

затем внимательно прочтите и примите данное заявление об отказе от ответственности.

Во время миграции​

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

Журналы будут отображаться в строке сообщений (вы можете навести на него курсор, чтобы увидеть всю историю). Они также будут доступны после миграции (как и любые другие операции) в меню «Инструменты» > «Журналы» (Tools > Logs).

Обратите внимание, что даже если вы по какой-либо причине закроете страницу веб-панели администратора, миграция продолжится в фоновом режиме (но веб-панель администратора будет частично недоступна).

Если миграция в какой-то момент завершилась с ошибкой/провалом​

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

Что делать после обновления​

Убедитесь, что вы действительно используете Debian Bullseye и YunoHost 11.x​

Для этого перейдите в раздел «Диагностика/Diagnosis» (категория «Базовая система/Base system») или посмотрите в нижней части веб-панели администратора. В командной строке можно использовать lsb_release -a и yunohost --version.

Выполните миграцию, чтобы восстановить ваше приложение Python​

После обновления ваши приложения Python должны стать недоступны, поскольку необходимо перестроить их виртуальное окружение (venv).

Для этого вы можете запустить ожидающие миграции в разделе Webadmin > Update. Приложения, указанные ниже, не будут автоматически восстановлены; вместо этого вам потребуется принудительно обновить их вручную с помощью команды yunohost app upgrade -F APP.

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

  • calibreweb
  • django-for-runners
  • ffsync (это приложение написано на Python 2 и больше не поддерживается; никаких гарантий не предоставляется)
  • jupiterlab
  • librephotos
  • mautrix
  • mediadrop
  • mopidy
  • pgadmin
  • tracim
  • synapse
  • weblate
подсказка

При необходимости вы можете отключить автоматическую пересборку конкретного Python-приложения, удалив специальный файл с расширением .requirements_backup_for_bullseye_upgrade.txt перед выполнением миграции. Этот файл находится рядом с venv (виртуальным окружением Python) вашего приложения в директории /opt или /var/www.

Убедитесь, что в ходе диагностики не было выявлено никаких проблем​

Кроме того, в разделе «Диагностика» (Diagnosis) веб-интерфейса администратора убедитесь, что после выполнения миграции не возникло никаких конкретных проблем (например, аварийной остановки какой-либо службы).

Если служба php7.3-fpm не работает, следует обновить PHP-приложения (например, пользовательское веб-приложение). После этого можно выполнить команду apt autoremove.

Проверьте, работают ли ваши приложения​

Проверьте работоспособность ваших приложений. Если они не работают, попробуйте обновить их (обновление также является хорошей идеей, даже если они и так работают).

Если ваше приложение не работает, а у вас уже была установлена последняя версия, вы можете повторно запустить обновление благодаря опции -F|--force:

yunohost app upgrade --force APP_NAME

Известные на данный момент проблемы после миграции​

Не удается выполнить миграцию из-за ошибки libc6-dev : Breaks: libgcc-8-dev issue​

Примечание: Эта проблема должна быть решена в версии yunohost_version: 4.4.2.13 У вас есть приложение, которое зависит от пакета build-essential.

См. это решение, чтобы исправить это вручную.

DNSmasq больше не работает​

Мы пока не нашли решения этой проблемы.

После выполнения миграции данных и перезагрузки Raspberry Pi 4 отсутствует подключение к сети Ethernet​

warning

Если вы ещё не перезагрузили сервер, не делайте этого (мы ищем решение). Это избавит вас от необходимости использовать клавиатуру и экран.

Мы нашли это в документации Raspberry Pi

После обновления пакета dhcpcd5 до последней версии (1:8.1.2-1+rpt1 -> 1:8.1.2-1+rpt2) Raspberry Pi не сможет получить IP-адрес по DHCP после следующей перезагрузки или запуска. Этой проблемы можно избежать, отключив и повторно включив параметр «Параметры системы -> Сеть при загрузке» (System Options -> Network at Boot) с помощью последней версии raspi-config после обновления пакета dhcpcd5 и до выключения или перезагрузки системы.

Если вы используете Raspberry Pi 4 (или, возможно, 3), ознакомьтесь с этим решением

Восстановление резервной копии ynh4 на чистую копию ynh11​

Если восстановить приложение не удаётся, но система восстановлена, вероятно, следует использовать команду regen conf для решения проблем с nginx:

yunohost tools regenconf nginx --force

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