среда, 31 октября 2007 г.

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

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

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

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

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

нюанс... при дороговизне трафика сборка из исходников полностью себя оправдывает. тратить деньги за десяток килобайт на сжатый 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)

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

7 комментариев:

Анонимный комментирует...

А вот почему бы не вкомпилить модули, необходимые для работы жёсткого диска, сетевой карты, корневой файловой системы и т.п монолитно? Ядро Linux'a всё-таки относится к монолитным ядрам, пусть и с некоторой поддержкой модульнотсти.
Всё в ядре и вообще никакой мороки с модулЯми?

Анонимный комментирует...

Таки рекомендую сходить на
http://ru.opensuse.org/%D0%A1%D0%B1%D0%BE%D1%80%D0%BA%D0%B0_%D1%8F%D0%B4%D1%80%D0%B0_Linux_-_SuSE_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4
Если уж речь зашда о сборке ядра для SUSE, в частности там предлагается собирать сразу rpm командой
make rpm

Анонимный комментирует...

Млин, ссылка корявая получилась
http://ru.opensuse.org/Сборка_ядра_Linux_-_SuSE_метод

sda комментирует...

HighwayStar
спасибо за комментарий. тут есть один очень интересный момент (на который многие не обращают внимания). стоит ли системе знать о наличии "нашего" ядра? если "да", то правильным будет сперва сделать .spec файл, по которому и собрать ядро (где и учесть 'depmod', 'mkinitrd' и т.п.). мне всё же кажется, учитывая, что ядра SuSE (за некоторыми исключениями) смело можно назвать эталоном, не стоит. ибо в противном случае (при сборке rpm ядра) нам потребуется указать системе о наличии именно 2-х кернелов (при rpm -i) и чуток подшаманить дабы не пропустить security kernel updates от SuSE (чего делать ни в коем случае не рекомендую). использовать же в SuSE только свои ядра равносильно потере функционала (пример - AppArmor). опять же никогда нельзя забывать, что "на заборе много чего может быть написано". и мой блог для некоторых вполне этим самым "забором" может оказаться. перед тем, как что-то делать нелишне иной раз просто подумать...

Анонимный комментирует...

Что-то я не понял тебя про .spec файл. Когда собираем ядро командой
make rpm
вместо просто
make
то как раз сначала make создает .spec файл для ядра, потом копирует куда надо сурцы и собирает kernel.rpm и kernel.src.rpm

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

Анонимный комментирует...

Про AppArmor погуглил и вышел на Security Through LSM: Linux Security Modules Interface.
В ванильном ядре есть только универсальные интерфейсы для систем безопастности таких как AppArmor и SELinux.
Сам AppArmor в user-space. Ссылка
http://en.opensuse.org/AppArmor_Detail

sda комментирует...

если судить по статье, то после rpm -i нужно руками задать mkinitrd, что есть свидетельство кривого %post скрипта в spec файле. с "канонической" точки зрения основа любого rpm есть spec файл. make rpm, равно как и checkinstall есть суть костыли для ниасиливших формирование спека. исходники AppArmor для нормального наложения патча на ядро я не нашёл (выдирать же из SuSE лениво). говорить, что SuSE пользует ванилу - бред. есть специальный репо для этого (кому именно нужны vanilla kernel). SuSE всегда был славен поддержкой железа, что достигалось вылизыванием патчей, попадавших в "шоколад" гораздо позже, чем в ядро SuSE.