Post navigation

Сборка «мира»

В первую очередь необходимо собрать обновления в пространстве пользователя (userland):

Команда прежде всего задействует исходный код, чтобы собрать инструменты, необходимые для сборки системного компилятора. После этого она инициирует сборку компилятора и сопутствующих библиотек. Наконец, с помощью новых инструментов, компилятора и библиотек будет собрано все базовое программное обеспечение FreeBSD. (Все это напоминает сборку автомобиля по инструкции, которая начинается так: «Спуститесь в шахту и накопайте железной руды».) Результаты работы помещаются в /usr/obj. Эта процедура может занять до нескольких часов, в зависимости от производительности аппаратного обеспечения. При этом можно продолжать работать и в ходе исполнения команды , если ваше аппаратное обеспечение функционирует достаточно устойчиво; потребляя системные ресурсы, эта команда не требует внимания.

Убедитесь, что команда выполнилась без ошибок! Если она завершилась с кучей сообщений вроде тех, что появляются при неудачном компилировании ядра, то процесс обновления следует остановить. В главе 2 рассказано, как получить помощь. Никогда не пытайтесь установить поврежденные или неполные обновления.

Сборка, установка и тестирование ядра

Лучший способ протестировать обновления — это собрать новое ядро GENERIC. Это позволит отгородиться от проблем, связанных с нестандартным ядром, и оценить возможные проблемы, касающиеся системы FreeBSD в целом. Самые активные из вас, безусловно, могут обновить свое ядро с нестандартной конфигурацией, но если что-то пойдет не так, нужно попробовать собрать ядро GENERIC. He забудьте сравнить конфигурацию своего ядра с конфигурацией ядра GENERIC, чтобы охватить все изменения в вашей нестандартной конфигурации.

По умолчанию в процессе обновления собирается ядро GENERIC. Если вам нужно обновить нестандартное ядро, определите имя ядра с помощью переменной . Задать значение этой переменной окружения можно из командной строки, в файле /etc/make.conf или в файле /etc/src.conf.

Собрать ядро можно одним из двух способов. Команда соберет новое ядро, но не установит его. В этом случае установку ядра можно выполнить следующей за командой . Команда выполнит обе эти команды подряд. Используйте способ, который больше соответствует вашим планам. Например, если мне нужно обновить систему во время воскресной профилактики, я могу выполнить команды и в течение предшествующей недели, чтобы сэкономить несколько часов моего драгоценного выходного дня. Однако до назначенного дня профилактических работ я не хочу устанавливать новое ядро — если в пятницу обнаружатся какие-либо проблемы и потребуется перезагрузка, желательно загрузить старое, рабочее ядро, а не новое. В воскресенье утром, когда я буду готов к выполнению обновления, я запущу команду . С другой стороны, при обновлении системы у себя на ноутбуке я предпочитаю запускать команду . Итак, чтобы обновить свое нестандартное ядро, я должен выполнить команду:

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

Установив новое ядро, выполните загрузку системы в однопользовательском режиме. Система должна перезапуститься без сбоев. Однако пользовательские программы могут работать не так, как ожидалось; многие из них зависят от интерфейсов, реализуемых ядром, которые могут измениться в результате обновления. Обычно об этом явно упоминается в файле /usr/src/UPDATING. Если с новым ядром система работает без сбоев, можно продолжать. В противном случае подробно опишите возникшую проблему и загрузите старое ядро, чтобы восстановить работу служб на то время, пока вы будете заниматься решением проблемы.

Формат конфигурационного файла

Ядро FreeBSD конфигурируется через текстовый файл. Для конфигурирования ядра отсутствуют какие-либо графические утилиты, управляемые системой меню, — процесс конфигурирования ядра не изменился со времен 4.4 BSD. Если вы чувствуете дискомфорт при работе с текстовыми конфигурационными файлами, тогда сборка нового ядра — не для вас.

Каждая конфигурационная запись располагается на отдельной строке. Каждая запись начинается с идентификационной метки, указывающей тип записи, за которой следует описание функции. Среди записей можно встретить множество комментариев, которые начинаются с символа решетки (#), как в следующей записи, соответствующей поддержке файловой системе FFS:

В каждом конфигурационном файле ядра присутствуют записи пяти типов: , , , и . Наличие или отсутствие этих записей определяет наличие поддержки аппаратных устройств или функциональных возможностей.

• Данная метка указывает, какие типы процессоров поддерживаются ядром. Конфигурационный файл ядра, предназначенного для устаревших персональных компьютеров, включал в себя несколько записей с указанием типа процессора, такие как 486 (I486_CPU), Pentium (I586_CPU) и для серии процессоров от Pentium Pro до современных Pentium 4 (I686_CPU). Конфигурация ядра для аппаратной платформы amd64/EM64T включает в себя единственную запись с указанием типа процессора. Конфигурация ядра может включать несколько типов процессоров при условии, что они принадлежат одной и той же архитектуре, — можно собрать ядро, которое будет работать и на процессорах 486, и на процессорах Pentium, но невозможно получить ядро, которое могло бы работать как на Intel-совместимых процессорах, так и на процессорах Sparc.
• Строка, начинающаяся с метки , содержит имя ядра. Именно таким образом ядро GENERIC получает свое имя. Это может быть любая произвольная строка.
• Данная строка содержит инструкции для программного обеспечения, выполняющего сборку ядра. Наиболее распространенный параметр — , который сообщает компилятору о необходимости включения в ядро отладочной информации. Отладочная информация помогает разработчикам в разрешении возникающих проблем.
• Записи этого типа описывают функции ядра, которые непосредственно не связаны с аппаратным обеспечением. Сюда входят файловые системы, сетевые протоколы и отладчики, встроенные в ядро.
• Записи этого типа описывают устройства или драйверы устройств, они содержат инструкции, которые описывают, как ядро должно взаимодействовать с определенными устройствами. Если вам необходимо, чтобы система осуществляла поддержку некоторого аппаратного обеспечения, ядро должно включать драйвер этого аппаратного устройства. Некоторые записи этого типа соответствуют так называемым псевдоустройствам, которые в действительности не являются аппаратными устройствами, а обеспечивают поддержку целых категорий аппаратных устройств, таких как сетевые карты, генераторы случайных чисел или электронные диски. Здесь вполне может появиться вопрос — чем псевдоустройства отличаются от записей типа . Дело в том, что псевдоустройства тем или иным способом отображаются в системе как устройства, тогда как функциональные возможности типа не имеют отличительных особенностей, присущих устройствам. Например, петлевое (loopback) псевдоустройство — это сетевой интерфейс, который позволяет подключаться только к локальному компьютеру. В данном случае отсутствует какое-либо аппаратное обеспечение, тем не менее программы могут подключаться через петлевой интерфейс и обмениваться данными с программами, исполняемыми на том же самом компьютере.

Оптимизация за счет многопоточной сборки

Для повышения скорости сборки опытные системные администраторы наверняка используют ключ утилиты make. Этот ключ позволяет запустить несколько процессов сборки и воспользоваться преимуществами многопроцессорной системы. Если в вашей системе несколько процессоров или в процессоре несколько ядер, ключ поможет ускорить сборку FreeBSD. Наиболее разумно — задать число процессов сборки, на единицу большее числа имеющихся процессоров. Например, если у вас четырехъядерный процессор, есть смысл использовать пять процессов сборки, введя команду .

Официально Проект FreeBSD не поддерживает выполнение обновлений с применением ключа , даже несмотря на то, что многие разработчики используют его. Если процесс сборки терпит неудачу при запуске с ключом , то прежде чем жаловаться, попробуйте запустить сборку без этого ключа.

[править] Установка конфигурационных файлов и скриптов

Итак очень важная часть, котору стоило бы вынести в отдельную статью.

# mergemaster

Пресловутые стереотипы

# mergemaster -m ${sourcepath} -A ${architecture} -D ${mountpoint}

При выполнении этой команды для новой системы создаются в основном скрипты и конфиги в папке ${mountpoint}/etc/. При обновлении будет выведено куча информации сравнения файлов скриптов и конфигурационных файлов. Здесь необходимо просмотреть каждое сообщение. Причина банальна. В файлах содержаться списки пользователей, настройки под конкретную систему. Кое-где придется вручную «сливать» два файла с просмотром каждой строки. От того как пройдет этот пункт будет зависеть будет ли следующая загрузка удачной.

[править] Сборка ядра

Осуществляется с помощью команды:

# make buildkernel

Расширенная версия:

# make -j4 buildkernel KERNCONF=GENERIC TARGET_ARCH=${architecture} \
TARGET=${architecture} __MAKE_CONF=${makeconf} SRCCONF=${srcconf} -C ${sourcepath}

где к описанным выше опциям добавилась опция

KERNCONF=GENERIC - GENERIC означает конфигурацию нового ядра.
Конфигурация лежит в /usr/src/sys/${architecture}/conf

Процедура установки

Внимание: алгоритм действий при сборке новой системы и обновлении существующей отличается

• Сборка мира
• Сборка ядра
• Установка мира
• Установка ядра
• Установка конфигурационных файлов

Алгоритм обновления

• Сборка мира
• Сборка ядра
• Установка ядра
• Перезагрузка
• Обновление части конфигурационных файлов

# cd /usr/src
# mergemaster -p

• Установка мира
• Обновление конфигурационных файлов

# mergemaster

Перезагрузка

Включение и исключение опций в GENERIC через дополнительный файл

Если необходимо оставить ядро GENERIC со всеми его опциями и в дополнение включить какие-либо модули (или исключить), то можно не редактировать GENERIC, а в дополнительном файле, например SMP-PAE-IPFW приинклудить опции GENERIC’а.

ident CORE-IPFW-DUMMYNET
include GENERIC

Подключать дополнительные модули и девайсы.

options SMP
device apic

Отключать модули и девайсы из GENERIC’а…

nooption SMP
nodevice apic

Такой подход хорош тем, что в зависимости от версии FreeBSD, файл GENERIC меняется (опции, девайсы) и в результате в разных версиях, даже при изменении опций GENERIC’а, такой подход будет работать.

Сохранение рабочего ядра

Из-за плохого ядра система может перестать загружаться, поэтому абсолютно необходимо всегда иметь под рукой хорошее ядро. В процессе установки нового ядра старое сохраняется на всякий случай в виде файла /boot/kernel.old. Это замечательно — иметь возможность вернуться к рабочему ядру в случае ошибки, но я рекомендую двинуться дальше.

Если хорошего надежного ядра нет, события могут развиваться так. При сборке нового ядра вы вдруг обнаруживаете, что допустили незначительную оплошность, и решаете устранить ее, еще раз пересобрав ядро. В этом случае заново собранное ядро становится текущим, а предыдущее (с изъяном) в свою очередь заменит старое, рабочее ядро, которое исчезнет. Когда обнаружится, что новое ядро содержит ту же самую или даже более серьезную ошибку, останется только сожалеть о том, что надежное ядро утеряно.

Обычное место для хранения хорошо зарекомендовавшего себя ядра — /boot/kernel.good. Перед настройкой ядра сохраните надежное работающее ядро:

# ср -Rp /boot/kernel /boot/kernel.good

Не бойтесь хранить несколько ядер. Дисковое пространство в наше время очень дешево. Некоторые администраторы даже размещают ядра в каталогах, названных по дате ядра. Благодаря этому они всегда могут вернуться к более ранней версии ядра. Кроме того, многие хранят копию ядра GENERIC в виде файла /boot/kernel.GENERIC для нужд тестирования и отладки. Ядер слишком много бывает лишь в том случае, если они совершенно заполнили корневой раздел.

Подготовка

Для сборки ядра необходим его исходный код. Если читатель последовал совету, данному в главе 2, то все уже готово. Если нет, надо вернуться в программу установки и загрузить исходный код ядра или перейти к главе 13 и использовать команду cvsup(8). Если неизвестно, инсталлирован ли исходный код ядра, поищите каталог /sys. Если он существует, и в нем имеются файлы и подкаталоги, значит, искомый код у вас есть.

Перед созданием нового ядра выясните, какие аппаратные средства присутствуют в системе. Порой это нелегко, поскольку торговая марка на компоненте необязательно имеет хоть какое-то отношение к возможностям и отличительным чертам устройства. Многие компании занимаются ребрэндингом универсальных компонентов — я помню одного производителя, который выпускал четыре разных типа сетевых карт с одним и тем же названием и не утруждал себя необходимостью указывать номер версии на первых трех из них. Единственный способ отличить их состоял в том, чтобы пробовать использовать разные драйверы устройств, пока не будет найден тот, который работает. Похожим образом многие компании производят сетевые карты, совместимые с NE2000. Даже если на коробке написано другое название, данное производителем, микросхемы чипа могут сообщать о себе как об устройствах NE2000. К счастью, некоторые производители используют стандартную архитектуру для своих устройств и драйверов. Так, вы всегда можете быть уверены, что сетевые карты компании Intel будут распознаваться драйверами устройств Intel.

Чтобы узнать, какие аппаратные средства обнаружила система FreeBSD, лучше всего обратиться к /var/run/dmesg.boot, о чем уже говорилось в главе 3. Каждая запись в этом файле представляет либо аппаратное устройство, либо программную особенность ядра. Приступая к сборке нового ядра, всегда держите под рукой файл dmesg.boot.

[править] Обновление и/или закачка дерева исходных кодов системы

Для начала все же советуем обновить до последней стабильной версии последнего стабильного релиза (на момент написания статьи 9.0 от января 2012). Для этого согласно официальной документации нам понадобится установленный пакет cvsup-whitout-gui. И внесенные изменения в файл /usr/share/examples/cvsup/stable-supfile. Заменить CHANGE_THIS.FreeBSD.org на cvsup2.ru.FreeBSD.org (опять же на момент написания статьи самый быстрый и доступный сервер для РФ). После этого выполнить команду:

# cvsup -g -L 2 /usr/share/examples/cvsup/stable-supfile

Далее ожидание выкачки дерева исходных кодов системы.

Просмотр списка загруженных модулей

В главе 3 было показано, как получить список загруженных модулей перед загрузкой, но этот метод не годится, после того как система загрузится. Получить список загруженных в настоящий момент модулей ядра можно с помощью команды kldstat(8).

# kldstat

На этом ноутбуке загружено три модуля ядра. Первый — это ядро (1), далее идут драйвер звуковой карты (2) и звуковая подсистема (3). (Это совершенно неудивительно, так как речь идет о ноутбуке.) Каждый модуль содержит один или более подмодулей, которые можно увидеть с помощью команды , но само ядро содержит несколько сотен подмодулей, поэтому будьте готовы получить очень длинный список.

Использование утилиты freebsd-update

Установить все обновления безопасности на сервер freebsd можно легко и быстро с помощью утилиты freebsd-update
. Итак, у нас имеется:

Запускаем freebsd-update
, проверяем наличие обновлений и скачиваем необходимые:

# freebsd-update fetch
Looking up update.FreeBSD.org mirrors… none found.
Fetching public key from update.FreeBSD.org… done.
Fetching metadata signature for 10.1-RELEASE from update.FreeBSD.org… done.
Fetching metadata index… done.
Fetching 2 metadata files… done.
Inspecting system… done.
Preparing to download files… done.
Fetching 19 patches…..10…. done.
Applying patches… done.
The following files will be updated as part of updating to 10.1-RELEASE-p1:

Устанавливаем обновления:

# freebsd-update install
Installing updates… done.

Если после этого мы снова проверим версию системы с помощью uname, то окажется, что ничего не изменилось. Будет показана та же версия. Что же произошло после этого обновления? Произошло бинарное обновление системы до актуальных значений. При этом, если у вас собрано и установлено свое ядро, отличное от GENERIC, то после перезагрузки у вас будет загружено ядро GENERIC. Про это обязательно нужно помнить. Я так долго разбирался, почему вдруг перестала работать команда forward в ipfw. Перепроверил все, что только мог, опустились руки. А все потому, что процесс обновления и перезагрузки сервера были сильно разделены по времени, а заметил я то, что не работает перенаправление еще позже, поэтому не сопоставил эти два события. О том, что у меня не то ядро загружено я и представить не мог. Я же знаю и помню, что ядро собирал и не трогал с тех пор. Вот такой нюанс, о котором нужно не забывать.

Чтобы отразить изменения в версии системы, пересоберем и установим ядро GENERIC. Исходные тексты системы, нужные для сборки, находятся в папке /usr/src. Если у вас там пусто, то их необходимо установить.

[править] Сборка мира

Перейти в каталог /usr/src, который служит контейнером файлов исходных кодов и выполнить

# make buildworld

Для некоторых ситуаций стоит особенно подчеркнуть что манипулируя опциями можно добиться мигрирования с архитектуры на архитектуру (например с i386 на AMD64)

# make -j4 buildworld TARGET_ARCH=${architecture} TARGET=${architecture} \
__MAKE_CONF=${makeconf} SRCCONF=${srcconf} -C ${sourcepath}

где:

-j4 - опция сборки в 4 потока, служит для ускорения.
Актуально на многопроцессорных и многоядерных системах и существенно сокращает время сборки
${architecture} - архитектура для сборки, по умолчанию та, на которой и происходит сборка (i386, AMD64)
${makeconf} - путь к специфичному файлу make.conf, по умолчанию /etc/make.conf
${srcconf} - путь к специфичному файлу src.conf, по умолчанию /etc/src.conf
${sourcepath} - путь к исходникам системы, по умолчанию /usr/src

3: Сборка и установка ядра

Создав пользовательские конфигурации ядра, нужно собрать и перекомпилировать его.

Вернитесь в каталог /usr/src и выполните команду make buildkernel, используя новый конфигурационный файл:

cd /usr/src
sudo make buildkernel KERNCONF=EXAMPLE

Это может занять некоторое время в зависимости от объёма ресурсов сервера (в среднем сервер в 1GB компилируется 90 минут).

После завершения перекомпиляции установите новое ядро:

sudo make installkernel KERNCONF=EXAMPLE

Затем перезапустите систему.

sudo shutdown -r now

После этого сервер отключит текущие сервисы, синхронизирует диски и обновит ядро.

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

sysctl kern.conftxt | grep ident

На экране должен появиться такой результат:

Настройка и перекомпиляция ядра выполнена успешно.

Сегодня мы научимся собирать ядро и мир (основные исполняемые файлы, библиотеки и тд) FreeBSD из сходных кодов. Ранее в заметке PostgreSQL: сборка из исходников и настройка под Linux мы выясняли, зачем нужно уметь собирать что-то из исходников. Основными сценариями являются оптимизация под конкретное железо и получение самого свежака прямо из ветки master. Кроме того, вы можете настроить ядро под свои конкретные нужды — выбрать шедулер, отключить IPv6, убрать поддержку лишнего железа и тд. Наконец, если вдруг вы планируете когла-нибудь стать коммитером в ядро FreeBSD, знания о том, как это ядро собирается, будут не лишними.

Подготовка окружения

При написании заметки я использовал следующий установочный диск:

FreeBSD-10.2-RELEASE-amd64-disc1.iso

Лишней железки под рукой у меня не было, поэтому все эксперименты ставились на VirtualBox. Был выбран VirtualBox, а не Vagrant , так как нам понадобится доступ к монитору системы. В VirtualBox в настройках сети было создана два адаптера — один NAT и один Host Only. Первый нужен для доступа гостевой системы в интернет. Второй позволит ходить в гостевую систему с хост-системы по SSH.

После установки системы ставим пакеты git-lite, vim-lite, tree, bash, sudo, правим /usr/local/etc/sudoers, затем меняем оболочку пользователя:

sudo
chsh
-s
/
usr/
local/
bin/
bash
eax

В ~/.gitconfig дописываем:

pager = less -S

Мне лично еще очень нравится иметь в системе привычный htop:

cd
/
usr/
postssudo
portsnap fetch extractcd
sysutils/
htop
sudo
make
-DBATCH
install
clean

Подробности про первоначальную настройку системы и управление пакетами во FreeBSD вы найдете в заметках Использование FreeBSD на десктопе, версия 2.0 и Управление пакетами во FreeBSD при помощи утилиты pkg соответственно.

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

То, как будет собираться ядро FreeBSD, контролируется несколькими файлами конфигурации.

Часть настроек лежит в /etc/make.conf. Этот файл влияет на сборку портов, мира, ядра FreeBSD, и вообще любых программ на C. Здесь можно указать CPU, под который производится сборка, флаги оптимизации, и так далее. Перечень всех доступных опций можно подглядеть в /usr/share/examples/etc/make.conf и man make.conf . Пример /etc/make.conf:

# используем Clang 3.7 вместо идущего по дэфолту 3.4
CC=/usr/local/bin/clang37
CXX=/usr/local/bin/clang++37
CPP=/usr/local/bin/clang-cpp37

# оптимизируем код под используемый на машине CPU
CPUTYPE?=native

# флаги при компиляции кода на C и C++
CFLAGS+=-O2 -pipe
CXXFLAGS+=-O2 -pipe

Еще есть /etc/src.conf, который имеет немного другие настройки и затрагивает только ядро и мир. Подробности смотри в man src.conf . Пример /etc/src.conf:

CPUTYPE?=native
CFLAGS+=-O2 -pipe
COPTFLAGS+=-O2 -pipe

Наконец, также существует и файл конфигурации самого ядра. Про него будет рассказано далее.

Если при установке FreeBSD вы поставили галочку «установить все исходники», то исходники ядра и мира будут находится в каталоге /usr/src. Информацию о том, что в каком подкаталоге находится, можно найти в Developer’s Handbook и файле README .

Автоматическая загрузка модулей ядра

Для автоматической загрузки модуля надо добавить его в файл /boot/loader.conf. Файл по умолчанию loader.conf содержит множество примеров загрузки модулей ядра, в которых используется один и тот же синтаксис. Нужно взять имя модуля ядра, убрать расширение файла .ko и добавить к нему строку . Например, чтобы автоматически загрузить модуль /boot/kernel/procfs.ko, в файл loader.conf нужно добавить такую строку:

Самое сложное во всем этом — узнать точное имя модуля, который требуется загрузить. Пользоваться драйверами устройств проще простого — если ядро не поддерживает новую сетевую карту или устройство SCSI, тогда вместо перенастройки ядра можно просто загрузить модуль драйвера. В этом случае нужно выяснить, какой драйвер поддерживает подключенное устройство, и здесь вам помогут страницы руководства и поисковая система Google. Везде в этой книге я буду упоминать модули ядра, которые помогут решать те или иные проблемы.

Впрочем, подождите минутку — зачем FreeBSD вынуждать загружать драйверы устройств, если она сама определяет их во время загрузки? Отличный вопрос! Дело в том, что вы можете собрать свое собственное ядро и удалить поддержку неиспользуемого устройства. Вы до сих пор не знаете, как собрать свое собственное ядро? Сейчас мы исправим этот недостаток.

[править] Установка ядра

Установка ядра в отличии от установки мира ничем примечательным не отличается. Разве что стоит отметить что старое ядро по умолчанию переместится в каталог /boot/kernel.old, а новое запишется на место старого по адресу /boot/kernel

# make installkernel

Не будем отходить от традиции

# make installkernel KERNCONF=GENERIC DESTDIR=${mountpoint} \
TARGET_ARCH=${architecture} TARGET=${architecture} \
__MAKE_CONF=${makeconf} SRCCONF=${srcconf} -C ${sourcepath}
где добавляем
${mountpoint} - путь для установки ядра относительно корня каталога в ${mountpoint}/boot/kernel

Загрузка и выгрузка модулей

Загрузка и выгрузка модулей ядра производится с помощью команд kldload(8) и kldunload(8). Например, обычно мой ноутбук подключается к сети посредством проводного соединения Ethernet. При беспроводном подключении мне необходимо загрузить модуль ядра wlan_wep.ko, который использует WEP-шифрование. Для этого я пользуюсь командой , которой передаю имя файла модуля ядра с требуемой функциональностью:

# kldload /boot/kernel/wlan_wep.ko

Как только беспроводное подключение станет ненужным, я выгружаю модуль.* Для этого требуется указывать не имя файла, а имя модуля, в том виде, как его отображает команда kldstat:

# kldunload wlan_wep.ko

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

Команды kldload(8) и kldunload(8) не требуют указания полного пути к модулю ядра, точно так же они не требуют указания расширения файла .ko. Если вы помните точное имя файла модуля ядра, можно использовать примерно такие команды:

# kldload wlan_wep
# kldunload wlan_wep

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

Шины и подключения

Каждое устройство в компьютере подключается к некоторому другому устройству. Если внимательно просмотреть файл dmesg.boot, можно увидеть целые цепочки устройств, подключенных друг к другу. Ниже приводится несколько сообщений из файла, в демонстрационных целях отредактированных:

Первое устройство в данной системе — это acpi0 (1). Скорее всего, вы не знаете, что это за устройство, но вы всегда можете воспользоваться командой , чтобы ликвидировать этот недостаток. (Или прочитать оставшуюся часть главы.) Следующее устройство в системе — acpi_ec (2), и оно подключено к устройству acpi0 (3). Микропроцессоры (4) также подключены к acpi0, как и мост PCI (5). Наконец, имеется первая шина PCI, pci0 (6), подключенная к мосту PCI (7), а не к acpi0. Обычно устройства PCI подключаются к иерархии шин PCI, которая в свою очередь подключается к мосту PCI, чтобы иметь возможность обмениваться данными с остальными компонентами компьютера. Можно было бы ознакомиться со всем содержимым файла dmesg.boot и нарисовать дерево подключения всех устройств в системе — хотя это и не является необходимым условием, тем не менее знание схемы включения устройств увеличивает вероятность успешной сборки нового ядра.

Если у вас что-то вызывает сомнения, воспользуйтесь утилитой pciconf(8), чтобы увидеть, что в действительности имеется в вашей системе. Команда перечислит все подключенные устройства PCI, имеющиеся в системе, независимо от того, были они обнаружены ядром или нет.

Удалённое тестирование собранного ядра

Бывает очень часто, что администратор собирает новое ядро удалённо, по сети. И в случае, если собранное ядро после перезагрузки не запустится (например, на главном маршрутизаторе), то кто-то может поседеть, а кто-то вдоволь наговориться с клиентами по телефону, с очередью звонков. К счастью, есть прекрасная утилита nextboot, с помощью которой можно указать с какого ядра грузиться при следующей перезагрузке единожды.

Для начала директорию собранного ядра переменуем в /boot/kernel.test, а в /boot/kernel запишем рабочее проверенное ядро (прошлое, из /boot/kernel.good).

# mv /boot/kernel /boot/kernel.test
# mkdir /boot/kernel
# cp /boot/kernel.good/* /boot/kernel/

После этого применим утилиту nextboot, указав откуда системе грузить ядро единожды при только следующей перезагрузке (путь к новому ядру указывается относительно директории /boot).

# nextboot -k kernel.test

Появится файл /boot/nextboot.conf, можно в него заглянуть и увидеть некоторые настройка. Проверим всё ещё раз и перезагружаем сервер.

# shutdown -r now

После перезагрузки логинимся на сервер и смотрим с каким ядром система запущена.

# uname -a
FreeBSD host.name.ru 8.2-RELEASE FreeBSD 8.2-RELEASE #0:
[email protected]:/usr/obj/usr/src/sys/CORE-IPFW-DUMMYNET  amd64

Что нам и требовалось. Перемещаем данное ядро в /boot/kernel и можно ещё раз перезагрузить сервер и проверить загружаемость нового ядра по-умолчанию.

# rm -r /boot/kernel
# mv /boot/kernel.test /boot/kernel
# shutdown -r now

freebsd/sborka_jadra_freebsd.txt · Последние изменения: 2014/12/02 04:33 (внешнее изменение)

Установка и обновление исходных текстов системы Freebsd

Для установки исходных текстов системы есть много способов. Я предлагаю воспользоваться, как мне кажется, самым простым — с помощью программы subversion
. Устанавливаем ее из портов:

# cd /usr/ports/devel/subversion
# make install clean
# rehash

И качаем исходники для версии 10.1:

# svn checkout https://svn0.ru.freebsd.org/base/release/10.1.0 /usr/src

Или для версии 10.2:

# svn checkout https://svn0.ru.freebsd.org/base/release/10.2.0 /usr/src

# svn checkout https://svn0.ru.freebsd.org/base/release/10.3.0 /usr/src

После того, как скачали исходники, снова запускаем обновление системы. Она найдет исправления, которые нужно внести в тексты:

# freebsd-update fetch
# freebsd-update install

После этого собираем и устанавливаем ядро GENERIC:

# cd /usr/src
# make buildkernel
# make installkernel
# shutdown -r now

Проверяем версию:

Все изменения вступили в силу и отображены.

Теперь для того, чтобы иметь всегда актуальную версию критических обновлений безопасности системы, создадим задание cron
на ежедневную проверку обновлений:

# echo «20 3 * * * root freebsd-update cron» >> /etc/crontab

По этому заданию каждый день в 3.20 будет проверяться наличие новых критических обновлений безопасности системы freebsd 10. В случае, если таковые найдутся, они будут закачаны и пользователю root отправлено оповещение. Устанавливать их необходимо вручную.