CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
26.09.2017

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: Debian

Заметки о Debian: 3. Ядро под deb-соусом

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

Тем не менее, необходимость в перекомпиляции ядра иногда возникает. И причин к ней - две. Во-первых, модульная поддержка широкого круга устройств и загрузка системы через initrd, неизбежные для ядер инсталляционных дисков (действительно, не будешь же встраивать в ядро поддержку всех возможных типов ATA- и SCSI-контроллеров), далеко не идеальна для индивидуальной пользовательской машины. А во-вторых, модульная поддержка далеко не всегда обеспечивает оптимальную работу устройств, в частности - максимальную производительность тех же жестких дисков.

Именно с последней ситуацией я столкнулся в своем свежеустановленном Debian testing (Etch). Как я рассказывал в предыдущей заметке, эта система была установлена на 1-й и единственный SATA (Seagate Barracuda, 120 Мбайт, 7200 об./мин, буфер 8 Мбайт), определенный в качестве загрузочного. Кроме того, в машине присутствовали еще два PATA-диска на 1-м IDE-канале, оба - Seagate Barracuda IV, 7200 об./мин, буфер 2 Мбайт, 40 и 80 Гбайт, соответственно. Первый использовался для экспериментов, второй - для backup'а. А поскольку шутки с данными глупы и неприличны, backup я делаю достаточно часто (в том числе и полный).

Так вот, на первой же сессии тотального резервирования меня удручила исключительная медленность процесса - почти как во FreeBSD, и это - при ReiserFS и на источнике, и на приемнике. Ясно, что дело в дисках - хотя оба моих PATA, как можно видеть из их имен, достаточно старые, используются мной уже давно, и их характеристики я помню на память. В частности, во всех Linux'ах, к которым они прикручивались ранее, по hdparm -t они стабильно давали 38-40 Мбайт/с.

Новый SATA внешне никаких нареканий в работе не вызывал. Опробование его hdparm'ом дало скорость в 56 Мбайт/с - вполне сопоставимо с той разницей между ним и PATA, которая у меня получалась во FreeBSD. Хотя это - при 16-битном доступе, включать 32 бита на этом диске hdparm отказался.

А вот оба PATA показали в ответ на hdparm -t лишь жалкие 7,8 Мбайт/с, что не могло не удручать. И чего следовало ожидать - дальнейшее пытание их показало как 16-битный доступ, так и отключение DMA. Положим, задействовать 32 бита через

$ haparm -c 1 /dev/hd?

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

Просмотр сетевых источников показал, что проблема эта - довольно часта для не-Intel'овских чипсетов (а у меня была "мать" на Nforce3). И как средство ее решения предлагалась пересборка ядра с жестким (не модульным) встраиванием в него поддержки наличных IDE- и SATA-контроллеров. Что я и решил проделать.

Руководство по Debian предлагало два метода выполнения этой процедуры - "как лучше", и "как всегда". Рекомендовался, естественно, первый, Debain-специфический. Да и для меня он был интересней: любой линуксоид моего поколения знает, как собирать ядро традиционным способом - не хуже, чем любой советский ребенок знал, как очищается политура. Так что к нему я и решил прибегнуть.

Стандартный Debian-метод предусматривает для пересборки ядра специальный пакет - kernel-package, каковой и надлежит установить с помощью зазубренных ранее волшебных заклинаний:

S apt-get install kernel-package

Заодно следует обзавестись и сопутствующими пакетами - debhelper, modutils и libncurses5-dev (последний нужен для генерации меню по команде make menuconfig). И еще - пакетом fakeroot, который отвечает за запуск команд в имитируемом root-окружении.

Далее, естественно, требуются исходники ядра. В качестве таковых можно взять последнюю версию ядра канонического, с http://www.kernel.org, можно - дополнить их патчами других разработчиков. А можно - просто пересобрать штатное ядро дистрибутива. В последнем случае (а я поступил именно так) нужно установить соответствующий пакет с исходниками, например:

S apt-get install kernel-source-2.6.12

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

Результатом выполнения последней команды будет появление в каталоге /usr/src тарбалла исходников. Переходим туда и распаковываем тарбалл обычным образом:

S tar xjvf kernel-source-2.6.12.tar.bz2

Да, в промежутке можно отредактировать файл /etc/kernel-pkg.conf - правда, кроме собственного имени и электронного адреса, вписывать в него вроде нечего.

Следующий этап Debian-метода построения ядра выполняется, "как всегда". То есть -

переходом в соответствующий каталог
S cd /usr/src/linux-source-2.6.12/

копированием в него нашего рабочего конфига ядра:

S cp /boot/config-2.6.12-1-amd64-generic .config

(дабы не начинать конфигурирование с нуля) и запуском команды

S make menuconfig

Процедуру конфигурирования описывать не буду - это а) делалось многократно, и б) вполне может составить отдельную тему. В контексте же нынешней скажу только, что, в целях избавления от initrd, необходимо жестко встроить в ядро поддержку всего, имеющего отношение к старту системы. То есть - контроллера "несущего" диска и типа файловой системы, содержащей корень файлового древа (в моем случае - Nforce, вместе с SATA и сопутствующим SCSI, и ReiserFS). Неплохо также избавиться от поддержки "лишних" чипсетов и прочего не имеющего быть оборудования.

Далее руководство в приказном порядке рекомендует выполнить очистку дерева исходников:

$ make-kpkg clean
Насколько я понял, это требуется для уничтожения следов от номеров предыдущих ревизий ядра - следующей командой мы определим свою их нумерацию. А командой этой будет

$ fakeroot make-kpkg --append_to_version \
	-amd64 --revision=rev.01 kernel_image

Здесь fakeroot создает "правильное" root-окружение (то есть команда может быть запущена от имени пользователя), make-kpkg - собственно программа для построения бинарного "ядерного" пакета, ее опции предписывают добавлять к имени пакета номер версии ядра, архитектуру, под которую оно собиралось, и номер ревизии, то есть нашей собственной сборки, а kernel_image - имя целевого пакета.

В результате указанной директивы сначала происходит компиляция ядра, а потом из него собирается самый обычный deb-пакет вида kernel-image-2.6.12-amd64_rev.01_amd64.deb, помещаемый в каталог /usr/src. Так что дело остается за малым - установить его обычным же образом:

$ cd ..
$ dpkg -i kernel-image-2.6.12-amd64_rev.01_amd64.deb

При этом файл образа ядра и соответствующий ему System.map будут не только скопированы куда следует (то есть в каталог /boot - если он составляет отдельную ветвь файлового древа, не забыть его примонтировать!), но и внесены изменения в файл конфигурации загрузчика (в моем случае - в /boot/grub/menu.lst): новое ядро займет умолчальную позицию в его меню, старое же сохранится в качестве резервного.

Должен сказать, что в моей конфигурации система упорно продолжает считать первым винчестером 1-й PATA (тогда как в BIOS выставлена загрузка с SATA, и grub полагает первым именно его). Так что на всякий случай файл /boot/grub/menu.lst нужно проверить и, при необходимости, поправить руками.

Теперь остается только перезагрузиться с новым ядром и посмотреть, что получилось. Надо сказать, что, не смотря на отказ от initrd и изобилия модулей, скорость загрузки на глаз не изменилась (а мерить ее мне было лень, да и не волнует меня это). А вот ситуация с дисками существенно выправилась.

Правда, для SATA-диска ничего не изменилось - 32-битный режим доступа так и остался недоступным, и скорость по hdparm -t по прежнему составляла 56 Мбайт/с (хотя куда уж больше). А вот для обоих PATA-дисков по умолчанию оказались сразу задействованы и 32-битный доступ, и DMA-режим. В результате чего измерения показали для них законные 38-39 Мбайт. Так что овчинка явно стоила выделки.




Комментарии

аноним, Tue Oct 20 11:04:42 2009:
извиняюсь за оффтоп, но подскажите ЧЕМ FAKEROOT ОТЛИЧАЕТСЯ от SUDO?
аноним, Tue Oct 20 11:04:05 2009:
извиняюсь за оффтоп, но подскажите ЧЕМ FAKEROOT ОТЛИЧАЕТСЯ от SUDO?
CJ AYHO, Thu Jun 5 01:31:00 2008:
>> После команды
>> $ dpkg -i kernel-image-2.6.12-amd64_rev.01_amd64.deb
>> модули сами рамещаются в /lib/modules ?

После команды dpkg от $ - не root, у него # - система насяльнику направит лесом

А от рута - есессна. и модули установятся и инитрд сгенерируется. то есть ядрышко будет готово к использованию.
аноним, Sun May 11 00:30:00 2008:
Попробывал собирать под дебиановским соусом не понравилось, почему-то при удалении неудачной сборки затрагиваются другие ядра. ИМХО ядра лучше штатными средствами собирать.
аноним, Wed Mar 26 08:32:35 2008:
После команды
$ dpkg -i kernel-image-2.6.12-amd64_rev.01_amd64.deb
модули сами рамещаются в /lib/modules ?
CJ AYHO, Thu Jul 12 13:29:38 2007:
Странно то, что на моем D 4.0 Etch пакет kernel-source называется linux-source...
Артур, Tue May 1 04:18:32 2007:
Неплохо было бы так же рассказать, о том, как имея на руках исходники ядра, и ОТДЕЛЬНО исходники каких-либо модулей для какого-нибуть устройства (something.c и something.h) заставить это устройство все же заработать :)
n0mad, Fri Mar 23 14:00:14 2007:
Поповоду того что система считает первым как мне кажется есть только одно решение.... параметром при загрузке ядра указывать ide=reverse

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds