Компиляция ядра Linux

---

Требуемые пакеты

Пакеты Red Hat 7.0 и 7.1:

1. glibc-x.x.x-x.i386.rpm
2. ncurses-x.x.x-x.i386.rpm
3. kernel-headers-x.x.x-x.0.i386.rpm
4. kernel-source-x.x.x-x.0.i386.rpm
5. glibc-devel-x.x.x-x.i386.rpm
6. cpp-x.x.x-x.i386.rpm
7. make-x.x.x-x.i386.rpm
8. ncurses-devel-x.x.x-x.i386.rpm
9. libstdc -devel-x.x.x-x.i386.rpm
10. gcc-c -x.x.x-x.i386.rpm
11. dev86-x.x.x-x.i386.rpm (contains the x86 Assembler)

Пакеты Red Hat 6.2:

1. glibc-2.1.3-15.i386.rpm
2. ncurses-5.0-11.i386.rpm
3. kernel-headers-2.2.14-5.0.i386.rpm
4. kernel-source-2.2.14-5.0.i386.rpm
5. glibc-devel-2.1.3-15.i386.rpm
6. cpp-1.1.2-30.i386.rpm
7. make-3.78.1-4.i386.rpm
8. ncurses-devel-5.0-11.i386.rpm
9. egcs-1.1.2-30.i386.rpm
10. egcs-objc-1.1.2-30.i386.rpm
11. dev86-0.15.0-2.i386.rpm (contains the x86 Assembler)

1. kernel-doc-2.2.14-5.0.i386.rpm <---- Необязательный
2. glibc-profile-2.1.3-15.i386.rpm <---- Необязательный
3. egcs-g77-1.1.2-30.i386.rpm <---- Необязательный
4. egcs-c -1.1.2-30.i386.rpm <---- Необязательный

1. kernel-doc-2.2.14-5.0.i386.rpm <---- Необязательный
2. glibc-profile-2.1.3-15.i386.rpm <---- Необязательный
3. egcs-g77-1.1.2-30.i386.rpm <---- Необязательный

---

Этапы перестроения ядра

1. Перейдите в исходный каталог Linux


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

Для изменения базового ядра Red Hat просто перейдет в каталог /usr/src/linux. Загруженные ядра не должны помещаться в /usr/src.

/usr/src/linux - это гибкая ссылка, которая указывает на текущий исходный каталог Linux, например: ln -s linux-2.4.2 /usr/src/linux


2. Редактирование EXTRAVERSION = строка в Makefile


Строка "EXTRAVERSION = " вверху Makefile определяет имена директорий, имена ядер, и т.д., которые будут использоваться при создании нового ядра и модулей. Обновление этой строки предотвратит путаницу и воспрепятствует тому, чтобы система затёрла сама себя. Изменяя эту строку, Вам больше не надо перемещать в сторону старую "/lib/modules/x.x.x" директорию.

Метод, который я обычно использую, для строки extraversion это установка даты и времени. Вот пример extraversion, если бы я собирался создать новое smp (smp = многопроцессорный) ядро 18 мая 2001 в 16:30 (обратите внимание на стоящее в начале тире, оно удобно для более лёгкого чтения):

EXTRAVERSION = -20010518-1630smp

Если бы создавал такое же ядро, только non-smp, нужно было бы создать строку extraversion в Makefile следующим образом:

EXTRAVERSION = -20010518-1630

3. make mrproper (first time / optional after first time)


Команда "make mrproper" действительно выполняет полную работу по очистке, включая удаление любых старых .config файлов, находящихся в исходной директории.

Примечание: Вы можете не запускать "make mrproper" каждый раз, когда пытаетесь построить ядро. Я бы порекомендовал запустить эту команду, хотя бы в первый раз при создании ядра.


4. Настройка arch/i386/defconfig (необязательно, но я рекомендую делать это)


Цель данного шага убедиться, что arch/i386/defconfig заполнен в соответствии с Вашими надобностями.

При запуске "make oldconfig" будет просматриваться файл .config (при наличии) за ответами на каждый вопрос по конфигурации. Если там не будет найдено ответа, затем будет просмотрен файл arch/i386/defconfig. Если ответ не будет найден ни в одном из файлов, тогда пользователю будет предложено ввести ответ. Отметьте, что "make mrproper" удаляет файл .config. "make xconfig" должен вести себя тем же самым способом, как "make oldconfig", но я не проверил это пока.

Пожалуйста, обратите внимание, что каждый раз, при запуске "make oldconfig", Вы должны знать содержимое arch/i386/defconfig (обычно копируется из каталога configs/.), и .config должен существовать (если у Вас нет старого .config, тогда я бы рекомендовал скопировать arch/i386/defconfig в .config следующим образом: cp arch/i386/defconfig .config)

Я настоятельно рекомендую иметь рабочий установленный файл arch/i386/defconfig, это облегчит создание годного файла .config -- без него Вам придётся отвечать на много, много вопросов, при создании нового файла .config при следующих шагах построения ядра.

Вы можете заполнить arch/i386/defconfig одним из 3 методов:


• Использование существующего файла "arch/i386/defconfig".


Вы обнаружите, что arch/i386/defconfig уже есть. Случайно я заметил, что этот файл не настроен так, как нужно мне. Имейте в виду, что Red Hat долежн грузиться со всем, что создано, как модули. Если Вы заметите, что почти всё в arch/i386/defconfig установлено на "no" (заблокировано или выключено), тогда я бы настоятельно рекомендовал заменить arch/i386/defconfig, как показано в других методах данного шага.


• Использование файла стандартной конфигурации, имеющегося в Red Hat (файл конфигурации из каталога "configs").


Red Hat предоставляет несколько файлов стандартной конфигурации, которые хранятся в каталоге "configs". Выберите любой с соответствующим названием и скопируете его в "arch/i386/defconfig". Например: "cd /usr/src/linux-2.4; cp configs/kernel-2.4.2-2-i386.config arch/i386/defconfig".


• Использование собственного файла ".config".


Вы можете взять старый, используемый файл .config и скопировать его в arch/i386/defconfig. Данный метод поможет свести к минимуму изменения конфигурации рабочего ядра -- что замечательно в этом так то, что используя этот метод, выполнив "make mrproper" и "make oldconfig" Вы получаете эффект "восстановление значения по-умолчанию".

Пожалуйста, обратите внимание, что каждый раз, при запуске "make oldconfig", Вы должны знать содержимое arch/i386/defconfig (обычно копируется из каталога configs/.), и .config должен существовать (если у Вас нет старого .config, тогда я бы рекомендовал скопировать arch/i386/defconfig в .config следующим образом: cp arch/i386/defconfig .config)




5. Создание файла ".config"


Примечание: Выберите один из следующих методов для создания файла ".config" (файл конфигурации ядра). Я предлагаю использовать следующую команду: yes "" | make oldconfig, или, если Вы интересуетесь, что нового в Вашем ядре, запустите просто "make oldconfig".

Пожалуйста, отметьте, что каждый раз при запуске "make oldconfig" Вы должны знать содержимое arch/i386/defconfig (обычно копируется из каталога configs/.), и .config должен существовать (если у Вас нет старого .config, тогда я бы рекомендовал скопировать arch/i386/defconfig в .config следующим образом: cp arch/i386/defconfig .config)




• Запуск "make oldconfig" создаст новый .config основанный на ответах, найденных в arch/i386/defconfig. Вам предложат ответить на вопросы, которые не перечислены в arch/i386/defconfig.

Пожалуйста, обратите внимание, что каждый раз, при запуске "make oldconfig", Вы должны знать содержимое arch/i386/defconfig (обычно копируется из каталога configs/.), и .config должен существовать (если у Вас нет старого .config, тогда я бы рекомендовал скопировать arch/i386/defconfig в .config следующим образом: cp arch/i386/defconfig .config)




• Запуск "make xconfig" делает то же, что и "make oldconfig"; однако Вам не будет предложено ввести ответы на отсутствующие пункты в arch/i386/defconfig.


6. Настройка ядра


Теперь, когда Ваш файл ".config" на месте, мы должны поработать над ним, чтобы создать ядро, какое Вам надо (также называется настройкой ядра).

Примечание: Выберите один из следующих методов для настройки ядра.


• make config


Утилита конфигурации ядра из командной строки. Данная утилита переходит от одного вопроса к другому. Данная утилита не позволяет вернуться к предыдущему вопросу. Может быть немного трудоёмко, чтобы ответить на все вопросы, особенно, если нет вопроса, который ищете. Эта утилита, вероятно, полезна как бэкэнд для некоторой другой утилиты сценариев. CTRL C прерывает работу утилиты "make config".


• make menuconfig


Утилита настройки ядра Ncurses (ncurses = символьная графика). Здесь Вы можете указывать и выбирать, на какие вопросы Вы ответите.


• make xconfig


Утилита настройки ядра GUI (X-Windows). Здесь Вы можете указывать и выбирать, на какие вопросы Вы ответите.

Примечание: "make xconfig" должно быть самая легкая утилита конфигурации ядра для использования.


7. make clean


"make clean" очистит от устаревших файлов исходные каталоги ядра.


8. make dep


"make dep" создаст все нужные подчинённые файлы.


9. Создание ядра


Примечание: Выберите bzImage для создания ядра.


• make bzImage


Создаёт bzip сжатый образ ядра. Наверное, это самый популярный метод.


• make zImage - (будет прекращен в будущем)


Создаёт сжатый образ ядра. Результирующее ядро обычно больше, чем ядро bzImage. Использование zImage не поощряется, так как возможно перестанет использоваться в будущем, пожалуйста, пользуйтесь вместо него bzImage.


• make bzdisk - (only for floppy)


Создаёт bzip сжатый образ ядра на дискете в /dev/fd0. Много есть способов создания загрузочной дискеты, это один из них.


10. make modules


Эта команда формирует модули ядра.


11. make modules_install


Данная команда устанавливает модули ядра. Данные модули будут помещены в каталог /lib/modules. И снова, имя каталога, который будет использоваться, определяется строкой "EXTRAVERSION = " в Makefile, не забудьте обновить информацию EXTRAVERSION при каждой попытке создания ядра.


12. Установка ядра (/boot)


Скопируйте и переименуйте: Скопируйте и переименуйте ядро из arch/i386/bzImage в /boot/vmlinuz-newkernelversion. Вот пример smp ядра 2.4.2 созданного 18 мая 18 2001 в 16:30:

cp arch/i386/bzImage /boot/vmlinuz-2.4.2-20010518-1630smp

Создайте ссылку: Вы также можете создать гибкую ссылку для /boot/vmlinuz:

ln -s /boot/vmlinuz-2.4.2-20010518-1630smp /boot/vmlinuz

Примечание: Если старый /boot/vmlinuz является файлом (не символьной ссылкой) я переименую его в vmlinuz-old.

Примечание: Если старый /boot/vmlinuz является символьной ссылкой я удалю ссылку и затем сгенерирую новый, как показано выше.


13. Установка System.map (/boot)


System.map формируется в исходном каталоге ядра (текущий каталог - смотри шаг 1)

Скопируйте и переименуйте: Я бы рекомендовал переименовать этот файл с использованием того же соглашения об именах, что и для каталога модулей (/lib/modules/2.4.2-x.x.x-x). Вот образец файла System.map для smp ядра 2.4.2 созданного 18 мая 2001 в 4:30pm:

cp System.map /boot/System.map-2.4.2-20010518-1630smp

Создайте ссылку: Затем я создам гибкую ссылку для /boot/System.map:

ln -s /boot/System.map-2.4.2-20010518-1630smp /boot/System.map

Примечание: Если старый /boot/System.map является файлом (не символьной ссылкой) я переименую его в System.map-old.

Примечание: Если старый /boot/System.map является символьной ссылкой я удалю ссылку и затем сгенерирую новый, как показано выше.

Примечание: System.map определяет функции ядра. Судя по всему, этот файл полезен для отладки проблем ядра и возможно, не требуется для корректной работы ядра.


14. Создайте новый initrd и установите его


В initrd содержатся требуемые при загрузке драйвера SCSI.

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

Примечание: Создание initrd требуется только в том случае, если требуется загрузка SCSI драйверов (и драйверов Compaq массива), как модулей. Если у Вас нету никаких драйверов SCSI (или драйверов Compaq массива), которые требуют загрузки в качестве модулей, Вам не нужно создавать initrd.

Создать initrd просто:


1. Проверьте содержимое файла /etc/conf.modules или /etc/modules.conf (в зависимости от имеющейся версии)


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

alias scsi_hostadapter cpqarray
alias scsi_hostadapter1 ncr53c8xx
alias scsi_hostadapter2 ncr53c8xx

Примечание: Если у Вас несколько контроллеров, загрузочный должен быть обозначен, как "scsi_hostadapter", а другие контроллеры названии добавляют номер по порядку "scsi_hostadapter1" "scsi_hostadapter2" "...".


2. Запуск команды mkinitrd


Удостоверьтесь, что пользуетесь тем же соглашением об именах, которое было использовано в /lib/modules, vmlinuz, и System.map:

mkinitrd -v /boot/initrd-2.4.2-20010518-1630smp.img 2.4.2-20010518-1630smp

Cинтаксис вышеупомянутый команды:


• -v = подробный экранный вывод
• /boot/initrd-2.4.2-20010518-1630smp.img = файл для создания
• 2.4.2-20010518-1630smp = каталог для считывания модулей (/lib/modules/x.x.x-x)


3. Вдобавок, Вы можете создать гибкую ссылку initrd:

ln -s /boot/initrd-2.4.2-20010518-1630smp.img /boot/initrd.img

15. Проверьте содержимое /etc/lilo.conf


Для /etc/lilo.conf я бы рекомендовал 2 позиции:


• Одна - для текущего (нового) ядра
• Одна - для последнего гарантированно работоспособного ядра

Каждая строка "label=" в /etc/lilo.conf должна быть уникальной.

Данные записи в /etc/lilo.conf могут быть сделаны для указания на гибкую ссылку или для указания на реальные файлы.

Рекомендуется, чтобы был отдельный раздел, в котором находятся гибкие ссылки для vmlinuz, для того, чтобы Вы могли, используя подпрограмму "make install", установить ядро Linux и ядро бы автоматически куда требуется, подключалась бы гибкая ссылка для vmlinuz к новому ядру в /boot, и автоматически запускался бы /sbin/lilo. Однако; Вам всё же придётся создать новый initrd, разместить там, где нужно, отредактировать /etc/lilo.conf, и снова запустить /sbin/lilo. Не уверен создается ли командой "make install" новый System.map - надо будет проверить.

Вот пример /etc/lilo.conf:

boot=/dev/sda1
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
linear
default=linux
message=/boot/message

image=/boot/vmlinuz-2.2.18-1.3smp
	label=linux-221813smp
	initrd=/boot/initrd-2.2.14-5.0smp.img
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

image=/boot/vmlinuz-2.2.19-200104091621
	label=linux-2219
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

other=/dev/sda3
	label=cpqconfig

image=/boot/vmlinuz-2.4.2-2smp
	label=linux
	initrd=/boot/initrd-2.4.2-2smp.img
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

image=/boot/vmlinuz-2.4.2-2
	label=linux-up
	initrd=/boot/initrd-2.4.2-2.img
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

Ввиду вышесказанного, я переименую раздел с label=linux в label=linux-old. Затем, вероятнее всего, добавлю новый раздел:

image=/boot/vmlinuz
	label=linux
	initrd=/boot/initrd.img
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

Также мы можем добавить раздел следующим образом:

image=/boot/vmlinuz-2.4.2-20010518-1630smp
	label=linux-2.4.2-20010518-1630smp
	initrd=/boot/initrd-2.4.2-20010518-1630smp.img
	read-only
	root=/dev/sda6
	append="hda=ide-scsi"

Проверьте, чтобы старый раздел указывал на старое ядро - в случае, если Ваше новое ядро не загружается.

Также проверьте, что новый раздел указывает на новое ядро:


• Проверьте строку "image="
• Убедитесь, что нет повторяющихся строк "label=", где угодно в файле /etc/lilo.conf
• Проверьте строку "initrd="
• Проверьте, чтобы "root=" указывал на верный дисковый раздел
• Проверьте, чтобы "boot=" указывал на верный загрузочный сектор:


"boot=" самая первая строка в файле /etc/lilo.conf. Убедитесь, что "boot=/dev/sda1" указывает либо на MBR либо на первый сектор загрузочного раздела, в зависимости от того, как настроена система.

Примечание: Если Вы переносите LILO с MBR на загрузочный раздел, Вам следует убедиться, что Вы удалили LILO из MBR (смотрите procedures/mbr.html для более подробной информации).

Строка "boot=" определяет, куда будет установлен LILO.


Примечание: Буква "z" в vmlinuz означает сжатие; поэтому, vmlinux - это несжатое ядро.

Примечание: Установите требуемые значения default= и timeout= .


16. /sbin/lilo


После того, как Вы убедились, что /etc/lilo.conf указывает во все нужные места, запускаем /sbin/lilo.

Теперь у Вас должно получиться загрузиться с новым ядром.

---

Контроль сборки Вашего ядра

1. Используйте команду "script".


Как только стартует script, он начинает вести log-файл всего в "typescript". Когда запись событий будет не нужна наберите слово "exit". Затем Вы можете просмотреть содержимое файла "typescript".


2. Можно выполнить отдельные команды, как эти, и получить в разные файлы обычный вывод и лог-ошибок:



your_command 2>>kernel_err.log 1>>kernel_out.log

3. Вы можете запустить все команды в цикле for и получить отдельные лог-файлы вывода/ошибок:



cd /usr/src/linux; vi Makefile; for X in mrproper xconfig clean dep bzImage modules modules_install; do make $X 2>/tmp/kernel-${X}-error.log 1>/tmp/kernel-${X}-output.log; if [ $? -ne 0 ]; then echo Error, check error logs in /tmp break; fi done

4. Вы можете запустить все команды в цикле for и получить все данные вывода и ошибок в 1 файл вывода и 1 файл ошибок:



cd /usr/src/linux; vi Makefile; for X in mrproper xconfig clean dep bzImage modules modules_install; do echo "---------------------- starting make $X --------------" echo "---------------------- starting make $X --------------" >2 make $X; echo "---------------------- ending make $X --------------" echo "---------------------- ending make $X --------------" >2 if [ $? -ne 0 ]; then echo Error, check error logs in /tmp break; fi done 2>/tmp/kernel-error.log 1>/tmp/kernel-output.log

---

SMP на более старых серверах Compaq ProLiant

---

Другие файлы в /boot:

---

Образец построения ядра

---

Другие примечания по построению ядра Linux

---

Предыдущая версия текущей страницы

---

Ссылки