Локальная сборка ISO
Содержание
- 1 Локальная сборка ISO
- 1.1 Введение
- 1.2 Подготовка рабочего окружения
- 1.3 Этапы сборки ISO
- 1.4 Формирование конфига сборки образа
- 1.5 Параметры скрипта сборки
- 1.5.1 ABF
- 1.5.2 RESULTS_DIR
- 1.5.3 BUILD_ID
- 1.5.4 PLATFORM
- 1.5.5 DE
- 1.5.6 ARCH
- 1.5.7 FILTER_PACKAGES
- 1.5.8 ADD_PACKAGES
- 1.5.9 ADD_REPOS
- 1.5.10 ADD_REPOS_INTO_ISO
- 1.5.11 ENABLE_CONTRIB_REPOS
- 1.5.12 ENABLE_TESTING_REPOS
- 1.5.13 DISABLE_STANDARD_REPOS
- 1.5.14 BRANDING
- 1.5.15 DISTROSYNC
- 1.5.16 CLEANUP
- 1.5.17 CUSTOMIZATION_FEATURES
- 1.5.18 LIVECD_CREATOR_EXTRA_ARGS
- 1.5.19 LIVECD_CREATOR_COMPRESSION
- 1.5.20 STRACE
- 1.5.21 SLEEP
- 1.5.22 TMPFS
- 1.5.23 FORCE_C_LOCALE
- 1.5.24 DNF_IN_OPTS
- 1.5.25 TMPFS_SIZE
- 1.5.26 FORCE_RECOMMENDS
- 1.6 Мета-пакет rosa-iso-info
- 1.7 Customization features
- 1.8 Сборка ISO на базе устаревших платформ (rosa2016.1, rosa2014.1)
Локальная сборка 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-образа.
Для сборки необходимо следующее окружение:
- ОС на базе платформы 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 DISTROSYNC=0 ./build-iso-abf.sh
Обратите внимание, что, если вы находитесь в не-root консоли и установите относящиеся к скрипту сборки переменные окружения через export VAR=value, то они не попадут в скрипт. При запуске приведенном выше способом — указании всех параметров после слова "sudo" — попадут.
Этапы сборки ISO
- начало работы скрипта сборки
- установка программы livecd-tools и других необходимых для работы пакетов
- подготовка конфигурационных файлов для livecd-tools (см. раздел "Формирование конфига сборки образа")
- запуск программы livecd-creator из пакета livecd-tools, которая в свою очередь выполняет следующие действия:
- запуск, обработка конфигурации
- создание RPM-пакета rosa-iso-info с мета-информацией об образе
- выполнение %pre-скриптов, при их наличии (по умолчанию их нет)
- создание образа файловой системы ext4
- создание 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
- запаковка образа ext4 в squashfs (в будущем, возможно, будет сразу в squashfs)
- создание конфигурационного файла загрузчика Grub2
- копирование загрузчиков (shim, grub2)
- запаковка ISO-образа
- перемещение собранного ISO-образа в заданный каталог
- завершение работы скрипты сборки
Установка ОС производится программой установки Anaconda путем rsync содержимого squashfs и удаления лишнего (например, самой Anaconda).
Формирование конфига сборки образа
Программа livecd-creator из пакета livecd-tools на вход получает файл в формате kickstart, в котором заданы все настройки сборки образа, пакеты и выполняемые до и после сборки скрипты.
Скрипт build-iso-abf.sh подставляет значения @переменных@ в файл template.ks. Изменения в файлы в текущем рабочем каталоге не вносятся, создается копия всех файлов, что позволяет удобно работать с git.
Из каталога packages/ берется файл pkgs-$DE.ks со списком пакетов.
Из каталога repos/ берется файл repos-$ARCH.ks со списком используемых для сборки образа репозиториев (источников).
Из файла DEs/$DE/head.ks берутся такие настройки сборки образа, как размер squashfs, часовой пояс, язык и раскладка клавиатуры по умолчанию и др.
Из файла DEs/$DE/post.ks берутся скрипты, которые запускаются внутри chroot после установки пакетов.
Параметры скрипта сборки
Все параметры скрипта сборки передаются переменными окружения. Если какой-либо параметр не задан, то используется его значение по умолчанию. Рекомендуется ознакомиться с кодом 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 — вариант без графической оболочки.
ARCH
Целевая архитектура. Значение по умолчанию: x86_64. Возможные значения:
- x86_64
- i686
- aarch64
- e2kv4
- riscv64
На архитектуре x86_64 возможна сборка образов под x86_64 и i686. В остальных случаях для сборки под иную, чем хостовые железо и ОС, архитектуры, можно использовать qemu и binfmt путем установки пакета qemu-*-static, который автоматически настроит binfmt. При использовании qemu возможны проблемы с монтированием loop-устройств.
FILTER_PACKAGES
Исключить перечисленные через пробел пакеты из образа, если они прописаны в списке пакетов или попадают по зависимостям. Примеры:
- FILTER_PACKAGES=foo — исключить пакет foo
- FILTER_PACKAGES="foo boo" — исключить пакеты foo и boo
ADD_PACKAGES
Добавить дополнительные, перечисленные через пробел пакеты. Примеры:
- ADD_PACKAGES=foo — добавить пакет foo
- ADD_PACKAGES="foo boo" — добавить пакеты foo и boo
ADD_REPOS
Добавить дополнительные репозитории в качестве источников для попадающих в образ пакетов (обратите внимание, что внутри ОС репозитории прописаны в пакете rosa-repos и не связаны с использованными для сборки образа репозиториями).
Добавляемые репозитории перечисляются через пробел.
Возможные варианты:
- ADD_REPOS=555444 — добавить контейнер из сборочного листа http://abf.io/build_lists/555444. Путь к контейнеру будет получен по API (должна быть установлена переменная API_TOKEN). Также будут автоматически добавлены контейнеры из сборочных листов, которые были подключены как дополнительные сборки в заданном сборочном листе, что позволяет указать лишь номер последнего контейнера в длинной цепочке.
- ADD_REPOS="-555444" — аналогично, но не добавляя контейнеры зависимостей сборочного листа.
- ADD_REPOS="555444 555445" — добавить контейнеры из сборочных листов 555444 и 555445 с разрешением зависимостей.
- ADD_REPOS="555444 -555445" — добавить контейнеры из сборочного листа 555444 с разрешением зависимостей и из 555445 без него.
- ADD_REPOS="+555,401,402,403" — добавить контейнеры из сборочных листов 555401, 555402, 555403 с разрешением их зависимостей.
- ADD_REPOS="+-555,401,402,403" — добавить контейнеры из сборочных листов 555401, 555402, 555403 без разрешения их зависимостей.
- ADD_REPOS="%username" — добавить репозиторий
https://abf-downloads.rosalinux.ru/%username_personal/repository/$PLATFORM/$ARCH/main/release/
- ADD_REPOS="http://vasya.ru/repo" — добавить репозиторий по URL.
- ADD_REPOS="/mnt/repo/x" — добавить локальный репозиторий по указанному пути.
ADD_REPOS_INTO_ISO
- ADD_REPOS_INTO_ISO=1 — добавить перечисленные в ADD_REPOS дополнительные репозитории в /etc/yum.repos.d/* результирующего образа
- ADD_REPOS_INTO_ISO=0 (по умолчанию) — не добавлять
ENABLE_CONTRIB_REPOS
- ENABLE_CONTRIB_REPOS=1 (по умолчанию) — подключить репозиторий contrib в качестве источника для сборки образа
- ENABLE_CONTRIB_REPOS=0 — не подключать.
ENABLE_TESTING_REPOS
- ENABLE_TESTING_REPOS=1 — подключить testing-подрепозитории в качестве источников для сборки образа
- ENABLE_TESTING_REPOS=0 (по умолчанию) — не подключать.
DISABLE_STANDARD_REPOS
- DISABLE_STANDARD_REPOS=1 — убрать все стандартные источники для сборки образа и тем самым использовать только заданные через ADD_REPOS (актуально при сборке с использованием локального зеркала репозитория)
- DISABLE_STANDARD_REPOS=0 (по умолчанию) — не делать этого.
BRANDING
Какой брендинг (файл /etc/os-release и пр.) использовать. Значение по умолчанию: fresh. Допустимо значение "chrome" или иное при наличии соответствующего пакета в подключенных источниках.
DISTROSYNC
Выполнять ли dnf distro-sync в хостовой ОС перед началом сборки.
- DISTROSYNC=1 (по умолчанию) — выполнять
- DISTROSYNC=0 — не выполнять.
Рекомендуется установить DISTROSYNC=0 при запуске на рабочем компьютере.
CLEANUP
- CLEANUP=1 (по умолчанию) — удалить временные каталоги по окончанию работы
- CLEANUP=0 — не удалять (для отладки).
CUSTOMIZATION_FEATURES
Перечисленные через пробел customization/features/* для подключения. Примеры:
- CUSTOMIZATION_FEATURES="samba-ad"
- CUSTOMIZATION_FEATURES="samba-ad ssh-server"
LIVECD_CREATOR_EXTRA_ARGS
Дополнительные параметры livecd-creator. Например, можно указать путь к кешу, чтобы при повторных сборках образа не скачивать пакеты заново:
LIVECD_CREATOR_EXTRA_ARGS="--cache=/var/tmp/livecd-creator-cache"
Из каталога кеша можно удалять только относящиеся к конкретному репозиторию файлы, чтобы при следующем запуске они были скачаны заново вместе с новыми метаданными репозитория, а файлы из остальных репозиториев не скачивались заново.
Сборка образа с таблицей разделов gpt2 ("uefi"):
LIVECD_CREATOR_EXTRA_ARGS="--isotype=gpt2"
Сборка образа с таблицей разделов mbr2 (по умолчанию):
LIVECD_CREATOR_EXTRA_ARGS="--isotype=mbr2"
LIVECD_CREATOR_COMPRESSION
Сжатие squashfs (см. раздел "Этапы сборки ISO"). По умолчанию используется zstd, что позволяет достичь оптимальный баланс между размером образа, скоростью запуска и установки ОС в LiveCD и скоростью сборки образа. Можно установить LIVECD_CREATOR_COMPRESSION=xz для уменьшения размера образа.
STRACE
- STRACE=1 — запустить livecd-creator и все скриптлеты устанавливаемых пакетов под strace
- STRACE=0 (по умолчанию) — не использовать strace.
SLEEP
Количество секунд задержки сразу после запуска скрипта. По умолчанию 0.
TMPFS
- TMPFS=1 — создавать tmpfs и запускать сборку в ней
- TMPFS=0 (по умолчанию) — не делать tmpfs.
FORCE_C_LOCALE
- FORCE_C_LOCALE=1 (по умолчанию) — выставить C-локаль, чтобы скриптлеты пакетов выполнялись с нею в процессе работы
- FORCE_C_LOCALE=0 — не делать этого.
DNF_IN_OPTS
Дополнительные параметры запуска dnf при установке утилит для сборки образа в хостовую ОС. Позволяет, например, указать дополнительный репозиторий с обновлением livecd-tools. Пример:
DNF_IN_OPTS="--nogpgcheck --repofrompath abf-user,http://abf-downloads.rosalinux.ru/abf-user_personal/repository/rosa2021.1/x86_64/main/release/"
TMPFS_SIZE
Размер tmpfs. По умолчанию 30 ГБ. Актуально только при TMPFS=1.
FORCE_RECOMMENDS
- FORCE_RECOMMENDS=1 — сделать обязательной добавку в образ пакетов Recommends из task-iso-* и зависимых task-*
- FORCE_RECOMMENDS=0 (по умолчанию) — не делать этого.
Мета-пакет 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 $ . /var/lib/rosa-iso-info && echo $DE xfce $ 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)
Данный пакет отсутствует в репозитории, а значит не будет обновляться, что позволяет сохранять и получать информацию именно о том образе, с которого была поставлена система.
Customization features
О c/f
В каталоге customizations/features можно создавать набор инструкций с дополнительными изменениями в образе. Для краткости будем называть их c/f.
Структура каталога customizations/features/xxx (все перечисленные файлы необязательны):
- packages.ks — какие пакеты добавить или убрать (пакеты, которые убрать относительно $DE, пишутся с минусом перед названием) (если этого файла нет, то не страшно, изменения в пакеты не будут внесены, аналогично для остальных файлов)
- post.ks — какие скрипты выполнить после установки пакетов в chroot (и после DEs/$DE/post.ks, см. template.ks)
- post-nochroot.ks — какие скрипты выполнить после установки пакетов вне сhroot
- head.ks — переназначить DEs/$DE/head.ks (см. раздел "Формирование конфига сборки образа")
- deps — какие другие c/f автоматически подключить при использовании этой c/f
- другие файлы — можно положить любые другие файлы и обращаться к ним из post.ks, post-nochroot.ks; путь к ним будет таким: features/xxx/файл.
Ниже описаны имеющиеся c/f, однако актуальность документации не гарантируется, смотрите код.
ad-client-sssd
Автоматически ввести LiveCD в домен AD с использованием sssd. Пример сценария использования:
- собрать ISO с c/f samba-ad
- собрать ISO с c/f ad-client-sssd
- запустить оба LiveCD
- без установки системы в первом автоматически поднимется контроллер домена
- второй можно ввести в домен
auto-kickstart
Автоматически установить систему по kistart-файлу (см. статью Anaconda).
empty-root-password
Сделать пароль root в LiveCD пустым.
freeipa
Автоматически запускающийся в LiveCD контроллер домена FreeIPA.
iso-builder
Включить в образ необходимые для запуска этих скриптов пакеты.
mini-vm
Собрать образ без инсталлятора Anaconda, linux-firmware и лишних локалей.
samba-ad
Автоматически запускающийся в LiveCD контроллер домена Samba AD. Использует встроенный в Samba DNS-сервер.
samba-ad-bind
Автоматически запускающийся в LiveCD контроллер домена Samba AD. Использует DNS-сервер bind.
sddm
Сборка образа с SDDM вместо GDM (недоделано).
small-grub-timeout
Уменьшить таймауты в пунктах меню Grub в LiveCD с 10 сек до 1 сек, чтобы LiveCD запускался быстрее.
ssh-server
- Создается пара ключей SSH: публичный и приватный ключи
- Публичный встраивается в /root/.ssh/authorized_keys LiveCD
- Создаются хостовые ключи ssh /etc/ssh/ssh_host_*, чтобы при каждом запуске LiveCD они не менялись и тем самым не менялся отпечаток на ssh-клиенте
- добавляется пакет openssh-server
- включается автозапуск службы sshd
- созданные ключи сохраняются в каталог для результатов сборки рядом с ISO-образом
- sshkey.pub — публичный ключ
- sshkey — приватный ключ
Пример использования приватного ключа:
ssh -i sshkey root@ip
tablet
Оптимизация и хаки для лучшей работы на планшетах (тачскринах).
Сборка 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-скрипты, выполняющие финальную настройку и доводку системы, установленной в образе.