Kernel/build unpackaged: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
 
(не показаны 3 промежуточные версии этого же участника)
Строка 1: Строка 1:
= Самостоятельная сборка ядра обычными средствами сборки, без создания RPM пакетов, на примере std-def =
= Самостоятельная сборка ядра обычными средствами сборки, без создания RPM пакетов, на примере std-def =


Для скачивания и компиляции ядра вам понадобится примерно 20 гигабайт, а для инсталляции ещё около 5 гигабайт дискового пространства.
Для скачивания и компиляции ядра в полной конфигурации из исходного кода вам понадобится примерно 20 гигабайт, а для инсталляции ещё около 5 гигабайт дискового пространства. Собранное таким образом ядро не будет на 100% идентично ядру в пакете дистрибутива, так как будет различаться ''сборочная среда'' — то какими утилитами и компилятором собиралось ваше ядро.


== Настраиваем сборочную среду ==
== Настраиваем сборочную среду ==
Все собранные пакеты попадают в, доступные на сайте git.alt, git репозитории [https://git.altlinux.org/gears/ gears]. Каждый репозиторий называется по имени пакета, а бранчи дистрибутива (sisyphus, p10) находятся в соответствующих бранчах git репозитория. Таким образом, в Сизифе для ядра с флейвором std-def пакет называется <code>kernel-image-std-def</code> — путь к его gears репозиторию на git.alt будет <code>/gears/k/kernel-image-std-def.git</code>, а git бранч sisyphus.


Под '''root''' ставим необходимые пакеты для сборки ядра (в Сизифе):
Под '''root''' ставим необходимые пакеты для сборки ядра (в Сизифе):


   # apt-get update
   # '''apt-get update'''
   # apt-get install -y rpm-build git bc dwarves flex libelf-devel zlib-devel openssl openssl-devel
   # '''apt-get install''' -y rpm-build git bc dwarves flex libelf-devel zlib-devel openssl openssl-devel


== Получаем исходный код ==
== Получаем исходный код ==
Будем использовать схему именования позволяющую работать со множеством репозиториев бранчей и апстримов — git remote для gears репозиториев называется <code>gears/флейвор</code>, то есть для std-def это будет <code>gears/std-def</code>, (затем можно будет добавить <code>gears/un-def</code> или апстрим), а git бранч называется <code>флейвор/бранч_дистрибутива</code>, то есть в нашем случае это <code>std-def/sisyphus</code>. Такая схема позволит различить remote и бранчи для разных флейворов.
Получите исходный код как описано в статье "[[Kernel/getting_sources|Получение исходного кода ядер Альт с помощью Git]]" и не забудьте проверить его целостность.
 
Далее выходим из root и продолжаем под своим пользователем.
=== Клонирование репозитория ===
Клонируем репозиторий так, чтоб remote назывался gears/std-def (опция <code>-o</code>) в каталог <code>kernel-image</code> (в будущем другие флейворы тоже будут там) и открываем бранч <code>std-def/sisyphus</code> из него:
 
  $ git clone -n -o gears/std-def http://git.altlinux.org/gears/k/kernel-image-std-def.git kernel-image
  $ cd kernel-image
{{Примечание| Если у вас уже есть репозиторий с ядром можно добавить к нему наши remote:
  $ cd linux
  $ git remote add -f gears/std-def http://git.altlinux.org/gears/k/kernel-image-std-def.git
}}
{{Примечание| Через какое-то время понадобится обновить исходный код ядра, можно не повторять предыдущие шаги, а сделать <code>git fetch</code> нужному remote и обязательно открыть/обновить нужный бранч (см. ниже).
  $ git fetch gears/std-def
}}
 
=== Открываем нужный бранч ===
В нужном бранче уже применены все ALT specific патчи, поэтому, достаточно его открыть. Называем его в соответствии с нашей схемой описанной выше.
 
'''Первоначальное''' (после клонирования) открытие бранча — создание локального бранча <code>std-def/sisyphus</code> соответствующего <code>gears/std-def/sisyphus</code> (то есть бранчу <code>sisyphus</code> в remote <code>gears/std-def</code>).
 
  $ git checkout -B std-def/sisyphus gears/std-def/sisyphus
 
'''Последующее''' (после <code>git fetch</code>) открытие бранча и его обновление:
 
  $ git checkout std-def/sisyphus
  $ git pull --rebase
 
Далее можно убедиться, что ядро свежее посмотрев на даты в <code>git log</code>.


== Конфигурация ядра ==
== Конфигурация ядра ==
Строка 47: Строка 18:
Конфиг собирается из частей находящихся в файлах <code>config*</code>, где к основному конфигу <code>config</code> добавляются конфиги соответствующих архитектуре (<code>config-архитектура</code>, в примере мы будем использовать переменную bash <code>$HOSTTYPE</code> для её определения) и флейвору (например для std-def добавляется <code>config-std</code>, а для un-def не добавляется).
Конфиг собирается из частей находящихся в файлах <code>config*</code>, где к основному конфигу <code>config</code> добавляются конфиги соответствующих архитектуре (<code>config-архитектура</code>, в примере мы будем использовать переменную bash <code>$HOSTTYPE</code> для её определения) и флейвору (например для std-def добавляется <code>config-std</code>, а для un-def не добавляется).


   $ make mrproper
   $ '''make''' mrproper
   $ scripts/kconfig/merge_config.sh -m config config-$HOSTTYPE config-std
   $ '''scripts/kconfig/merge_config.sh''' -m config config-$HOSTTYPE config-std
   $ make olddefconfig
   $ '''make''' olddefconfig
 
{{Примечание| На этом этапе вы можете редактировать получившийся <code>.config</code> или добавить свой патч. Например, для ускорения сборки и уменьшения размера итогового ядра (собранное ядро уменьшится примерно на 14 гигабайт, а инсталлированное примерно на 4.5 гигабайта) можно отключить отладочную информацию:
{{Примечание| На этом этапе вы можете редактировать получившийся <code>.config</code> или добавить свой патч. Например, для ускорения сборки и уменьшения размера итогового ядра (собранное ядро уменьшится примерно на 14 гигабайт, а инсталлированное примерно на 4.5 гигабайта) можно отключить отладочную информацию:
   $ scripts/config -d DEBUG_INFO
   $ '''scripts/config''' -d DEBUG_INFO
}}
}}


Строка 58: Строка 28:
{{Примечание| Компиляцию лучше производить используя параллельную сборку с опцией <code>-j количество_потоков</code>, рекомендуемое количество потоков равно количеству ядер в системе (вывод утилиты <code>nproc</code>).}}
{{Примечание| Компиляцию лучше производить используя параллельную сборку с опцией <code>-j количество_потоков</code>, рекомендуемое количество потоков равно количеству ядер в системе (вывод утилиты <code>nproc</code>).}}


   $ make -j`nproc` bzImage
   $ '''make''' -j$(nproc) bzImage
   $ make -j`nproc` modules
   $ '''make''' -j$(nproc) modules


== Инсталляция ядра в систему ==
== Инсталляция ядра в систему ==
Строка 65: Строка 35:
Снова под '''root''', зайдите в каталог с ядром:
Снова под '''root''', зайдите в каталог с ядром:


   # make -j`nproc` modules_install
   # '''make''' -j$(nproc) modules_install
   # make install
   # '''make''' install


Шаг <code>make modules_install</code> поместит модули ядра в каталог <code>/lib/modules/KERNELRELEASE</code>, где <code>KERNELRELEASE</code> — строка с версией ядра (её можно посмотреть запустив под пользователем <code>make kernelrelease</code>, например, это может быть <code>5.15.77+</code>.)
Шаг <code>make modules_install</code> поместит модули ядра в каталог <code>/lib/modules/KERNELRELEASE</code>, где <code>KERNELRELEASE</code> — строка с версией ядра (её можно посмотреть запустив под пользователем <code>make kernelrelease</code>, например, это может быть <code>5.15.77+</code>.)


Шаг <code>make install</code> поместит файлы <code>'''config''', '''System.map''', '''vmlinuz'''</code> в каталог <code>/boot</code>, там же будет сгенерирован <code>'''initrd'''</code>. При этом, все файлы будут иметь суффикс <code>-KERNELRELEASE</code> и будут поставлены ''симлинки'' initrd и vmlinuz на новое ядро — таким образом, загрузка ядра по умолчанию (из первого пункта загрузчика) будет в это ядро.
Шаг <code>make install</code> поместит файлы <code>'''config''', '''System.map''', '''vmlinuz'''</code> в каталог <code>/boot</code>, там же будет сгенерирован <code>'''initrd'''</code>. При этом, все файлы будут иметь суффикс <code>-KERNELRELEASE</code> и будут поставлены ''симлинки'' initrd и vmlinuz на новое ядро — таким образом, загрузка ядра по умолчанию (из первого пункта загрузчика) будет в это ядро.

Текущая версия от 18:34, 11 ноября 2022

Самостоятельная сборка ядра обычными средствами сборки, без создания RPM пакетов, на примере std-def

Для скачивания и компиляции ядра в полной конфигурации из исходного кода вам понадобится примерно 20 гигабайт, а для инсталляции ещё около 5 гигабайт дискового пространства. Собранное таким образом ядро не будет на 100% идентично ядру в пакете дистрибутива, так как будет различаться сборочная среда — то какими утилитами и компилятором собиралось ваше ядро.

Настраиваем сборочную среду

Под root ставим необходимые пакеты для сборки ядра (в Сизифе): 

 # apt-get update
 # apt-get install -y rpm-build git bc dwarves flex libelf-devel zlib-devel openssl openssl-devel

Получаем исходный код

Получите исходный код как описано в статье "Получение исходного кода ядер Альт с помощью Git" и не забудьте проверить его целостность.

Конфигурация ядра

Конечно можно взять готовый конфиг из /boot/config-* или /proc/config.gz, но вероятно, он не точно соответствует версии ядра, которую вы собираете — поэтому воспроизведем генерацию конфига как она происходит при сборке пакета.

Конфиг собирается из частей находящихся в файлах config*, где к основному конфигу config добавляются конфиги соответствующих архитектуре (config-архитектура, в примере мы будем использовать переменную bash $HOSTTYPE для её определения) и флейвору (например для std-def добавляется config-std, а для un-def не добавляется). 

 $ make mrproper
 $ scripts/kconfig/merge_config.sh -m config config-$HOSTTYPE config-std
 $ make olddefconfig
Примечание: На этом этапе вы можете редактировать получившийся .config или добавить свой патч. Например, для ускорения сборки и уменьшения размера итогового ядра (собранное ядро уменьшится примерно на 14 гигабайт, а инсталлированное примерно на 4.5 гигабайта) можно отключить отладочную информацию: 
 $ scripts/config -d DEBUG_INFO

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

Примечание: Компиляцию лучше производить используя параллельную сборку с опцией -j количество_потоков, рекомендуемое количество потоков равно количеству ядер в системе (вывод утилиты nproc).
 $ make -j$(nproc) bzImage
 $ make -j$(nproc) modules

Инсталляция ядра в систему

Снова под root, зайдите в каталог с ядром: 

 # make -j$(nproc) modules_install
 # make install

Шаг make modules_install поместит модули ядра в каталог /lib/modules/KERNELRELEASE, где KERNELRELEASE — строка с версией ядра (её можно посмотреть запустив под пользователем make kernelrelease, например, это может быть 5.15.77+.)

Шаг make install поместит файлы config, System.map, vmlinuz в каталог /boot, там же будет сгенерирован initrd. При этом, все файлы будут иметь суффикс -KERNELRELEASE и будут поставлены симлинки initrd и vmlinuz на новое ядро — таким образом, загрузка ядра по умолчанию (из первого пункта загрузчика) будет в это ядро.