![[OpenBSD]](../../images/smalltitle.gif){kind=small}
[FAQ-Index] [Глава 4 - Установка OpenBSD 5.2] [Глава 6 - Сеть]
,------o-----------o----X 4.9 Stable
| . .
| . ,------o---------o----X 5.0 Stable
| . | . .
| . | . ,----o----------o--> 5.1 Stable
| . | . | . .
| . | . | . ,-----o--> 5.2 Stable
| . | . | . | .
| . | . | . | .
-->4.9Rel----->5.0Rel----->5.1Rel----->5.2Rel----> Current
Время --->
Ветка -current используется для разработки следующего релиза -release OpenBSD. Каждые шесть месяцев, когда выходит новая версия OpenBSD, -current замораживается и становится релизом -release: официальной точкой в дереве исходных кодов. Исходники в релизах никогда не меняются; это то, что находится на CD и FTP серверах.
Ветка -stable базируется на коде из -release и является ответвлением основной линии разработки OpenBSD. Когда в -current вносятся серьёзные исправления, они переносятся (back ported) в -stable; по этой причине -stable также известна, как »patch-branch«. На приведённой иллюстрации вертикальные пунктирные линии обозначают исправления ошибок, включаемые в ветви -stable. Следует также отметить, что ветвь 4.9-stable подходит к концу вместе с 5.1-release, а 5.0-stable заканчивается с 5.2-release -- старые релизы поддерживаются обычно до появления двух последующих. Поддержка старых релизов отнимает время и ресурсы, в то время как мы продолжаем поддерживать старые релизы, мы могли бы сконцентрироваться на новых возможностях. Ветка -stable целенаправленно поддерживается легко перестраиваемой из -release той же версии (например переход от 5.2-release к 5.2-stable).
Ветка -stable - это тот же -release плюс патчи, находящиеся на странице errata (пер. с англ. – «опечатка, описка»), и некоторые изменения, не входящие в список errata. Обычно на практике -stable работает аналогично -release’у, на котором он и основан. Если man страницы должны быть изменены, они, возможно, не будут занесены в -stable. Другими словами, поддержка нового устройства НЕ будет добавлена в -stable и, скорее всего, поддержка новых возможностей не будет добавлена.
Стоит отметить, что обозначение "-stable" не подразумевает то, что -current ненадежен. Скорее, -current изменяется и развивается, тогда как поведение и API -stable не изменяются, и вам не придется изучать заново свою систему, или изменять конфигурационные файлы, или испытывать проблемы с установкой дополнительных приложений в систему.
В действительности, так как мы надеемся непрерывно совершенствовать OpenBSD, вы можете даже обнаружить, что -current надежней чем -stable, более безопасна, и, конечно же, включает новые функции. Можно сказать, что -current является »лучшей« версией OpenBSD.
Большинству пользователей рекомендуется использовать либо -stable либо -release. Как уже было сказано, много пользователей используют -current, и, что очень важно, некоторые делают это для обнаружения ошибок и тестирования новых возможностей. Несмотря на это, если вы не знаете, как правильно объяснить, определить и бороться с проблемой, не говорите себе (или еще кому-либо), что вы «помогаете проекту» используя -current. «Это не работает!» -- не очень полезное сообщение об ошибке. Сообщение: «Недавние изменения, внесенные в драйвер pciide, нарушили совместимость с моим Slugchip-based IDE интерфейсом, dmesg работающей и нарушенной системы следующий …» -- может помочь разработчикам (разумеется оно должно быть на английском языке).
Бывает, что обычные пользователи хотят быть в «центре событий» и используют -current. Обычно, объяснением этому является то, что этот пользователь имеет устройство не поддерживаемое -release (и соответственно –stable), или хочет использовать новую возможность в –current. В этом случае выбор падает либо на -current, либо на то, чтобы не использовать это устройство, и, обычно, -current оказывается «меньшим злом». При этом пользователю не следует рассчитывать на детальную помощь от разработчиков.
Иногда спрашивают о том, существует ли возможность получить точную копию кода, который использовался при создании snapshot'а. Ответ на этот вопрос - Нет. Во-первых, для этого нет никаких серьезных причин. Во-вторых, snapshot'ы собираются по желанию, как позволяет время и как позволяют ресурсы. На быстрых платформах за день может быть создано несколько snapshot'ов, в то время как на медленных платформах их создание может занять несколько недель. Предоставление тэгов или отметок для snapshot'ов в дереве исходных кодов будет весьма непрактичным. В третьих, срезы (snapshots) часто содержат экспериментальный код, ещё не отправленный в дерево исходников.
Upgrading (модернизация) - процесс установки новой версии OpenBSD, с новой функциональностью. Например, переход от v5.1 к v5.2, или переход от среза (snapshot) 12 июня к срезу (snapshot) 20 июня. При модернизации (upgrading), как правило, вы должны ознакомиться с Following -current or the Upgrade guide (при смене релиза) для проведения необходимых изменений для запуска новой версии OpenBSD.
Updating (обновление) - процесс применения патчей к системе для улучшения качества работы БЕЗ изменения ее основной функциональности или совместимости на уровне бинарников. Обычно это выполняется наложением патча на исходный код или используя stable . Когда вы обновляете "update" вашу систему, она переходит от -release до -stable (или -release с наложенными патчами) той же самой версии, что и был изначально сам релиз. К примеру, 5.2-release стал 5.2-stable. В дальнейшем вы можете обновить его до более новой -stable той же самой версии. Обычно процесс обновления update более сложен, так как надо менять файлы /etc или другие конфигурационные системные файлы.
Таким образом, вы можете установить систему (к примеру, 5.1-release) используя CD, в дальнейшем обновить систему до 5.1-stable, а затем модернизировать (upgrade) до версии 5.2-release с CD, и, опять-таки, в дальнейшем обновить (update) перед модернизацией до следующего release.
Также необходимо понять, что процесс обновления поддерживается только в одном направлении: от старых версий к новым, и от -stable до -current. Вы не можете запустить 5.2-current (или snapshot), а потом решить, что для вас это слишком опасно, и откатиться до 5.1-stable. Единственный официальный способ вернуться к старой версии - переустановить систему с нуля. Вы вольны выбирать любой другой путь но, в этом случае не ожидайте поддержки от команды разработчиков OpenBSD.
Да, это также означает, что вы должны хорошо подумать, прежде чем переходить на -current.
Несколько причин, почему НЕ нужна перекомпиляция:
Разработчики OpenBSD регулярно выкладывают новые сборки, основанные на коде ветки -current. С большой долей вероятности этого вполне должно хватить для использования ветки -current.
Наиболее распространенная причина сборки из исходников — следование ветке -stable, для которой это единственная поддерживаемая возможность.
Wird -current aus dem Quelltext übersetzt, so ist es SEHR empfehlenswert, dies nur auf einer Maschine zu machen, auf deren Konsole man uneingeschränkten Zugriff hat. Es wird Zeiten im Entwicklungsprozess geben, in denen die Diskrepanz zwischen deinem neuen Betriebssystemkern und deinem alten Userland dazu führt, dass das System über das Netzwerk nicht ansprechbar ist. Dies ist kein Problem mit einem korrekt erzeugten -stable.
| У вас есть | Конечная цель | Обновить бинарник до | затем ... |
| старый -release | новый release | новейший release | Все готово! |
| -release | -stable | новейший release | загрузить и собрать -stable |
| старый -stable | -stable | новейший release | загрузить и собрать -stable |
| -release | -current | последний Snapshot | (optional) загрузить и собрать -current |
| старый -current | -current | последний Snapshot | (optional) загрузить и собрать -current |
Рекомендуется, что бы вы устанавливали бинарники по средствам функции "Upgrade", которая есть на установочном носителе. Если это не представляется возможным вы можете распаковать бинарники как описано здесь. К сожалению вы должны будете сделать полный процесс обновления, включая создание пользователей и внесение других изменений в каталог /etc.
После того, как вы выбрали, какой AnonCVS сервер вы будете использовать, следует загрузить ("checkout") дерево исходников, после чего сохранить и обновиться ("updates") для поддержания актуальных файлов в вашем локальном дереве.
Команды CVS(1) имеют много опций, некоторые из них необходимы для получения и обновления дерева исходных кодов. Некоторые команды могут привести к неполадкам. Важно понимать, что и в каком направлении вы делаете.
В случае -current
Предположим, что мы используем какой-нибудь AnonCVS сервер, anoncvs@anoncvs.example.org:/cvs. Мы также предполагаем, что вы используете sh(1) как командную оболочку, если вы используете другую оболочку, некоторые команды могут отличаться.В случае -stableДля загрузки -current CVS дерева исходиков:
# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -P srcПосле загрузки вы можете его обновить:
# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -Pd
Если вы хотите загрузить альтернативную "ветвь" дерева, отличную от -stable, используйте для этого опцию -r:# cd /usr # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT checkout -rOPENBSD_5_2 -P srcЭто позволит получить исходники ветки OPENBSD_5_2, которая также известна как "Patch branch" или »-stable«. Подобным образом вы можете обновить код:# cd /usr/src # export CVSROOT=anoncvs@anoncvs.example.org:/cvs # cvs -d$CVSROOT up -rOPENBSD_5_2 -PdФактически, CVS достаточно хорош для использования "тегов" в проверенной файловой системе, поэтому вам не нужно помнить часть командной строки -rOPENBSD_5_2, он сам будет помнить об этом, пока вы не очистите его или не установите новый тег, используя опцию -A для обновления. Однако лучше предоставлять больше информации при помощи опций для CVS.
Пока рассмотрены только »src« исходники, в то время как вам предстоит сделать те же самые действия для »xenocara« и »ports«. Поскольку все части OpenBSD должны быть синхронизированы, то все деревья исходников, которые вы используете, следует извлечь и обновить вместе. Возможно комбинирование (показано для -stable):
# export CVSROOT=anoncvs@anoncvs.example.org:/cvs
# cd /usr
# cvs -d$CVSROOT checkout -rOPENBSD_5_2 -P src ports xenocara
В любом случае, обновления должны затрагивать каждую директорию.
На данном этапе, вне зависимости от -stable или -current, у вас должно быть исходное дерево пригодное к использованию. Будьте очень осторожны с деревьями исходных кодов, которые вы используете. Помните о синхронизации и несмешивании разных веток.
Для распаковки исходников с CD в /usr/src (предполагая что CD смонтирован в /mnt):
# cd /usr/src; tar xzf /mnt/src.tar.gz
# cd /usr; tar xzf /mnt/xenocara.tar.gz
# cd /usr; tar xzf /mnt/ports.tar.gz
Исходные коды, которые доступны для загрузки с FTP серверов разделены на
два файла для уменьшения времени скачивания для тех, кто желает работать
только с одной частью дерева исходников. Файл sys.tar.gz содержит
в себе файлы для сборки ядра, а src.tar.gz содержит все другие
"userland" утилиты за исключением дерева портов и исходников X11.
Тем не менее, в большинстве случаев вам будут нужны оба эти файла.
Файлы src.tar.gz и sys.tar.gz находятся в /usr,
применение загруженных файлов:
# cd /usr/src
# tar xzf ../sys.tar.gz
# tar xzf ../src.tar.gz
# cd /usr
# tar xzf xenocara.tar.gz
# tar xzf ports.tar.gz
Не всем захочется распаковывать весь набор файлов, но поскольку система должна быть синхронизирована, то вам в большинстве случаев нужно будет устанавливать все части дерева.
Аналогично с опцией »-d« в команде "update" - она создаёт новые каталоги, которые могут быть добавлены к дереву, при начальной отладке. Для успешного обновления не забудьте использовать опцию -Pd.
Опытные CVS пользователи могут возразить, почему в данном примере использовался CVSROOT, поскольку cvs(1) запишет местоположения CVS сервера в проверенном дереве. Это верно, однако есть достаточно времени, где каждый может отменить anoncvs сервер по умолчанию. Многие люди рекомендуют всегда указывать хранилище прямо. Стоит так же отметить, переменная окружения CVSROOT может быть использована непосредственно в cvs(1) только в том случае, если ничто другое её не перезаписывает (т.е., без неё cvs(1) выдаст ошибку), тогда как определение её в командной строке cvs(1) презапишет все другие значения.
Часто бывает полезно использовать файл .cvsrc в домашнем каталоге, чтобы определить значения по умолчанию для некоторых из этих опций. Пример .cvsrc файла:
$ more ~/.cvsrc
cvs -q -danoncvs@anoncvs.example.org:/cvs
diff -up
update -Pd
checkout -P
Этот файл будет заставлять cvs(1) использовать сервер
anoncvs@anoncvs.example.org:/cvs, исключая обычно ненужный вывод
(»-q« обозначает »quiet«, т.е. тихий) для всех операций, "cvs up" команда
по умолчанию с использованием -Pd, "cvs diff" по умолчанию для обеспечения
"unified diffs" из-за опции »-u« и "cvs checkout" будет использовать опцию
»-P«. Хотя это удобно, но если вы забудете, что этот файл существует или
попытаетесь выполнить команды, которые вы привыкли использовать на машине без этого
файла, у вас могут возникнуть проблемы.
Поскольку исходные деревья в основном состоят из большого количества маленьких файлов, включая обновления для части дерева исходных кодов, то это всегда будет давать значительно лучшую производительность.
Понятно, ядро СИЛЬНО связано с аппаратной частью системы. Исходный код ядра находится в каталоге /usr/src/sys. Некоторая часть кода ядра OpenBSD используется для всех поддерживаемых платформ, другие специфичны для конкретных архитектур. Если вы посмотрите деректории /usr/src/sys/arch/ некоторые вещи могут вас немного смутить -- к примеру, здесь есть каталоги mac68k, m68k и mvme68k. В данном случае, системы mvme68k и mac68k работают с использованием одного и того же процессора, однако данные системы различаются весьма сильно, что потребовало использования сильно отличных друг от друга ядер (в дизайне компьютера есть еще много чего кроме процессора!). Тем не менее, некоторые части исходников ядра являются общими, потому часть общего кода ядра помещена в директорию m68k. Если вы просто собираете ядро, без изменения базовой архитектуры, вам не придется работать с каталогом m68k, вы будете работать исключительно с архитектурно-ориентированным каталогом, например mvme68k.
Сборка ядра осуществляется на основе конфигурационных файлов, которые находятся в каталоге /usr/src/sys/arch/<your platform>/conf. Сборка ядра производится с помощью программы config(8), и в итоге скомпилированное ядро будет находится в каталоге /usr/src/sys/arch/<your platform>/compile/<KernelName>. Пример для платформы i386:
# cd /usr/src/sys/arch/i386/conf
# config GENERIC
# cd ../compile/GENERIC
# make clean && make
[... jede Menge Ausgabe ...]
# make install
На данном этапе мы должны перезагрузить компьютер для использования нового ядра. Заметим, что новое ядро следует запустить перед следующим этапом, хотя, если речь идет об обновлении до очередного среза (snapshot-а), это не важно. Однако иногда изменения API приводят к тому, что старое ядро не может исполнять новые приложения, новое ядро будет запускать старые приложения.
Помните, что для компиляции ядра не понадобятся права root, но они понадобятся для того, чтобы его потом установить.
Заметим, что использование каталога /usr/obj обязательно. Невыполнение этого шага перед сборкой остальной части дерева, вероятно, приветет к тому, что src-дерево окажется сломаным.# rm -rf /usr/obj/* # cd /usr/src # make obj
# cd /usr/src/etc && env DESTDIR=/ make distrib-dirs
Это скомпилирует и установит утилиты окружения "userland" в требуемом порядке. Это требующий временных ресурсов этап - весьма быстрая машина выполнит эту операцию примерно за час, а на медленной машине может и несколько дней потребоваться. Как только этот этап завершится, вы будете иметь новые скомпилированные бинарные файлы в необходимых местах системы.# cd /usr/src # make build
Процесс сборки релиза использует созданные в /usr/obj бинарные файлы процессом, описанным ранее, так что вы должны сначала завершить предыдущие этапы, и в каталоге /usr/obj не должно ничего мешать. Ситуация, при которой может возникнуть проблема, возникает, если вы используете memory disk в качестве /usr/obj, что может в итоге привести к перезагрузке компьютера между шагами "build" и "release".
Процесс сборки релиза потребует два рабочих каталога, которые мы назовем DESTDIR и RELEASEDIR. Все файлы, которые являются частью "чистой (сlean)" OpenBSD устанавливаются в отведенное для них место в DESTDIR. Затем они будут упакованы с помощью tar(1) и помещены в RELEASEDIR. В завершении процесса RELEASEDIR должна будет содержать полный релиз OpenBSD. Процесс создания релиза также использует в работе /mnt, поэтому следует позаботиться о том, чтобы данной точкой монтирования процесс создания релиза мог воспользоваться без проблем. Для примера мы будем использовать DESTDIR - /usr/dest и RELEASEDIR - /usr/rel.
Для сборки релиза OpenBSD используются утилита crunchgen(8), она создает единый бинарный файл из большого количества отдельных программ. Имя этого исполняемого файла определяется запущенным компонентом.
Для создания релиза вам потребуются права root.
Очистим содержимое DESTDIR и создадим необходимые каталоги:# export DESTDIR=/usr/dest # export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}.old && rm -rf ${DESTDIR}.old &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
Начинаем сборку релиза:
После того, как релиз собран, хорошей идеей будет убедиться, что нужные нам файлы создались в DESTDIR. Их не так много на этом этапе.# cd /usr/src/etc # make release
Теперь вы имеете полный комплект созданных и проверенных файлов в RELEASEDIR. Эти файлы могут использоваться для установки или обновления OpenBSD на других машинах.# cd /usr/src/distrib/sets # sh checkflist
Официалоьные инструкции по созданию релиза находятся в release(8).
Замечание: если вы захотите использовать эти файлы для установки или обновлении через/используя HTTP, создайте файл "index.txt", который будет содержать список всех новых файлов, вошедьших в релиз.
Если вы полностью собрали релиз, вы можете использовать эти файлы для стандартной установки или обновления на другом компьютере, или, если хотите обновиться до -stable, просто распакуйте tar-архивы в корневом каталоге (на целевой машине).# /bin/ls -1 >index.txt
Для упрощения жизни пользователей OpenBSD была разработана система, получившая название Xenocara. Эта система "конвертирует" X обратно в одно общее большее дерево исходных кодов. В качестве дополнительного бонуса, этот процесс сборки гораздо больше похож на процесс сборки, используемый остальными компонентами OpenBSD. В предыдущих версиях это было не так.
Официальные инструкции по сборке X содержатся на вашем компьютере в файле /usr/xenocara/README и в release(8).
$ cd /usr $ cvs -qdanoncvs@anoncvs.example.org:/cvs checkout -P xenocara
Если вы захотите внести изменения в исходный код, вам потребуется несколько дополнительных пакетов. Подробности в файле /usr/xenocara/README.# cd /usr/xenocara # rm -rf /usr/xobj/* # make bootstrap # make obj # make build
В данном примере мы используем для DESTDIR и RELEASEDIR /usr/dest и /usr/rel соответственно . Это должно быть выполнено после процесса сборка, описанного ранее.
# export DESTDIR=/usr/dest
# export RELEASEDIR=/usr/rel
# test -d ${DESTDIR} && mv ${DESTDIR} ${DESTDIR}- && \
rm -rf ${DESTDIR}- &
# mkdir -p ${DESTDIR} ${RELEASEDIR}
# make release
Cкорее всего - не за чем.
Свое, нестандартное ядро - это ядро, собранное с файлом конфигурации, отличающимся от ОБЫЧНОГО GENERIC файла конфигурации. Оно может быть собрано на основе исходников всех деревьев -release, -stable или -current, так же как и GENERIC ядро. И в то время как компиляция GENERIC ядра поддерживается командой OpenBSD, компиляция нестандартного/вашего ядра - нет.
Стандартная конфигурация ядра OpenBSD (GENERIC) разработана так, что подходит практически всем. Среди людей пытавшихся настраивать ядро гораздо больше тех, кто в результате обрушил систему, чем тех кто смог улучшить её работу. Есть мнение, что что для оптимальной производительности ядра и системы в целом, необходима нестандартная настроенная сборка, но в случае с OpenBSD это мнение - не верно. Только самые опытные пользователи, обладающие обширными знаниями, для работы очень требовательных приложений должны беспокоиться о перенастройке ядра или системы.
Причины которые могут сподвигнуть на сборку собственного ядра:
Несколько причин не собирать свое ядро:
Удаление драйверов устройств ускоряет загрузку вашей системы, однако при ремонте аппаратной части осложнит вам жизнь, поэтому это скорее неправильное решение. Удоление драйверов не сделает вашу систему заметно быстрее, хотя вы и будете иметь меньшее по размеру ядро. Удаление функций отладки и мониторинга, конечно, увеличит быстродействие системы, однако сделает невозможной работу по устранению неполадок если что-то заработает не как положено.
К тому же, разработчики чаще всего игнорируют сообщения об ошибках на пользовательских ядрах, за исключением случаев когда проблема воспроизведена и на GENERIC ядре. Имейте ввиду.
Процес создания ядра OpenBSD по умолчанию управляется с помощью конфигурационных файлов в директории /usr/src/sys/arch/<arch>/conf/. Для всех архитектур имеется файл для генерации стандартного ядра GENERIC, который используется при создании стандартного ядра OpenBSD для данной платформы. Также там могут находиться другие конфигурационные файлы для создания специализированных ядер, к примеру, для систем с небольшим количеством памяти, бездисковых станций и так далее.
config(8) обрабатывает конфигурационный файл, создает и работает с катологом для компиляции ../compile, при стандарной установке это /usr/src/sys/arch/<arch>/compile/. config(8) также создает Makefile и другие файлы, необходимые для процесса сборки ядра.
Параметры конфигурации ядра (Kernel Configuration Options) позволяют вам управлять функциональностью ядра. Управление опциями позволит вам создать ядро с поддержкой только того аппаратного обеспечения, что вам необходимо, без поддержки ненужных вам устройств. Параметров для конфигурации ядра много. Здесь мы рассмотрим только некоторые, наиболее часто используемые. Ознакомтесь на странице руководства (man) options(4) с полным списком параметров. Поскольку эти параметры время от времени меняются, не лишним будет проверить соответствие для вашей версии OpenBSD. Также не помешает ознакомиться с примерами конфигурационных файлов для вашей архитектуры.
Не добавляйте, не удаляйте, не меняйте параметры вашего ядра без надобности! Не редактируйте стандартный конфигурационный файл GENERIC!!! Только ядра, построенные на базе стандартной конфигурации GENERIC, поддерживаются группой разработки OpenBSD; опции в /usr/src/sys/arch/<arch>/conf/GENERIC и /usr/src/sys/conf/GENERIC поставляются с опциями авторов OpenBSD (то есть, НЕИЗМЕНЕННЫМИ). Ответом на ваше письмо о проблемах с вашим ядром практически однозначно приведет к ответной просьбе воспроизвести вашу проблему на ядре GENERIC. Не все параметры совместимы друг с другом, некоторые сочетания параметров могут привести к неработоспособности системы. Нет никакой гарантии, что собранное вами с вашими параметрами вообще сможет запуститься. Не гарантируется, что все будет нормально после использования config(8).
С конфигурационными файлами для указанных платформ можно ознакомиться здесь:
Ознакомтесь с этими файлами. В начале каждого из них вы увидите:
include "../../../conf/GENERIC"
Это ссылка на конфигурационный платформеннонезависимый конфигурационный файл,
в нем - единые настройки для всех платформ. Созавая свою конфигурацию, на забудьте
заглянуть в
/sys/conf/GENERIC.
Параметры ядра помещаются в файл конфигурации ядра в виде:
option Nameили
К примеру, для включения опции "DEBUG" в ядре, добавьте следующее:option Name=Параметр
Опции конфигурации ядра OpenBSD транслируются в опции препроцессора компилятора, таким образом, что параметр типа DEBUG будет откомпилирован с опцией -DDEBUG, что эквивалентно добавлению #define DEBUG непосредственно в код ядра.option DEBUG
Возможно, вы захотите изменить параметр, стандартно находящийся в файле src/sys/conf/GENERIC. Можно, конечно, внести поправки и в копию этого файла, но куда лучше воспользоваться инструкцией rmoption. Для примера, если вы хотите отключить встроенный в ядро отладчик (не рекомендуется!), вы можете добавить строку:
rmoption DDB
Опция DDB в вашем стандартном конфигурационном файле
src/sys/conf/GENERIC включена, но строка rmoption
деактивирует её.
Пожалуйста, еще раз просмотрите options(4) для дополнительной информации об опциях. Обратите внимание, некоторые опции имеют свои страницы руководств - прочитайте все, что имеется, перед тем как что либо добавить или удалить из ядра.
Две строки относительно карты boca(4) мы копируем из GENERIC и раскомментируем их, редактируем по необходимости прерывания IRQ. Преимуществом использования "wrapper" является то, что мы вынесли все изменения из GENERIC, и GENERIC можно автоматически обновлять пор мере необходимости. Недостатком является невозможность удаления драйверов (что, конечно же, плохая идея).include "arch/i386/conf/GENERIC" boca0 at isa? port 0x100 irq 10 # BOCA 8-port serial cards com* at boca? slave ?
Еще один способ создания собственного конфигурационного файла ядра является копирование GENERIC в файл с другим именем и его редактирование по мере необходимости. Недостаток данного способа - неудобство автоматического обновления файла в будущем - нам потребуется руками переносить изменения из GENERIC в наш конфигурационный файл.
Полное описание создания собственного ядра есть в man-странице config(8).
Иногда вы можете столкнуться с ситуацией, когда ядро обнаруживапет устройство, но используемое прерывание IRQ неправильно. А вам изначально необходимо использование этого устройства. Ну что ж, OpenBSD позволяет воспользоваться конфигурацией на этапе загрузки, без перекомпиляции ядра. Воспользоваться этой возможностью в первый раз, когда это требуется, есть правильный подход к решению проблемы. После перезагрузки вам снова придется повторять эти действия. Так что это временное решение, и в дальнейшем стоит решить проблему используя config(8). Ваше ядро должно иметь опцию option BOOT_CONFIG, которую имеет GENERIC ядро.
Большую часть этого документа можно найти на странице руководства boot_config(8).
Для загрузки в User Kernel Config, или UKC, используйте опцию -c при загрузке.
Или другое ядро, которое надо загрузить. После этого появится приглашение UKC. Здесь вы сможете вводить команды, изменяющие поведение ядра. Например, вы можете работать с устройствами, включать и отключать их.boot> boot hd0a:/bsd -c
Вот список команд UKC.
Закончив конфигурирование, выполните quit или exit для продолжения загрузки. После этого следует сохранить постоянные изменения ядра, как это описывается в "Использование config(8) для изменения параметров ядра".
Опции -e и -u, используемые с config(8), могут хорошо сэкономить время, затрачиваемое на компиляцию ядра. Параметр -e позволяет войти в UKC (User Kernel Config) на исполняемой системе. Изменения вступят в силу после перезагрузки. Параметр -u проверяет, были ли внесены изменения в ядро во время загрузки, т.е. использовали ли вы параметр boot -c для входа в UKC во время загрузки системы.
В примере ниже показано как отключить ep*-устройства в ядре. Для избежания проблем лучше воспользоваться опцией -o для записи в указанный другой файл. К примеру: config -e -o bsd.new /bsd запишет изменения в bsd.new. В примере не используется параметр -o, поэтому изменения просто игнорируются, а не записывается в файл конфигурации ядра. Для дополнительной информации об ошибках обратитесь к странице руководства config(8).
$ sudo config -e /bsd
OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
warning: no output file specified
Enter 'help' for information
ukc> ?
help Command help list
add dev Add a device
base 8|10|16 Base on large numbers
change devno|dev Change device
disable attr val|devno|dev Disable device
enable attr val|devno|dev Enable device
find devno|dev Find device
list List configuration
lines count # of lines per page
show [attr [val]] Show attribute
exit Exit, without saving changes
quit Quit, saving current changes
timezone [mins [dst]] Show/change timezone
bufcachepercent [number] Show/change BUFCACHEPERCENT
nkmempg [number] Show/change NKMEMPAGES
ukc> list
0 video* at uvideo* flags 0x0
1 audio* at uaudio*|sb0|sb*|gus0|pas0|ess*|wss0|wss*|ym*|eap*|envy*|eso*|sv*|n
eo*|cmpci*|clcs*|clct*|auacer*|auglx*|auich*|auixp*|autri*|auvia*|azalia*|fms*|m
aestro*|esa*|yds*|emu* flags 0x0
2 midi* at umidi*|sb0|sb*|ym*|mpu*|mpu*|autri*|eap*|envy* flags 0x0
3 drm* at inteldrm*|radeondrm* flags 0x0
4 inteldrm* at vga0|vga* flags 0x0
5 radeondrm* at vga0|vga* flags 0x0
6 radio* at udsbr*|bktr0|fms* flags 0x0
7 vscsi0 at root flags 0x0
8 softraid0 at root flags 0x0
9 nsphy* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*|jm
e*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte*|v
r*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl*|r
l*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
10 nsphyter* at url*|udav*|mos*|axe*|aue*|xe*|ef*|hme*|lii*|bce*|ale*|alc*|age*
|jme*|et*|nfe*|stge*|vge*|bnx*|bge*|lge*|nge*|msk*|sk*|ste*|se*|sis*|wb*|tl*|vte
*|vr*|pcn*|sf*|ti*|gem*|ne0|ne1|ne2|ne*|ne*|ne*|epic*|sm0|sm*|dc*|dc*|re*|re*|rl
*|rl*|mtd*|fxp*|fxp*|xl*|xl*|ep0|ep*|ep*|ep*|ep*|ep* phy -1 flags 0x0
[...snip...]
ukc> disable ep
95 ep* disabled
96 ep* disabled
281 ep0 disabled
282 ep* disabled
283 ep* disabled
340 ep* disabled
ukc> quit
not forced
В вышеуказанном примере мы отключили все ep*-устройства в ядре; ядро не будет их искать. Иногда, когда вы используете UKC, при параметре boot -c вам потребуется сделать изменения постоянными, т.е. сохранить их. Для этого надо использовать опцию -u. В следующем примере компьютер загружается в UKC, и отключаются устройства wi(4). Поскольку изменения, сделанные при boot -c НЕ являются постоянными, их надо сохранить. В примере показывается, как в boot -c сохранить изменения при использовании нового ядра bsd.new.
$ sudo config -e -u -o bsd.new /bsd
OpenBSD 5.2 (GENERIC) #278: Wed Aug 1 10:04:16 MDT 2012
deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
Processing history...
161 wi* disabled
162 wi* disabled
417 wi* disabled
Enter 'help' for information
ukc> quit
UKC> verbose autoconf verbose enabled UKC> quit
Теперь вы сможете получить более подробный вывод при загрузке.
Чаще всего можно столкнуться со следующими:
Сборка OpenBSD и других программ из исходников гораздо сильнее нагружает аппаратную часть, чем большинство других задач. В результате этого, если имеются поблемы в работе оборудования, они скорее всего проявятся в процессе сборки. Signal 11 обычно возникает при аппаратных проблемах, чаще всего с памятью, реже при проблемах процессора, материнской платы или перегрева. Ваша система должна работать очень стабильно, иначе сборка окажется невозможной.
Вы, вероятно, предпочтете найти причину проблемы и заменить компоненты, ибо проблемы могут себя проявить и в будущем. Если у вас появились такие проблемы, а оборудование вы тем не менее хотите использовать, используйте snapshot или release.
Для получения дополнительной информации смотрите Sig11 FAQ.
# cd /usr/src
# find . -type l -name obj | xargs rm
# make cleandir
# rm -rf /usr/obj/*
# make obj
# umount /usr/obj
# newfs DeineObjPartition
# mount /usr/obj
чем это: rm -rf /usr/obj/*
Примечание: это может привести к поломке системы. Проект OpenBSD не поддерживает результаты этого действия, т.е. делаете это вы на свой страх и риск.
Snapshot'ы могут не выкладываться (или долго не меняться) непосредственно перед выходом -release.
В соответствии с политикой, программы из дерева OpenBSD автоматически не модифицируют /etc. Это означает, что всегда необходимые изменения должен сделать администратор. Обновление не является исключением. Для обновления файлов в этих каталогах сначала определите, какие изменения произошли в файлах дистрибутива (distribution), и затем внесите их вручную.
К примеру, посмотреть изменения можно так:
# cd /usr/src/etc
# ls -lt |more
Для просмотра изменений в /etc между выбранными версиями OpenBSD можно воспользоваться CVS. К примеру, просмотреть изменения между 5.1 и 5.2 можно так:
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_5_1 -rOPENBSD_5_2
Для сравнения 5.2 и -current ("HEAD"):
# cd /usr/src/etc
# cvs diff -u -rOPENBSD_5_2 -rHEAD
Скрипт
/dev/MAKEDEV не обновляется в процессе сборки, однако он устанавливается при
обновлении бинарных пакетов. Скопировать (если требуется)
и запустить скрипт перед обновлением будет хорошей идеей:
# cd /dev
# cp /usr/src/etc/etc.`machine`/MAKEDEV ./
# ./MAKEDEV all
Перед тем, как сделать изменения, сохраните на всякий случай резервные копии.
Обычно изменения /etc между релизами включают в себя:
Время от времени файлы и каталоги добавляются и удаляются из file hierarchy. Кроме того может измениться и информация о владельцах (ownership). Самый простой способ убедиться в актуальности - использовать утилиту mtree(8).
Сначала получите последний исходник, затем выполните:
# cd /usr/src/etc/mtree
# install -c -o root -g wheel -m 600 special /etc/mtree
# install -c -o root -g wheel -m 444 4.4BSD.dist /etc/mtree
# mtree -qdef /etc/mtree/4.4BSD.dist -p / -u
Ваш file hierarchy теперь актуален.
Когда разработчики начинают поддерживать новую систему, они сосредотачиваются на работе именно для этой системы/архитектуры/платформы. Сборка системы значительно нагружает и саму ОС, и машину, что само по себе является хорошим тестом работоспособности. По этой причине проект OpenBSD использует процесс создания платформ, называемый "native building", т.е. процесс сборки на той же платформе, для которой она собирается. Без такого процесса трудно быть уверенным, что система работает действительно стабильно, а не просто загружается.
[FAQ-Index] [Глава 4 - Установка OpenBSD 5.2] [Глава 6 - Сеть]
![[back]](../../images/back.gif){kind=small}
www@openbsd.org