главная пошаговое создание livecd что такое linux ISO образы
Операционная система с графическим интерфейсом
На главнуюКонтактыКарта сайта
Полезное


 

ДОБРО ПОЖАЛОВАТЬ


Slackware LiveCD, или Возвращение к теме "живых" дисков

Linux LiveCD появляются в последнее время, как "грибы после дождя". Неудивительно: потребность в проблемно-ориентированных системах, допускающих использование без инсталляции на жесткий диск, была всегда, а прогресс IBM PC и возможности Linux сделали создание таких систем в настоящее время задачей почти тривиальной. Мы уже обсуждали устройство прародителя этого семейства - Knoppix, отмечали особенности Gentoo LiveCD и инсталляционного диска CRUX, являющегося, в сущности, также "живым" компактом: как и все инсталляционные диски Linux, это - проблемно-ориентированная система, решающие "проблему" инсталляции ОС на жёсткий диск. Предмет нынешнего обсуждения - Slackware LiveCD Томаша Матежичека (Tomas Matejicek).

Сразу оговоримся, что для конечного пользователя Slackware LiveCD не так привлекателен, как "всеобъемлющий" Knoppix, или, напротив, "изящный" (20-ти мегабайтный) MoviX. Да и тщательность - визитная карточка "родительского" Slackware Патрика Волькердинга (Patrick Volkerding), почему-то не "унаследована" Slackware LiveCD: то mplayer не запускается, то соответствующее позиции меню приложение не обнаруживается... Не об этом речь. Просто со Slackware LiveCD разговор о способах организации (следовательно: и создания) LiveCD приобретает некоторую логическую завершённость. А обобщение такое "дорогого стоит", поскольку позволяет пониманием закономерностей дополнить (или - заменить?) знание конкретных реализаций LiveCD.

По традиции...

А начинается всё с того известного факта, что необходимая для работы Linux корневая файловая система может быть расположена в ОЗУ, на виртуальном, так сказать, диске. Не "к ночи буде упомянута" MicroSoft Co., кстати, тоже подобного достигла. На уровне MS DOS 7.0, если память не изменяет. То есть, виртуальный диск был известен в MS DOS с версии 3.3, но одновременно перенести ядро ОС в расширенную память, а файловую систему - на виртуальный диск, да так, чтобы дисковод можно было освободить и продолжать работать... Мне, почему-то такое удалось увидеть только на Start-Up дискете Windows'95. Не исключаю, впрочем, что это моя вина: плохо смотрел. Только неважно это: последующие ОС от MicroSoft начисто такой возможности лишились - и забудем об этом. Вернёмся к Linux.

Здесь для использования этой самой возможности даже специальную "сущность" изобрели: initrd (Initial RAM Disk) называется. В Red Hat чуть ли не средства для её создания разработали: mkinitrd, кажется. Только лишнее это. От лукавого. Достаточно знать, что: файловая система ext2, например, может создаваться не только в разделе диска, но и в файле; файл этот может монтироваться, как файловая система, с использованием виртуального устройства loopback (/dev/loop); на этапе загрузки такой файл может "разворачиваться" в ОЗУ в оответствии с опцией загрузки initrd. Даже будучи компрессированным; а опция загрузки root=/dev/ram0 вынуждает загружаемое ядро принимать файловую систему виртуального диска как корневую.

Если прибавить к этому само собой разумеющуюся возможность монтирования к данной файловой системе в режиме read only директорий CD ROM, то первый способ организации (и создания, соответственно) LiveCD - налицо. Именно так организовано большинство инсталляционных дисков дистрибутивов, именно так работают LiveCD CRUX, LiveCD Movix и первая фаза загрузки Gentoo LiveCD. Этот способ прост и экономичен: если всё необходимое для решения проблемы (будь то инсталляция дистрибутива, восстановление системы или воспроизведение медиа-файлов) можно разместить на виртуальном диске, то так, безусловно, и надо поступать.

Вопрос в том, возможно ли это. Так, уже для LiveCD MoviX2, несущего в себе X Window, требуется минимум 128 Мб ОЗУ. Память нынче дёшева, но следует ли из этого автоматически, что на всех IBM PC 128 и более Мб памяти? Боюсь, что нет. Правда, если отказаться от желания освобождать после загрузки CD ROM, то можно использовать упомянутую выше возможность монтирования к виртуальной файловой системе директорий CD ROM, но... Для LiveCD MoviX2, который и разрабатывался-то, прежде всего, для просмотра видео, такой вариант не подходит: какие уж тут DVD, когда привод занят? Да и хватит ли объёма CD ROM, если LiveCD создаётся, например, для демонстрации всего многообразия Open Source ПО, как LiveCD Knoppix? Что же, фиаско?

В стиле "авангард"...

Не совсем. Способ сжатия данных известен: компрессия. Другое дело, что декомпрессировать данные нужно "на лету", по мере надобности, то есть. И средства для этого не "заставили себя ждать". Решение в стиле Александра Македонского демонстрирует, например, Клаус Кноппер. Его KNOPPIX представляет собой один 700-Мб файл, уже не помещающийся на стандартные "болванки". К моменту окончательного старта системы, в память, кроме ядра и модулей поддержки аппаратуры и файловых систем, загружен модуль cloop, обеспечивающий доступ ко всему содержимому файла KNOPPIX. Содержимое initrd выполнило свои функции и забыто: /dev и /proc унаследованы и ни один килобайт ОЗУ не занят тем, без чего может обойтись целевая система. Аналогично происходит загрузка Gentoo LiveCD. А вот пара ухищрений для этого решения: если файл компрессированного образа целевой системы (livecd.cloop у LiveCD Gentoo или KNOPPIX у LiveCD Knoppix и его клонов) помещается в ОЗУ, то стоит перенести его в /tmpfs: реактивность системы, осуществляющей декомпрессию файлов "на лету" и так хуже, нежели у той, что полностью резидирует на виртуальном диске - не стоит позволять приводу CD ROM ещё более "тормозить" её. Как это делается, можно увидеть в linuxrc, "добытом" из initrd Gentoo LiveCD;

как вариант, может рассматриваться размещение файла компрессированного образа на жёстком диске: три необходимых файла (ядро vmlinuz, initrd.gz и KNOPPIX, например) это всё-таки меньше, чем 2-х гигабайтный раздел, требующийся для аналогичной инсталляции LiveCD Debian. Заодно и быстродействие системы повысится. Разумеется, в этом случае стартовый скрипт в поисках файла KNOPPIX должен перебирать не только /dev/cdrom*. Такой приём иллюстрируется init.rc из damnsmall - самого маленького из уже довольно многочисленных "потомков" LiveCD Knoppix; обязательно нужно позаботиться о разделе подкачки: благо в настоящее время его успешно эмулирует файл (см. linuxrc у LiveCD Knoppix).

Такое решение можно считать "антиподом" первого, традиционного способа организации LiveCD. Кардинально, но... не без недостатков. Во-первых, пакет cloop не является каноническим и, так сказать, общепризнанным. Какова будет его дальнейшая судьба при развитии ядра? Никаких гарантий, если вообще уместно говорить о гарантиях в нашем "царстве свободы". Во-вторых: чем больше размер компрессированного образа, тем труднее с ним работать. Всё больше требуется памяти, всё больше дожен быть swap-раздел, всё дольше процедура компрессии. Когда проходишь её в десятый раз, а поводом была всего лишь редакция rc-файла одного из почти двух тысяч приложений... Раздражает, честно скажу.

Ещё одна попытка...

Вот тут-то у нас и появляется повод поинтересоваться Slackware LiveCD. Отдадим должное Томашу: для изучения его LiveCD нам не потребуется добывать стартовые скрипты из initrd.gz и "по шагам" их анализировать. Возможно, это единственный LiveCD, снабжённый подробной инструкцией по созданию ему подобных и даже соответствующими скриптами. К этому Томаш, похоже, подошёл более тщательно, чем к меню KDE. Может - и правильно. Мне, во всяком случае, это - интереснее.

Так вот, основным отличием Slackware LiveCD является использование cramfs (compressed RAM file system): файловой системы, поддержка которой включена в каноническое ядро Линуса. Подробнее о ней - в /usr/src/linux/Documentation/fs/cramfs.txt. Там же - о некоторых её недостатках, не настолько существенных, что бы помешать созданию Slackware LiveCD. А вот какими советами Томаш делится в своём LIVECD_CREATE_HOWTO: при создании прообраза файловой системы LiveCD следить за тем, чтобы директории корневого каталога имели объём не более 500 Мб, поскольку размер файлов cramfs ограничен 256-тью Мб; удалить с помощью скрипта delete_mess излишние для LiveCD файлы документации (вспомните, как бесцеремонно CRUX избавляется от /info /doc и nls). Похоже, обилие документации, которое ещё пару лет назад ставили в заслугу Linux, утомляет всё большее число людей; с помощью images_cram создать компрессированные образы директорий корневого каталога. Это - второе принципиальное отличие Slackware LiveCD от Knoppix, скажем. С такими "частичными" образами работать удобнее и быстрее. Используемая утилита - mkcramfs; скрипт initrd_create - прекрасная иллюстрация создания initrd. Так её Томаш и рекомендует: для другого дистрибутива (не Slackware) конкретные команды будут иными - и лишь принцип останется прежним; создание загружаемого iso-образа - также общая для всех LiveCD задача. Скрипт create_bootiso сделает это за вас, а лучше - покажет, как это делал Томаш.

В заключение...

Сказать, что только описанное выше представляет интерес в Slackware LiveCD, было бы неправдой. Кроме пакетов, унаследованных от собственно Slackware, в дистрибутив входят mplayer (хотя и не совсем удачно), KDE Instant Messenger kopete, свободно распространяемый клиент Windows NT Terminal Server rdesktop, MPEG-4 совместимый видео кодек xvid. Однако, наш нынешний интерес - создание LiveCD и, поэтому, остальные особенности этого дистрибутива мы не обсуждаем.

Всё вышесказанное относится к последним версиям упомянутых LiveCD. Во всех случаях это ядро 2.4.20, со всеми его уже привычными атрибутами: /devfs, /tmpfs, а в случае Slackware LiveCD, ещё и cramfs. Нельзя сказать, что описанные приёмы неприложимы к ядрам предыдущих версий, но факт, что для ядер 2.2.хх, потребовалось бы более развёрнутое описание.

Таким образом, Slackware LiveCD занимает как бы промежуточное положение между реализациями, не использующими компрессированный образ целевой файловой системы (CRUX, MoviX2), и теми, что используют пакет cloop (Knoppix, Damnsmall, Gentoo). Можно ли считать это "золотой серединой"? Не знаю, да и вряд ли это имеет значение. Зато, почти наверняка, можно сказать, что использование cramfs (как у Slackware LiveCD) с переносом компрессированных образов в /tempfs (как у Gentoo), с автоконфигуратором и созданием виртуального swap-раздела (как у Knoppix), позволит создавать ещё более эффектные и эффективные Linux LiveCD. Ведь их истории - "всего - ничего". "Вся жизнь впереди", как пел когда-то один популярный ВИА (если кто-то ещё помнит, что это такое). Post Scriptum

А вот и иллюстрация: цитирую еженедельный обзор LWN.net от 24.04: "вышел очередной релиз rpm-livecd... Изменения: система перешла на работу с образом loopback. Добавлена поддержка tmpfs и средства поиска всех локальных Windows и Linux разделов..."