Свой дистрибутив alt linux

Свой дистрибутив alt linux

Источник: linux.org.ru

Источник: linux.org.ru ALT Linux – это дистрибутив Linux, который обладает большим набором инструментов и возможностей. Возможность создания собственной сборки особенно полезна для пользователей, которые хотят иметь в своем распоряжении операционную систему, полностью адаптированную под их потребности. В данной статье мы рассмотрим процесс создания собственной сборки ALT Linux, основанный на методе ремастеринга.

Установка ALT Linux

Прежде всего, необходимо установить базовую версию ALT Linux на ваш компьютер. Скачайте образ дистрибутива с официального сайта и следуйте инструкциям по установке.

Установка необходимых инструментов для ремастеринга

Для ремастеринга потребуются следующие инструменты: make-initrd, mksquashfs, unsquashfs, genisoimage, isohybrid. Установите их с помощью команды:

sudo apt-get install make-initrd mksquashfs unsquashfs genisoimage isohybrid 

Создание рабочей директории для ремастеринга

Создайте рабочую директорию и скопируйте содержимое установленной системы в нее:

mkdir ~/remaster sudo rsync -a --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/tmp --exclude=/mnt --exclude=/media --exclude=/home / ~/remaster/ 

Настройка и модификация системы

Теперь вы можете внести любые изменения в вашу систему, установить или удалить программы, настроить параметры. Все изменения будут сохранены в директории ~/remaster/.

Создание нового образа системы

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

sudo mksquashfs ~/remaster ~/new_squashfs.img -comp xz 

Замена старого образа системы на новый

Теперь замените старый образ системы на новый:

sudo cp ~/new_squashfs.img /live/filesystem.squashfs 

Создание нового образа ISO

Создайте новый образ ISO с помощью команды:

sudo genisoimage -l -r -J -V "ALT Linux Remastered" -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o ~/ALT_Linux_Remastered.iso /live 

Превращение образа ISO в загрузочный

Сделайте ваш образ ISO загрузочным:

sudo isohybrid ~/ALT_Linux_Remastered.iso 

Тестирование образа

Перед тем как распространять вашу сборку, необходимо убедиться, что все работает как должно. Вы можете проверить это, запустив образ в виртуальной машине с помощью программы, такой как VirtualBox, или записав образ на флеш-накопитель и загрузившись с него на вашем компьютере.

Распространение вашей сборки

Если все работает корректно, вы можете распространить вашу сборку ALT Linux. Вы можете разместить его на своем веб-сайте, поделиться с друзьями или сообществом. Не забудьте предоставить информацию о ваших изменениях и инструкции по установке.

Читайте также:  Типы операционных систем операционные системы linux семейство операционных систем windows

Создание собственной сборки ALT Linux – не только интересный процесс, но и возможность получить систему, которая идеально соответствует вашим потребностям. Данный гид поможет вам освоить базовые навыки ремастеринга и создать свою уникальную сборку ALT Linux. Вперед к открытому и свободному миру Linux!

Источник

Mkimage/Profiles/Desktop

готовим релиз

mkimage-profiles-desktop (кратко m-p-d) — это набор профилей для сборки дистрибутивных образов на пакетной базе ALT Linux при помощи mkimage, представленный как:

  • семейство git-репозиториев, поддерживаемых различными людьми (де-факто «точка сбора» — boyarsh@);
  • пакеты в бранчах и дистрибутивах [1] .

Зачем может пригодиться?

  • релиз-менеджеры (те, кто выпускает дистрибутивы) используют профили, чтобы укомплектовать и собрать из пакетной базы и информации в профиле пригодный к использованию образ — например, инсталятор или LiveFlash;
  • системным администраторам бывает удобно вносить свои небольшие изменения для минимизации действий после типичной установки дистрибутива;
  • нормальным людям может быть удобней собирать образы локально из пакетов на зеркале, чем тащить исошки.

При отсутствии локального зеркала какого-либо бранча или сизифа эксперименты может быть лучше отложить, потому как трафик.

Как собрать дистрибутив?

Если рассматривать штатный для ALT Linux 4.0+ случай с использованием:

  • pam_mktemp и достаточного объёма tmpfs в /tmp[2] ,
  • сконфигурированного в sources.list репозитория [3] (желательно локального или NFS-зеркала),
  • настроенного для текущего пользователя hasher,
mkdir -p ~/git cd ~/git git clone git://git.altlinux.org/people/boyarsh/packages/mkimage-profiles-desktop git checkout p5 autoconf ./configure mkdir /tmp/mkimage-work-dir TMP=/tmp/mkimage-work-dir nice time make rescue.cd

…и через несколько минут или полчасика при отсутствии неожиданностей образ будет готов. Список целей make можно посмотреть в Makefile.in ; некоторые примеры:

make . получаем проверено (на репо [4] )
rescue.cd маленький спасательный LiveCD 20100315 mike (5.1/i586)
live.cd большой самостоятельный LiveCD с KDE 20100315 mike (5.1/x86_64)
gnome.dvd инсталяционный образ с GNOME 20100315 mike (p5/x86_64)
minimal.cd небольшой инсталяционный образ с IceWM 20100315 mike (Sisyphus/x86_64)
school-terminal.dvd школьный терминальный сервер 20100315 mike (p5/i586)

а свой как?

Читайте дальше по порядку. Только это уже для терпеливых.

Концепция

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

Реализация

дистрибутив

Итоговый образ может включать:

  • средства начальной загрузки образа (stage1);
  • инсталятор (install2) и/или LiveCD (live);
  • пакетную базу (main, contrib);
  • иное (например, rescue).

Таким компонентам соответствуют субпрофили (profiles/*).

компоненты

Создаются при сборке субпрофилей, которые:

  • описывают соответствующие им базовые наборы списков пакетов и необходимые действия;
  • могут конфигурироваться сообразно требованиям к дистрибутиву;
  • могут содержать дополнительные скрипты, отрабатывающие при формировании соответствующего компонента.
Читайте также:  Linux mint nvidia driver install

особенности

Поскольку различные образы (например, инсталяционные) могут иметь одни и те же предопределённые наборы принципиальных компонент (например, stage1+install2+main), но существенно отличаться в их итоговом наполнении — предусмотрен механизм для конфигурирования путём накопления необходимых значений переменных во включаемых makefile, реализованный блоками настроек use-* в use.mk.

Дистрибутивообразующие данные «протекают» сверху вниз следующим образом:

  1. умолчания: заложены разработчиком профиля на всех уровнях;
  2. опции configure: заданы пользователем (релиз-менеджером);
  3. Makefile: соответствие «дистрибутив-блоки», в том числе выбор субпрофилей;
  4. use.mk: конфигурирование блоков;
  5. profiles/*: задействование созданной конфигурации;
  6. profiles/*/*scripts.d/*: нижний уровень, при возможности (и отсутствии конфигурируемости) «выселяется» в installer-feature-*.

Ознакомление

Загляните в README m-p-d; хотя бы вкратце ознакомьтесь с README.ru mkimage, куда стоит обращаться за описанием используемых в субпрофильных makefile переменных и целей сборки.

Изучение существующих примеров удобней начинать с корневого Makefile.in и далее по profiles/*/Makefile.in и profiles/pkg/lists/*. Стоит иметь в виду, что IMAGE_PACKAGES может содержать как пути ко включаемым файлам со списками имён пакетов, так и сами имена пакетов.

Практика

m-p-d из профиля для сборки десктопного дистрибутива превратился в комбайн с вертикальным взлётом, позволяющий создавать широкий спектр образов и довольно неплохо масштабируемый по разработке.

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

Поэтому при добавлении use-блоков или profiles/pkg/lists/* следует по возможности изучить и повторно использовать уже существующие (в этом может помочь bin/pkgdups.sh). Также в промежутках между релизами стоит находить время и уделять внимание рефакторингу инфраструктуры; соображения по ортогонализации профиля и наследованию дистрибутивообразующих переменных можно почитать здесь.

Модификация

используя уже существующее

Если создаётся вариация на тему уже существующего вида — например, десктопный инсталер — может оказаться достаточным скомбинировать уже существующие цели use-* из подключаемой библиотеки use.mk.in в одной строчке, добавленной в корневой Makefile.in . Например, так можно добавить rescue к понравившемуся дистрибутиву, собранному без него.

В частности, как подправить список пакетов:

  • совсем «крупноблочно» — в Makefile.in для нужной цели
  • более тонко — в use.mk.in
  • совсем тонко — в profiles/pkg/lists/* , используемых для сборки желаемого образа

Выяснить точный список попадающих в дистрибутив списков бывает неудобно (приходится изучать сгенерированные stage-autocfg.mk в субпрофилях); также рекомендуется сохранять лог сборки с VERBOSE=1, чтоб иметь возможность анализировать состав.

Читайте также:  Mysql to excel linux

с добавлением новых блоков

Например, потребовался ещё не описанный десктопный инсталер с LXDE; для подготовки к его сборке может оказаться достаточным:

  1. создать список пакетов (например, profiles/pkg/lists/lxde);
  2. добавить строчку с описанием дистрибутива в корневой Makefile.in:
lxde.cd: | use-lxde use-xdm install2 main install-cd.@IMAGETYPE@

При этом необязательно явно описывать «мостик» между именем списка пакетов (lxde) и промежуточной целью (use-lxde) в подключаемой библиотеке use.mk: тривиальные случаи обрабатываются шаблоном use-%, который вносит «прилетевшее» имя в списки для субпрофилей main и live в предположении, что это название пакаджлиста — тем самым обеспечивая его «подхватывание» при сборке как образа дистрибутива для инсталяции, так и LiveCD.

синхронизация

Дистрибутивы — штука сложная. В одиночку их делать можно, но довольно тяжело. Поэтому лучше пользоваться уже существующими наработками: даже если на их освоение придётся потратить некоторое время, их переизобретение также не дастся даром. Также хорошо стараться делать правки так, чтобы не понижать универсальность профиля, не исходя из предположения «да мне только под свой дистрибутив заточить»: внесение наработок в апстрим может помочь снизить затраты времени на поддержание своей ветки.

Обсуждение масштабных переработок профилей релиз-менеджерами производится в рассылке devel-distro@ [5] . Обратите внимание на то, что хотя бы кратенько анонсировать предполагаемые изменения лучше до их реализации, чтобы иметь возможность получить их оценку другими участниками и

  • избежать непредвиденных последствий;
  • доставить другим минимум неудобств при втягивании изменений.

Разумеется, для удобного отсмотра изменений и обмена ими стоит использовать git и аккуратно оформлять коммиты.

Ссылки

  • mkimage
  • бранчи
  • инсталятор
  • компоненты инсталятора
  • устаревшая ветка этой страницы
  • пошаговые инструкции
  • Небольшая инструкция по самостоятельной сборке дистрибутивов на базе бранча 5.1
  • Пример сборки своего LiveCD (документ .odt)
  • «Введение в сборку дистрибутивов»
  • Иллюстрация к спискам пакетов(несколько устаревшая, читать profiles/pkg/lists/ и profiles/pkg/groups/)
  • про pkg/groups и alterator-pkg

Примечания

  1. ↑ если нет цели посмотреть именно дистрибутивный профиль, лучше сразу в git
  2. ↑ текущая версия mkimage (проверено на 0.1.3) умеет делать workdir’ы на tmpfs вне каталога профиля, но всё-таки лучше собирать из отдельной копии во избежание случайных коммитов мусора (подставленных autoconf .in-файлов, не добавленных в .gitignore, и т. п.).
  3. ↑ mkimage используется начиная с 4.0/branch и до Sisyphus; со старыми ветками — M40, M41 — и соответствующими профилями возможны старые грабли
  4. ↑ Сборка на Sisyphus обычно из бранча master профиля, на 5.1/branch либо p5/branch — p5.
  5. ↑ подписывает mike@ по запросу

Источник

Оцените статью
Adblock
detector