Gentoo LiveCD изнутри

Данные Разработка Безопасность Инфраструктура Курсы и книги

2005 г.

Gentoo LiveCD изнутри
Анализируем LiveCD от Gentoo Linux

Версия 1.1, 30 мая 2005 г.
Версия 1.0 - на Unix.ginras.ru

Вступление

В этой статье описывается внутреннее устройство инсталляционного диска Gentoo Linux, позволяющего не только выполнить не только первичную установку этого дистрибутива, но и использовать его для аварийно-восстановительных работ. А также просто для начального знакомства с системой - то есть в качестве LiveCD-дистрибутива.

Несмотря на привязку к конкретному дистрибутиву, и даже к определенному диапазону его версий - 1.4 (RC2-RC4), описанные здесь приемы применимы к LiveCD, построенному на базе почти любой иной Linux-системы.

Часть 1. От BIOS до загрузки

Не вдаваясь в подробности устройства весьма (и - заслуженно) популярного пакета 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 и в более новых версиях может незначительно отличаться):

определение переменных (l.9-12) опускаем. Очевидно;
mount -oremount,rw / - l.13, монтирование "корня" в режиме чтения/записи;
mount /proc - l.14, монтирование /proc (потребуется для операции смены корневого каталога командой chroot);
команды, прокомментированные в тексте скрипта, "переописывать" не будем, определение переменных (l.17-29) - также опускаем;
mkdir newroot - l.40, создаём каталог, который впоследствии и станет новым "корнем";
mount -t tmpfs tmpfs /newroot - l.41, монтируем к нему виртуальную файловую систему (другой-то у нас и нет);
и создаём все необходимые подкаталоги: l.43;
если в каталоге /newroot/dev/ не обнаруживается .devfsd (а откуда он там возьмётся?) - монтируем devfs к /newroot/dev: l.48;
далее, если вы не отказались от определения SCSI, в соответствие со списком (l.134) будет предпринята попытка загрузки (командой insmod -f) всех перечисленных модулей. В результате модули поддержки обнаруженных контроллеров будут установлены (l.130-135);
предложение загрузить keymap (l.137) интереса не представляет - ни на какую локализацию это в дальнейшем не повлияет; напротив, выбор русской раскладки, вследствие странности оной, может только доставить неудобства;
после чего предпринимается попытка монтировать LiveCD (l.140): все устройства /newroot/dev/cdroms/ монтируются и проверяются на наличие на них файла /livecd.cloop. Обработку ошибочных ситуаций опускаем: полагаем LiveCD найденным и смонтированным;
mknod /dev/cloop b 240 0 - l.141, для работы с компрессированным образом LiveCD создаётся файл соответствующего устройства;
далее (l.145) при значении переменной 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

livecd.cloop

KNOPPIX[.cloop]

cdcache

если же CDCACHE="no" (в том числе: и из-за неудачи при попытке копировать livecd.cloop в память), то модуль cloop.o устанавливается с параметром file=/newroot/mnt/cdrom/livecd.cloop. То есть: файл - тот же, но уже не из памяти, а непосредственно с CD ROM; и, соответственно, размонтировать последний не удастся; что касается монтирования livecd.cloop, то оно выполняется точно так же, как и в предыдущем случае (l.159-160);
операции копирования и создания символических ссылок (l.166-173) завершают формирование новой корневой системы;
а l.181-182 окончательно делают её активной корневой; запускаемый процесс - /sbin/init, то есть - нормальная загрузка.

Таков путь загрузки от BIOS до системы, подготовленной maintainer-ом для выполнения инсталляции. Что бы "улучшить"?

более естественным для варианта "по умолчанию" представляется отсутствие SCSI;
опция загрузки cdcache представляется совершенно не лишней; настолько, что её-то как раз и следовало бы сделать "умолчательной", и в ходе инициализации сообщать оператору: может он демонтировать CD ROM (успешное кэширование) или нет.

Для этого редактируются: linuxrc в initrd и help.msg в /isolinux. Разумеется, и add.msg никто не запретит отредактировать...

На уровне isolinux-livecd.cloop - всё. Разумеется, эти "возня" совершенно не обязательно предполагает "прожигание болванок". Отредактированный образ initrd прекрасно воспринимается Grub или LILO: всегда можно собственную редакцию проверить.

Дальнейшее "рукоблудие" предполагает операции с livecd.cloop: исключительно. Это будет

Часть 2. Углубленное потрошение

Таким образом, как "образуется" подготовленная 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). Всё!