Network | Development | Download | Offtopic| Карта сайта
FreeNotes| Форум POSIX.ru
Владимир Попов
Алексей Федорчук
2003.04.15
В этой статье описывается внутреннее устройство инсталляционного диска Gentoo Linux, позволяющего не только выполнить не только первичную установку этого дистрибутива, но и использовать его для аварийно-восстановительных работ. А также просто для начального знакомства с системой - то есть в качестве LiveCD-дистрибутива.
Несмотря на привязку к конкретному дистрибутиву, и даже к определенному диапазону его версий - 1.4 (RC2-RC4), описанные здесь приемы применимы к LiveCD, построенному на базе почти любой иной Linux-системы.
Не вдаваясь в подробности устройства весьма (и - заслуженно) популярного пакета syslinux Питера Анвина (Peter Anvin), включающего isolinux, отвечающий за обеспечение загрузки с компакта, отметим только: возможности загрузки CD, выполненного с использованием isolinux, определяются содержимым одноименного каталога, который имеется на каждом LiveCD, изготовленном по этой методике. Во всех пре-релизах версии 1.4 содержание его следующее.
$ ls mount_cd/isolinux boot.cat boot.msg gentoo gentoo.lss help.msg initrd isolinux.bin isolinux.cfg
Опустим специальные файлы boot.cat, gentoo.lss и isolinux.bin. Посмотрим оставшиеся:
boot.msg - начальное сообщение при загрузке, ничего интересного;help.msg - текст, выводимый по F2. Кроме возможностей сократить "путь загрузки" (noapic, noscsi, nonet, acpi=no), он описывает такую важную опцию загрузки, как cdcache - возможность кэшировать содержимое CD в файловой системе tmpfs, о чем будет сказано ниже;gentoo - загружаемое ядро, разумеется, оно собрано с поддержкой всевозможных опций, которые могут потребоваться при инсталляции;initrd - образ виртуального диска (initial ram disk), очевидно;isolinux.cfg - конфигурационный файл загрузки, и определяющий, собственно, назначение всех вышеперечисленных файлов: убеждаемся в том, что файлы эти идентифицированы правильно, корневой системой сразу после загрузки станет /dev/ram0, а процесс инициализации определяется файлом /linuxrc.В версии 1.4-rc4 в этом каталоге дополнительном можно обнаружить файл add.msg, содержащий описание дополнительных режимов загрузки, вызываемое нажатием клавиши F3. Режимы эти - загрузка графической консоли с различными разрешениями (от 800x600 до 1280x1024), реализуемой через frame buffer, чисто текстовый режим загрузки, загрузка для SMP-конфигураций, и т.д. Соответственно, и файлов образом загрузочного RAM-диска здесь оказывается несколько (initrd.800, initrd.1024, initrd.1280, initrd2).
Рассматривать все разновидности initrd мы не будем. Посмотрим только на содержимое initrd. Выполнив:
$ gzip -dc ./initrd >initrd.img
получаем образ виртуального диска, который уже можно монтировать:
$ mount ./initrd.img /mnt/initrd -t ext2 -o loop
Смотрим, что получилось:
/bin - всего лишь "старый добрый" busybox, заменяющий нам утилиты, ныне объдиняемые, как правило, в пакет под названием coreutils, и несколько родственных;/sbin - символическая ссылка на /bin;/dev - пока вполне обычный, со множеством всяких наличествующих и отсутствующих устройств; но в дальнейшем он станет точкой монтирования файловой системы устройств - devfs, каковая и будет задействована в реальности;/etc - с единственным файлом fstab, который обеспечивает монтирование /dev/ram0 и proc. Тоже - понятно;/keymaps содержит то, что ему и положено - раскладки клавиатуры, выбираемые в начале загрузки с LiveCD;/proc, /lost+found и /tmp также в пояснениях не нуждаются;/modules находим очень интересный cloop.o (но о нём - позднее) и подкаталог storage с 29 модулями scsi-контроллеров. Этот набор, кстати, определяет вероятность определения scsi в вашей конфигурации;/usr содержит символические ссылки на /bin и /sbin;linuxrc - главный конфигурационный скрипт LiveCD-системы, который, собственно, и будет запущен на выполнение.Именно linuxrc, как нетрудно догадаться, и становится предметом дальнейшего анализа. Назначение его - получить из LiveCD полноценную систему, поскольку при всех достоинствах busybox для полноценной работы его "маловато будет". Итак (нумерация строк дана для версии 1.4-rc2 и в более новых версиях может незначительно отличаться):
mount -oremount,rw / - l.13, монтирование "корня" в режиме чтения/записи;mount /proc - l.14, монтирование /proc (потребуется для операции смены корневого каталога командой chroot);mkdir newroot - l.40, создаём каталог, который впоследствии и станет новым "корнем";mount -t tmpfs tmpfs /newroot - l.41, монтируем к нему виртуальную файловую систему (другой-то у нас и нет);/newroot/dev/ не обнаруживается .devfsd (а откуда он там возьмётся?) - монтируем devfs к /newroot/dev: l.48;insmod -f) всех перечисленных модулей. В результате модули поддержки обнаруженных контроллеров будут установлены (l.130-135);keymap (l.137) интереса не представляет - ни на какую локализацию это в дальнейшем не повлияет; напротив, выбор русской раскладки, вследствие странности оной, может только доставить неудобства;/newroot/dev/cdroms/ монтируются и проверяются на наличие на них файла /livecd.cloop. Обработку ошибочных ситуаций опускаем: полагаем LiveCD найденным и смонтированным;mknod /dev/cloop b 240 0 - l.141, для работы с компрессированным образом LiveCD создаётся файл соответствующего устройства;CDCACHE="yes" (то есть если при начальной загрузке в ответ на приглашение boot> была выбрана опция cdcache, делается попытка скопировать livecd.cloop в память (виртуальную файловую систему - tmpfs) и, если эта попытка была успешной, то устанавливается модуль работы с livecd.cloop, после чего образ монтируется:insmod /modules/cloop.o file=/newroot/mnt/cdrom/livecd.cloop mount -o ro -t ext2 /dev/cloop /newroot/mnt/cloopЭто очень важный момент - он делает возможным в дальнейшем размонтирование инсталляционного CD, его извлечение из привода и замену; на этот момент tmpfs занимает всю свободную память, кроме занятой ядром и "иже с ним" (даже в 64-мегабайтной системе половина ОЗУ обычно попадает в tmpfs); отсюда: практически никогда не возникают трудности при копировании в память 70-мегабайтного
livecd.cloop от Gentoo (и они весьма вероятны при попытке копирования, например, 700-мегабайтного KNOPPIX[.cloop] от knoppix); другое дело, что занимать всю tmpfs - неразумно (а вдруг, после загрузки ещё и сделать что-то захочется?); так что практический вывод: 128 и более Мбайт - вполне достаточно для работы опции cdcache (лично проверено - 386 Мбайт хватает с гарантией);
CDCACHE="no" (в том числе: и из-за неудачи при попытке копировать livecd.cloop в память), то модуль cloop.o устанавливается с параметром file=/newroot/mnt/cdrom/livecd.cloop. То есть: файл - тот же, но уже не из памяти, а непосредственно с CD ROM; и, соответственно, размонтировать последний не удастся; что касается монтирования livecd.cloop, то оно выполняется точно так же, как и в предыдущем случае (l.159-160);/sbin/init, то есть - нормальная загрузка.Таков путь загрузки от BIOS до системы, подготовленной maintainer-ом для выполнения инсталляции. Что бы "улучшить"?
cdcache представляется совершенно не лишней; настолько, что её-то как раз и следовало бы сделать "умолчательной", и в ходе инициализации сообщать оператору: может он демонтировать CD ROM (успешное кэширование) или нет.Для этого редактируются: linuxrc в initrd и help.msg в /isolinux. Разумеется, и add.msg никто не запретит отредактировать...
На уровне isolinux-livecd.cloop - всё. Разумеется, эти "возня" совершенно не обязательно предполагает "прожигание болванок". Отредактированный образ initrd прекрасно воспринимается Grub или LILO: всегда можно собственную редакцию проверить.
Дальнейшее "рукоблудие" предполагает операции с livecd.cloop: исключительно. Это будет
Таким образом, как "образуется" подготовленная maintainer-ом система, думаю, понятно. Посмотрим теперь, что же он нам, собственно, подготовил...
Любой LiveCD предполагает, что его файловая система частично находится в памяти (каталоги с динамически изменяемым содержимым - всегда, каталоги с неизменяемым содержимым - по мере возможности). Что касается первых (/proc, /var, /tmp, /home, /root etc.), то с ними всё ясно: кроме как в памяти им больше и быть негде. Что до вторых, то для обеспечения скорости доступа хорошо бы и им быть на виртуальном диске, но не всегда это возможно: потребности, как правило, обычно превосходят количество доступной RAM. И, чем дальше - тем больше. Глядишь: а для всего ПО, которое хотелось бы иметь в системе, уже и объёма CD не хватает...
Само собой напрашивается желание держать это самое ПО в компрессированном виде, независимо от того, памяти или объёма CD перестало хватать. Средств компрессии - "бери - не хочу". Вот только хотелось бы декомпрессию осуществлять "на лету", на уровне ядра, скажем... Почему - нет? Начал - Поль Рассел (Paul 'Rusty' Russel), "подхватил" известный энтузиаст LiveCD Клаус Кноппер (Klaus Knopper): и вот уже все желающие могут воспользоваться пакетом cloop с сайта Knoppix.
Как конечный продукт (после компиляции), пакет представляет собой три файла:
cloop.o, осуществляющий компрессию "на лету";create_compressed_fs;extract_compressed_fs.Сборка пакета выполняется командой:
$ make KERNEL_DIR=/path/to/linux-kernel/sources
Несложно догадаться, что для компиляции требуется каталог с исходниками ядра. А точнее - конфигурационный файл /usr/src/linux/.config и подкаталог /usr/src/linux/include/linux. Маленькое "но": предполагается, что ветка ядра - xfs. Работоспособный модуль cloop.o действительно был впервые построен только для ядра ветки xfs. Однако не возбраняется и использование другого ядра, например, канонической vanilla.
Для использования модуля потребуются следующие команды:
$ mkdir -p /lib/modules/misc && cp cloop.o /lib/modules/misc/ $ depmod -a $ mknod /dev/cloop b 240 0
Назначение команд, думается, очевидно.
Модуль загружается, например, уже приводившейся командой:
$ insmod /modules/cloop.o file=/newroot/mnt/cdrom/livecd.cloop
где параметр file указывает на компрессированный образ. Возможен и более, так сказать, современный способ загрузки:
$ modprobe cloop file=/path/to/compressed/image
Впрочем, выбор между insmod или modprobe - скорее дело привычки...
Доступ к файловой системе становится возможным, конечно же, после её монтирования. В рассматриваемом LiveCD это:
$ mount -o ro -t ext2 /dev/cloop /newroot/mnt/cloop
Что бы посмотреть, что же находится внутри livecd.cloop, воспользуемся одной из собранных утилит:
$ ./extract_compressed_fs ./livecd.cloop > livecd.loop
Полученный файл монтируем, как обычно. Например:
$ mount ./livecd.loop /mnt/loop -t ext2 -o loop
Смотрим: вполне узнаваемая gentoo-система. Те же конфигурационные файлы и каталоги. Хотим - дополняем документацией на своё усмотрение, хотим - расширяем число установленных пакетов, хотим - конфигурируем на своё усмотрение. Только сначала переносим все каталоги в какой-нибудь /home/myLiveCD, делаем всё необходимое для использования его в качестве корневого, и - chroot!
После того, как будущая LiveCD-система будет признана вполне отвечающей пожеланиям, покинем её (exit), предварительно демонтировав всё лишнее. И создадим наш новый livecd.cloop:
$ mkisofs -r /home/myLiveCD | \ create_compressed_fs - 65536 > livecd.cloop
Полученный файл, наряду с подкаталогами /gentoo и /isolinux оригинального диска, файлами README.html, quickinstall.html и любыми другими, которые мы захотим поместить на создаваемый LiveCD станут объектом компиляции, выполняемой всё той же mkisofs. Правда, опций на сей раз потребуется побольше. Но об этом - у Питера Анвина и в документации на одноименную программу - она достаточно подробна. В /isolinux не забудьте поместить результат работы на предыдущем этапе (initrd и isolinux.cfg). Всё!