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

Материал из Rosalab Wiki
Версия от 15:35, 7 марта 2024; Ilfat (обсуждение | вклад) (Import your own ssh public keys into the image)

Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Локальная сборка 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"

Из каталога кеша можно удалять только относящиеся к конкретному репозиторию файлы, чтобы при следующем запуске они были скачаны заново вместе с новыми метаданными репозитория, а файлы из остальных репозиториев не скачивались заново. Также можно удалить конкретные rpm из кеша, тогда они будут скачаны заново, актуальной версии.

Сборка образа с таблицей разделов 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

Включить в образ необходимые для запуска этих скриптов пакеты.

gdm

Сборка образа с GDM вместо SDDM.

mini-vm

Собрать образ без инсталлятора Anaconda, linux-firmware и лишних локалей.

mini-locales

Собрать образ без task-locales, т.е. без установки множества пакетов locales-* (лишние удаляются Анакондой после установки ОС), но с locales-en и locales-ru.

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

Кроме того, есть возможность импортировать свои публичные SSH ключи. Для этого нужно создать файл authorized_keys, в каталоге ./customizations/features/ssh-server (от корня проекта), и записать их в этот файл по одному ключу на строку.

tablet

Оптимизация и хаки для лучшей работы на планшетах (тачскринах).

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

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

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

Особых требований к системе, на которой запускается сборка, нет, единственное, что мешает ее запускать на дистрибутивах 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

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

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