Локальная сборка ISO

Ссылки сюда (3) →

Локальная сборка ISO

Введение

Данная статья описывает процесс сборки ISO-образов ROSA Fresh/Хром с помощью публично доступных скриптов, которыми собираются официальные релизные установочные образы.

Скрипты сборки ISO-образов находятся здесь: https://abf.io/soft/rosa-build-iso

Также имеются скрипты сборки rootfs, но эта статья описывает только лишь сборку ISO.

Статья описывает работу со скриптами rosa-build-iso, собирающими образы на основе платформ rosa2021.1 и rosa2023.1, а скрипты сборки ISO на основе старых платформ (rosa2014.1, rosa2016.1) описаны в последнем разделе этой статьи.

Этапы сборки ISO

• начало работы скрипта сборки
• установка программы livecd-tools и других необходимых для работы пакетов
• подготовка конфигурационных файлов для livecd-tools
• запуск программы livecd-creator из пакета livecd-tools, которая в свою очередь выполняет следующие действия:
  • запуск, обработка конфигурации
  • создание RPM-пакета rosa-iso-info с мета-информацией об образе
  • выполнение %pre-скриптов, при их наличии (по умолчанию их нет)
  • создание chroot (rootfs) путем запуска пакетного менеджера dnf (используется Python API dnf, а не CLI-утилита dnf напрямую); пакетному менедежеру указывается список всех пакетов, которые должны попасть в образ; он ставит их всех за **одну** транзакцию (поэтому важно, чтобы в пакетах были правильно прописаны Requires, Requires(pre), Requires(post), OrderWithRequires, OrderWithRequires(pre), OrderWithRequires(post) и т.д. и не было зацикленных зависимостей)
  • выполнение %post-скриптов в созданном chroot, при их наличии
  • выполнение %post --nochroot скриптов вне созданного chroot, при их наличии
  • установка пакета rosa-iso-info
  • запаковка полученного chroot в squashfs
  • создание конфигурационного файла загрузчика Grub2
  • копирование загрузчиков (shim, grub2)
  • запаковка ISO-образа
• перемещение собранного ISO-образа в заданный каталог
• завершение работы скрипты сборки

Подготовка рабочего окружение

Рассмотрим подготовку рабочего места оператора сборки ISO-образа.

Для сборки необходимо следующее окружение:

• ОС на базе платформы rosa2021.1 или rosa2023.1 (например, ROSA Fresh 12, ROSA Хром 12)
• root-права
• достаточные для монтирования loop-устройств capability (актуально для контейнеров)

Возможны следующие варианты среды сборки:

• запущенная непосредственно на желез ОС Роса
• запущенная в виртуальной машине ОС Роса
• контейнер с ОС Роса

В процессе сборки монтируются loop-устройства, поэтому запускать сборку лучше либо на железе, либо в виртуальной машине, однако можно и в контейнере, если пробросить в него /dev/loop*, что бывает проблематично.

Пример запуска systemd-nspawn для сборки в контейнере на базе rootfs Росы:

sudo systemd-nspawn -D /путь/к/распакованной/rootfs --capability=CAP_MKNOD --property='DeviceAllow=/dev/loop0 rwm' -b

А внутри контейнера сделать:

mknod /dev/loop0 b 7 0

При использовании ВМ или запуске на железе манипуляции с mknod проделывать не нужно.

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

Необходимо скачать скрипты сборки:

git clone https://abf.io/soft/rosa-build-iso.git

Если программа git не установлена, то установите ее:

sudo dnf install git-core

Если при сборке параметрами указываются номера контейнеров на ABF (ADD_REPOS="номер номер..."), то должна быть установлена переменная окружения API_TOKEN=API-ключ_ABF, ключ можно взять из персональных настроек ABF: https://abf.io/settings/private

Запуск скрипта производится от root, параметры описаны ниже, пример запуска:

cd rosa-build-iso
sudo DE=plasma5 BUILD_ID=001 API_TOKEN=xxx ./rosa-build-iso.sh

Обратите внимание, что, если вы находитесь в не-root консоли и установите относящиеся к скрипту сборки переменные окружения через export VAR=value, то они не попадут в скрипт. При запуске приведенном выше способом — указании всех параметров после слова "sudo" — попадут.

Параметры скрипта сборки

Все параметры скрипта сборки передаются переменными окружения. Если какой-либо параметр не задан, то используется его значение по умолчанию. Рекомендуется ознакомиться с кодом build-iso-abf.sh, все параметры с пояснениями перечислены в начале скрипта. Ниже будет рассмотрено большинство параметров, однако актуальность этой документации не гарантируется, рекомендуется смотреть в код.

ABF

• ABF=1 — скрипт запускается в одноразовом виртуальном окружении
• ABF=0 — наоборот.

Если 1, то mirror.rosalab.ru заменяется на abf-downloads.rosalinux.ru в /etc/yum.repos.d/*

RESULTS_DIR

Путь к каталогу, куда положить результирующий ISO-образ. По умолчанию (если не задано иное) это /home/vagrant/results (такой путь по историческим причинам).

BUILD_ID

ID сборки. Может содержать в себе любые латинские буквы и цифры. ABF сам выставляет значением BUILD_ID внутренний номер сборки. При создании своих сборок вы можете придумать свою систему идентификаторов. Обратите внимание, что BUILD_ID попадает в название образа, которое может быть не длиннее 32 символов. Ищите "FS_LABEL" в коде скрипта сборки. Также BUILD_ID попадает в мета-пакет rosa-iso-info.

PLATFORM

Платформа, на базе которой собирать образ: rosa2021.1, rosa2023.1

DE

Графическое окружение. Значение может быть в любом регистре (маленькими или большими буквами). Возможные варианты см. в каталоге "DEs" в rosa-build-iso. DE=server — вариант без графической оболочки.

Мета-пакет rosa-iso-info

При сборке образа создается RPM-пакет rosa-iso-info, в который попадает информация о данной сборке. Этот пакет устанавливается в образ и сохраняется после установки системы из него. Сборка производится по спеку rosa-iso-info.spec.

В этом пакете в виде и Provides, и файла /var/lib/rosa-iso-info сохраняется следующая информация:

• платформа в виде целого числа (как макрос %{mdvver}), например: 202110
• BUILD_ID
• UNIX-время сборки (кол-во секунд с 01.01.1970)
• DE

Примеры запроса информации из этого пакета:

$ rpm -qi rosa-iso-info
Name        : rosa-iso-info
Version     : 202110
Release     : 43195
DistTag     : rosa2021.1
Architecture: noarch
Install Date: Вс 17 апр 2022 17:57:58
Group       : System/Base
Size        : 61
License     : Public Domain
Signature   : (none)
Source RPM  : rosa-iso-info-202110-43195.src.rpm
Build Date  : Вс 17 апр 2022 15:08:34
Build Host  : 0f8117f279f7
Vendor      : ROSA
Bug URL     : http://bugzilla.rosalinux.ru
Summary     : Information about which ISO image this OS was installed from
Description :
Information about which ISO image this OS was installed from
$ rpm -ql rosa-iso-info
/var/lib/rosa-iso-info
$ cat /var/lib/rosa-iso-info
BUILD_ID=43195
BUILD_TIME=1650197314
DE=xfce
PLATFORM=202110
$ rpm -q rosa-iso-info --provides
rosa-iso-info = 202110-43195
rosa-iso-info(buildid) = 43195
rosa-iso-info(buildtime) = 1650197314
rosa-iso-info(de) = xfce
rosa-iso-info(platform) = 202110

Пример использования в boolean-зависимостях пакетов:

Requires: (foo if rosa-iso-info(buildid) >= 555)

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

Сборка ISO на базе устаревших платформ (rosa2016.1, rosa2014.1)

Если вам хочется собрать собственный 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

Переключитесь на ветку нужной платформы:

git checkout rosa2016.1

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

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 не задана, то она формируется так: REPO="${MIRROR}/${ROSA_PLATFORM}/repository/${ARCH}/"

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

• устанавливает все обновления на хост;
• средствами 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-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.