Взгляд ушастого ламера на компиляцию ядра из исходников...

sda00

2007-12-13

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

Какие могут быть причины для подобного шага? Их всего три:

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

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

Нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый diff файл или тянуть десяток мегабайт кем-то скомпиленного готового ядра? это справедливо для любых "крупных" пакетов, будь то OpenOffice, kernel, E17.

Ещё один спорный момент: монолит или модульное? На ваше усмотрение, господа присяжные заседатели. С точки зрения "ламера ушастого" - монолит ноне не нужен.

Что нам понадобится из "инструментария":

Meld (пользователи SuSE имеют в "загашнике" JMeld) и конфиг ядра дистрибутива, работающего в данный момент (стоит ли напомнить, что желательно иметь одинаковую major версию ядра - например, 2.6.*?). Предположим, что конфиг вкомпилен в ядро и его можно "достать" командой:

>zcat /proc/config.gz

что мы и делаем в качестве нашего первого шага:

zcat /proc/config.gz > /home/USER/config_current

распаковываем исходники нового ядра и выполняем:

make menuconfig

затем выбираем опцию:

"Load an Alternate Configuration File" -> /home/USER/config_current

тем самым загружая текущую конфигурацию ядра. После сразу же делаем:

"Save an Alternate Configuration File" -> /home/USER/config_new

всё, что нам осталось сделать, это пройтись meld-ом по этим двум файлам (config_current и config_new) и сформировать наш будущий конфиг с учётом всех новых опций, загрузив его уже известным "Load an Alternate Configuration File". Если есть сомнения в параметрах новых опций - ставим "=m", видим явно лишнюю опцию - комментируем, ставя в начало строки "#". Желаете описание каждой опции в параметрах конфигурации ядра - читайте документацию. Основное правило: в ядро - только необходимый минимум, всё, что только можно, - вынести в модули. Именно при таком подходе можно получить выигрыш во времени как при старте системы (подгружая только необходимое), так и по использованию памяти самим ядром.

N.B. товарищ, помни: "автоматом" подгрузить модуль можно, но выгрузить - только "вручную" (как вариант - использовать скрипты -"обвязки").

Дальнейшие команды по сборке и установке нового ядра (make dep && make clean успели устареть):

make
make modules
sudo make modules_install
sudo make install

Необязательные (но иногда крайне полезные) команды, выполняемые после установки (но до перезагрузки). Если внимательно смотреть на вывод предыдущих 2-х команд, то в них нужды особой нет (так как именно они и выполняются в процессе), хотя...:

sudo depmod -a
(sudo depmod -aq)

Смотрим на вывод команды и проверяем, какие модули будут активированы при загрузке того или иного установленного в системе ядра и собственно проверяем корректность map файла нового ядра. Эта команда позволит сравнить загружаемые модули вашего старого/(старых) и только что установленного нового кернела. Излишне, пожалуй, говорить, что практически все проблемы разряда "сабрал новае видро а ано нигрузиццо..." могут/должны быть устранены на этой стадии.

В зависимости от системы можно (естественно при желании) пересобрать Initial RAM Disk командами "mkinitrd" или "mkinitcpio" (обратите внимание на /etc/mkinitcpio.conf!!! отсутствие необходимых опций в нём может привести к провалу при загрузке нового ядра) - читайте справку по опциям. Приведу для примера свой /etc/mkinitcpio.conf:

MODULES="pata_via sata_via reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata usbinput keymap filesystems"

Сие означает, что на чипсете VIA имею IDE и SATA винты, плюс пользую reiserfs. Основная же нагрузка падает на HOOKS. Для понимания оных - читайте доки и комментарии в самом /etc/mkinitcpio.conf (мне хватило комментариев).

На закуску - несколько интересных статей в продолжение темы:

Ядерная физика для домохозяйки

Ещё одна абсолютно чумовая статейка с использованием временных "рэперов" и живым примером перехода от 2.4 до 2.6:
Установка ядра linux-2.6.1 (вместо 2.4.x)

Намеренно не затронут вопрос модификации загрузчика (внесения нового ядра в список оного) - ибо пошло и неинтересно.