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

Материал из Rosalab Wiki
Перейти к: навигация, поиск
(Обновление после множества правок скриптов сборки)
Строка 15: Строка 15:
 
   
 
   
 
  git clone https://foo:bar@abf.io/soft/build_plasma5_desktop_ee.git
 
  git clone https://foo:bar@abf.io/soft/build_plasma5_desktop_ee.git
 
Создадим папку, в которой будут храниться результирующие образы и некоторые логи (к сожалению, сейчас нельзя задать иной путь к этой папке, если не хотите ее создавать, попробуйте mount --bind):
 
 
sudo mkdir -p /home/vagrant/results
 
  
 
Переведем терминал в директорию со скачанными скриптами:
 
Переведем терминал в директорию со скачанными скриптами:
Строка 28: Строка 24:
 
  sudo env TYPES="64u" DE=kde4 RELEASE=R11 BUILD_ID=20001 ./MATRIX
 
  sudo env TYPES="64u" DE=kde4 RELEASE=R11 BUILD_ID=20001 ./MATRIX
  
Обратите внимание, что при запуске скрипта MATRIX терминал должен быть именно в той директории, в которой лежит скрипт MATRIX. В корне этой директории будет создана директория "ROSA.DESKTOP.$RELEASE", которая будет использоваться для раскатывания базового chroot, внутри которого будет запущена сборка с помощью [https://abf.io/import/livecd-tools livecd-tools], который сделает еще один чрут внутри существующего чрута. В общем, нужно достаточное количество свободного места.
+
Обратите внимание, что при запуске скрипта MATRIX терминал должен быть именно в той директории, в которой лежит скрипт MATRIX. В корне этой директории будет создана директория "ROSA.DESKTOP.$RELEASE", которая будет использоваться для раскатывания базового chroot, внутри которого будет запущена сборка с помощью [https://abf.io/import/livecd-tools livecd-tools], который сделает еще один чрут внутри существующего чрута. В общем, нужно достаточное количество свободного места. Результирующий образ будет в папке results/, если не задано иное (см. ниже).
  
Скрипт MATRIX запускается с `set -e`, из-за чего он завершит свою работу при ошибке на любой промежуточной операции, что упрощает отладку, но может создать некоторые проблемы при сборке в нестандартном окружении. Стандартным условно считаем то, что на ABF.
+
Скрипт MATRIX запускается с set -e, из-за чего он завершит свою работу при ошибке на любой промежуточной операции, что упрощает отладку, но может создать некоторые проблемы при сборке в нестандартном окружении. Стандартным условно считаем то, что на ABF.
  
 
Смысл переменных окружения (параметров сборки):
 
Смысл переменных окружения (параметров сборки):
 +
* RESULTS_DIR: директория, куда сохранять результирующие образы и логи; по умолчанию создается папка results в текущей директории;
 
* TYPES: список типов образов, которые будут собираться (возможные варианты: 32, 32u, 64, 64u — соответственно, 32- и 64-битные образы с поддержкой UEFI или без оной); на данный момент можно собирать только один тип за раз, пример: TYPES=64u
 
* TYPES: список типов образов, которые будут собираться (возможные варианты: 32, 32u, 64, 64u — соответственно, 32- и 64-битные образы с поддержкой UEFI или без оной); на данный момент можно собирать только один тип за раз, пример: TYPES=64u
 
* DE: суффикс у файла со списком пакетов, обычно, соответствующий графическому окружению (например, для DE=kde4 будут использоваться файлы commonkde4.lst, i586kde4.lst, x86_64kde4.lst), также $DE войдет в имя файла результирующего образа;
 
* DE: суффикс у файла со списком пакетов, обычно, соответствующий графическому окружению (например, для DE=kde4 будут использоваться файлы commonkde4.lst, i586kde4.lst, x86_64kde4.lst), также $DE войдет в имя файла результирующего образа;
Строка 47: Строка 44:
 
* в созданном chroot запускает [https://abf.io/import/livecd-tools livecd-tools], который собирает образ по .ks.template;
 
* в созданном chroot запускает [https://abf.io/import/livecd-tools livecd-tools], который собирает образ по .ks.template;
 
* в результирующий образ добавляется mirror.rosalab.ru в качестве единственного репозитория (то есть сначала собирается образ с тем репозиторием, который вы задали, а потом добавляется другой, без гарантии, что содержимое этих репозиториев одинаковое);
 
* в результирующий образ добавляется mirror.rosalab.ru в качестве единственного репозитория (то есть сначала собирается образ с тем репозиторием, который вы задали, а потом добавляется другой, без гарантии, что содержимое этих репозиториев одинаковое);
* копирует результирующий образ и логи в /home/vagrant/results/.
+
* копирует результирующий образ и логи в $RESULTS_DIR (results/).
  
 
Если нужно внести какие-то свои изменения, то потребуется править файлы:
 
Если нужно внести какие-то свои изменения, то потребуется править файлы:
* commonkde4.lst, i586kde4.lst, x86_64kde4.lst: списки устанавливаемых в образ пакетов (общий список и, при необходимости, архитектуро-зависимые; вместо «kde4» нужно подставить значение переменной DE);
+
* commonplasma5.lst, i586plasma5.lst, x86_64kplasma5.lst: списки устанавливаемых в образ пакетов (общий список и, при необходимости, архитектуро-зависимые; вместо «plasma5» нужно подставить значение переменной DE);
 
* i586repo.lst, x86_64repo.lst: дополнительные репозитории или контейнеры (например, если надо собрать образ с тестовой версией пакета, отсутствующей в основном репозитории) (эти контейнеры используются при сборке образа, но НЕ добавляются в качестве репозиториев в результирующий образ!);
 
* i586repo.lst, x86_64repo.lst: дополнительные репозитории или контейнеры (например, если надо собрать образ с тестовой версией пакета, отсутствующей в основном репозитории) (эти контейнеры используются при сборке образа, но НЕ добавляются в качестве репозиториев в результирующий образ!);
 
* каталог extraconfig: может использоваться для прямого подкладывания или замены файлов в файловой системе образа (кажется, функционал его копирования поломан);
 
* каталог extraconfig: может использоваться для прямого подкладывания или замены файлов в файловой системе образа (кажется, функционал его копирования поломан);
 
* .ks.template: шаблон Kickstart-файла, используемого для сборки; включает в себя в числе прочего post-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.
 
* .ks.template: шаблон Kickstart-файла, используемого для сборки; включает в себя в числе прочего post-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.

Версия 11:32, 4 марта 2019

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

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

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

В каждом репозитории могут быть несколько веток. Основная ветка имеет имя актуальной платформы (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=kde4 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-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.