Регенерация ядра

Нужно отметить, что регенерация ядра во FreeBSD - процедура практически неизбежная. В отличие от Linux: многих его дистрибутивов никакой потребности в перекомпиляции могут не испытать длительное время. В чем причина?

Во-первых, в модульности ядра Linux. Где поддержка множества устройств, файловых систем и прочего осуществляется двояко: либо прямым ее, поддержки, включением в ядро, либо оформлением внешних модулей, подключаемых по мере необходимости и потому не особенно поглощающих ресурсы.

И потому составители многих (особенно так называемых end-user-ориентированных, вроде Mandrake, скажем) дистрибутивов включают включают модульную поддержку почти всего, что ему, этому самому end'овому user'у может потребоваться впредь: звук, эмуляцию SCSI-протокола через IDE-интерфейс и многое, многое другое. И в принципе, если не стоит каких либо специальных задач или нет веского желания облегчить систему, можно спокойно работать и на ядре, сгенерированном в процессе инсталляции.

Во FreeBSD дело обстоит несколько иначе. Не то что ее ядро менее модульно - оснований для такого суждения у меня нет. Насколько я смог понять, и здесь многие вещи в принципе могут быть реализованы как модули. Но, как известно, в "Принципе" есть все, а вот в реальности... Так что модульная поддержка ряда устройств и файловых систем во FreeBSD просто не реализована. О причинах чего судить не возьмусь.

Вторая причина - в том, что ядро системы, генерируемое при инсталляции FreeBSD (так и называемое - GENERIC), есть еще более обобщенный и абстрактный образ, чем ядро большинства дистрибутивов Linux. Поскольку FReeBSD много сильнее, чем Linux, настроено на установку по сетевым протоколам. Как я скажу ниже, даже нормальная доустановка недостающих компонентов без сети невозможна или очень затруднена. Кроме того, в отличие от Linux же, FreeBSD, как система изначально серверная, более ориентирована на использование SCSI-дисков.

И в итоге разработчикам, чтобы обеспечить успешную первичную установку, пришлось включить в ядро GENERIC поддержку такого широкого спектра и сетевых адаптеров, и SCSI-карт, какого на одной машине по определению быть не может. Пренебрегая, в противовес этому, поддержкой устройств, сочтенных излишествами для серьезного пользователя (тех же звуковых карт, к примеру).

Так что, повторяю, регенерации ядра при общении с FreeBSD избежать, скорее всего, не удастся. Впрочем, процесс это никаких принципиальных сложностей, по сравнению с Linux, не обнаруживает. И к тому же детальнейшим образом документирован Иваном Паскалем в его прекрасном мемуаре FreeBSD глазами администратора. К коему и отсылаю за подробностями.

Правда, процесс регенерации ядра несколько отличен от такового в Linux. В основе его - не интерактивная утилита menuconfig, а прямое редактирование конфигурационного файла, выполняемое средствами любого текстового редактора.

В каталоге /usr/src/sys/i386/conf таких файлов обнаруживается даже два. Естественно, если сами по себе исходные тексты ядра наличествуют (то есть каталог /usr/src/sys/ не пуст). О чем следовало бы позаботится при инсталляции, выбрав соответствующую ее порцию. Но восполнимо и сейчас - посредством все той же sysinstall.

Однако убедившись, что с исходниками ядра все в порядке, я перво-наперво, во избежание тяжких последствий, вернулся бы в корневую директорию, где собственно и имеет место пребывания файла ядра - /kernel, загружаемого при включении машины. И посредством

cp kernel kernel.*

скопировал бы его в новый файл, в имени которого .* будет любым понятным вам мнемоническим обозначением старого ядра, kernel.inst, например, или kernel.nul. Но только - не kernel.old. Почему?

Дело в том, что в процессе регенерации будет создан новый файл kernel, тогда как старый получит имя kernel.old. И при неудаче сборки, то есть получении неработосопосбного ядра (от чего, как говорят резонные люди, не должны зарекаться и опытные сисадмины), систему можно будет перезагрузить с прежним ядром, введя на приглашение загрузчика строчку

kernel.old

и продолжить эксперименты по конфигурированию. Однако при второй попытке регенерации наш собранный собственноручно первым (и неработоспособный!) файл kernel заместить собой работающий kernel.old. И если и эта попытка окажется неудачной, мы будем располагать двумя самодельными вполне непригодными к использованию ядрами - kernel и kernel.old, тогда как исходный (и рабочий) суперстарый kernel просто исчезнет безвозвратно. Тут-то и придет время вспомнить о его копии - ядре нулевой генерации, и спокойно загрузить с него систему для дальнейших развлечений.

Обезопасив себя таким образом, пора вернуться в каталог /usr/src/sys/i386/conf, где можно будет увидеть два простых текстовых файла - CENERIC и LINT. Первый описывает конфигурацию ядро того самого ядра, которое было сгенерировано на стадии инсталляции, второй - включает все возможные опции конфигурирования. В том числе и те, которые вряд ли смогли бы ужиться в одной машине.

Соответственно, путей для конфигурирования ядра - два. Можно взять за основу заведомо работоспособную (коль скоро система наша как-то грузилась) сгенерированную конфигурацию и убирать из нее все лишнее, добавляя необходимое. А можно в качестве базовой принять LINT, но тут уж придется только вычеркивать, и притом - немало.

Естественно, в любом случае, во избежание потери точки отсчета, все изменения следует производить не в оригинала файлов, а их копиях, сохраненных, например, под именем first (дабы в случае фиаско в запасе были бы second и прочие значения из натурального ряда чисел).

Первый способ позволяет подходить к делу поэтапно: добавили/убавили одно устройство - проверили, что получилось. И так далее. Что требует, конечно, времени, но зато позволяет если не избежать проблем, то по крайней мере четко локализовать их.

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

Я опробовал оба способа. Начав, в силу самонадеянности, с первого. Создав конфигурационный файл по своему разумению, исключив полностью все, чего у меня не было (в том числе все SCSI-адаптеры и сетевые карты), и включив - все, что было.

Результат получился скверный. Ни в одном случае мне не удалось дойти даже до стадии загрузки - ядро просто отказывалось компилироваться. Иногда это вызывалось моей очевидной ошибкой, иногда следовали сообщения о нарушении зависимостей; а иногда докопаться до причины мне так и не удалось.

Провозившись таким образом изрядное время, я подумал: а стоит ли игра свеч? Ведь использование самых моих экзотических устройств под FreeBSD было пока проблематичным. Так стоит ли с ними возиться до решения главной проблемы?

И я пошел по первому пути: взял файл GENERIC и внес в него минимально необходимые изменения. Именно об этом я и хочу вкратце рассказать. Поскольку структура LINT не только детально описана, но и прокомментирована Иваном Паскалем в цитировавшемся сочинении. Конечно, в каждой конкретной конфигурации файл GENERIC будет несколько отличаться. Однако, поскольку он описывает некую усредненную конфигурацию, описание его конкретного примера может иметь некий общий смысл,

Но сначала - пару слов о том, на чем все это конфигурировалось:

процессор P-III/733EB (FSB 133 Mhz;
материнская плата MSI-6326 (чипсет i815)$
память 256 Мбайт (2 модуля PC-133 производства квази-Micron);
видеокарта ASUS V3800 Magic (Riva TNT2 64M) с 16 Мбайт памяти;
HDD-1 - IBM 15 Гбайт, ATA-100, 7200 об/мин; HDD-2 - Fujitsu 8 Гбайт, ATA-66, 5400 об/мин;
CD-R/RW Pamasonic 8x4x24, IDE;
Sound Blaster AWE128 (чип Ensoniq1371);
плата видеозахвата, она же TV-тюнер AverMedia Studio на чипе BT-не_помню_сколько;
PS/2 мышь (Logitech, 3-кнопочная) и клавиатура неизвестного происхождения.

Прочие компоненты, типа колонок, думаю, на конфигурирование ядра оказать влияние не в силах.

Итак, файл GENERIC включает в себя строки описания конфигурации (некоторые из которых должны быть обязательно) и скупые комментарии, маркируемые знаком #. Чисто условно (исключительно в целях зрительного восприятия) пустыми строками он разбивается на отдельные секции, никак, впрочем, и не озаглавленными. Тем не менее строение файла я рассмотрю именно по этим секциям, просто для некоей упорядоченности. Оставив без комментариев те фрагменты, смысл которых остался для меня не вполне ясным. Правда, оригинальные комментарии, если они имеются, я сохраняю для определенности.

В моем случае первыми, после комментариев, строками была секция такого вида:

machine    i386
#cpu    I386_CPU
#cpu    I486_CPU
#cpu    I586_CPU
cpu    I686_CPU
ident    GENERIC
maxusers  32

Очевидно, что первая строка указывает, что мы имеем дело с 32-разрядным процессором Intel'овской архитектуры; а не с Альфой, скажем, или прочим PowerPC. И, естественно, является обязательной. А следующие четыре конкретизируют это до типа процессора. По умолчанию все они включены. Но ничего не запрещает закомментировать их все, кроме отвечающей реально имеющемуся "камню", как это сделано в моем случае.

Теоретически компиляция под конкретный процессор должна дать прирост производительности. Но практически - не знаю, проверял ли кто это под FreeBSD количественно. А пример дистрибутивов Linux, скомпилированных под процессоры i586 и i686 (Mandrake начиная с 6-й версии), свидетельствует о сомнительности этого положения. Вызывая в ряде случаев проблемы с некоторыми Intel-клонами.

Следующие две строки в секции - это некий идентификатор данной конфигурации ядра (ident) и максимальное количество пользователей. Первая может иметь абсолютно любое значение (типа My_Best_Kernel), которое при этом не обязано быть уникальным (я, как видно из приведенного, сохранил идентификатор GENERIC, просто по забывчивости, - и ничего, работает. Но сама по себе строка быть обязана.

А про максимальное количество пользователей сказать ничего не могу - оставил исходное значение. Иван пишет, что "...исходя из этого количества вычисляется размер некоторых таблиц в ядре (количество одновременно работающих процессов, количество открытых файлов, количество буферов памяти и т.п.)... Поэтому, даже если на вашей машине и не планируется много юзеров, но вы собираетесь запускать одновременно много приложений, лучше сделать это число побольше." Параметр этот - обязателен.

Следующий блок строк -

#makeoptions  DEBUG=-g
  #Build kernel with gdb(1) debug symbols

указывает, насколько я понял, что в ядро следует включать всякого рода отладочную информацию. Мне, как не-программисту, это не нужно, и я оставил ремарки, бывшие в оригинале. Очевидно, что строка эта не обязательна.

Далее единым блоком идет некая сборная солянка, которую я чисто произвольно разобью на несколько секций в меру совей испорченности:

#options   MATH_EMULATE
  #Support for x87 emulation

Очевидно, что это эмуляция математического сопроцессора. При наличии встроенного - никакой необходимости в ней нет.

Далее - сетевые системы и протоколы:

options   INET
  #InterNETworking
options   INET6
  #IPv6 communications protocols

Ничего не понимая в этом, оставил все без изменений, на всякий случай. Ведь поддержка всякого TCP/IP требуется и при работе на локальной машине.

Затем - файловые системы: options FFS #Berkeley Fast Filesystem options FFS_ROOT #FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support

Первая строка - родная система FreeBSD, без поддержки которой работать в ней, думается, несколько затруднительно. Вторая строка разрешает зашрузку с устройства, имеющего ffs. Резонное желание грузиться с собственного раздела, не так ли? А вот смысла третьей строки я не понял, оставив все как и было.

Затем - о чуждых файловых системах:

options  EXT2FS

Это поддержка файловой системы Linux, ради чего весь огород и городился. В исходном файле, естественно, отсутствовала, в LINT была помечена как экспериментальная. В виде модуля не реализована, поэтому при необходимости должна быть включена в ядро. Иван ее работоспособность тоже не гарантирует. К счастью, у меня все обошлось...

#options   MFS
  #Memory Filesystem
#options   MD_ROOT
  #MD is a potential root device

Эти две строки включают поддержку того, что в DOS некогда называлось RAM-диском, и разрешает поддержку с такого устройства. В чем нынче необходимость увидеть трудно. Разве что если оперативную память некуда девать, можно работать с такого диска и с программами, и с данными. Причем - со страшной научно-фантасчисекой скоростью. Чего, впрочем, на практике не проверял...

options   NFS
  #Network Filesystem
options   NFS_ROOT
  #NFS usable as root device, NFS required
options   MSDOSFS
  #MSDOS Filesystem
options   CD9660
  #ISO 9660 Filesystem
options   CD9660_ROOT
  #CD-ROM usable as root, CD9660 required
options   PROCFS
  #Process filesystem

Смысл этих строчек понятен: поддержка разделов FAT, файловой системы CD ROM, загрузки с последних и т.д. Очевидно, что ряд опций сцеплены: трудненько было бы загрузиться с CD при отсутствии поддержки iso9660... Ну а поддержка системы proc в Linux рассматривается как обязательная, думаю, здесь - также.

options   COMPAT_43
  #Compatible with BSD 4.3 [KEEP THIS!]
options   SCSI_DELAY=15000
  #Delay (in ms) before probing SCSI
options   UCONSOLE
  #Allow users to grab the console
options   USERCONFIG
  #boot -c editor
options   VISUAL_USERCONFIG
  #visual boot -c editor
options   KTRACE
  #ktrace(1) support
options   SYSVSHM
  #SYSV-style shared memory
options   SYSVMSG
  #SYSV-style message queues
options   SYSVSEM
  #SYSV-style semaphores
options   P1003_1B
  #Posix P1003_1B real-time extensions
options   _KPOSIX_PRIORITY_SCHEDULING
options    ICMP_BANDLIM
  #Rate limit bad replies
options   KBD_INSTALL_CDEV
  # install a CDEV entry in /dev

Смысл строк приведенного выше блока или очевиден, или для меня непонятен и потому оставлен без комментариев. Кое о чем можно почитать у Ивана.

Далее следует секция о мультипроцессорности, которую я за отсутствием практического (для меня значения) опускаю. А тот, кто рискнет настраивать мультипроцессорную станцию, думаю, разбирается в этом уж получше меня.

Далее на полдюжины экранов идет ряд секций, посвященных конфигурированию устройств, как реальных, так и именуемых pseudo. Смысл многих строк ясен из названия (isa, pci, ata и так далее). Я пока ничего здесь не менял и от комментариев воздержусь. Хотя очевидно, что в реальной машине всего этого богачества быть не может, и большую часть строк можно безболезненно изъять...

Завершив редактирование конфигурационного файла (и не забыв сохранить изменения под мнемонически понятным именем, например, first), осуществляем собственно конфигурирование (оставаясь в том же каталоге /usr/src/sys/i386/conf):

config first

что создаст каталог /usr/src/sys/compile/firts, куда будут помещены все необходимые в дальнейшем файлы. В этот каталог и лежит теперь наш путь, чтобы, по рекомендации Ивана, дать там команду для собственно компиляции ядра

make

Правда, при этом последует предупреждение, что не выполнено уставновление зависимостей (на которое я, честно говоря, поначалу не обратил внимания). Так что, вероятно, make следовало бы предварить командой

make depend

Однако, как ни странно, если конфигурационный файл составлен без грубых ошибок, компиляция начнется в любом случае. Хотя сообщения об ошибках и, соответственно, ее аварийное завершение, могут произойти уже в ее ходе. Как у меня и было при попытках создать нечто монументальное из LINT. Тогда как чуть подправленная конфигурация GENERIC собралась с первого же раза (не смотря на то, что никаких зависимостей я не строил и в этот раз).

Говорят, процесс компиляции может быть весьма долгим. У меня он (при заведомой избыточности конфигурации - от сетевых и SCSI-адаптеров я так и не избавился) занял 7 минут - преимущество быстрой машины. Хотя при регенрации ядра все равно основное время тратится на редактирование конфигурационного файла и последующее исправление напортаченного. Так что ради экспериментов с ядром обзаводиться Восьмиумом резона нет.

По завершении (успешном, разумеется) компиляции новое ядро должно быть водружено на подобающее ему место, то есть в корневой каталог. Делается это командой

make install

которая одновременно и переименовывает старое ядро в kernel.org. Исходя из общих соображений, мне кажется, что и ей должна предшествовать команда

make clean

ликвидирующая следы жизнедеятельности компилятора. Но указаний на необходимость этого в доступной мне литературе я не нашел. И сам без нее обошелся...

А вот теперь наступает волнующий момент - перезагрузка системы с новым ядром. Кстати говоря, во FreeBSD, как и Linux, это можно проделать разными способами: командой halt или shutdown, вызывающими останов системы (первая - сразу, вторая - после заданного промежутка времени), командой reboot, приводящей к останову и немедленной перезагрузке. правда, все они требую прав суперпользователя.

Ну а простому смертному пришлось бы прибегнуть к бессмертной комбинации из трех пальцев (если эта возможность, конечно, не запрещена при генерации ядра - в ядре GENERIC использование Alt+Control+Delete по умолчанию разрешается). Единственное, что очень не рекомендуется использовать для перезагрузки - так это кнопку Reset на корпусе или сетевую вилку: последствия могут быть весьма плачевными (как, впрочем, и в Linux).

Ну так вот, перезагружаем систему любой из команд (излишне говорить, что и все манипуляции с ядром можно сделать только от лица root'а). И внимательно смотрим на экран в ожидании какого-либо неприятного сообщения и прекращения загрузки. Мне, правда, не довелось узнать, впадает ли FreeBSD в то состояние, которое в Linux именуется panic mode: с первого же раза система загрузилась нормально.

Я вздохнул с облегчением (не смотря на то, что меры по технике безопастности, описанные выше, принял). И приступил к дальнейшему исследованию системы.

Результаты этого исследования будут описаны в дальнейших разделах. Пока же скажу, что первой цели своей - получить доступ к Linux-разделам с данными, - я достиг. Они спокойно монтировались соответствующей командой, о чем я поведаю при разговоре о функциональности.

[Назад] [Содержание] [Вперед]