Опять о Live CD
Владимир Попов
[email protected]
Продолжая тему...
Linux LiveCD появляются в последнее время, как "грибы после дождя".
Неудивительно: потребность в проблемно-ориентированных системах, допускающих
использование без инсталляции на жесткий диск, была всегда, а прогресс IBM
PC и возможности Linux сделали создание таких систем в настоящее время
задачей почти тривиальной. Мы уже обсуждали устройство Gentoo
LiveCD, отмечали особенности инсталляционного диска CRUX, являющегося, в сущности, также LiveCD, как и большинство
инсталляционных дисков Linux (тоже ведь - проблемно-ориентированные
системы, решающие "проблему" инсталляции ОС на жёсткий диск). Предмет
нынешнего обсуждения - Slackware Live CD Томаша Матежичека (Tomas
Matejicek).
Сразу оговоримся, что для конечного пользователя Slackware Live
CD не так привлекателен, как "всеобъемлющий" knoppix, или,
напротив, "изящный" (20-ти мегабайтный) Movix. Да и тщательность -
визитная карточка "родительского" Slackware Патрика Волькердинга
(Patrick Volkerding), почему-то не "унаследована" Slackware Live CD:
то mplayer не запускается, то соответствующее позиции меню
приложение не обнаруживается... Не об этом речь. Просто со Slackware
Live CD разговор о способах организации (следовательно: и создания)
Live CD приобретает некоторую логическую завершённость. А обобщение такое
"дорогого стоит", поскольку позволяет пониманием закономерностей дополнить
(или - заменить?) знание конкретных реализаций Live CD.
По традиции...
А начинается всё с того известного факта, что необходимая для работы
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, то
первый способ организации (и создания, соответственно) Live CD - налицо.
Именно так организовано большинство инсталляционных дисков дистрибутивов,
именно так работают CRUX, Movix и первая фаза загрузки
Gentoo Live CD. Этот способ прост и экономичен: если всё необходимое
для решения проблемы (будь то инсталляция дистрибутива, восстановление
системы или воспроизведение медиа-файлов) можно разместить на виртуальном
диске, то так, безусловно, и надо поступать.
Вопрос в том, возможно ли это. Так, уже для MoviX2, несущего в
себе X Window, требуется минимум 128 Мб ОЗУ. Память нынче дёшева, но
следует ли из этого автоматически, что на всех IBM PC 128 и более Мб
памяти? Боюсь, что нет. Правда, если отказаться от желания освобождать после
загрузки CD ROM, то можно использовать упомянутую выше возможность
монтирования к виртуальной файловой системе директорий CD ROM, но... Для
MoviX2, который и разрабатывался-то, прежде всего, для просмотра
видео, такой вариант не подходит: какие уж тут DVD, когда привод занят? Да
и хватит ли объёма CD ROM, если Live CD создаётся, например, для
демонстрации всего многообразия Open Source ПО, как knoppix? Что же,
фиаско?
В стиле "авангард"...
Не совсем. Способ сжатия данных известен: компрессия. Другое дело, что
декомпрессировать данные нужно "на лету", по мере надобности, то есть. И
средства для этого не "заставили себя ждать". Решение в стиле Александра
Македонского демонстрирует, например, Клаус Кноппер. Его KNOPPIX
представляет собой один 700-Мб файл, уже не помещающийся на стандартные
"болванки". К моменту окончательного старта системы, в память, кроме ядра и
модулей поддержки аппаратуры и файловых систем, загружен модуль
cloop, обеспечивающий доступ ко всему содержимому файла
KNOPPIX. Содержимое initrd выполнило свои функции и забыто:
/dev и /proc унаследованы и ни один килобайт ОЗУ не занят
тем, без чего может обойтись целевая система. Аналогично происходит
загрузка Gentoo Live CD. А вот пара ухищрений для этого решения:
- если файл компрессированного образа целевой системы
(livecd.cloop у Gentoo или KNOPPIX у knoppix
и его клонов) помещается в ОЗУ, то стоит перенести его в /tmpfs:
реактивность системы, осуществляющей декомпрессию файлов "на лету" и так
хуже, нежели у той, что полностью резидирует на виртуальном диске - не
стоит позволять приводу CD ROM ещё более "тормозить" её. Как это делается,
можно увидеть в linuxrc, "добытом" из initrd Gentoo
Live CD;
- как вариант, может рассматриваться размещение файла
компрессированного образа на жёстком диске: три необходимых файла (ядро
vmlinuz, initrd.gz и KNOPPIX, например) это всё-таки
меньше, чем 2-х гигабайтный раздел, требующийся для аналогичной
инсталляции Debian. Заодно и быстродействие системы повысится.
Разумеется, в этом случае стартовый скрипт в поисках файла KNOPPIX
должен перебирать не только /dev/cdrom*. Такой приём
иллюстрируется init.rc из damnsmall - самого маленького из
уже довольно многочисленных "потомков" knoppix;
- обязательно нужно позаботиться о разделе подкачки: благо в настоящее
время его успешно эмулирует файл (см. linuxrc у
knoppix).
Такое решение можно считать "антиподом" первого, традиционного способа
организации Live CD. Кардинально, но... не без недостатков. Во-первых,
пакет cloop не является каноническим и, так сказать, общепризнанным.
Какова будет его дальнейшая судьба при развитии ядра? Никаких гарантий,
если вообще уместно говорить о гарантиях в нашем "царстве свободы".
Во-вторых: чем больше размер компрессированного образа, тем труднее с ним
работать. Всё больше требуется памяти, всё больше дожен быть swap-раздел,
всё дольше процедура компрессии. Когда проходишь её в десятый раз, а
поводом была всего лишь редакция rc-файла одного из почти двух тысяч
приложений... Раздражает, честно скажу.
Ещё одна попытка...
Вот тут-то у нас и появляется повод поинтересоваться Slackware Live
CD. Отдадим должное Томашу: для изучения его Live CD нам не потребуется
добывать стартовые скрипты из initrd.gz и "по шагам" их
анализировать. Возможно, это единственный Live CD, снабжённый подробной
инструкцией по созданию ему подобных и даже соответствующими скриптами. К
этому Томаш, похоже, подошёл более тщательно, чем к меню KDE. Может - и
правильно. Мне, во всяком случае, это - интереснее.
Так вот, основным отличием Slackware Live CD является
использование cramfs (compressed RAM file system): файловой системы,
поддержка которой включена в каноническое ядро Линуса. Подробнее о ней - в
/usr/src/linux/Documentation/fs/cramfs.txt. Там же - о некоторых её
недостатках, не настолько существенных, что бы помешать созданию
Slackware Live CD. А вот какими советами Томаш делится в своём
LIVECD_CREATE_HOWTO:
- при создании прообраза файловой системы Live CD следить за тем, чтобы
директории корневого каталога имели объём не более 500 Мб, поскольку
размер файлов cramfs ограничен 256-тью Мб;
- удалить с помощью скрипта delete_mess излишние для Live CD
файлы документации (вспомните, как бесцеремонно CRUX избавляется от
/info /doc и nls). Похоже, обилие документации,
которое ещё пару лет назад ставили в заслугу Linux, утомляет всё большее
число людей;
- с помощью images_cram создать компрессированные образы
директорий корневого каталога. Это - второе принципиальное отличие
Slackware Live CD от knoppix, скажем. С такими "частичными"
образами работать удобнее и быстрее. Используемая утилита -
mkcramfs;
- скрипт initrd_create - прекрасная иллюстрация создания
initrd. Так её Томаш и рекомендует: для другого дистрибутива (не
Slackware) конкретные команды будут иными - и лишь принцип
останется прежним;
- создание загружаемого iso-образа - также общая для всех Live CD
задача. Скрипт create_bootiso сделает это за вас, а лучше -
покажет, как это делал Томаш.
В заключение...
Сказать, что только описанное выше представляет интерес в Slackware
Live CD было бы неправдой. Кроме пакетов, унаследованных от собственно
Slackware, в дистрибутив входят mplayer (хотя и не совсем удачно), KDE Instant Messenger kopete, свободно распространяемый клиент
Windows NT Terminal Server
rdesktop, MPEG-4 совместимый видео кодек xvid. Однако, наш нынешний интерес - создание
Live CD и, поэтому, остальные особенности этого дистрибутива мы не
обсуждаем.
Всё вышесказанное относится к последним версиям упомянутых Live CD.
Во всех случаях это ядро 2.4.20, со всеми его уже привычными атрибутами:
/devfs, /tmpfs, а в случае Slackware Live CD, ещё и
cramfs. Нельзя сказать, что описанные приёмы неприложимы к ядрам
предыдущих версий, но факт, что для ядер 2.2.хх, потребовалось бы более
развёрнутое описание.
Таким образом, Slackware Live CD занимает как бы промежуточное
положение между реализациями, не использующими компрессированный образ
целевой файловой системы (CRUX, MoviX2), и таковыми,
использующими пакет cloop (knoppix, damnsmall,
Gentoo). Можно ли считать это "золотой серединой"? Не знаю, да и
вряд ли это имеет значение. Зато, почти наверняка, можно сказать, что
использование cramfs (как у Slackware) с переносом
компрессированных образов в /tempfs (как у Gentoo), с
автоконфигуратором и созданием виртуального swap-раздела (как у
knoppix), позволит создавать ещё более эффектные и эффективные Linux
Live CD. Ведь их истории - "всего - ничего". "Вся жизнь впереди", как пел
когда-то один популярный ВИА (если кто-то ещё помнит, что это такое).
P.s.
А вот и иллюстрация: цитирую еженедельный обзор LWN.net от
24.04: "вышел
очередной релиз rpm-livecd... Изменения: система перешла на работу с образом
loopback. Добавлена поддержка tmpfs и средства поиска всех локальных
Windows и Linux разделов..."
