Так что поневоле приходится смотреть, как и где делаются загрузочные CD. В принципе, есть проприетарные программы, но речь тут не о них.
1 – Поскольку это загрузочный диск, то на нём должен находится загрузчик, умеющий работать с isofs (iso9660).
Из тех, что на слуху – это или grub или syslinux
-no-emul-boot -boot-load-size 4 -boot-info-table \
<root-of-iso-tree>
(Опции – см man mkisofd)
2 – Сформированный «контейнер» пакетов – собственно то, что будет являться тем дистрибутивом, который расположена на Live CD
В последнее время эту среду упаковывают в какую-нибудь специфическую файловую систему – это на ваш выбор.
3 – То, что видно пользователю при открытии диска.
Если говорить образно, то первый и второй пункт это тот «корабль», который может иметь на своему борту пассажиров.
А третий пункт – это то, что нужно увидеть пользователю для текущей работы (дистрибутив установки, сырцы и т.п.)
Работа Live CD аналогична работе обычной работе с жёсткого диска, но отличается всем понятыми отличиями :
– Нет возможности изменять файлы на самом CD поэтому приходится размещать корень файловой системы в памяти (одна из причин упаковки в специфическую файловую систему).
– Live CD должен уметь определять аппаратуру компьютера на который он загружен и подгружать необходимые модули.
– В частности Live CD должен уметь находить разделы жёсткого диска компьютера и внешние носители информации (флеш-память, флоппи-диски и т.п.)
– Желательна возможность догружать «редко встречающиеся» и специфичные модули ядра (cups и т.п.) не учтённые при создании Live CD.
1 загрузка ядра и его модулей из initrd (ещё одна упакованная файловая система с «драйверами»).
2 распаковка модулей ядра из Мandrake arhiv (mar) – исторически идёт от Мандрейка.
3 монтирование специфического файлового образа и создание корня в памяти компьютера.
4 монтирование остальных файловых систем (в том числе некоторых то-же в памяти)
В остальном всё аналогично обычной или сетевой загрузке.
Для того, чтобы сформировать образ Live CD необходимо
– во-первых необходимо иметь пакетную базу (репозитарий пакетов), из которого можно спокойно собрать сборочную
среду и желательно, что-бы эта пакетная база была «непротиворечива» (без unmet` ов и т.п.)
– во-вторых создать какой-нибудь «контейнер» для построения будущего Live CD
Теоретически, если у вас есть устойчивый и непротиворечивый дистрибутив, то вам можно сказать повезло и вам этот этап возможно не потребуется. Другое дело, если вы хотите собрать дистрибутив из пакетной базы, в которой «не всё так гладко» или надо выбрать из неё только часть пакетов.
Наверное. есть более простой путь, чем предлагаю я, но он ведёт к написанию собственных скриптов или пакетов (что конечно это самый правильный путь).
В пакете rpmtools есть очень полезный перловый скрипт gendistrib, как я понимаю, он остался ещё со времён старого установщика.
У него есть очень полезное для нас свойство – он в заданной директории, заполненной пакетами rpm (назовём это базой дистрибутива) находит :
+ недостающие для этой базы дистрибутива пакеты
+ указывает на нарушение зависимостей и конфликты пакетов (написал и задумался – а так-ли это ?)
но у него есть один недостаток – он работает с определённой структурой папок (можно посмотреть, например в Junior )
*Distrib
** .disk
** ALTLinux
* RPMS
* RPMS.alpha (ссылка на RPMS)
* base
1 Итак, открывем файл ./ALTLinux/base/hdlists и прописываем туда строчку :
hdlist1.cz ALTLinux/RPMS MyLiveCD 0.01 LiveCD
2 Прописываем в ./disk/info
MyLiveCD 0.01 LiveCD
3. На всякий случай (вроде-бы и не надо)
4 Натравливаем на базу дистрибутива gendistrib :
5 Читаем результаты и по ним принимаем решение – что можно удалить из дистрибутива, что надо пересобрать, и что надо добавить.
Так, как мы собираемся собирать свой Live CD через spt( или separator), то то-же надо положить в базу дистрибутива и сделать так, что-бы он в нём остался :)
Тем, кто будет читать :
Важное замечание получил я от Михаила Шигорина :
Почитай sandman или spt.
И мой ответ :
А spt лежит по зависимостям «глубоко внизу» и может быть, поэтому, неустанавливаемым. Отсюда, прежде чем им начать пользоваться, надо
выбрать в базу дистрибутива, как минимум, те пакеты, которые обеспечивают возможность
поставить spt. Получается заколдованный круг.
Отсюда его недостаток – он ломается по зависимостям и
становится «неработоспособным». Будь моя воля, я-бы его на части
разделил для каждого этапа (что-бы каждый отдельный этап его работы
обслуживал отдельный пакет, имеющий минимальные зависимости).
Например, в идеале spt на этапе выбора паетной базы,
должен зависеть только от rpm (apt).
Ну и «сшил» бы вызовы программ отдельного этапа скритом,
написанном на ash, который бы вызывал «скрипт» каждого этапа убирает его хвосты, в случае неудачи,
а также выдаёт на output наиболеее важные моменты построения дистрибутива в удобной форме + механизм выполнять построение с заданного этапа до какого-то другого (особенно хорошо при возникновении ошибок).
Тогда-бы не было этого заколдованного круга.
PS Про sandman ничего сказать не могу, уже читаю :)
PPS В голове почему-то крутится аналогия с этапами загрузки компьютера.
Вначале выполняется первый этап, который даёт выполнится второму.
Т.е. построение базы пакетов, которая позволяет построить пакет A, что-бы его поставить, с тем, что-бы следующий этап мог спокойно выполнится и включить в базу пакет B, который позволяет выполнится следующему этапу. Тут что-то с хэшером связано :)