Создание собственного профиля инсталлятора
Cтруктурa
Набор ПО для установки системы делится на две части: стартовая система и собственно инсталлятор, с которым в основном пользователь и работает.
Стартовая система запускается при помощи аппаратно реализованных низкоуровневых протоколов (протокол загрузки с CD/DVD, PXE для загрузки через сеть).
В силу больших ограничений на занимаемое место, единственная её задача:
запустить ядро, найти (при необходимости получить из сети) и запустить инсталлятор.
В целях уменьшения размера специализированной среды, внутри которой работает инсталлятор, часть работы инсталлятор проводит уже внутри установленной системы.
Параметры командной строки
Инсталлятор принимает следующие параметры:
- xdriver – графический инсталлятор предпринимает попытку автоматического подбора драйвера видеокарты, но иногда это ему не удаётся. Данным параметром, можно отключить «искуственный интеллект».
- instdebug – если будет присутсвовать этот параметр, то до и после инсталлятора будет запущена оболочка shell. Очень полезное средство, когда требуется выяснить почему инсталлятор не запускается. Вообще последовательность работы внутренних скриптов следующая: install2 -> xinit -> alterator-install2 -> “alterator-wizard”. При необходимости, можно вручную загрузить xorg (команда xinit), и в открывшемся окне терминала запустить alterator-install2 (или alterator-wizard) вручную.
Отладочная информация
В ходе работы инсталлятора на одной из виртуальных консолей доступна оболочка shell для отладки (на остальных консолях можно при этом наблюдать сообщения от различных работающих подсистем).
Инсталлятор создаёт несколько файлов журнала и в случае возникновения каких-либо проблем эти файлы можно отослать разработчикам для «разбора полётов» и выяснения причин отказа.
Во время работы инсталлятора эти журналы размещаются в /tmp, в установленную систему они копируются в /root/.install-log.
Возможно изучение следующих журналов:
- install2.log – стандартный вывод (stdout, stderr) от инсталлятора. Тут можно обнаружить полезные сообщения, если инсталлятор вдруг не запустился или «свалился» на пол-пути.
- basesystem.log – стандартный вывод (stdout,stderr) от процесса установки базовой системы. Здесь наблюдаются все ошибки в устанавливаемых пакетах, в частности немаловажным является изучение порядка установки.
- wizard.log – отладочная информация от alterator. Здесь записаны все команды пролетавшие по его внутренней шине. Полезно для уточнения причин отказа того или иного шага. Будьте осторожны, информация здесь хранится в необработанном виде, в том числе хранятся и ввёденные пароли.
Типичный сценарий работы инсталлятора
- Выбор языка и клавиатуры – по некоторому алгоритму выбирается язык на котором будет происходить установка системы и её работа. Вместе с языком надо бы выбрать и раскладку клавиатуры, ибо не у всех народов мира она QWERTY. (см. тж. #6781)
- Настройка даты и времени – чтобы вся дальнейшая установка отработала корректно, необходимо убедиться, что на машине правильно установлены часы
- Подготовка целевого устройства – создание разделов, настройка точек монтирования
- Установка базовой системы – фактически базовая система — это система, достаточная для того чтобы всю оставшуюся работу инсталлятора проводить в ней. В частности, в базовую систему устанавливаются модули инсталлятора, которые будут запущены чуть позже.
- Перенос настроек в установленную систему – часть данных введённых пользователем ранее осталась в среде инсталлятора, необходимо их донести до новой системы. Также на этом этапе выгружаются из памяти большая часть предыдущих модулей и инсталлятор переходит (chroot) к работе из новой системы.
- Дополнительные настройки – дальнейший тюнинг системы: установка дополнительных пакетов, настройка сети, задание пароля для администратора системы, создание первого пользователя, и так далее и тому подобное... Все запускаемые модули должны быть предварительно установлены в базовую систему.
-
Вполне допустимо вносить изменения в установленный порядок, но делайте это всё на свой страх и риск. Например, модули могут быть не подготовлены к тому, чтобы сделанные при их помощи настройки были перенесены из среды инсталлятора в базовую систему. Самая правильная идея – заниматься творчеством в районе пункта №6.
Неинтерактивные модули инсталлятора
Часть шагов установщика пользователь видит на экране (настройка времени, установка системы), а часть нет. Неинтерактивные шаги оформленны как последовательно запускаемые скрипты.
Есть три точки в ходе работы установщика, где можно вставить свой собственный скрипт:
- initinstall – выполняются перед стартом инсталлятора. В этот момент как правило производится вся подготовительная работа (генерация конфигурационного файла xorg.conf, необходимые исправления в evms.conf). Если вам потребуется задать несколько дополнительных вопросов, прежде чем сформировать файл сценария для автоустановщика (autoinstall.scm), то следует это оформить как initinstall скрипт.
- preinstall – выполняются сразу после установки базовой системы. Как правило это скрипты для дополнительной настройки базовой системы (перед установки дополнительного набора ПО) и для переноса настроек из среды инсталлятора. Добавлять суда свои собственные скрипты стоит только тогда когда вы чётко представляете свои цели (например перенесли шаг до установки базовой системы и теперь требуется перенести настройки). Все скрипты данной категории размещаются в каталоге /usr/share/install2/preinstall.d
- postinstall – выполняются сразу после последнего шага инсталлятора. Как правило это скрипты, удаляющие служебные пакеты инсталлятора из базовой системы и прочий «окончательный тюнинг» установленных пакетов для тех или иных нужд. Если захочется сделать какие-нибудь специфические настройки «из коробки», то это самое лучшее место для этого. Все скрипты данной категории размещаются в каталоге /usr/share/install2/postinstall.d
Схема запуска различных подсистем инсталлятора (процесс /sbin/install2):
- предварительная подготовка и разбор командной строки
- запуск /sbin/initinstall -> запуск initinstall.d скриптов
- запуск alterator. В ходе работы alterator сразу по окончанию установки базовой системы происходит запуск preinstall.d скриптов.
- запуск /sbin/postinstall -> postinstall.d скриптов
- отмонтирование всех файловых систем, завершение работы.
Данные и метаданные
Инсталлятор размещается в корне CD/DVD-диска в файле altinst. Это образ файловой системы формата squashfs.
Для работы ваших скриптов им возможно потребуются некоторые файлы с данными.
Первый способ (
«данные») – разместить их вместе с инсталлятором. Это делается во время сборки squashfs образа (при помощи хуков spt или mkimage). Соответственно для того чтобы изменить данные – надо перегенерить файл altinst. Иногда это не очень удобно и хочется менять отдельные параметры созданного дистрибутива без полной пересборки. А поэтому существует ...
Второй сопособ (
«метаданные») – рядом с файлом altinst вы обнаружите каталог Metadata. Всё что туда положите можно будет потом получить прямо в скриптах вызвав утилиту cp-metadata – данные будут доставлены, даже если и установка идёт через сеть ;)
Формат запуска «metadata-cp <целевой-каталог>/<файл>". В результат будет взят(скачан, скопирован) Metadata/<файл> и положен в <целевой-каталог>.
На данный момент используются следующие метаданные:
- basesystem.manifest – список rpm-пакетов составляющих базовую систему. Фактически это список пакетов из каталога RPMS.base. Получение происходит на стадии запуска initinstall.d
- (устарело) alterator-apt.profile – описание групп пакетов, устанавливаемых дополнительно при помощи модуля alterator-apt. Получение происходит на стадии запуска preinstall.d
- pkg-groups.tar – описание групп пакетов, устанавливаемых дополнительно при помощи модуля alterator-pkg. Получение происходит на стадии запуска preinstall.d
- autoinstall.scm – сценарий автоматической установки для alterator-autoinstall. Получение происходит на стадии запуска initinstall.d.
- vm-profile.scm – различные варианты автоматической разбивки диска для модуля разбивки диска alterator-vm. Получение происходит на стадии запуска initinstall.d.
Описание шагов инсталлятора
Описание шагов инсталлятора делится на две части: описание порядка шагов и собственно описание каждого шага. Для каждого шага указывается:
- Название (c переводами на разные языки)
- «урл» модуля установки
- название «темы» в справочной системе
Формат описания – так, как это принято в desktop-файлах. Вот пример описания шага добавления пользователя (users-add.desktop):
Все описания шагов размещаются в каталогe
/usr/share/install2/steps/. А порядок шагов – в файле
/usr/share/install2/installer-steps. В этом файле перечисляются имена desktop-файлов без полного пути и суффикса
.desktop. Вот пример типичного набора шагов инсталлятора:
Примечание:
По техническим причинам (инсталлятору нужно видеть описание всех шагов при старте одновременно, а часть из-них появляется после базовой системы), dekstop-файлы не распределяются по пакетам модулей, а лежат в пакетах installer-*-stage2. Пакет installer-stage2 содержит набор готовых desktop-файлов, достаточный для большинства дистрибутивов. Если хочется добавить свои особые шаги – сохраняйте все необходимые вам desktop-файлы в installer-
flavour-stage2.
Рекомендация: если в пакете
installer-flavour несколько step-ов, то стоит поставить суффикс (
flavour) префиксом имени файла в step/. Например, для installer-hpc это может быть steps/hpc-storage.desktop
Справка к модулям
В процессе установке, на каждом шаге, пользователь может нажать клавишу F1 и получить краткие указание по данному этапу.
Как было уже сказано ранее в описании каждого шага указывается ссылка на «тему». Сама же справка должна быть оформлена как небольшой документ html и размещена по адресу
/usr/share/install2/help/<язык>/<тема>.html .
Здесь <язык> – это локаль без указания кодировки (ru_RU, uk_UA, en_US).
Сборка собственного инсталлятора
Ядро инсталлятора, основные скрипты, шаги установки и файлы с описанием основных шагов размещаются в серии пакетов installer (installer,installer-stage2,installer-stage3). Часть шагов инсталлятора размещается в отдельных пакетах. Вот самые распространённые из них:
- alterator-sysconfig – настройка языка, настройка клавиатуры.
- alterator-license – лицензия дистрибутива. Сама лицензия размещается в каталога /usr/share/alt-license (пакет alt-license-<имя дистрибутива>). Данный шаг может использоваться в последствии и в центре управления для того чтобы напоминать пользователям о лицензии продукта которым они пользуются ;)
- alterator-vm – разбивка диска
- alterator-tzone, alterator-datetime – настройка даты и времени
- alterator-lilo – настройка загрузчика
- alterator-users – работа с пользователям
- alterator-apt – установка дополнительных пакетов
- alterator-net-eth, alterator-net-general, alterator-net-junior – различные вариации на тему настройки сети
- alterator-x11 – настройка графической подсистемы (xorg).
От вас требуется только создать серию пакетов installer-<дистрибутив> (installer-distro,installer-distro-stage2,installer-distro-stage3). Добавить во внутрь описания своих дополнительных шагов, preinstall и postinstall – скрипты, справку и, самое главное – перечисление шагов в том порядке, в каком хотите видеть. Не забудьте добавить зависимости на все внешние модули которые используете. В частности installer-distro-stage2 должен зависеть от installer-stage2, а installer-distro-stage3 – от installer-stage3.
Пакеты *-stage2 устанавливаются в специальную среду установщика, Пакет *-stage3 – в базовую систему.
Примеры уже готовых пакетов installer-<дистрибутив> можно найти в Sisyphus и git.alt (начало 2008: desktop, hpc, ltsp).
многодисковая установка
<boyarsh> Многодисковость делается легко. Нужен новый installer и alterator-pkg и добавить соответствующий шаг
<boyarsh> а на дополнительном диске должны быть пакеты и Metadata/pkg-groups.tar
нюансы при необходимости что-то из пакетов достать в процессе (например, собрать чрут для бездисковых систем при установке; см. тж. mknfsroot в сизифе):
<gvy> Стас, а куда делся /media/cdrom из /mnt/destination при install2?
<gvy> (если это новый installer в бранче...)
<inger> в смысле?
<inger> он отмонтируется нынче при возможности
<inger> у нас же многодисковый инсталлер
<gvy> на 0.3-alt3 у меня к моменту запуска preinstall.d был /mnt/destination/media/cdrom
<gvy> а, самому монтировать?
<inger> да
<gvy> а как посоветуешь сделать, чтоб по возможности независимо от NFS/CDROM/...?
<gvy> или где глянуть :)
<gvy> прикольненько =) на инсталере с мультидисковостью у меня отвалилась сборка чрута — /media/cdrom в чруте уже нет к этому моменту
<gvy> что бы руками туда смонтировать...
<gvy> /image?
<boyarsh> ну так image тоже нет...
<boyarsh> видимо, cdrom
<gvy> уже понял. /dev/cdrom? а если NFS?
<boyarsh> если nfs то он не отмонтируется
<boyarsh> а если cdrom, то $CDROMDEV
<gvy> если не cdrom, то $CDROMDEV пуст?
<boyarsh> да
<boyarsh> ещё есть переменная $METHOD
<gvy> cdrom/nfs/...?
<boyarsh> Стас знает или rtfs пакет installer
<inger> а в чём проблема, по идее apt сам умеет всё делать
<inger> можешь принудительно при методе cdrom замонтировать диск
<gvy> похоже, так и сделаю
<gvy> при других $METHOD /image остаётся смонтирован в /mnt/destination/media/cdrom, так?
<inger> да
<inger> можешь вообще не глядя говорить mount /media/cdrom
<inger> в крайнем случае ничего не смонтирует ;)
<gvy> :) нарисовал так:
local MOUNTED=
[ "$METHOD" = “cdrom” -a -n "$CDROMDEV” ] && {
MOUNTED="$destdir/media/cdrom"
mount "$CDROMDEV" "$MOUNTED"
}
# .........
[ -n "$MOUNTED" ] && umount "$MOUNTED"
<inger> наверное покатит ... это куда, в хук?
<inger> тогда не забудь отхачить его чтобы он был последним
<inger> позже 99-cdrom
<gvy> это 99-ltsp =)
<inger> это postinstall.d ?
<inger> если так, то всё нормально
<gvy> preinstall.d
<inger> а почему preinstall
<inger> это же не перенос настроек
<inger> это пост-инсталл хаки
<gvy> он относительно долго выполняется — так маскируется savesettings, а так будет висеть минуту на выгрузке
<gvy> я бы подумал, что машинка висит
<gvy> вообще надо отдельным шагом, чтоб ещё и таскался между дистрами легче
<gvy> или собирать чрут при сборке образа...
<inger> отдельный шаг, да, было бы неплохо ;)
<gvy> а, и ещё — в preinstall точно стоит нужный мне диск :)
<gvy> хотя при отдельном шаге появляется возможность наоборот — выкинуть ltsp на отдельный носитель
<inger> ну ... если ты делаешь через apt, то он об этом позаботится ;)
<inger> да, многодисковость позволяет делать, доп. фичи к стандартному dekstop ;)
<inger> то есть можно юзать installer-desktop + диск с ltsp ;)
Ссылок на эту страницу нет