Локальная сборка ISO — различия между версиями

Версия 20:32, 14 марта 2019

Если вам хочется собрать собственный ISO-образ Росы, а доступа для сборки образов на ABF нет, можно собрать образ на локальной машине.

Если нужна сборка корневой системы, а не ISO-образа, то см. статью "Образ rootfs".

Особых требований к системе, на которой запускается сборка, нет, единственное, что мешает ее запускать на дистрибутивах GNU/Linux, отличных от ROSA — это прямой вызов urpmi для создания базового chroot.

Для сборки используются специальные проекты, хранящиеся в Git-репозиториях на ABF и включающие в себя все необходимые для сборки скрипты и вспомогательные файлы. На текущий момент поддерживаются следующие проекты:

• KDE4: soft/build_kde4_desktop_ee
• KDE5: soft/build_plasma5_desktop_ee
• XFCE: soft/build_xfce_desktop
• MATE: soft/build_mate_desktop
• GNOME: soft/build_gnome_desktop
• LXQT: soft/build_lxqt_desktop (устарела и не подходит для текущей версии инструкции)

В каждом репозитории могут быть несколько веток. Основная ветка имеет имя актуальной платформы (rosa2016.1); могут присутствовать и различные дополнительные ветки для тестов и экспериментов. Для начала нужно в любую папку склонировать репозиторий из нужной ветки, пример:

git clone https://foo:bar@abf.io/soft/build_plasma5_desktop_ee.git

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

cd build_plasma5_desktop_ee

Теперь можно запускать сборку, пример сборки с минимальным набором параметров, задаваемых переменными окружения:

sudo env TYPES="64u" DE=plasma5 RELEASE=R11 BUILD_ID=20001 ./MATRIX

Обратите внимание, что при запуске скрипта MATRIX терминал должен быть именно в той директории, в которой лежит скрипт MATRIX. В корне этой директории будет создана директория "ROSA.DESKTOP.$RELEASE", которая будет использоваться для раскатывания базового chroot, внутри которого будет запущена сборка с помощью livecd-tools, который сделает еще один чрут внутри существующего чрута. В общем, нужно достаточное количество свободного места. Результирующий образ будет в папке results/, если не задано иное (см. ниже).

Скрипт MATRIX запускается с set -e, из-за чего он завершит свою работу при ошибке на любой промежуточной операции, что упрощает отладку, но может создать некоторые проблемы при сборке в нестандартном окружении. Стандартным условно считаем то, что на ABF.

Смысл переменных окружения (параметров сборки):

• RESULTS_DIR: директория, куда сохранять результирующие образы и логи; по умолчанию создается папка results в текущей директории;
• TYPES: список типов образов, которые будут собираться (возможные варианты: 32, 32u, 64, 64u — соответственно, 32- и 64-битные образы с поддержкой UEFI или без оной); на данный момент можно собирать только один тип за раз, пример: TYPES=64u
• DE: суффикс у файла со списком пакетов, обычно, соответствующий графическому окружению (например, для DE=kde4 будут использоваться файлы commonkde4.lst, i586kde4.lst, x86_64kde4.lst), также $DE войдет в имя файла результирующего образа;
• RELEASE: номер релиза Росы;
• BUILD_ID: номер собираемого образа, может задаваться произвольно;
• MIRROR: зеркало, с которого брать пакеты, пример: MIRROR=http://mirror.rosalab.ru/rosa или MIRROR=http://mirror.yandex.ru/rosa или MIRROR=http://abf-downloads.rosalinux.ru; если не задано, то ставится MIRROR=http://abf-downloads.rosalinux.ru;
• REPO: путь к репозиторию, откуда будут скачиваться пакеты, пример: http://abf-downloads.rosalinux.ru/rosa2016.1/repository/x86_64/, если переменная REPO не задана, то она формируется так: EPO="${MIRROR}/${ROSA_PLATFORM}/repository/${ARCH}/"

Скрипт MATRIX делает следующее:

• добавляет в хостовую систему репозиторий mikhailnov_test_personal, в котором весь стек RPM и URPMI бекпортирован из rosa2016.1 в rosa2012.1 и rosa2014.1 (связано с тем, что при сборке на ABF использовался хост с rosa2012.1, а старый urpmi имел критичные баги), а также urpmi может быть новее, чем в main/updates;
• устанавливает все обновления на хост;
• средствами urpmi делает chroot с целевой платформой, образ которой собирается;
• заменяет шаблонные вещи типа #ARCH# в файле .ks.template (в .ks.template много чего делается, и на данный момент делается это без set -e, то есть сборка образа не прекращается при ошибке промежуточной команды в .ks.template, что затрудняет отладку);
• в созданном chroot запускает livecd-tools, который собирает образ по .ks.template;
• в результирующий образ добавляется mirror.rosalab.ru в качестве единственного репозитория (то есть сначала собирается образ с тем репозиторием, который вы задали, а потом добавляется другой, без гарантии, что содержимое этих репозиториев одинаковое);
• копирует результирующий образ и логи в $RESULTS_DIR (results/).

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

• commonplasma5.lst, i586plasma5.lst, x86_64kplasma5.lst: списки устанавливаемых в образ пакетов (общий список и, при необходимости, архитектуро-зависимые; вместо «plasma5» нужно подставить значение переменной DE);
• i586repo.lst, x86_64repo.lst: дополнительные репозитории или контейнеры (например, если надо собрать образ с тестовой версией пакета, отсутствующей в основном репозитории) (эти контейнеры используются при сборке образа, но НЕ добавляются в качестве репозиториев в результирующий образ!);
• каталог extraconfig: может использоваться для прямого подкладывания или замены файлов в файловой системе образа (кажется, функционал его копирования поломан);
• .ks.template: шаблон Kickstart-файла, используемого для сборки; включает в себя в числе прочего post-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.