Mkimage-profiles — гибкий инструмент сборки дистрибутивов для множества платформ (Антон Мидюков, OSSDEVCONF-2019)

Короткая ссылка: 20190828E

Докладчик: Антон Мидюков

Необходимость сборки дистрибутивов для множества платформ стала вызовом для mkimage-profiles.

С какими трудностями пришлось столкнуться при создании универсальных профилей дистрибутивов для нескольких архитектур?

Как эти трудности были преодолены?

Как адаптировать старый профиль под новые реалии?

В докладе будут даны ответы на эти и другие немаловажные вопросы.

Видео

on youtube

Презентация

Thesis

Почему возникли проблемы?

mkimage-profiles изначально был ориентирован на сборку дистрибутивов для PC.

При этом предполагались следующие типы целей:

distro — образы дисков iso с загрузчиком syslinux:
1. Установочный дистрибутив installer;
2. Живые диски live с возможностью установки и без;
3. Два в одном: install + live;
ve/ — виртуальные окружения без ядра и загрузчика, запакованные в архивы tar, tar.gz, tar.xz;
vm/ — образы виртуальных машин: img, qcow2, vdi и т. д.

Изначально заложенных вариантов оказалось недостаточно.

При портировании профилей на новые платформы встали следующие задачи:

Необходимость упаковки архивов с ядром и загрузчиком, что в свою очередь заставило решать следующие задачи:
1. Необходимо было вынести из tar2fs сборку initrd и подготовку конфига загрузчика;
2. Принять решение порождать ли новый тип целей или расширить возможности одной из существующих: ve/ или vm/;
Использование специфичных загрузчиков для каждого устройства поставило вопрос, а как их всех охватить, сделав лишь одну сборку?
Для distro/ встала проблема перехода с syslinux на grub и его вариации;
В связи с необходимостью выпуска почти идентичных сборок не только в формате iso, но и в формате архивов и образов виртуальных машин, необходимо было выделить общую часть для них у каждой сборки;
Необходимо было также учесть доступность пакетов в списках для каждой поддерживаемой платформы.

Непростые решения

Наиболее сложным решением был выбор: порождать ли новый тип целей или расширить возможности одной из существующих. Было последовательно опробовано три варианта:

Использовать тип целей ve/ для упаковки архивов с ядром и загрузчиком. По началу выбор казался очевидным. Но вскоре стало ясно, что это создаёт некоторые неудобства. Как делать make-initrd? В отдельной feature под устройство? Так сначала и делалось, но это было неправильно, так как необходимо по максимуму выделять общее и сводить к нулю копипаст.
Создать новый тип целей mr/ (mashine rootfs), в которых бы явно проверялось наличие ядра, делался make-initrd. Но вскоре стало ясно, что mr/ есть не что иное, как vm/, но в виде тарбола, а потому был опробован третий вариант.
Адаптировать vm/, чтобы можно было создавать ещё и тарболы, а не только образы. Это позволило сократить число целей в два раза, что сильно упростило жизнь для случая регулярных сборок и стартеркитов. Вот его и выбрали. Хотя это тоже спорное решение, так как не всегда состав архива файловой системы для одноплатного компьютера должен быть по составу такой же, как и образ для qemu. Но это решается использованием проверочного условия для $(IMAGE_TYPE):

   ifeq (,\$(filter-out qcow2 qcow2c,\$(IMAGE\_TYPE)))
   …
   endif

Остальные решения были просты и не мучительны.

Всё общее в сборках постепенно выделялось в отдельный конфиг mixin.mk. Изначально предполагалось, что цели mixin/ не должны зависеть друг от друга, но это предубеждение удалось преодолеть. И теперь эти цели можно рассматривать как кубики для получения почти одинаковых по составу сборок всех типов: distro/ ve/ vm/.

Ответ на вопрос, как сделать так, чтобы одну сборку можно было использовать для множества устройств, оказался прост. Необходимо переложить все специфические действия на пользователя. Для того, чтобы пользователю это не было делать обременительно, был написан скрипт alt-rootfs-installer. alt-rootfs-installer постепенно обрастает функционалом и скоро начнёт претендовать на место tar2fs.

Перевод сборок iso на grub осуществлён для aarch64 и ppc64le. Потребовалась правка mkimage, но это уже другая история. Предстоит ещё создание аналога feature syslinux для генерации конфига grub.

Как адаптировать старый профиль под новые реалии?

Теперь это сделать достаточно просто:

Выносим из профиля цели mixin/ с независимым от типа цели содержимым;
Специфичное для платформы огораживаем условиями например так:
```
    ifeq (,\$(filter-out aarch64 armh,\$(ARCH)))

    …

    endif
```
Проходим по спискам пакетов и отмечаем архитектурно-зависимые пакеты указанием через знак «@» архитектуры, для которой он предназначен:

grub-pc@X86

grub-efi@X86

grub-efi@aarch64

grub-ieee1275@ppc64le
Создаём новые цели со спецификой для типа цели: vm/ или ve/

Итого: в mkimage-profiles появилась возможность делать почти одинаковые по составу сборки iso, tar, img и т. д. для нескольких архитектур.

Примечания и ссылки

Plays:31 Comments:6