Наши партнеры

UnixForum






Книги по Linux (с отзывами читателей)

Библиотека сайта rus-linux.net

Заметки пользователя Linux. Второй этюд о компиляции ядра из исходных кодов

(C) В.А.Костромин, kos @ rus-linux dot net

11 декабря 2003 г., последние изменения внесены 13 декабря 2003 г.

В ситуацию, когда я был вынужден ставить ядро из исходных кодов, я попадаю второй раз. И оба раза эта ситуация возникла при попытке установить систему виртуальных машин VMware. Первый случай я описал в статье [1] и книге [2], а о втором собираюсь рассказать в настоящей заметке.

Напомню, что после не совсем удачного эксперимента по обновлению существующей системы я вынужден был заново установить на своем домашнем компьютере систему ASP Linux 7.2. После ее успешной установки я попытался поставить систему VMware, для чего скачал с сайта vmware.com пакет VMware-Workstation-4.0.5-6030.i386.rpm и попытался его установить. Сам пакет установился без проблем и каких-либо запросов. Но при запуске скрипта /usr/bin/vmware-config.pl появилось требование предварительно установить gcc. Для gcc потребовался еще пакет glibc-devel, а последнему - пакет kernel-headers >= 2.2.1. Пакеты gcc и glibc-devel нашлись на втором дистрибутивном диске, а вот с kernel-headers и начались проблемы. На дистрибутивных дисках такого пакета не нашлось, хотя у меня полная версия этого дистрибутива, так называемый ASP Linux 7.3 Deluxe Edition на 10 CD-дисках.

Полез я в Интернет, на свои любимые сайты для поиска rpm-пакетов rpm.pbone.net и Rufus.W3.Org. Но ни на том, ни на другом сайте я не нашел пакета kernel-headers-2.4.18-5asp, соответствующего установленному у меня ядру. На сайте asplinux.ru нужного пакета тоже не обнаружилось, что уж совсем непонятно. Ближайшим по номеру версии пакет, который нашелся на Rufus.W3.Org, был пакет kernel-headers-2.4.18-15.i586.rpm.

После установки пакета kernel-headers-2.4.18-15.i586.rpm, а также пакетов gcc и glibc-devel, скрипт /usr/bin/vmware-config.pl успешно перешагнул тот рубеж, на котором остановился в предыдущий раз, однако ушел таки недалеко и снова застопорился, выдав сообщение

The directory of kernel headers (version 2.4.18-15) does not match your running kernel (version 2.4.18-5asp). Even if the module were to compile successfully, it would not load into the running kernel.

What is the location of the directory of C header files that match your running kernel? [/usr/src/linux/include]

и далее идти отказался.

Перечитав свои заметки об установке ядра из исходников, которой я занялся тоже по причине того, что не мог установить систему VMware, я обнаружил, что и в прошлый раз скрипт vmware-config.pl никак не признавал соответствие kernel-headers установленному ядру. Поэтому я решился снова заняться установкой ядра из исходников. Скачал из Интернет самую последнюю версию ядра, которую смог найти (почему-то это была версия 2.4.23, хотя из новостей я знаю, что уже выпущена версия 2.4.25), развернул архив в каталоге /usr/src/linux-2.4.23, положил перед собой свою книгу [2], раскрытую на главе 17 "Обновление ядра" и приступил к повторению тех действий, которые там описаны.

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

Во-первых, отмечу, что развернуть tar-bzip2-архив с правами простого пользователя мне почему-то не удалось. Пошли сообщения о том, что какого-то файла или каталога не существует, причем в огромных количествах. Когда же я провел ту же операцию от имени суперпользователя, все прошло без всяких сообщений об ошибках. В результате в первом случае (при работе от обычного пользователя развернулось всего 23,8 МБ, а во втором случае - 186,5 МБ. Разница, как видите, очень существенная!

Во-вторых, что вы тоже видите из приведенных цифр, объем исходных кодов ядра существенно вырос: для версии 2.4.2 это было 108 МБ, а для 2.4.23 - уже 186,5 МБ. Так что задумавшись об установке ядра из исходников, позаботьтесь о наличии свободного места на вашем диске.

В этот раз я проводил компиляцию ядра в окне эмулятора терминала, причем в одной виртуальной консоли открыл файл /usr/src/linux-2.4.23/Documentation/Configure.help, а в другой виртуальной консоли проводил собственно процедуру компиляции. Это позволило мне обращаться за подсказкой во всех затруднительных ситуациях.

Но долго размышлять над тем, каким образом задать значение каждого параметра быстро надоедает, и вскоре я стал полагаться на значения задаваемые по умолчанию. Только в некоторых случаях, когда название параметра или краткое пояснение к нему вызывали такое желание, обращался за разъяснениями к файлу /usr/src/linux-2.4.23/Documentation/Configure.help. И все же ответы на вопросы заняли более часа.

Остальные операции я выполнил точно по рекомендациям в книге. Точнее выполнил следующую последовательность команд:

[root]# make config
[root]# make dep
[root]# make bzImage
[root]# make modules
[root]# make modules_install

После этого переименовал полученные файлы следующим образом

System.map -> System.map-2.4.23
vmlinux -> vmlinux-2.4.23
bzImage -> vmlinuz-2.4.23
и переместил их в каталог /boot. А затем добавил в файл /boot/grub/grub.conf новую секцию следующего вида (просто скопировал существующую секцию для ядра 2.4.18, а затем заменил цифру 18 на 23):
title linux-2.4.23
kernel /vmlinuz-2.4.23 root=/dev/hda5 hdc=ide-scsi
initrd /initrd.2.4.23.img
boot
и перезапустил компьютер. В меню загрузчика GRUB появилась строка
linux-2.4.23
Ее я и выбрал, но, к сожалению, загрузка не прошла. Сразу после меню GRUB появилось сообщение
initrd /initrd.2.4.23.img
Error 15: File not found

Тогда я вспомнил, что при конфигурировании нового ядра отказался от создания RAM-диска, а поэтому перезагрузился снова в старое ядро и закомментировал строку

initrd /initrd.2.4.23.img
в файле /boot/grub/grub.conf. Теперь загрузка прошла чуть дальше, но завершиться опять не смогла. Появилось сообщение о том, что в разделе /dev/hda5 либо неправильная файловая система, либо сбойный суперблок.
fsck.ext3 /dev/hda5
The superblock could not be read or does not describe a correct ext2 filesystem. 
If the device is valid and it really contains an ext2 filesystem (and not swap 
or ufs or something else), then the superblock is corrupt, and you might try 
running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
No such file or directory while trying to open /dev/hda5.

Вроде поддержку ext3fs в ядре я задавал. Запустил команду make xconfig, перепроверил конфигурацию и снова повторил компиляцию, однако результат не изменился. Тут я вспомнил, что если ядро уже было компилировано в данном каталоге, то рекомендуется перед его повторной компиляцией выполнить команду make mrpropeer. После ее выполнения файл .config в каталоге /usr/src/linux-2.4.23 пропал. Пришлось еще раз повторять конфигурирование. Только на этот раз я воспользовался командой make xconfig, которая показалась мне более удобной. После этого снова повторил все действия по компиляции и переименованию полученных файлов, перенес их в каталог /boot и снова перезагрузился. На сей раз загрузка системы прошла относительно успешно - хоть и появлялись в ходе загрузки какие-то непонятные сообщения, но в консольный режим система все же вышла.

А вот в графический режим - отказалась, сообщив:

Failed to initialize the NVdriver kernel module.
Этому я уже обрадовался, поскольку хотя бы понятно, в каком направлении копать!

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

Список литературы и ссылки.

  1. В.А.Костромин, "Семь шагов к новому ядру" (обновление ядра до версии 2.4.2), апрель 2001 г.
  2. В.А.Костромин, "Linux для пользователя", изд. БХВ-Петербург, 2002 год, серия "Самоучитель", 650 стр.