Участник:HihinRuslan/LiveCDHowto
Материал из ALT Linux Wiki
(→Рассмотрим вначале вопрос -- что должно находится на этом CD .) |
(→Рассмотрим вначале вопрос -- что должно находится на этом CD .) |
||
Строка 27: | Строка 27: | ||
(Опции - см man mkisofd) | (Опции - см man mkisofd) | ||
- | Для dvd вместо mkisofs используется growisofs с аналогичными (практически теми-же опциями - см man growisofs). | + | Для dvd вместо mkisofs используется growisofs с аналогичными |
+ | (практически теми-же опциями - см man growisofs). | ||
Версия 19:32, 25 мая 2010
Содержание |
Вступление
Мне на работе часто приходится решать задачу -- накидать какую-то инфу на CD/DVD (далее -- просто CD) с тем, чтобы потом можно было скинуть её где-нибудь в другом городе, где найти комп с Win проблема, не говоря уже о том, чтобы была нормальная ОС.
Так что поневоле приходится смотреть, как и где делаются загрузочные CD. В принципе, есть проприетарные программы, но речь тут не о них.
Алгоритм работы LiveCD
Допустим, мне надо перенеси небольшую "кучку" RPM с одного места на другое, и я хочу, чтобы носителем этой "кучки" был небольшой дистрибутив Linux (желательно последнее ядро и интерфейс покрасивее, чтобы на меня смотрели не с сожалением, а с изумлением :) ).
Рассмотрим вначале вопрос -- что должно находится на этом CD .
1 - Поскольку это загрузочный диск, то на нём должен находится загрузчик, умеющий работать с isofs (iso9660).
Из тех, что на слуху - это или grub или syslinux
- Для grub команда установки загрузчика (сформулировано мной нечётко, но кратко)
- выглядит так (info grub раздел 3.4):
- $ mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot \
- -boot-load-size 4 -boot-info-table -o grub.iso iso
- $ mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot \
- Для syslinux так (isolinux.man) :
- mkisofs -o <isoimage> \
- -b isolinux/isolinux.bin -c isolinux/boot.cat \
- -no-emul-boot -boot-load-size 4 -boot-info-table \
- <root-of-iso-tree>
- mkisofs -o <isoimage> \
(Опции - см man mkisofd)
Для dvd вместо mkisofs используется growisofs с аналогичными
(практически теми-же опциями - см man growisofs).
2 - Сформированный "контейнер" пакетов - собственно то, что будет являться тем дистрибутивом, который расположен на LiveCD
В последнее время эту среду упаковывают в какую-нибудь специфическую файловую систему - это на ваш выбор.
3 - То, что видно пользователю при открытии диска.
Если говорить образно, то первый и второй пункт это тот "корабль", который может иметь на своему борту пассажиров. А третий пункт - это то, что нужно увидеть пользователю для текущей работы (дистрибутив установки, сырцы и т.п.)
Непосредственный алгоритм работы LiveCD
Работа LiveCD аналогична работе обычной работе с жёсткого диска, но отличается всем понятыми отличиями :
- Нет возможности изменять файлы на самом CD поэтому приходится размещать корень файловой системы в памяти (одна из причин упаковки в специфическую файловую систему). - LiveCD должен уметь определять аппаратуру компьютера на который он загружен и подгружать необходимые модули. - В частности LiveCD должен уметь находить разделы жёсткого диска компьютера и внешние носители информации (флеш-память, флоппи-диски и т.п.) - Желательна возможность догружать "редко встречающиеся" и специфичные модули ядра (cups и т.п.) не учтённые при создании LiveCD.
1 загрузка ядра и его модулей из initrd (ещё одна упакованная файловая система с "драйверами"). 2 распаковка модулей ядра из Мandrake arhiv (mar) - исторически идёт от Мандрейка. 3 монтирование специфического файлового образа и создание корня в памяти компьютера. 4 монтирование остальных файловых систем (в том числе некоторых то-же в памяти)
В остальном всё аналогично обычной или сетевой загрузке.
Как сформировать образ LiveCD
Для того, чтобы сформировать образ LiveCD
- во-первых необходимо иметь пакетную базу (репозитарий пакетов), из которого можно спокойно собрать сборочную среду и желательно, что-бы эта пакетная база была "непротиворечива" (без unmet` ов и т.п.) - во-вторых создать какой-нибудь "контейнер" для построения будущего LiveCD
Создание пакетной базы
Теоретически, если у вас есть устойчивый и непротиворечивый дистрибутив, то вам можно сказать повезло и вам этот этап возможно не потребуется. Другое дело, если вы хотите собрать дистрибутив из пакетной базы, в которой "не всё так гладко" или надо выбрать из неё только часть пакетов.
Наверное. есть более простой путь, чем предлагаю я, но он ведёт к написанию собственных скриптов или пакетов (что конечно это самый правильный путь).
В пакете 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. На всякий случай (вроде-бы и не надо)
- genbasedir --progress --todir `pwd`/Distrib ALTLinux alpha
4 Натравливаем на базу дистрибутива gendistrib :
- gendistrib --distrib Distrib
5 Читаем результаты и по ним принимаем решение - что можно удалить из дистрибутива, что надо пересобрать, и что надо добавить.
Так, как мы собираемся собирать свой LiveCD через spt( или separator), то то-же надо положить в базу дистрибутива и сделать так, что-бы он в нём остался :)
Создание "контейнера" для построения LiveCD
Ну тут можно просто настроить apt на созданную нами базу дистрибутива, прописать в профиль spt (или separator) пакеты, прописанные в базе дистрибутива и дожидаться когда он всё построит, хотя в принципе можно оставвшуюся часть то-же сделать руками (или своим скриптом). Просто надо понять что осталось нам сделать для построенния полноценного LiveCD.
Критика и самокритика
Тем, кто будет читать : Важное замечание получил я от МихаилаШигорина :
Почитай sandman или spt.
И мой ответ :
А spt лежит по зависимостям "глубоко внизу" и может быть, поэтому, не устанавливаемым. Отсюда, прежде чем им начать пользоваться, надо выбрать в базу дистрибутива, как минимум, те пакеты, которые обеспечивают возможность поставить spt. Получается заколдованный круг. Отсюда его недостаток - он ломается по зависимостям и становится "неработоспособным". Будь моя воля, я-бы его на части разделил для каждого этапа (что-бы каждый отдельный этап его работы обслуживал отдельный пакет, имеющий минимальные зависимости). Например, в идеале spt на этапе выбора паетной базы, должен зависеть только от rpm (apt). Ну и "сшил" бы вызовы программ отдельного этапа скритом, написанном на ash, который бы вызывал "скрипт" каждого этапа убирает его хвосты, в случае неудачи, а также выдаёт на output наиболеее важные моменты построения дистрибутива в удобной форме + механизм выполнять построение с заданного этапа до какого-то другого (особенно хорошо при возникновении ошибок). Тогда-бы не было этого заколдованного круга.
PS Про sandman ничего сказать не могу, уже читаю :) PPS В голове почему-то крутится аналогия с этапами загрузки компьютера.
Вначале выполняется первый этап, который даёт выполнится второму. Т.е. построение базы пакетов, которая позволяет построить пакет A, что-бы его поставить, с тем, что-бы следующий этап мог спокойно выполнится и включить в базу пакет B, который позволяет выполнится следующему этапу. Тут что-то с хэшером связано :)
Ссылки