Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/devel/kernelnotes ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Эта страница была перенесена на altlinux.org. Текст на freesource.info заморожен.

Собираем новое ядро


Например я буду собирать ядро версии 2.6.23. Нижеследующие примеры будут относится к ядру этой версии.
Вам понадобится хорошая быстрая машина, с быстрым процессором, и большим обемом ОЗУ.
У автора ЦПУ Athlon 64 X2 Dual Core 3800+ 1GB ОЗУ, по субьективной оценке, не очень быстро работали.
Для более быстрой сборки vsu рекомендует использовать ccache, установив перед этим в переменные:


$ export LC_ALL=C
$ export GCC_USE_CCACHE=1 

Подготовительный этап

У ALT Linux разработана своя среда (kernel-build-scripts) для сборки ядер. Основным мантейнером этой среды является vsu.
Я рекомендую скачать kernel-build-scripts непосредственно с репозитария vsu:


$ git clone git://git.altlinux.org/people/vsu/packages/kernel-build-scripts
$ cd kernel-build-scripts
$ ls 

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git


Как видно, среда состоит из набора скриптов.
Настоятельно рекомендую ознакомится с расположенным
в каталоге kernel-build-scripts файлом README.koi8,
в котором описана вся кухня по сборке ядра.
Существует два вида скриптов, *-hsh собирают через hasher, другие – без.
Если вы будете собирать пакеты без помощи hasher, тогда вам необходимо будет по мере надобности скопировать пакеты kernel-source-* в папку source.
Там эти пакеты распаковываются в tmp/root и используется для сборки, без установки в систему, и без создания chroot; прочие buildrequires нужно удовлетворить как обычно.

II 

Пакеты ядра и модулей для дистрибутивов ALT Linux собирают vsu, lakostis, silicium и другие (может кто-то еще, я не вкурсе).
Репозиторий c ядром должен находится в папке: kernel-build-script/kernel
Забираем ядро, например, у vsu или lakostis:


$ git clone --origin vsu git://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18 kernel
или
$ git clone --origin lakostis git://git.altlinux.org/people/lakostis/packages/kernel-image-2.6.22 kernel 

Добавляем репозиторий, содержащий новую версию ядра (для git-remote, по дурацким и необъяснимым историческим причинам может потребоваться поставить пакет perl-GIT):


$ git remote add linux-2.6.23 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git 

В master ветку этого репозитория, Linus Torvalds помещает обновления для ядер серии 2.6.23 (например 2.6.23.1, 2.6.23.2,....)
В нашем репозитарии будет создана ветка linux-2.6.23/master, которая будет отслеживать обновления для ванильного ядра 2.6.23.


Загрузим с репозитория linux-2.6.23 исходный код ядра.


$ git fetch linux-2.6.23 

Теперь в нашем репозитории ветка linux-2.6.23/master содержит ядро 2.6.23 с обновлениями.
Убедимся:


$ git-log --pretty=short -n 1 linux-2.6.23/master
commit 4367388f04eea72e78347dc9b299698bf4275f92
Author: Greg Kroah-Hartman <gregkh@suse.de>

    Linux 2.6.23.1 

Собрираем пакет kernel-source-2.6.23–1.0.0-alt1.noarch.rpm

Как видно, данный пакет не зависит от архитектуры.
Внутри пакета содержиться только файл с иходными кодами ванильного ядра:
/usr/src/kernel/sources/kernel-source-2.6.23.tar.bz2
Заметьте, что данный пакет содержит исходный код ядра версии 2.6.23, а не 2.6.23.1.
Собрать этот пакет не составит труда. Достаточно:


$ git checkout -b kernel-source vsu/kernel-source # создадим ветки на основе ветки vsu
$ git pull -s ours . tag v2.6.23 # иначе будет ругаться gear
$ vim kernel-source.spec # увеличиваем версию
$ add_changelog kernel-source.spec 

В ответ на ругань add_changelog что версия пакета не изменилась, можно добавить к alt1 точку: 'alt1.', потом удалить.
Версия пакета не изменяется, а изменяется имя пакета.


$ vim .gear-rules  # обновить версию ядра в файле (тег)
$ gear-update-tag -a -c
$ git add .gear-rules kernel-source.spec
$ git commit -m "kernel-source-2.6.23 1.0.0-alt1" 

Осталось собрать сам пакет с помощью gear в hasher:


$ gear --hasher -- hsh
или
$ gear --hasher -- hsh --apt-config=$HOME/apt/apt.conf.sisyphus.x86_64.hasher $HOME/hasher 

Замечания вида:
warning: Macro %kernel_srcdir not found
warning: Macro %kernel_srcdir not found
warning: Macro %kernel_src not found
на результат не влияет, там Build Requires?(pre) не хватает.
После сборки этот пакет будет находится в репозитории hasher-a.

Собираем пакет kernel-image-std-smp-2.6.23-alt1.i586.rpm

Собственно этот пакет содержит само ядро + стандартные модули поставляемые с ядром.


Несколько слов о структуре репозитария.
На мой взгляд следует различать ветки:

Имя ветки сообщает, какое конкретное дополнение она несет.

Цель ветки kernel-image-std-smp создать мега патч-бомбу который накладывается на ванильное ядро 2.6.23, скомпилировать бинарное ядро, собрать пакет.


Файл branches-to-merge используется скриптом merge-all-branches.
Может возникнуть вопрос: «Зачем мержить ветки которые указаны в branches-to-merge, если они уже в замерженыы в ветку kernel-image-std-smp ?"
Ответ: Периодически в этих ветках появляется что-то новое, вот скрипт и проверяет, что появилось. Ещё возможен вариант вида branch-*
скрипт merge-all-branches проверяет, есть ли что-то новое, если нет – ничего не делает, если есть – спрашивает, надо ли это мержить.


В моем случае, накатывать 2.6.23 поверх пропатченого 2.6.18, бесмысленно, иначе там всё развалится.
Придётся делать по сути rebase всех веток с патчами, и подцеплять к старой истории в самом конце.
При сборке 2.6.23 лучше создать новые ветки fix-stable, kernel-image-std-smp, ...

A

Cоздадим ветку fix-stable. Задача этой ветки содержать последние официальные исправления для ядра от Linus Torvalds:


$ git checkout -b fix-stable linux-2.6.23/master 

При будущих обновлениях можно поступать одним из следующим способов:
1. Из tracking branch:


$ git fetch linux-2.6.23
$ git pull . linux-2.6.23/master 

2. Загрузить обновления непосредственно из репозитория Linus-а:


$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git 

B

Создадим ветку kernel-image-std-smp на основе тега v2.6.23. Задача этой ветки содержать код ядра со всеми приложеными патчами.
Т.е. в эту ветку мержатся остальные ветки feat-*-* fix-*-*.


$git checkout -b kernel-image-std-smp v2.6.23 

Заберем из старой ветки vsu/kernel-image-std-smp файлы:
kernel-image.spec
config-i586
config-x86_64
branches-to-merge
.gear-rules
modules.build


Для каждого вышеперечисленного файла выполним:


$ git ls-tree vsu/kernel-image-std-smp
$ git cat-file blob 'sha1' >kernel-image.spec
$ git add -f kernel-image.spec config-i586 config-x86_64 branches-to-merge .gear-rules modules.build 

флаг -f указывает добавить .gear-rules, даже если он занесен в .gitignore

C

Создадим ветки feat-*-* и fix-*-*.
Например создадим ветку добавляющую поддержку файловой системы unioinfs.


$ git checkout -b feat-fs-unionfs v2.6.23 

Патч можно наложить в ручную (patch -p1 < .....) или же средствами git. Что будет более правильно, и облегчит добавление файлов в index,
если патч затрагивает слишком много файлов:


$ git apply --index --whitespace=nowarn unionfs.patch 

Отличие от patch в том, что git apply рассматривает любой fuzz как ошибку.
Ещё особенность в том, что по умолчанию, если есть хотя бы одна ошибка, патч не применяется вообще.
Можно добавить – -reject, чтобы создавались *.rej, как с обычным patch.
Кстати, такой внешний патч может иметь смысл совать в отдельную ветку, растущую прямо из той версии ядра, для которой предназначен патч
а потом уже мержить. Дело в том, что 3way merge зачастую работает надёжнее, чем наложение патча на изменившуюся версию
изменения из патча иногда могут молча улетать в другой участок с похожим содержимым.


$ git commit -m "Add unionfs 2.1.8 support" 

Ничего страшного не будет если самому создать сам ветку git checkout -b fix-xxx, а потом добавить коммит из ветки vsu/fix-xxx с помощью git cherry-pick.
vsu так же делал большей части этих веток. Т.е. получается мы крадем коммиты vsu с помощью cherry-pick.
Единственная неприятность от cherry-pick – если эти коммиты появятся в нескольких местах, потом, возможно, придётся что-то мержить руками.
Если изменения точно совпадают, git merge происходит автоматически, если с одной стороны есть ещё какие-то изменения сверху, может вылезти конфликт на ровном месте.


Если Linus Torvalds добавил в официальное ядро присутвовавшие у нас исправления то можно сделать в ветке fix-stable:


$ git pull -s ours fix-xxx 

этот фиктивный мерж проходит всегда автоматом, а потом git уже просто не смотрит внутрь этой ветки.


В итоге у меня получились следующие ветки :

feat-core- -rt
feat-core-bootsplash
feat-evms
feat-evms-nodm
feat-fs-squashfs
feat-fs-unionfs
fix-core- -init
fix-core- -syslog
fix-stable
kernel-image-std-smp
kernel-source
master

D


Мержим все исправления в ветку kernel-image-std-smp, исправляем конфликты.


$ git pull . feat-fs-unionfs 

E


В ветке kernel-image-std-smp, создадим новый конфиг на базе старого:


$ cp config-i586 .config
$ make oldconig 

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


Проверяем все ли впорядке:


$ make menuconfig 

Опцию CONFIG_LOCALVERSION_AUTO следует отключить.


$ cp .config config-i586
$ vim kernel-image.spec .gear-rules
$ add_changelog kernel-image.spec
$ gear-update-tag -acv
$ git add config-i586 kernel-image.spec .gear-rules
$ git commit 

F


Собираем ядро


$ ./buildkernel-hsh --hsh-workdir=/home/stanv/hasher std-smp
или
$ ./buildkernel-hsh --hsh-options=--apt-config=/home/stanv/apt/apt.conf.sisyphus.x86_64 --hsh-workdir=/build/stanv/hasher/ std-smp
или
$ time ./buildkernel-hsh --target=x86_64 --hsh-workdir=/home/stanv/hasher --hsh-options='--apt-config=/home/stanv/apt/apt.conf.sisyphus.x86_64 --repo=/home/stanv/tmp/repo-2.6.23 --target=x86_64' wks 

Сборка дополнительных модулей

A


Каждый пакет, несущий дополнительный модуль собирается на основе шаблона.
Шаблоны для всех дополнительных модулей раньше можно было загрузить с CVS:


$ cvs -d cvs.alt:/cvs/kernel checkout -d modules kernel/modules
или
$ cvs -d anoncvs@anoncvs.altlinux.org:/cvs/kernel co -d modules kernel/modules 

Теперь шаблоны для модулей находятся в репозиториях kernel-modules у мантейнеров.

B


Например, при сборке пакета kernel-modules-nvidia-std-smp-100.14.19-alt3.132631.1.i586.rpm
будет использован шаблон modules/nvidia/kernel-modules-nvidia.spec и пакет
kernel-source-nvidia-1001419–100.14.19-alt39.i586.rpm.


Пакет kernel-source-nvidia-1001419–100.14.19-alt39.i586.rpm берем из Sisyphus.


Пакеты kernel-source-* собираются как обычно. У кого-то лежит в гите, у кого-то старым дедовским способом.
Получается что мантейниры модулей предлагают только kernel-source-%modulename, а сам бинарный модуль собирает vsu.
Пакеты с бинарными модулями нужно собирать с каждым обновлением ядра.
Если kernel-source-modulename плохо собран, тогда vsu выполняет двойную работу, либо забивает на этот модуль.

Заметки


На patch_level_numeric (1.0.0) фактически забили. Он был нужен, когда собирали pre/rc

Undeground

т.е., rpm-build-kernel – для BuildRequires, kernel-build-tools – скрипты для использования мантейнерами


pull . сейчас можно менять на merge
что лучше cherry-pick или pull ?
это в древних версиях git merge не предназначался для вызова руками
зависит от ситуации... если в ветке куча коммитов, которые в свежей версии уже есть, merge с большой вероятностью не пройдёт автоматически
если это патчи, которые не вошли в новую версию, вероятно, лучше сделать merge
а я сделал cherry :(
кстати, в подобном случае может иметь смысл сначала сделать merge новой версии в эту ветку
хотя это зависит от того, что в дальнейшем предполагается делать с этими изменениями
если нужно получить патчи для свежего апстрима, придётся делать rebase
если это какие-то изменения, которые апстриму нафиг не нужны, может быть проще смержить свежую версию апстрима туда и разгрести конфликты
кстати, в самом свежем git сделали поддержку revert и cherry-pick для merge... указывается, с каким родителем делать дифф, который потом откатывается или применяется
A->B ы :( т.е. cherry-pick может забирвать все коммиты, между A и B ?
нет... это git rebase умеет
только он портит исходный бранч
а в чем тогда новая фишка ?
cherry-pick и revert – это почти одно и то же, различаются тем, в какую сторону применяется патч
патч генерируется между указанным коммитом и его родителем
если это merge, нужно указать, какой из родительских коммитов нужно брать
вот эту опцию и добавили
т.е., если сделать cherry-pick для merge, получится один мегапатч со всеми изменениями
вообще это полезно для revert

Ссылки


Страницы, ссылающиеся на данную: AltLinux/Sisyphus


 
Файлы [Скрыть файлы/форму]
Комментариев нет. [Показать комментарии/форму]