- Kernel/build for dummies
- Содержание
- Сборка ядра для чайников на примере Unbrekable Enterprise kernel для p6 [ править ]
- Курим документацию: [ править ]
- подготовка окружения kernel-build-tools [ править ]
- подготовка git репозитария с исходниками ядра [ править ]
- Собираем [ править ]
- Что делать есть сборка обрывается [ править ]
- Беремся за модули [ править ]
- Обновление ядра
- Содержание
- update-kernel [ править ]
- Обновление модулей ядра [ править ]
- Доустановка модулей ядра [ править ]
- Установка старого ядра [ править ]
- Удаление старых версий ядра [ править ]
- QuickStart/Обновление системы
- Обновление системы до актуального состояния [ править ]
- Alterator-update-kernel
- Содержание
- Название пакета [ править ]
- Назначение [ править ]
- Запуск [ править ]
- Использование модуля [ править ]
- Установка/обновление ядра и установка модулей ядра [ править ]
- Сделать ядро загружаемым по умолчанию [ править ]
- Удаление ядра [ править ]
- Удаление модулей ядра [ править ]
- Сборка модулей ядра
- Содержание
- Модули ядра [ править ]
- О модулях и названиях [ править ]
- Как собрать модуль локально [ править ]
- Что нам нужно [ править ]
- Сборка [ править ]
- Как собрать модуль правильно [ править ]
- Шаблоны [ править ]
- Подготовка рабочей директории [ править ]
- Сборка модуля из шаблона (с помощью gear-specsubst) [ править ]
- Управление архитектурами, для которых собираются модули [ править ]
- Создание тегов для сборки на git.alt (схема с gear-specsubst) [ править ]
- Сборка модулей на git.alt [ править ]
- Некоторые моменты [ править ]
- Пересобрать отдельно один модуль [ править ]
- Сборка нового модуля [ править ]
- Сборка kernel-source-module [ править ]
- Создание нового шаблона [ править ]
- Как выложить свой модуль в репозиторий [ править ]
- Рекомендации по взаимодействию с мейнтейнерами ядер [ править ]
- Про symvers и модули зависящие от других модулей [ править ]
Kernel/build for dummies
NOTE: статья сильно устарела.
Содержание
Сборка ядра для чайников на примере Unbrekable Enterprise kernel для p6 [ править ]
Курим документацию: [ править ]
- file:///usr/share/doc/kernel-build-tools-0.99.1/README.ru.html
- Kernelnotes/mike
подготовка окружения kernel-build-tools [ править ]
Собирать будем по корану, т.е. используя hasher
подготовка git репозитария с исходниками ядра [ править ]
Согласно корану пакеты с ядрами именуются согласно шаблону kernel-image-$flavor. kernel-build-tools для сборки требует наличие в git репозитарии локального бранча с именем kernel-image-$flavor. Далее будем использовать flavor=el-uek.
создадим пустой репозитарий
создадим пустой бранч, из которого будем собирать наше ядро:
с чистой совестью проигнорируем уведомление о невозможности удаления .git/index.
Добавим репозитарии с исходниками ядер vanila и uek
проверить что мы добавили можно командой
Oracle собирая uek2 взяли за основу vanila kernel v3.0 и изменили название версии ядра, поэтому их ядро имет версию якобы 2.6.39. Это сделано для разлиной проприетарщины которая не понимает новую нумерацию версий ядра.
Скопируем бранч исходников linux-v3.0 как kernel-source:
Аналогично поступим с исходниками от oracle:
Сливаем все в кучу:
Cоздаем или попируем файлы kernel-image.spec config-x86_64 config-i586 kernel-image.spec логично взять из репозитария aspsk@ и использовать в качестве шаблона для uek. Не забиваем на:
config-* создадим на предварительно собирая ядро посредством:
Заодно создадим список модулей которые должны собираться вместе с ядром:
Настроим gear. При сборке мы планируем использовать уже упакованные до нас исходники vanila kernel из пакета kernel-source-3.0 и один большой патч который можно посмотреть командой
Собираем [ править ]
Что делать есть сборка обрывается [ править ]
Иптыть. обломались в процессе сборки, нужно поправить kernel-image.spec. На самом деле это не проблема, править и добивать ногами сборку будем hasher.
если в конце концов ядро собралось то необходимо вытащить все файлы которые изменялись из дириктории hasher/chroot и положить в kernel. Не забывая при этом говорить
и в случае если менялся spec файл:
в дириктории kernel.
если собралось, то:
Беремся за модули [ править ]
Смотрим что доступно для нашего дистрибутива, например p6
Создаем локальные бранчи
теперь можно выкатывать папку hashe/repo/ в pub для тестированя и использования.
Источник
Обновление ядра
APT в дистрибутивах ALT Linux и в Sisyphus автоматом не обновляет ядра вместе с обновлением системы (см. настройки hold в apt.conf), поскольку обновление такого критичного компонента системы может привести к нежелательным последствиям. Вместо этого в систему могут быть поставлены пакеты нескольких ядер и модулей к разным ядрам одновременно. И LiLo, и Grub можно настроить таким образом, что простая перезагрузка (в том числе по reset) будет возвращать старое ядро.
Содержание
update-kernel [ править ]
Для обновления ядра предлагается использовать утилиту update-kernel , находящуюся в одноимённом пакете. Установка, если ещё не установлено:
Пример использования (не забываем про apt-get update , если индексы сегодня ещё не обновлялись):
или, если хотите обновить/установить другой тип ядра (например un-def):
update-kernel обновляет и пакеты с модулями ядра, но исходя из списка установленных для текущего ядра пакетов. Следует понимать, что у ядер разных типов модули могут быть собраны по-разному, и, тогда, update-kernel может не доустановить нужное. Например, если у текущего ядра модуль собран в составе пакета с ядром, а у нового отдельно, то пакет с нужным модулем не будет доустановлен автоматически.
В некоторых дистрибутивах apt по умолчанию не содержит подключенных репозитариев. Для проверки и/или настройки можно воспользоваться утилитой apt-repo или просто проверить и отредактировать конфиги в /etc/apt/.
Обновление модулей ядра [ править ]
update-kernel обновляет и модули ядра, если в репозитории обновилось что-то из модулей без обновления ядра. Запуск как при обновлении ядра.
Доустановка модулей ядра [ править ]
Иногда возникает необходимость доустановить модули. Сложностей нет, но есть ряд нюансов.
где = std-def, un-def и т.п. См. kernel/Flavours
После этого уже можно обновлять модуль ядра. Например, мы хотим перейти на ветку un-def и установить модуль fglrx:
Установка старого ядра [ править ]
Иногда требуется установить старое ядро. Описание процесса.
Удаление старых версий ядра [ править ]
После успешной загрузки на обновленном ядре можно удалить старое:
Источник
QuickStart/Обновление системы
Обновление системы до актуального состояния [ править ]
После установки системы, её лучше сразу обновить до актуального состояния. Можно не обновлять и сразу приступать к работе только в том случае, если вы не планируете подключаться к сети или Интернету, не собираетесь устанавливать дополнительных программ, если всё железо успешно работает. Открываем терминал и вводим:
Получив рутовую консоль, набираем в ней:
После успешной загрузки на новом ядре (update-kernel) снова открываем терминал:
Такова общая схема обновления в пределах текущего бранча. А теперь подробнее со всеми тонкостями. Смотрим, какие репозитории сейчас подключены:
Допустим, нас это не устраивает. Допустим, в локальной сети уже есть NFS-сервер с зеркалом и мы хотим переключиться на него. Делаем следующее:
Тем самым мы указали APT’у искать репозиторий на локальном диске в каталоге /ALT/p8 , однако такого каталога ещё нет. Делаем следующее:
Здесь вместо NFSSERVER нужно вписать имя или IP-адрес сервера в своей локальной сети. По аналогии замените space своим названием экспортируемого каталога NFS. Если последняя команда отработала успешно, вы увидите содержимое этого каталога, иначе – смотрите dmesg. Обратите внимание: каждый раз после перезагрузки компьютера для обновления системы придётся заново набирать:
Так задумано! Не убирайте параметр noauto, если не хотите внезапно получить не загружаемую систему, когда начнутся проблемы в локальной сети. Осталось связать каталог /ALT с тем, что мы только что смонтировали:
Здесь /mnt/space/ALTLinux – каталог с зеркалом репозиториев, /mnt/space/ALTLinux/p8 – каталог с зеркалом бранча P8. Пути конечно же вымышленные, замените их своим вариантом.
На этом – ВСЁ, разовая подготовка завершена! Теперь все обновления пойдут не через Интернет, а с локального зеркала. Приступаем:
Первая команда («apt-get update») только обновит индексы. Её надо давать всегда перед второй командой, а также перед тем, как что-либо устанавливать. Вторая команда («apt-get dist-upgrade») обновит систему, но ядро и образ диска начальной загрузки останутся нетронутыми. Так задумано! Если хотите обновить сразу и ядро, сначала загляните СЮДА и дайте команду:
другие варианты (обусловлены тем, что в актуальных дистрибутивах АЛЬТ преимущественно используется два типа ядер – std-def и un-def):
Новое ядро загрузится только после перезапуска системы, который рекомендуется выполнить немедленно. Если с новым ядром что-то пойдёт не так, вы сможете вернуться к предыдущему варианту, выбрав его в начальном меню загрузчика. Если с новым ядром всё в порядке, не копите старые ядра, удаляйте их (только после перезагрузки):
другие варианты (с параметром «-n» ничего не изменится, вам только покажут, что будет удалено):
Если пакеты ставились из сети и кэш больше не требуется, можно освободить место на диске, дав команду:
Источник
Alterator-update-kernel
Содержание
Название пакета [ править ]
Назначение [ править ]
Модуль Обновление ядра реализует функционал утилиты update-kernel . Данный модуль предоставляет возможность:
- просматривать список установленных ядер;
- устанавливать, обновлять и удалять ядра;
- задавать ядро, загружаемое по умолчанию;
- устанавливать/удалять отдельные модули ядра.
Запуск [ править ]
Модуль Обновление ядра доступен как в GUI (раздел Система ▷ Обновление ядра ):
так и в веб-интерфейсе https://ip-address:8080 ( Система ▷ Обновление ядра ):
Использование модуля [ править ]
В главном окне модуля отображается ядро, загруженное по умолчанию, список установленных ядер (поле «Установленные ядра»), список установленных модулей ядра.
Установка/обновление ядра и установка модулей ядра [ править ]
При обновлении ядра, обновляются и модули ядра, но исходя из списка установленных для текущего ядра пакетов.
Для того, чтобы обновить ядро или установить модули ядра, необходимо нажать кнопку «Обновить ядро…».
В открывшемся окне будет показано доступное к установке ядро:
В выпадающем списке можно выбрать тип ядра (flavour — см. Kernels/Flavours). В окне «Доступные модули» отмечаются модули, которые будут установлены.
Чтобы обновить ядро, необходимо нажать кнопку «Обновить ядро». Откроется окно, в котором следует нажать кнопку «Да» для того, чтобы обновить ядро, или «Нет», чтобы отказаться от данного действия.
Установленное ядро станет загружаемым по умолчанию.
Если ядро не требует обновления, в окне «Доступные модули» можно отметить модули ядра, необходимые к установке, и нажать кнопку «Установить модули»:
Новое ядро загрузится только после перезагрузки системы.
Сделать ядро загружаемым по умолчанию [ править ]
В дистрибутивах ALT Linux можно установить несколько версий ядра одного и того же типа одновременно. После установки или обновления ядра старые ядра не удаляются. В случае возникновения проблем с новым ядром можно переключиться на установленное ранее.
Для этого следует выбрать нужное ядро в списке «Установленные ядра» и нажать кнопку «Сделать ядро загружаемым по умолчанию»:
Удаление ядра [ править ]
Накопленный при обновлениях набор ранее установленных ядер можно удалить для освобождения дискового пространства. Для этого следует выбрать нужное ядро в списке «Установленные ядра» и нажать кнопку «Удалить ядро».
Удаление модулей ядра [ править ]
При установке операционной системы автоматически устанавливаются модули для различных аппаратных средств, включая различные модели видеокарт. Для уменьшения нагрузки при обновлениях неиспользуемые модули можно удалить. Для этого в списке «Установленные ядра» выберите ядро, модули которого хотите удалить, затем в списке «Установленные модули» выделите удаляемые модули и нажмите кнопку «Удалить модуль»:
Источник
Сборка модулей ядра
Содержание
Модули ядра [ править ]
Ядро Linux содержит в себе множество кода, поддерживающее ту или иную возможность или оборудование. Основная часть этого кода (обычно это код поддержки процессоров, памяти и других базовых вещей) вкомпилирована в ядро и загружается с ним, а части кода, необходимые только части пользователей — драйверы устройств, поддержка файловых систем, и т.д. — собраны в виде модулей.
Модули могут подключаться к ядру по команде пользователя (modprobe, insmod) или автоматически при помощи udev, и быть выгружены либо самим ядром, либо командой rmmod.
Большинство модулей находится в пакете ядра, однако иногда по техническим, административным или юридическим причинам некоторые модули собираются отдельно.
О модулях и названиях [ править ]
Поскольку в репозитории может быть множество ядер, модули собираются особым способом: имеется пакет с исходными кодами модуля, и пакеты с модулями, собранным для конкретного ядра. При этом SRPM последних содержит только .spec и патчи, а исходные коды получает по сборочным зависимостям. Таким образом, для модуля module и варианта ядра flavour у нас имеются пакеты с именами
- kernel-source-module — содержит только исходники
- kernel-modules-module-flavour — модуль module, собранный для ядра flavour (например, kernel-modules-nvidia-std-def)
Поле release пакетов с модулями заполняется так: alt . . , где
- — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
- — версия ядра в формате (2^16) * major + (2^8) * mid + minor, то есть 2.6.25=132633. Не пугайтесь, это число рассчитывает скрипт, описанный позже;
- — релиз пакета с ядром.
К примеру, модуль с nvidia для ядра kernel-image-std-def-2.6.25-alt8 будет называться kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8.
Как собрать модуль локально [ править ]
Данная фаза нужна в первую очередь для тестирования модуля, и, в общем-то, необязательна, но полезна для понимания процесса.
Что нам нужно [ править ]
Кроме gcc, make и прочих стандартных сборочных вещей нам нужно kernel-headers-modules- (и всё что от него зависит). Этот пакет содержит ту часть исходных кодов, заголовочных файлов, make-файлов и скриптов, которые необходимы для сборки модулей для данного ядра.
Сборка [ править ]
Скачав и распаковав исходники модуля, мы обнаружим что просто make обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге /lib/modules/ /build , но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в /lib/modules/ запрещён.
Для того, чтобы обойти эту проблему, нужно переопределить переменную (обычно KERNELSOURCE или KSRC ) в Makefile . Далее запускаем сборку, например make KSRC=/usr/src/linux-2.6.25-std-def . Обычно модуль после этого собирается.
Собранный модуль можно попробовать загрузить с помощью insmod , или положить его к другим модулям ядра в /lib/modules/ и загрузить modprobe . Если модуль загрузился и работает, то можно переходить к следующей части.
Как собрать модуль правильно [ править ]
Почему предыдущий способ не является правильным? Потому что он не дистрибутивен. Для нормальной сборки нам нужны:
- знание git (крайне желательно хотя бы начальное знание!)
- умение пользоваться gear и hasher
- настроенный hasher
- доступ на git.alt (для публикации результатов)
- достаточно терпения
Шаблоны [ править ]
Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, была разработана схема, при которой для каждого модуля создается шаблон, а gear (при помощи директивы specsubst, в которой указывается flavour ядра) подгоняет этот шаблон к конкретному ядру (в том числе вычисляет релиз модуля). Остальная работа ложится на макрос %setup_kernel_module, который вычисляет все остальные параметры, нужные для сборки модуля: версию ядра, релиз ядра и релиз модуля. Сами шаблоны хранятся в git-репозитории, в котором есть множество веток, ветки с шаблонами называются template/module/distro, где module — это собственно название модуля (например, nvidia) а distro — это то, подо что мы собираем. Обычно это sisyphus, но, поскольку для разных бранчей шаблоны приходиться менять, можно установить поле distro в соответствующее значение. Обычно distro сейчас совпадает с именем бранча.
Подготовка рабочей директории [ править ]
Нам потребуются утилита km-create-tag для сборки модулей из пакета kernel-build-tools:
Для использования бранчей с шаблонами придётся их завести локально, например:
Сборка модуля из шаблона (с помощью gear-specsubst) [ править ]
Когда вы собираете локально в тестовых целях, удобно установить параметр gear.specsubst.kflavour с вашим ядром:
После этого модуль можно собрать с помощью команды:
Управление архитектурами, для которых собираются модули [ править ]
Разные ветки ядер в разных репозиториях собираются для разного набора архитектур. Аналогично, многие модули имеют ограничения, в силу которых могут быть собраны не для всех возможных архитектур.
Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность:
В файле .gear/km-karch может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox:
Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64
Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян).
Для того, чтоб это работало, в спек файле должны быть строки:
А в .gear/rules файле строка:
Создание тегов для сборки на git.alt (схема с gear-specsubst) [ править ]
Например, для создания тега для модуля nvidia, собираемого для ядра std-def
Или, для создания тегов для всех модулей, можно сделать:
Сборка модулей на git.alt [ править ]
После этого можно запушить полученные бранчи и тэги на git.alt.
и добавить список модулей к последнему task’у (где предположительно уже добавлен на сборку соответствующий kernel-image):
Следует, однако, учитывать, что updatemodules и km-create-tag не затирают файл out/taglist и вам нужно делать это вручную.
Если же вы обновляете ядро, но не собираетесь обновлять шаблоны модулей, можно сделать:
$ ssh git.alt task add [номер задания] kmodules std-def
это добавит в задание (где предположительно уже добавлен на сборку соответствующий kernel-image) все модули, собранные для ядра std-def.
Некоторые моменты [ править ]
- Если в репозитории: kernel-image-std-def-3.0.4-alt0.M60P.1.i586.rpm
- Тогда в имени пакета: kernel-modules-emlog-std-def-0.51-alt2.196612.0.M60P.1.i586.rpm
В релиз модуля запаковывается версия + релиз ядра. СТРАШНО?
Пересобрать отдельно один модуль [ править ]
Допустим нужно пересобрать в репозитарий некий модуль без пересборки ядра и всех модулей.
Ветка kernel-modules-rt3070-std-def/sisyphus — должна быть вытянута последняя из http://git.altlinux.org/gears/
- Изменяем ветку template/rt3070/sisyphus, коммитим наши изменения
- km-create-tag -k std-def rt3070
- проверяем сборку чем-нибудь вроде: gear -t $(git describe) —hasher — hsh $TMP/
Сборка нового модуля [ править ]
Сборка kernel-source-module [ править ]
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так:
Редактируем по образу и подобию kernel-source-module.spec — обычно там надо заменить имя модуля, версию, описание и changelog, а сам процесс сборки обычно можно не трогать.
Далее собираем пакет при помощи gear. В результате в пакете должен оказаться всего один файл, а именно /usr/src/kernel/sources/kernel-source-module.tar.bz2
Обратите внимание на то, что некоторые пакеты с исходниками в своём имени содержат версию, например, kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 2.6.18).
Создание нового шаблона [ править ]
После сборки пакета с исходными кодами модуля, нам нужно создать новую ветку в репозитории с модулями:
где module — название вашего модуля.
Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:
Внимание, верхняя запись changelog должна оставаться неизменной и состоять их тех жутких макросов, из которых она состоит в любом модуле ядра в любом актуальном репозитории ALT
Как выложить свой модуль в репозиторий [ править ]
Выкладывание модулей ничем не отличается от выкладывания обычных пакетов.
Выкладываем собственно модуль:
Осталось собрать пакеты через git.alt.
Важное замечание: для того чтобы сборка прошла правильно, kernel-source-module должен быть собран до сборки kernel-modules-module.
Рекомендации по взаимодействию с мейнтейнерами ядер [ править ]
Для нормальной совместной работы рекомендуется:
- При обновлении модуля обновлять сборки под максимальное количество ядер
- Своевременно обновлять шаблоны в репозитории на git.alt
- Оповестить мейнтейнеров ядер (в списке рассылки devel-kernel), о том что есть ваш модуль,
- Настроить git remote на kernel-modules других мейнтейнеров,
- В спеках kernel-modules- поле Packager установить в Kernel Maintainers team.
Про symvers и модули зависящие от других модулей [ править ]
Иногда бывает, что пакет с модулями, должен собираться под другой пакет с модулями. Так например просиходит с gspca и v4l. Для нормальной сборки нам нужно 2 вещи: во-первых, проставить правильно зависимости на headers (у v4l есть свои хедеры), во-вторых, нужно импортировать файл с symvers. В gscpca проблема решилась добавлением следующей строчки в %prep фазу пакета с модулем gspca:
Источник