Альт линукс исходный код

Самостоятельная сборка ядра обычными средствами сборки, без создания 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 на новое ядро — таким образом, загрузка ядра по умолчанию (из первого пункта загрузчика) будет в это ядро.

Источник

Получение исходного кода ядер Альт с помощью git

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

Название git remote и бранчей

Будем использовать схему именования позволяющую работать со множеством репозиториев, бранчей и апстримов.

Git remote для gears репозиториев будет называться gears/флейвор , то есть для std-def, это будет gears/std-def , (затем можно будет добавить gears/un-def или апстримные репозитории), а git бранч назовём флейвор/бранч_дистрибутива , то есть в нашем случае это std-def/sisyphus . Такая схема позволит различить remote и бранчи для разных флейворов.

Клонирование репозитория

Клонируем репозиторий так, чтоб remote назывался gears/std-def (опция -o ) в каталог linux (в будущем другие флейворы тоже будут там) и открываем бранч std-def/sisyphus из него:

$ git clone -n -o gears/std-def https://git.altlinux.org/gears/k/kernel-image-std-def.git linux

linux$ git remote add -f gears/std-def https://git.altlinux.org/gears/k/kernel-image-std-def.git

Примечание: Через какое-то время понадобится обновить исходный код ядра, можно не повторять предыдущие шаги, а сделать git fetch нужному remote и обязательно открыть/обновить нужный бранч (см. ниже).

linux$ git fetch gears/std-def

Открываем нужный бранч

В нужном бранче уже применены все ALT specific патчи, поэтому, достаточно его открыть. Называем его в соответствии с нашей схемой описанной выше.

Первоначальное (после клонирования) открытие бранча — создание локального бранча std-def/sisyphus соответствующего gears/std-def/sisyphus (то есть бранчу sisyphus в remote gears/std-def ).

linux$ git checkout -B std-def/sisyphus gears/std-def/sisyphus

Последующее (после git fetch ) открытие бранча и его обновление:

linux$ git checkout std-def/sisyphus linux$ git pull --rebase

Далее можно убедиться, что ядро свежее посмотрев на даты в git log .

Проверка целостности исходного кода

Проверьте целостность полученного исходного кода как описано в статье «Проверка целостности исходного кода в git репозитории ядра».

Источник

Самостоятельная сборка ядра с помощью средства пакетирования (hasher) на примере std-def

Все пакеты в Альт собираются с помощью инструмента hasher и ядро не исключение. Для того, чтоб воспроизвести сборку пакета ядра вам понадобится около 26 гигабайт дискового пространства. Сборка не будет на 100% совпадать с оригинальным пакетом так как у вас будет различаться сборочная среда — версии утилит с помощью которых осуществлялась сборка.

Настраиваем использование hasher

Настройка системы

Под root ставим необходимые пакеты и настраиваем hasher:

root# apt-get update root# apt-get install -y hasher gear kernel-build-tools

Для вашего пользователя добавляем пользователей-сателлитов. Допустим, у вас рабочий пользователь devel, тогда команды следующие:

root# hasher-useradd devel Adding user devel to group devel_a Adding user devel to group devel_b Adding user devel to group hashman 

Добавляем в /etc/hasher-priv/system строки:

allowed_mountpoints=/proc,/dev/pts,/dev/shm,/sys allowed_devices=/dev/kvm allow_ttydev=yes 

Запускаем необходимый сервис:

root# systemctl enable --now hasher-privd

Настройка пользователя

По умолчанию hasher использует системные APT репозитории, но все это настраивается (через ~/.hasher/config документация в man hsh ). Под пользователем создаем рабочий и конфигурационный каталоги:

$ mkdir -p ~/hasher ~/.hasher

Дополнительно нужно сконфигурировать hasher, например для сборки из Сизифа под x86_64, примеры содержимого трех конфигурационных файлов:

Файл ~/.hasher/config

known_mountpoints=/proc,/dev/pts,/dev/kvm lazy_cleanup=yes def_target=x86_64 apt_config=~/.hasher/apt.conf 

lazy_cleanup=yes не обязателен и нужен для того чтоб сборочная среда не была очищена после сборки, если вы захотите ей воспользоваться через hsh-shell .

Файл ~/.hasher/apt.conf

Dir::Etc::main "/dev/null"; Dir::Etc::parts "/var/empty"; Dir::Etc::SourceParts "/var/empty"; Dir::Etc::SourceList "/home/devel/.hasher/sources.list"; 

Обратите внимание, что в параметре SourceList указан полный путь в домашний каталог вашего пользователя devel.

Файл ~/.hasher/sources.list

rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/x86_64 classic rpm [alt] http://ftp.altlinux.org/pub/distributions/ALTLinux Sisyphus/noarch classic 

Примечание: Соответственно, для сборки под p10, нужно заменить тут Sisyphus на p10/branch , в этом случае [alt] надо заменить на [p10] . (Значение в квадратных скобках указывает, какими ключами проверять подписи при установке пакетов, поэтому отсутствие в этих ссылках https не критично.) Для сборки под другую архитектуру заменяйте x86_64 , скажем, на i586 (так же надо поменять значение у def_target в ~/.hasher/config ).

Для того чтоб убедиться, что hasher настроен и работает можно запустить hsh —init .

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

Получите и проверьте целостность исходного кода как описано в статье «Получение исходного кода ядер Альт с помощью Git».

Сборка из пакетного тэга

Самый простой вариант — собрать из пакетного Git тэга. Для этого находим нужный тэг — у ядра они как правило начинаются на kernel-image- содержат флейвор, версию и релиз через дефис. Например, вы хотите собрать тэг kernel-image-std-def-5.15.78-alt1 .

linux$ gear-hsh -t kernel-image-std-def-5.15.78-alt1 |& tee build.log . Wrote: /usr/src/RPM/SRPMS/kernel-image-std-def-5.15.78-alt1.src.rpm (w2T16.xzdio) Wrote: /usr/src/RPM/RPMS/x86_64/kernel-image-std-def-5.15.78-alt1.x86_64.rpm (w2T16.xzdio) . 

На производительной машине это может занять 20-30 минут. RPM пакеты появятся в архитектурно-зависимых каталогах в ~/hasher/repo/ (пути из строк Wrote: /usr/src/RPM/… это пути внутри chroot hasher’а).

Сборка без тэга

Более сложный вариант сборки, но позволяющий вносить ваши изменения.

В релизном тэге могут содержаться важные параметры сборки — для ядра это флейвор (kflavour). Для сборки без тэга необходимо его установить в правильное значение (и не забывать менять, если вы собираете ядро другого флейвора) в Git конфиге репозитория:

linux$ git config --local gear.specsubst.kflavour std-def

Если вы не член ALT Linux Team, то надо отключить некоторые проверки при сборке пакетов, добавив в ~/.hasher/config параметр no_sisyphus_check= и указать ваш Е-мэйл адрес в packager= :

no_sisyphus_check="packager,changelog,gpg" packager="Test Test " 

Затем внесите ваши изменения, для пример отключим DEBUG_INFO, который включен в config :

linux$ scripts/config --file config -d DEBUG_INFO linux$ git commit -a -m "Turn off DEBUG_INFO"

Если вы не меняли версию ядра а лишь применили изменения конфигурации или наложили патч, то увеличьте в kernel-image.spec в строке Release: число после alt (например с alt1 на alt2 ). Это позволит не перепутать собранное вами ядро с ядром из репозитория. Данное изменение требует добавления записи в %changelog :

linux$ perl -pi -e 's/^(Release:.*alt)(\d+)/$1.($2+1)/e' kernel-image.spec linux$ safe-add-changelog -e "- Turned off DEBUG_INFO." kernel-image.spec

Не обязательный шаг — коммитим изменение spec:

linux$ gear-commit -a --no-edit

После этого воспользуемся опцией —commit у gear-hsh , которая делает автоматический временный коммит и применяет kflavour, который мы ранее ставили в конфиге. Эту опцию надо применять даже в случае если вы уже закоммитили ваши изменения, но собираете не из тэга.

linux$ gear-hsh --commit |& tee build.log

Сборка из своего тэга

Аналогично предыдущему варианту, 1) прописывать флейвор к конфиг не нужно, 2) коммитим свои изменения, 3) ставим тэг (например, он будет называться test1 ) командой gear-create-tag и 4) собираем из тэга:

linux$ gear-create-tag -n test1 -s kflavour=std-def linux$ gear-hsh -t test1 |& tee build.log

Источник