Debian имеет ли смысл перекомпилировать ядро linux

• ru
• Make-Kpkg

Компиляция и установка ядра Linux из исходников в Debian

Материал из Bryansk Linux Users Group и www.rm.pp.ru

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

Содержание

1. Примечание
2. Способ первый. Сборка ядра в .deb пакеты
3. Накладываем патчи
4. Конфигурирование ядра
5. Компиляция ядра
6. Установка нового ядра
7. Способ второй. «traditional» way
8. Проблемы
9. Ссылки

Примечание

Будет описано два способа сборки ядра. Первым будет описан вариант сборки .deb пакетов, которые могут быть установлены в Вашей или другой системе. Второй метод, так называемый «traditional» путь.

Способ первый. Сборка ядра в .deb пакеты

Установка необходимых пакетов для компиляции ядра

Для начала обновим списки пакетов:

Установим нужные нам пакеты:

Скачиваем исходники ядра

Переходим в каталог /usr/src, идем на www.kernel.org и выбираем нужную версию ядра. В данном случае будет рассмотрена версия linux-2.6.23.1.tar.bz2. Скачиваем:

Распакуем исходники и создадим символьную ссылку:

Накладывание патчей

Опционально и без необходимости не делайте этого!

Иногда требуются драйвера или средства, которые не поддерживаются в имеющемся ядре, например технология виртуализации или иная другая специфика, которой нет в текущем релизе. В любом случае это исправляется наложением так называемых патчей (если таковые имеются).

Итак, предположим вы скачали необходимый патч (для примера назовем patch.bz2) в /usr/src. Применим скачанный патч на наши исходники (Вы должны быть все еще в каталоге /usr/src/linux):

Первая команда — только тест и никакие изменения не будут применены к исходникам. Если после первой команды не было выдано никаких ошибок, можно выполнить вторую команду для применения патча. Ни в коем случае не выполняйте вторую команду, если после первой были выданы ошибки!

Таким образом Вы можете накладывать патчи на исходники ядра. Например, имеются некоторые особенности, которые доступны только в 2.6.23.8 ядре, а исходники не содержали необходимой функциональности, но выпущен патч patch-2.6.23.8.bz2. Вы можете применить этот патч к исходникам ядра 2.6.23, но не 2.6.23.1 или 2.6.23.3 и т.д. Подробнее об этом можно прочитать на [1]:

Предъисправления (препатчи) — эквивалентны альфа релизам; патчи должны быть применены к исходникам полного предыдущего релиза с 3-х значной версией (например, патч 2.6.12-rc4 может быть применен к исходникам версии 2.6.11, но не к версии 2.6.11.10.)

Это значит, если мы хотим собрать ядро 2.6.23.8, необходимо скачать исходники версии 2.6.23 (http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.23.tar.gz) применительно во втором способе «traditonal» путь!

Применяем патч patch-2.6.23.8.bz2 к ядру 2.6.23:

Конфигурирование ядра

Неплохой идеей будет использование существующего конфигурационного файла работающего ядра и для нового. Поэтому копируем существующую конфигурацию в /usr/src/linux:

Далее даем команду,

после которой загрузится графическое меню конфигурации ядра. Выбираем в меню конфигуратора пункт «Load an Alternate Configuration File» и нажимаем «Оk». Затем (если требуется) сделайте необходимые изменения в конфигурации ядра перемещаясь по меню (подробности конфигурации ядра можно найти в www.google.com ). Когда закончите и нажмете «Exit», будет задан вопрос «Do you wish to save your new kernel configuration?», отвечаем утвердительно «Yes».

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

Сборка ядра выполняется всего в две команды:

После —append-to-version=, можно написать любое название, какое Вам угодно, но оно должно начинаться со знака минус (-) и не иметь пробелов.

Процесс компиляции и сборки .deb пакетов может занят довольно продолжительное время. Все будет зависить от конфигурации ядра и возможностей Вашего процессора.

Решение проблемы с созданием initrd.img

С недавнего времени в Debian появился баг, заключающийся в том, что после установки пакетов с собранными описанным здесь способом ядрами, не создаётся соответствующий им файл /boot/initrd.img. Для исправления применительно к уже установленному ядру, придётся создать initrd.img вручную:

Для решения проблемы «на будущее» – закомментировать, как показано, вторую из процитированных ниже строк в файле /etc/kernel/postinst.d/initramfs-tools:

Установка нового ядра

Когда удачно завершится сборка ядра, в каталоге /usr/src будут созданы два .deb пакета:

linux-image-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb — собственно само актуальное ядро и linux-headers-2.6.23.1-cybermind_2.6.23.1-cybermind-10.00.Custom_i386.deb — заголовки ядра, необходимые для сборки других модулей (например при сборке модулей драйвера nVidia). Устанавливаем их:

(Эти пакеты теперь могут быть установлены на другой системе и собирать их заново уже не будет необходимости.)

Всё, установка завершена, меню загрузчика, установка нового RAM-диска и ядра будут сделаны автоматически. Остается только перезагрузиться:

Способ второй. «traditional» way

Выполняем все пункты, описанные выше ДО пункта «Компиляция ядра».

Далее, традиционный способ:

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

Основной недостаток этого метода — если вы часто обновляете ядра, то через некоторое время их накопится большое количество и захочется удалить неиспользуемые. Чтобы это было сделать проще, можно собрать ядро и другие файлы, которые устанавливаются в систему по командам «make modules_install» и «make install» в deb-пакет (а точнее в два начиная с ядра 2.6.27) подобно первому способу, но воспользуемся здесь скриптами самого ядра:

В каталоге на уровень выше каталога исходников появятся два .deb-файла. Я собирал ядро в каталоге /usr/src/linux-2.6.27.10 и у меня в каталоге /usr/src/ появились файлы

Ядро устанавливается командой

Старые ядра можно удалять, например, из synaptic’a

Следующие шаги

Ядро собрано и установлено, но еще теперь необходимо создать RAM-диск (без которого ядро просто не загрузится) и необходимо обновить загрузчик GRUB. Для этого выполним следующее:

Обновим легко и безболезненно загрузчик:

Всё, загрузчик и новое ядро готовы, остается только перезагрузиться:

Источник

Зачем компилировать ядро?

Часто пишут про компилирование ядра для поддержки разного оборудования. Зачем это делать если есть динамически загружаемые модули ядра и можно собрать только необходимые модули, а ядро оставить как есть? Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

Я например компиляю ядро чтобы оно было монолитное, пропатчить драйвер видеокарты для поддержки видеокартой 4К разрешения, потому как в дефолте она прикидывается, что может только в 1920х1080. Можно еще собрать ядро реального времени чтобы звук был без задержек совсем. Кроме того когда нет нужды компилять все модули это происходит в разы быстрее — 5 минут вместо часа например. Когда хочется отключить патчи ядра, снижающие быстродействие, которые защищают от угроз и много чего еще.

А в вашем дебиане всегда так. Если там чего то нет — значит это никому не нужно и вообще ни на что не влияет. Но оно влияло, когда эта фича только появилась, я отмечал разницу между ядрами с 250 и 1000hz визуально, при перемещении окон в КДЕ например. Никакой OpenGL тогда ничего не ускорял и банальный композитинг казался чрезвычайно продвинутой и крутой фишкой. Сейчас наверное действительно разницу можно только в динамических играх почувствовать.

Я например компиляю ядро чтобы оно было монолитное

Просто чтобы оно таким было, из религиозно-фанатических соображений?

пропатчить драйвер видеокарты для поддержки видеокартой 4К разрешения

Ну, ОК, такое. Что за драйвер, удивлён тем что нужно патчить для этого. Сам 4к не практикую, просто интересно знать на будущее.

Можно еще собрать ядро реального времени чтобы звук был без задержек совсем.

А можно использовать rt ядро для своего дистрибутива, если оно есть. Тоже, такое. Ну ОК.

Кроме того когда нет нужды компилять все модули это происходит в разы быстрее — 5 минут вместо часа например.

А если пользоваться готовым — 0 секунд.

Когда хочется отключить патчи ядра, снижающие быстродействие, которые защищают от угроз

Достаточно прописать mitigations=off в параметры загрузки ядра, пересобирать его совсем не обязательно для этого, кроме того в конфиге не все mitigations отключаются.

Хм. А что это за тайно супер возможности, которые не нужны настолько, что легче перекомпелять ядро?

Уже не первый раз на протяжении многих лет задаётся вопрос в лоб — «Зачем компилировать ядро?» И ни разу я не слышал ничего вменяемого. «Не всем нужно то что по дефолту, некоторым нужно нечто особенное» и никакой конкретики. И даже мантры про то, что ядро становится быстрее уже не повторяют.

А в вашем дебиане всегда так. Если там чего то нет — значит это никому не нужно и вообще ни на что не влияет.

А у тебя что за дистрибутив, где по дефолту 1000 герц стоит?

Хм. А что это за тайно супер возможности, которые не нужны настолько, что легче перекомпелять ядро?

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

А там где архитектура стандартная я давно и прекрасно пользуюсь дефолтным ядром и ущербным себя не чувствую. Если ты думаешь меня поджечь на флейм самосбор или дефолт, модули или монолит и т.п. — зря, я не бомбану. Всегда утверждал и утверждаю что от добра добра не ищут, если в готовом дистрибутивном ядре всё работает и всё устраивает — это прекрасно. Правильно говорят, те кто пересобирают ядра сами обычно знают зачем они это делают. А тем кто спрашивает «зачем пересобирать?» пересобирать ядра незачем. Иначе они бы этот вопрос не задавали.

А у тебя что за дистрибутив, где по дефолту 1000 герц стоит?

А, ну у них там всё не как у людей. Насколько я помню они и патчи с BFQ раньше накладывали, до того как его в апстрим влили, и ещё что-то. Но в большинстве дистрибутивов это либо 250, либо 300 герц.

я отмечал разницу между ядрами с 250 и 1000hz визуально

Испытания проводил двойным слепым методом? Или поменял и сразу «заметил»?

Сейчас наверное действительно разницу можно только в динамических играх почувствовать

Игры тут вообще не причём. Суть была в том, что изначально к CONFIG_HZ были привязаны все планировщики ядра. С ростом производительности дефолтное значение в 100 (т.е. 10мс) стало слишком большим для планировщика типичного десктопа — мощность процессора позволяла комфортно работать с несколькими задачами, но время переключения между ними упиралось в 10мс интервал между принятиями решений планировщиком. Аналогичная проблема была с планировщиком ввода-вывода — характерные времена задержки у винчестеров упали меньше 10мс. Поэтому сначала добавили вариант с 1000 (1мс), а потом и 250 (4мс), когда выяснилось, что 1000 даёт великоватый оверхэд. Но время шло, росло число ядер (при обработке пользовательского действия во время уже работающей одной задачи теперь не надо ждать принятия решения планировщиком по приостановке этой задачи и отдачи процессора на другую, теперь она просто запускается на свободном ядре с нулевой задержкой), появлялись NCQ и SSD, которые вообще сводили на нет нужду в планировщике в/в, под это всё менялись и планировщики, теперь тот же bfq полностью отвязан от CONFIG_HZ.

Прогнал тест таймеров на Linux 5.8.1, OpenSUSE, результаты нормальные, но хуже, чем у Haiku: https://imgur.com/a/jwdP1QI.

в большинстве дистрибутивов это либо 250, либо 300 герц.

Мне почему то кажется что так только в Дебиане и в серверных дистрибутивах, RHEL\CentOS там. В бубунте кажется 1000, в сусе и федоре тоже, но могу наврать, не уверен. В любом случае там ядер на все случаи жизни есть, и десктопные наверняка с 1000, а серверные — нет. В Кальке только десктопное ядро с 1000, а серверное с 300 или 250, не помню, но не 1000.

Gentoo же, видеокарта использует драйвер Radeon и в биосе ограничен, плюс крашит логин менеджеры вроде GDM, SDDM, ругаясь на кривой биос у видеокарты. Вот тут описание с файлами, где изменения

Если использовать скачиваемое ядро, то я видел у войда скорость низкую, так что пока оно скачает под 300 мегабайт, то архив на 70 мегабайт уже соберется.

Можно и так, но вдруг есть любители нарочно включать то, что должно быть выключено. Мало ли какие ситуации бывают в жизни, это просто вариант.

Кажется. 250. В росе 300.

Испытания проводил двойным слепым методом? Или поменял и сразу «заметил»?

Поменял и заметил, именно так. Это было миллиард лет назад, МНЕ разница в отклике и поведении ГУИ была очевидна, и сейчас я доказывать ничего не собираюсь. И даже более того, соглашусь что сейчас возможно разницы и нет, но проверять не буду, так как у меня всё прекрасно так как есть и трогать я это не буду больше.

Игры тут вообще не причём. Суть была в том, что изначально.

Полностью согласен и спорить не буду. Уверен что сейчас разницу в производительности и отзывчивости между этими параметрами можно увидеть только в синтетике и она будет на грани погрешности измерений.

Нет, я не поджигаю. Я просто конкретики хочу. Про NUMA — это повод, но не массовое явление. Это нужно 0.001% линуксоидов. Как и другие реальные проблемы. И каждый, кто решал такие проблемы в состоянии в двух-трёх словах описать это, но обычно доводы лоровцев на животрепещущий вопрос — «патамучо нада!»

П.с. это не наезд на тебя, а то вдруг опять не так поймёшь 🙂

А можно смешной вопрос? А как другие дистрибутивы ведут себя на данном компе?

Когда вообще возникает необходимость компилировать ядро кроме сборки или обновления системы из исходников?

Если нужно что-то в конфиге изменить или если какие-нибудь сторонние патчи нужны (например, сторонний планировщик CPU).

Кстати откуда вы берёте частоту таймеров? У меня ничего такого нет, ядро родное от OpenSUSE:

Прогнал тест таймеров на Linux 5.8.1, OpenSUSE, результаты нормальные, но хуже, чем у Haiku.

HPET в бивисе\уефи выключен или включён?

Читал что HPET для десктопа «не очень», снижает производительность в играх, и его рекомендуется выключать, но я тупой и так и не всосал до конца чем он плох. Но на всякий случай выключил.

NUMA — это довольно таки массовое явление среди линуксоидов. Не на десктопе, конечно. Собирать, конечно, никто не собирает, потому что в мейнстриме не принято обрезать нуму, на дебиане, убунте, центоси всё пучком из коробки.

Источник