OpenBSD FAQ - Собираем систему из исходников [FAQ - На главную]

OpenBSD's Flavors

Существует три flavors (разновидности, ветки) OpenBSD: Только для двух последних версий (релиза) OpenBSD доступны исправления и патчи безопасности для базовой части ОС (base system).

Большинству пользователей рекомендуется использовать либо -stable либо release. Как уже было сказано, многие пользователи используют -current, и, что очень важно, некоторые делают это для обнаружения ошибок и тестирования новых возможностей и функциональности.

Разрабатываемые Snapshot'ы

Между официальными релизами OpenBSD выкладываются также snapshot'ы на основе -current ветки. Это просто сборки скомпилированного кода, который сейчас находится в репозитории.

Последний доступный snapshot это все, что обычно необходимо для запуска -current. Если вы хотите собрать все из исходников, используйте только последний доступный snapshot. Этого можно добиться при помощи опции -s утилиты sysupgrade(8). Проверьте страницу о последних -current и использования snapshots, чтобы ознакомиться с последними изменениями конфигурации или дополнительными шагами, необходимыми для сборки из исходников.

Не исключено, что вы обнаружите ошибки в snapshots. Собственно это и является причиной, почему они собираются и доступны всем для скачивания. Если вы нашли баг, не стесняйтесь сообщить о нем, если этого еще не сделал кто-то другой.

Собираем OpenBSD из исходников

Сборка OpenBSD из исходников включает в себя последовательность из нескольких шагов: Этот раздел FAQ расскажет и поможет в подготовке, необходимой для описанных выше шагов. Основное руководство по этой теме находится в release(8).

Обновление бинарников до следующих доступных версий

Не пытайтесь обновляться с одного релиза до другого путем компиляции исходного кода.

Проверьте и убедитесь, что у вас установлена самая последняя доступная версия системы. Это должна быть либо OpenBSD x.y, если вы хотите обновиться до OpenBSD x.y-stable, либо последний snapshot, если вы хотите обновиться до -current.

Загрузка исходников

OpenBSD использует систему контроля версий CVS для работы с исходниками. Программа cvs(1) используется для загрузки исходников на вашу машину для дальнейшей компиляции. Краткую информацию по программе, введение, можно найти в cvs(1), а более детальная докуменация, включающая примеры работы с деревом исходников, находится на специальной странице о анонимных CVS. Сначала вы должны загрузить себе содержимое репозитория при помощи команды cvs checkout. После этого, чтобы обновить уже существующие или дозагрузить новые файлы из того же репозитория, надо будет сделать cvs update. Вы так же можете настроить и поддерживать свой локальный CVS репозиторий при помощи программы reposync, доступной в виде пакета. О настройке зеркала репозитория рассказывается на странице, посвященной анонимному CVS.

Избегайте Root привилегий

Избегайте использование cvs(1) от root. Каталог /usr/src (где обычно находятся загруженные исходники) открыт на запись для участников группы wsrc по умолчанию, так что добавьте пользователей, которым нужно пользоваться cvs(1), в эту группу. 
# user mod -G wsrc exampleuser
Изменения вструпят в силу после следующего входа в систему этого пользователя.

Если вы хотите загрузить исходники xenocara или портов от имени этого пользователя, потребуется создать каталог и установить права доступа вручную. 

# cd /usr
# mkdir -p   xenocara ports
# chgrp wsrc xenocara ports
# chmod 775  xenocara ports

Загрузка -stable

Для загрузки -stable src дерева исходников, укажите branch, который вам нужен, при помощи параметра -r: 
$ cd /usr
$ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -rOPENBSD_7_5 -P src
После того как вы загрузили исходники, вы можете обновить/синхронизировать дерево в любое время при помощи следующих команд: 
$ cd /usr/src
$ cvs -q up -Pd -rOPENBSD_7_5
Замените src на xenocara или ports в зависимости от того, что именно вы планируете сделать. Так как все части OpenBSD тесно взаимосвязаны между собой, все деревья с исходниками, с которыми вы работаете, должны загружаться и обновляться синхронно.

Загрузка -current

Для загрузки -current src дерева исходников, воспользуйтесь следующими командами: 
$ cd /usr
$ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -P src
Обновить их можно можно вот так: 
$ cd /usr/src
$ cvs -q up -Pd -A
Замените src на необходимый вами модуль, такой как xenocara или ports.

Сборка OpenBSD

Наконец-то вы готовы приступить к сборке OpenBSD из исходников.

Если вы собираете -current, просмотрите изменения, а также специальные инструкции по сборке, перечисленные на этой странице.

Следуйте детальным инструкциям, описанным в шагах 2 и 3 руководства по release(8).

Дополнительная информация по процессу собрки

Сборка релиза

Релиз - это полный комплект файлов, который может быть использован для установки или обновлении OpenBSD на другом компьютере. В качестве примера необходимости сборки релиза можно рассмотреть ситуацию, когда вы собираете -stable на быстром компьютере, с целью последующей установки собранного релиза на другие машины. Если у вас только один компьютер с OpenBSD, у вас нет никакой необходимости собирать релиз, поскольку описанные выше действия уже сделали все необходимое для вас.

Инструкции по сборке релиза находятся в release(8). Этот процесс использует бинарники в /usr/obj, процесс создания которых описывался выше.

Замечание: если вы захотите использовать эти файлы для установки или обновлении через/используя HTTP(S), создайте файл index.txt, который будет содержать список всех файлов, вошедьших в новый релиз. 

# ls -nT > index.txt
Если вы хотите подписать созданные файлы, man-страница по signify(1) расскажет как это сделать.

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

Создание релиза требует наличие noperm-раздела. Это позволит инфраструктуре сборки использовать непривилегированного пользователя build для большей части процесса.

Создайте ФС на /dest с установленной noperm mount(8) опцией. Соответствующая fstab(5) строка должна быть похожа на эту: 

c73d2198f83ef845.m /dest ffs rw,nosuid,noperm 1 2
Владельцем (owner) этой ФС должен быть пользователь build, который имеет там права 700: 
# chown build /dest
# chmod 700   /dest
Создайте каталог DESTDIR для base и xenocara: 
# mkdir /dest/{,x}base
Ваша RELEASEDIR не обязательно должна быть на noperm ФС. Удоставерьтесь, что она пренадлежит пользователю build и имеет права u=rwx.

Использование noperm mfs раздела

Вы можете использовать mfs раздел вместо физического диска. Это можно сделать добавив похожую строчку в ваш /etc/fstab: 
swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0
Создайте прототип каталога DESTDIR: 
# mkdir -p /var/dest/{,x}base
# chown -R build /var/dest
# chmod -R 700   /var/dest
Теперь вы можете подмонтировать /dest до того как приступили к сборке релиза: 
# mount /dest

Собираем X

Начиная с 7-ой версии, X.Org стал использовать модульную систему сборки, разделив исходники X.org на более трехсот более или менее связанных друг с другом пакетов.

Чтобы упростить жизни пользователям OpenBSD, была разработана система, получившая название Xenocara. Эта система "конвертирует" X обратно в одно общее большее дерево исходных кодов. В качестве дополнительного бонуса, этот процесс сборки стал похож на аналогичные процессы, используемые остальными компонентами OpenBSD.

Официальные инструкции по сборке X находятся в файле xenocara/README, а так же описаны в пятом шаге release(8).

Распростаненные проблемы при компиляции

Чаще всего к проблемам при сборке приводит невнимательность. Есть отдельные проблемы при сборке -current из-за новых изменений коде, но проблемы при сборке release или -stable чаще всего вызваны ошибками самого пользователя.

Чаще всего можно столкнуться со следующими:

Я забыл сделать make obj перед make build

Выполнение make build до make obj приведет к тому, что целая куча объектных файлов будет разбросана в /usr/src каталоге. Это плохо. Чтобы не загужать исходники (src tree) снова, удалите obj-файлы: 
$ cd /usr/src
$ find . -type l -name obj -delete
$ make cleandir
$ rm -rf /usr/obj/*
$ make obj

Сборка останавливается из-за ошибки "Signal 11"

Сборка OpenBSD и других программ из исходников гораздо сильнее нагружает аппаратную часть машины (интенсивно используется процессор, жеский диск и память), чем большинство других задач. Signal 11 обычно возникает при аппаратных проблемах.

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

Для получения дополнительной информации смотрите Sig11 FAQ.

Разные вопросы и советы

Добавьте себя в группу wobj

Если вы собираетесь скомпилировать отдельную программу в дереве с исходниками -- например, внося изменения в ее код, т.е. занимаясь разработкой -- вам понадобиться добавить себя в группу wobj. Это даст вам права на запись в каталог /usr/obj.

Tag файлов

Так как mg(1) и vi(1) являются редакторами для разработчиков, они имеют встроенную поддержку файлов ctags(1), что позволяет быстро перемещаться по дереву с исходниками.

Для большинства программ или архивов с исходниками (library source directories), вы можете создать ./tags файлы вот так: 

$ make tags
Во время сборки и установки libc, создается файл /var/db/libc.tags.

По умолчанию, tags ядра для каждой архитектуры находится в /sys/arch/$(machine)/. Эти файлы могут быть созданы при помощи make tags, запущенной в /sys/kern. Вы можете выполнить make links от root, чтобы создать symlink на tags файл вашего ядра в каждом каталоге и в /var/db/.

Как я могу пропустить сборку той или иной части дерева?

Используй параметр SKIPDIR в mk.conf(5).

Как на счет кросскомпиляции?

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

Когда разработчики начинают поддерживать новую платформу, одним из первых важнейших тестов является так называемый "native building", т.е. процесс сборки системы на той же платформе, для которой она собирается. Сборка системы из исходников значительно нагружает и саму ОС, и машину, что само по себе является хорошим тестом работоспособности. По этой причине в OpenBSD используется метод сборки всех компонентов на платформе, для которой она собирается и на которой планируется использоваться.

Собственное ядро

Есть три возможности настройки ядра:

Настройка во время загрузки

Boot-time конфигурация OpenBSD ядра, boot_config(8), позволяет администратору изменить некоторые kernel-настройки, такие как влкючение или отключение поддержки какого-то железа, без необходимости пересобирать ядро.

Для загрузки в User Kernel Config, или UKC, используйте опцию -c при загрузке. 

Using drive 0, partition 3.
Loading......
probing: pc0 com0 com1 mem[638K 1918M a20=on]
disk: hd0+ hd1+
>> OpenBSD/amd64 BOOT 3.33
boot> boot hd0a:/bsd -c
После этого появится приглашение UKC. Используйте комадну help чтобы получить список доступных команд.

Использование boot_config(8) дает лишь временное одноразовое изменение, т.е. процедуру придется повторять каждый раз после перезагрузки. В следующем разделе объясняется, как сделать изменения постоянными.

Использование config(8) для изменения параметров ядра

Запуск config(8) с параметром -e позволит войти в UKC в запущенной системе. Все внесенные изменения вступят в силу после перезагрузки. Параметр -u проверяет, были ли внесены изменения в ядро во время загрузки, т.е. использовали ли вы параметр boot -c для входа в UKC во время загрузки системы.

Чтобы избежать риска перезаписи рабочего ядра сломанным, предусмотрена возможность использования параметра -o для сохранения нового измененного ядра в новый файл для тестирования: 

# config -e -o /bsd.new /bsd
Таким образмо можно сохранить новое ядро в /bsd.new файл. После того, как вы загрузили это новое ядро и убедились, что все работает, изменения можно сделать постоянными, поместив их в bsd.re-config(5). Это избавит от необходимости выбирать ядро при загрузке и гарантирует, что hibernation и линковка ядра (kernel relinking) продолжат работать.

Примеры конфигурации ядра можно найти в man-странице для config(8).

Сборка собственного ядра

Только GENERIC и GENERIC.MP ядра поддерживаются командой разработчиков. Конфигурация GENERIC ядра зависит от комбинации параметров в /sys/arch/$(machine)/conf/GENERIC и /sys/conf/GENERIC. Сообщение о проблеме в собственно собраном ядре практически всегда приведет к тому, что вам предложат попытаться воспроизвести проблему с GENERIC ядром.

Ознакомьтесь с документацией для config(8) и options(4). Следующие шаги являются частью процесса сборки собственного ядра: 

$ cd /sys/arch/$(machine)/conf
$ cp GENERIC CUSTOM
$ vi CUSTOM    # make your changes
$ config CUSTOM
$ cd ../compile/CUSTOM
$ make

Подготовка Diff

Если вы изменили что-то в коде OpenBSD и решили поделиться этими изменениями с разработчиками, не забывайте о следующем: Если вы используете git зеркало с исходниками OpenBSD, в вашем репозитории нужно будет выполнить 
$ git config diff.noprefix true
после чего создать diff можно будет вот так: 
$ git diff --relative .