Глава 26. Обновление и смена версии FreeBSD

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

Содержание

26.1. Обзор

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

Прочитав эту главу, вы будете знать:

  • Как поддерживать систему FreeBSD в актуальном состоянии с помощью freebsd-update или Git.

  • Как сравнить состояние установленной системы с известной чистой копией.

  • Как поддерживать установленную документацию в актуальном состоянии с помощью Git или портов документации.

  • Разница между двумя ветвями разработки: FreeBSD-STABLE и FreeBSD-CURRENT.

  • Как пересобрать и переустановить всю базовую систему.

Прежде чем читать эту главу, вы должны:

В этой главе для получения и обновления исходных кодов FreeBSD используется git. При желании можно использовать порт или пакет devel/git.

26.2. Обновление FreeBSD

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

Этот инструмент поддерживает бинарные обновления безопасности и исправления ошибок в FreeBSD без необходимости ручной компиляции и установки патчей или нового ядра. Бинарные обновления доступны для всех архитектур и выпусков, которые в настоящее время поддерживаются командой безопасности. Список поддерживаемых выпусков и их предполагаемые даты окончания поддержки приведены на странице https://www.FreeBSD.org/security/.

Эта утилита также поддерживает обновления операционной системы со сменой младших версий, а также переход на другую ветку выпусков. Перед обновлением до нового выпуска ознакомьтесь с его анонсом, так как он содержит важную информацию, относящуюся к выпуску. Анонсы выпусков доступны по адресу https://www.FreeBSD.org/releases/.

Если существует crontab(5), использующий возможности freebsd-update(8), его необходимо отключить перед обновлением операционной системы.

В этом разделе описывается файл конфигурации, используемый freebsd-update, демонстрируется применение патча безопасности, обновление со сменой мледшей или старшей версии операционной системы, а также рассматриваются некоторые аспекты, которые следует учитывать при обновлении ОС.

26.2.1. Файл конфигурации

Файл конфигурации по умолчанию для freebsd-update работает без изменений. Некоторые пользователи могут захотеть настроить конфигурацию по умолчанию в /etc/freebsd-update.conf, чтобы лучше контролировать процесс. Комментарии в этом файле объясняют доступные опции, но следующие моменты могут потребовать дополнительного пояснения:

# Components of the base system which should be kept updated.
Components world kernel

Этот параметр определяет, какие части FreeBSD будут поддерживаться в актуальном состоянии. По умолчанию обновляется вся базовая система и ядро. Вместо этого можно указать отдельные компоненты, например src/base или src/sys. Однако лучшим вариантом будет оставить значение по умолчанию, так как изменение параметра для включения конкретных компонентов требует перечисления всех необходимых элементов. Со временем это может привести к катастрофическим последствиям, поскольку исходный код и исполняемые файлы могут перестать быть синхронизированными.

# Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths /boot/kernel/linker.hints

Чтобы оставить указанные каталоги, такие как /bin или /sbin, без изменений в процессе обновления, добавьте их пути в эту инструкцию. Эта опция может быть использована для предотвращения перезаписи локальных изменений с помощью freebsd-update.

# Paths which start with anything matching an entry in an UpdateIfUnmodified
# statement will only be updated if the contents of the file have not been
# modified by the user (unless changes are merged; see below).
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile

Эта опция будет обновлять только неизмененные конфигурационные файлы в указанных каталогах. Любые изменения, внесенные пользователем, предотвратят автоматическое обновление этих файлов. Существует другая опция, KeepModifiedMetadata, которая предписывает freebsd-update сохранять изменения во время слияния.

# When upgrading to a new FreeBSD release, files which match MergeChanges
# will have any local changes merged into the version from the new release.
MergeChanges /etc/ /var/named/etc/ /boot/device.hints

Список каталогов с файлами конфигурации, которые freebsd-update должен попытаться объединить. Процесс объединения файлов представляет собой серию патчей diff(1). Объединения могут быть приняты, открыты в редакторе или привести к прерыванию работы freebsd-update. В случае сомнений создайте резервную копию /etc и просто примите объединения.

# Directory in which to store downloaded updates and temporary
# files used by FreeBSD Update.
# WorkDir /var/db/freebsd-update

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

# When upgrading between releases, should the list of Components be
# read strictly (StrictComponents yes) or merely as a list of components
# which *might* be installed of which FreeBSD Update should figure out
# which actually are installed and upgrade those (StrictComponents no)?
# StrictComponents no

Когда эта опция установлена в yes, freebsd-update будет считать список Components полным и не будет пытаться вносить изменения за его пределами. Фактически, freebsd-update попытается обновить каждый файл, принадлежащий списку Components.

Обратитесь к freebsd-update.conf(5) для получения дополнительной информации.

26.2.2. Применение обновлений безопасности

Процесс применения патчей безопасности FreeBSD был упрощен, что позволяет администратору поддерживать систему в полностью обновленном состоянии с помощью freebsd-update. Дополнительная информация о выпусках безопасности FreeBSD доступна в Рекомендации по безопасности FreeBSD.

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

# freebsd-update fetch
# freebsd-update install

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

Обычно пользователь должен быть готов перезагрузить систему. Чтобы проверить, требуется ли перезагрузка из-за обновления ядра, выполните команды freebsd-version -k и uname -r. Перезагрузите систему, если их вывод различается.

Систему можно настроить для автоматической проверки обновлений раз в день, добавив следующую запись в /etc/crontab:

@daily                                  root    freebsd-update cron

Если существуют патчи, они будут автоматически загружены, но не применены. Пользователь root получит письмо, чтобы патчи можно было просмотреть и установить вручную с помощью freebsd-update install.

Если что-то пойдет не так, freebsd-update может откатить последние изменения с помощью следующей команды:

# freebsd-update rollback
Uninstalling updates... done.

Вновь, система должна быть перезапущена, если ядро или какие-либо модули ядра были изменены, и все затронутые бинарные файлы должны быть перезапущены.

Только ядро GENERIC может быть автоматически обновлено с помощью freebsd-update. Если установлено пользовательское ядро, его необходимо пересобрать и переустановить после завершения установки обновлений freebsd-update. Имя ядра по умолчанию — GENERIC. Для проверки его установки можно использовать команду uname(1).

Всегда сохраняйте копию ядра GENERIC в /boot/GENERIC. Оно может быть полезно при диагностике различных проблем и при обновлении версий. Инструкции по получению копии ядра GENERIC можно найти в Custom Kernels with FreeBSD 9.X and Later.

Если конфигурация по умолчанию в /etc/freebsd-update.conf не была изменена, freebsd-update установит обновленные исходные коды ядра вместе с остальными обновлениями. Затем пересборка и переустановка нового пользовательского ядра могут быть выполнены обычным способом.

Обновления, распространяемые через freebsd-update, не всегда затрагивают ядро. Нет необходимости пересобирать собственное ядро, если исходные коды ядра не были изменены командой freebsd-update install. Однако freebsd-update всегда обновляет файл /usr/src/sys/conf/newvers.sh. Текущий уровень патча, обозначаемый числом после -p в выводе uname -r, берётся из этого файла. Пересборка собственного ядра, даже если ничего больше не менялось, позволяет uname точно отображать текущий уровень патча системы. Это особенно полезно при обслуживании нескольких систем, так как позволяет быстро оценить установленные обновления на каждой из них.

26.2.3. Выполнение обновлений с изменением младших и старших версий

Обновления с изменением младшей версии FreeBSD называются минорными обновлениями. Пример:

  • FreeBSD 13.1 до 13.2.

Мажорные обновления увеличивают номер старшей версии. Пример:

  • FreeBSD 13.2 до 14.0.

Оба типа обновления могут быть выполнены путем указания freebsd-update целевой версии выпуска.

После каждого нового выпуска RELEASE серверы сборки пакетов FreeBSD в течение ограниченного периода времени не используют новую версию операционной системы. Это обеспечивает преемственность для многих пользователей, которые не обновляются сразу после объявления о выпуске. Например:

  • Пакеты для пользователей версий 13.1 и 13.2 будут собираться на сервере под управлением 13.1, пока поддержка 13.1 не прекратится

 — и, что критически важно:

  • модуль ядра, собранный в версии 13.1, может не подойти для версии 13.2.

Итак, при любом обновлении ОС, будь то обновление младшей или старшей версии, если ваш пакет требует включить какой-либо модуль ядра:

  • be prepared to build the module from source.

Если система работает на собственном ядре, убедитесь перед началом обновления, что копия ядра GENERIC осталась в /boot/GENERIC. Обратитесь к Собственные ядра системы в FreeBSD 9.X и более поздних версиях для получения инструкций о том, как получить копию ядра GENERIC.

Перед обновлением до новой версии убедитесь, что текущая установка FreeBSD обновлена с учетом исправлений безопасности и ошибок:

# freebsd-update fetch
# freebsd-update install

Следующая команда, выполненная на системе FreeBSD 13.1, обновит её до версии FreeBSD 13.2:

# freebsd-update -r 13.2-RELEASE upgrade

После получения команды freebsd-update оценит файл конфигурации и текущую систему, чтобы собрать информацию, необходимую для выполнения обновления. На экране появится список компонентов, которые были и не были обнаружены. Например:

Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 13.1-RELEASE from update1.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games
src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
world/base world/info world/lib32 world/manpages

The following components of FreeBSD do not seem to be installed:
kernel/generic world/catpages world/dict world/doc world/games
world/proflibs

Does this look reasonable (y/n)? y

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

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

WARNING: This system is running a "MYKERNEL" kernel, which is not a
kernel configuration distributed as part of FreeBSD 13.1-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"

Это предупреждение можно безопасно проигнорировать на данном этапе. Обновлённое ядро GENERIC будет использовано как промежуточный шаг в процессе обновления.

После загрузки всех патчей в локальную систему они будут применены. Этот процесс может занять некоторое время в зависимости от скорости и загруженности машины. Затем будут объединены конфигурационные файлы. Процесс объединения требует вмешательства пользователя, так как файл может быть объединен автоматически или на экране появится редактор для ручного объединения. Результаты каждого успешного объединения будут отображаться пользователю по мере выполнения процесса. Неудачное или пропущенное объединение приведет к прерыванию процесса. Пользователям рекомендуется создать резервную копию /etc и вручную объединить важные файлы, такие как master.passwd или group, позже.

Система пока не изменяется, так как все исправления и слияния происходят в другом каталоге. Как только все исправления будут успешно применены, все конфигурационные файлы объединены и процесс, по всей видимости, пройдёт без проблем, пользователь может записать изменения на диск с помощью следующей команды:

# freebsd-update install

Ядро и модули ядра будут пропатчены первыми. Если система работает с пользовательским ядром, используйте nextboot(8), чтобы установить ядро для следующей загрузки в обновлённый /boot/GENERIC:

# nextboot -k GENERIC

Перед перезагрузкой с ядром GENERIC убедитесь, что оно содержит все драйверы, необходимые для корректной загрузки системы и подключения к сети, если обновляемая машина доступна удалённо. В частности, если текущее кастомное ядро включает встроенную функциональность, обычно предоставляемую модулями ядра, убедитесь, что временно загрузили эти модули в ядро GENERIC с помощью механизма /boot/loader.conf. Также рекомендуется отключить несущественные сервисы, а также любые монтирования дисков и сетевые подключения до завершения процесса обновления.

Машину теперь следует перезагрузить с обновлённым ядром:

# shutdown -r now

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

# freebsd-update install

В зависимости от того, были ли изменены номера версий библиотек, может быть только две фазы установки вместо трёх.

Обновление завершено. Если было выполнено обновление старшей версии, переустановите все порты и пакеты, как описано в Обновление пакетов после обновления старшей версии.

26.2.3.1. Собственные ядра в FreeBSD 9.X и более поздних версиях

Перед использованием freebsd-update убедитесь, что копия ядра GENERIC осталось в /boot/GENERIC. Если собственное ядро собиралось только один раз, ядро в /boot/kernel.old является ядром GENERIC. Просто переименуйте этот каталог в /boot/GENERIC.

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

# mount /cdrom
# cd /cdrom/usr/freebsd-dist
# tar -C/ -xvf kernel.txz boot/kernel/kernel

Или ядро GENERIC может быть пересобрано и установлено из исходного кода:

# cd /usr/src
# make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null

Чтобы ядро было идентифицировано как GENERIC с помощью freebsd-update, конфигурационный файл GENERIC не должен быть каким-либо образом изменён. Также рекомендуется собирать ядро без каких-то дополнительных специальных опций.

Перезагрузка с ядром GENERIC не требуется, так как freebsd-update нужен только файл /boot/GENERIC.

26.2.3.2. Обновление пакетов после обновления старшей версии

Обычно установленные приложения продолжают работать без проблем после обновления младших версий. Старшие версии используют разные бинарные интерфейсы приложений (ABI), что приведёт к неработоспособности большинства сторонних приложений. После обновления старшей версии необходимо обновить все установленные пакеты и порты. Пакеты можно обновить с помощью pkg upgrade. Для обновления установленных портов используйте утилиты, например ports-mgmt/portmaster.

Принудительное обновление всех установленных пакетов заменит пакеты на новые версии из репозитория, даже если номер версии не увеличился. Это необходимо из-за изменения версии ABI при обновлении между старшими версиями FreeBSD. Принудительное обновление можно выполнить с помощью команды:

# pkg-static upgrade -f

Перестройка всех приложений, установленных из коллекции портов, может быть выполнена с помощью следующей команды:

# portmaster -af

Эта команда отобразит экраны конфигурации для каждого приложения, имеющего настраиваемые параметры, и будет ожидать взаимодействия пользователя с этими экранами. Чтобы предотвратить такое поведение и использовать только параметры по умолчанию, добавьте -G в указанную выше команду.

После завершения обновления программного обеспечения завершите процесс обновления, выполнив последний вызов freebsd-update, чтобы устранить все нерешенные вопросы, оставшиеся в процессе обновления:

# freebsd-update install

Если временно использовалось ядро GENERIC, сейчас самое время собрать и установить новое пользовательское ядро, следуя инструкциям из раздела Настройка ядра FreeBSD.

Перезагрузите машину с новой версией FreeBSD. Процесс обновления завершен.

26.2.4. Сравнение состояния системы

Состояние установленной версии FreeBSD можно проверить с помощью freebsd-update IDS, сравнив его с известной исправной копией. Эта команда оценивает текущие версии системных утилит, библиотек и конфигурационных файлов и может использоваться как встроенная система обнаружения вторжений (IDS — Intrusion Detection System).

Эта команда не является заменой настоящей системы обнаружения вторжений, такой как security/snort. Поскольку freebsd-update хранит данные на диске, возможность их подделки очевидна. Хотя эту возможность можно уменьшить, используя kern.securelevel и сохраняя данные freebsd-update на файловой системе только для чтения, когда они не используются, лучшее решение — сравнить систему с защищённым диском, таким как DVD или надёжно хранимое внешнее USB-устройство. Альтернативный метод обеспечения функциональности системы обнаружения вторжений с использованием встроенной утилиты описан в Проверка двоичных файлов

Для начала сравнения укажите выходной файл для сохранения результатов:

# freebsd-update IDS >> outfile.ids

Система будет проверена, и в указанный выходной файл будет отправлен длинный список файлов вместе с хеш-значениями SHA256, как для известного значения в релизе, так и для текущей установки.

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

# cat outfile.ids | awk '{ print $1 }' | more
/etc/master.passwd
/etc/motd
/etc/passwd
/etc/pf.conf

Этот пример вывода был сокращён, так как существует гораздо больше файлов. Некоторые файлы имеют естественные изменения. Например, /etc/passwd будет изменён, если в систему были добавлены пользователи. Модули ядра могут отличаться, так как freebsd-update мог их обновить. Чтобы исключить определённые файлы или каталоги, добавьте их в параметр IDSIgnorePaths в файле /etc/freebsd-update.conf.

26.3. Обновление загрузочного кода

Следующие руководства описывают процесс обновления загрузочного кода и загрузчиков: gpart(8), gptboot(8), gptzfsboot(8) и loader.efi(8).

26.4. Обновление документации

Документация является неотъемлемой частью операционной системы FreeBSD. Хотя актуальная версия документации FreeBSD всегда доступна на сайте FreeBSD (Портал документации), может быть удобно иметь актуальную локальную копию веб-сайта FreeBSD, руководств, FAQ и статей.

Этот раздел описывает, как использовать исходный код или коллекцию портов FreeBSD для поддержания локальной копии документации FreeBSD в актуальном состоянии.

Для получения информации о редактировании и отправке исправлений в документацию обратитесь к руководству "Проект документации FreeBSD: введение для новых участников" (Проект документации FreeBSD: введение для новых участников).

26.4.1. Обновление документации из исходных текстов

Пересборка документации FreeBSD из исходных текстов требует набора инструментов, которые не входят в базовую систему FreeBSD. Необходимые инструменты можно установить, следуя этим шагам из вводного руководства Проекта документации FreeBSD.

После установки используйте git, чтобы получить чистую копию исходного кода документации:

# git clone https://git.FreeBSD.org/doc.git /usr/doc

Первоначальная загрузка исходного кода документации может занять некоторое время. Дождитесь завершения процесса.

Будущие обновления исходного кода документации можно получить, выполнив:

# git pull

После того как актуальный снимок исходников документации будет загружен в /usr/doc, всё готово для обновления установленной документации.

Полное обновление можно выполнить, набрав:

# cd /usr/doc
# make

26.5. Отслеживание ветки разработки

FreeBSD имеет две ветви разработки: FreeBSD-CURRENT и FreeBSD-STABLE.

Этот раздел содержит объяснение каждой ветки и её целевой аудитории, а также инструкции по поддержанию системы в актуальном состоянии для каждой из веток.

26.5.1. Использование FreeBSD-CURRENT

FreeBSD-CURRENT — это "передовой край" разработки FreeBSD, и от пользователей FreeBSD-CURRENT ожидается высокий уровень технической подготовки. Менее опытным пользователям, которые хотят следить за веткой разработки, рекомендуется использовать FreeBSD-STABLE.

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

FreeBSD-CURRENT доступен для трёх основных групп пользователей:

  1. Участники сообщества FreeBSD, которые активно работают над какой-либо частью дерева исходного кода.

  2. Участники сообщества FreeBSD, которые активно тестируют. Они готовы тратить время на решение проблем, высказывать тематические предложения по изменениям и общему направлению развития FreeBSD, а также предоставлять патчи.

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

Версия FreeBSD-CURRENT не должна рассматриваться как быстрый способ получить новые функции до следующего релиза, так как предрелизные функции ещё не полностью протестированы и, скорее всего, содержат ошибки. Это не быстрый способ исправления багов, так как каждый коммит с такой же вероятностью может добавить новые ошибки, как и исправить существующие. FreeBSD-CURRENT ни в коем случае не является "официально поддерживаемой".

Для отслеживания FreeBSD-CURRENT:

  1. Присоединитесь к спискам рассылки Список рассылки, посвящённый обсуждению FreeBSD-CURRENT и {dev-commits-src-main}. Это важно для того, чтобы видеть комментарии пользователей о текущем состоянии системы и получать важные уведомления о состоянии FreeBSD-CURRENT.

    Список {dev-commits-src-main} фиксирует запись журнала изменений для каждого внесённого изменения, а также любую сопутствующую информацию о возможных побочных эффектах.

    Чтобы присоединиться к этим спискам, перейдите на Сервер списков рассылки FreeBSD, выберите список, к которому хотите подписаться, и следуйте инструкциям. Для отслеживания изменений во всём дереве исходного кода, а не только в FreeBSD-CURRENT, подпишитесь на {dev-commits-src-all}.

  2. Синхронизация с исходным кодом FreeBSD-CURRENT. Обычно для получения кода -CURRENT из ветки main репозитория FreeBSD Git используется git (подробности см. в “Использование Git”).

  3. Из-за размера репозитория некоторые пользователи предпочитают синхронизировать только те разделы исходного кода, которые их интересуют или для которых они готовят патчи. Однако пользователи, планирующие собирать операционную систему из исходных кодов, должны загрузить весь FreeBSD-CURRENT, а не только отдельные его части.

    Перед компиляцией FreeBSD-CURRENT внимательно прочитайте /usr/src/Makefile и следуйте инструкциям в Обновление FreeBSD из исходного кода. Ознакомьтесь с Список рассылки, посвящённый обсуждению FreeBSD-CURRENT и /usr/src/UPDATING, чтобы быть в курсе других процедур начальной загрузки, которые иногда становятся необходимыми на пути к следующему выпуску.

  4. Будьте активными! Пользователям FreeBSD-CURRENT рекомендуется предлагать свои идеи по улучшению или исправлению ошибок. Предложения с приложенным кодом всегда приветствуются.

26.5.2. Использование FreeBSD-STABLE

FreeBSD-STABLE - это ветка разработки, из которой создаются основные выпуски. Изменения попадают в эту ветку медленнее и с общим предположением, что они сначала были протестированы в FreeBSD-CURRENT. Это всё ещё ветка разработки, и в любой момент исходный код FreeBSD-STABLE может быть или не быть пригодным для общего использования. Это просто ещё один инженерный трек разработки, а не ресурс для конечных пользователей. Пользователям, у которых нет ресурсов для тестирования, следует использовать последний выпуск FreeBSD.

Те, кто заинтересован в отслеживании или участии в процессе разработки FreeBSD, особенно в контексте следующего выпуска FreeBSD, могут рассмотреть возможность подписки на FreeBSD-STABLE.

Хотя ветка FreeBSD-STABLE должна компилироваться и работать в любое время, это не может быть гарантировано. Поскольку больше людей используют FreeBSD-STABLE, чем FreeBSD-CURRENT, неизбежно, что иногда в FreeBSD-STABLE будут обнаружены ошибки и крайние случаи, которые не были очевидны в FreeBSD-CURRENT. По этой причине не следует слепо следовать за FreeBSD-STABLE. Особенно важно не обновлять какие-либо производственные серверы до FreeBSD-STABLE без тщательного тестирования кода в среде разработки или тестирования.

Для отслеживания FreeBSD-STABLE:

  1. Присоединяйтесь к рассылке Список рассылки, посвящённый обсуждению FreeBSD-STABLE;, чтобы быть в курсе зависимостей сборки, которые могут появиться в FreeBSD-STABLE, или других вопросов, требующих особого внимания. Разработчики также будут объявлять в этой рассылке о рассмотрении спорных исправлений или обновлений, давая пользователям возможность высказаться, если у них есть замечания по предлагаемым изменениям.

    Присоединяйтесь к соответствующему списку рассылки git для отслеживаемой ветки. Например, пользователи, отслеживающие ветку 14-STABLE, должны подписаться на {dev-commits-src-branches}. Этот список рассылает сообщения с комментарием коммита для каждого внесённого изменения, как только оно сделано, а также любую соответствующую информацию о возможных побочных эффектах.

    Чтобы присоединиться к этим спискам, перейдите на Сервер списков рассылки FreeBSD, выберите список для подписки и следуйте инструкциям. Для отслеживания изменений во всём дереве исходного кода подпишитесь на {dev-commits-src-all}.

  2. Для установки новой системы FreeBSD-STABLE установите последний выпуск FreeBSD-STABLE с сайтов зеркал FreeBSD или используйте ежемесячный снимок, собранный из FreeBSD-STABLE. Дополнительную информацию о снимках можно найти на www.freebsd.org/snapshots.

    Для компиляции или обновления существующей системы FreeBSD до FreeBSD-STABLE используйте git для получения исходного кода нужной ветки. Имена веток, например stable/13, перечислены на сайте www.freebsd.org/releng.

  3. Перед компиляцией или обновлением до FreeBSD-STABLE внимательно прочитайте файл /usr/src/Makefile и следуйте инструкциям в Обновление FreeBSD из исходного кода. Ознакомьтесь с Список рассылки, посвящённый обсуждению FreeBSD-STABLE; и файлом /usr/src/UPDATING, чтобы быть в курсе других процедур начальной загрузки, которые иногда становятся необходимыми на пути к следующему выпуску.

26.5.3. N-номер

При поиске ошибок важно знать, какие версии исходного кода использовались для создания системы, в которой обнаружена проблема. FreeBSD предоставляет информацию о версии, встроенную в ядро. uname(1) извлекает эту информацию, например:

% uname -v
FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021     fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED

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

main-n247514-031260d64c18

main		(1)
n247514		(2)
031260d64c18	(3)
		(4)
1Имя ветки Git. Примечание: сравнения n-номеров действительны только для веток, опубликованных проектом (main, stable/XX и releng/XX). Локальные ветки будут иметь n-номера, которые могут пересекаться с коммитами их родительской ветки.
2n-номер — это линейный счетчик коммитов от начала репозитория Git, начиная с хэша Git, указанного в строке.
3Хэш Git дерева исходного кода
4Иногда добавляется суффикс -dirty, если ядро было собрано в дереве с незафиксированными изменениями. В данном примере он отсутствует, так как ядро FRED было собрано из чистой копии репозитория.

Команда git rev-list используется для нахождения n-номера, соответствующего хэшу Git. Например:

% git rev-list --first-parent --count 031260d64c18 (1)
247514 (2)
1Хеш git для перевода (используется тот же хеш из приведённого выше примера)
2n-номер.

Обычно этот номер не так важен. Однако, когда фиксы ошибок попадают в репозиторий, это число позволяет быстро определить, присутствует ли исправление в текущей работающей системе. Разработчики часто ссылаются на хэш коммита (или предоставляют URL, содержащий этот хэш), но не указывают n-номер, так как хэш является легко видимым идентификатором изменения, в отличие от n-номера. В уведомлениях о безопасности и бюллетенях исправлений также указывается n-номер, который можно напрямую сравнить с вашей системой. Если вы используете неполные (shallow) клоны Git, вы не сможете надежно сравнивать n-номера, так как команда git rev-list подсчитывает все ревизии в репозитории, которые неполный клон пропускает.

26.6. Обновление FreeBSD из исходного кода

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

26.6.1. Быстрый старт

Это краткая справка по типовым шагам, используемым для обновления FreeBSD путем сборки из исходного кода. Более подробное описание процесса приведено в следующих разделах.

При переходе с mergemaster(8) на etcupdate(8) первый запуск может некорректно объединить изменения, создавая ложные конфликты. Чтобы избежать этого, выполните следующие действия перед обновлением исходных кодов и сборкой нового мира:

# etcupdate extract (1)
# etcupdate diff (2)
1Загрузите базы данных стандартных файлов /etc; дополнительную информацию смотрите в etcupdate(8).
2Проверьте изменения после начальной настройки. Удалите все локальные изменения, которые больше не нужны, чтобы уменьшить вероятность конфликтов при будущих обновлениях.

  • Обновление и сборка

    # git -C /usr/src pull (1)
check /usr/src/UPDATING  (2)
# cd /usr/src          (3)
# make -j4 buildworld  (4)
# make -j4 kernel      (5)
# shutdown -r now      (6)
# etcupdate -p         (7)
# cd /usr/src          (8)
# make installworld    (9)
# etcupdate -B         (10)
# shutdown -r now      (11)
1Получите последнюю версию исходного кода. Подробнее о получении и обновлении исходного кода см. в Обновление исходного кода.
2Проверьте /usr/src/UPDATING на наличие необходимых действий перед или после сборки из исходного кода.
3Перейдите в исходный каталог.
4Соберите систему (world), всё кроме ядра системы.
5Скомпилируйте и установите ядро системы. Это эквивалентно make buildkernel installkernel.
6Перезагрузите систему с новым ядром.
7Обновите и объедините конфигурационные файлы в /etc/, это обязательно перед выполнением installworld.
8Перейдите в исходный каталог.
9Установить систему (world).
10Обновите и объедините конфигурационные файлы в /etc/.
11Перезагрузите систему для использования новой собранной системы (world) и ядра.

26.6.2. Подготовка к обновлению исходного кода

Прочитайте файл /usr/src/UPDATING. В этом файле описаны все необходимые действия, которые нужно выполнить до или после обновления.

26.6.3. Обновление исходного кода

Исходный код FreeBSD находится в /usr/src/. Предпочтительный метод обновления этого исходного кода — через систему управления версиями Git. Проверьте, что исходный код находится под управлением версий:

# cd /usr/src
# git remote --v
origin  https://git.freebsd.org/src.git (fetch)
origin  https://git.freebsd.org/src.git (push)

Это указывает, что /usr/src/ находится под управлением версий и может быть обновлён с помощью git(1):

# git -C /usr/src pull

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

Получение исходного кода:

Если вывод содержит fatal: not a git repository, значит, файлы отсутствуют или были установлены другим способом. Необходимо выполнить новое получение исходного кода.

Таблица 1. Версии FreeBSD и ветви репозиториев
uname ‑r OutputПуть репозиторияОписание

X.Y-RELEASE

releng/X.Y

Версия Release с добавлением только критических исправлений безопасности и ошибок. Эта ветка рекомендуется для большинства пользователей.

X.Y-STABLE

stable/X

Версия Release и все дополнительные разработки в этой ветке. STABLE означает, что двоичный интерфейс приложений (ABI) не изменяется, поэтому программное обеспечение, скомпилированное для более ранних версий, продолжает работать. Например, программное обеспечение, скомпилированное для работы на FreeBSD 10.1, будет работать и на FreeBSD 10-STABLE, собранной позже.

Ветки STABLE иногда содержат ошибки или несовместимости, которые могут повлиять на пользователей, хотя они обычно быстро исправляются.

X-CURRENT

main

Последняя невыпущенная разрабатываемая версия FreeBSD. Ветка CURRENT может содержать серьёзные ошибки или проблемы совместимости и рекомендуется только для опытных пользователей.

Определите версию FreeBSD с помощью uname(1):

# uname -r
13.2-RELEASE

На основе Версии FreeBSD и ветви репозиториев, исходный код для обновления 13.2-RELEASE имеет путь в репозитории releng/13.2. Этот путь используется при проверке исходного кода:

# mv /usr/src /usr/src.bak (1)
# git clone --branch releng/13.2 https://git.FreeBSD.org/src.git /usr/src (2)
1Переместите старую директорию в другое место. Если в этой директории нет локальных изменений, её можно удалить.
2Путь из Версии FreeBSD и ветви репозитория добавляется к URL репозитория. Третий параметр — это целевой каталог для исходного кода в локальной системе.

26.6.4. Сборка из исходного кода

Система (world) , или вся операционная система, за исключением ядра, компилируется. Это делается в первую очередь, чтобы предоставить актуальные инструменты для сборки ядра. Затем компилируется само ядро:

# cd /usr/src
# make buildworld
# make buildkernel

Скомпилированный код записывается в /usr/obj.

Вот основные шаги. Дополнительные параметры для управления сборкой описаны ниже.

26.6.4.1. Выполнение чистой сборки

Некоторые версии системы сборки FreeBSD оставляют ранее скомпилированный код во временном каталоге объектов /usr/obj. Это может ускорить последующие сборки, избегая перекомпиляции неизменившегося кода. Для принудительной чистой пересборки всего используйте cleanworld перед началом сборки:

# make cleanworld

26.6.4.2. Установка количества задач

Увеличение количества задач сборки на многоядерных процессорах может повысить скорость сборки. Определите количество ядер с помощью sysctl hw.ncpu. Процессоры различаются, как и системы сборки, используемые в разных версиях FreeBSD, поэтому тестирование — единственный надежный способ определить, как разное количество задач влияет на скорость сборки. В качестве отправной точки рассмотрите значения от половины до удвоенного количества ядер. Количество задач указывается с помощью -j.

Пример 1. Увеличение количества заданий сборки

Сборка системы и ядра с использованием четырех задач:

# make -j4 buildworld buildkernel

26.6.4.3. Сборка только ядра

buildworld должен быть выполнен, если исходный код изменился. После этого buildkernel для сборки ядра может быть запущен в любое время. Чтобы собрать только ядро:

# cd /usr/src
# make buildkernel

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

Стандартное ядро FreeBSD основано на конфигурационном файле ядра GENERIC. Ядро GENERIC включает наиболее часто востребованные драйверы устройств и параметры. Иногда полезно или необходимо собрать собственное ядро, добавляя или удаляя драйверы устройств и параметры для соответствия конкретным требованиям.

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

Файлы конфигурации ядра находятся в /usr/src/sys/arch/conf/, где arch — это результат выполнения команды uname -m. На большинстве компьютеров это amd64, что соответствует каталогу с конфигурационными файлами /usr/src/sys/amd64/conf/.

/usr/src можно удалить или создать заново, поэтому предпочтительнее хранить конфигурационные файлы собственного ядра в отдельном каталоге, например, в /root. Свяжите конфигурационный файл ядра с каталогом conf. Если этот каталог будет удалён или перезаписан, конфигурацию ядра можно снова связать с новым каталогом.

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

# cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER
# cd /usr/src/sys/amd64/conf
# ln -s /root/STORAGESERVER .

Затем отредактируйте файл /root/STORAGESERVER, добавляя или удаляя устройства или параметры, как показано в config(5).

Собственное ядро собирается путем установки KERNCONF в файл конфигурации ядра в командной строке:

# make buildkernel KERNCONF=STORAGESERVER

26.6.5. Установка скомпилированного кода

После завершения шагов buildworld и buildkernel новые ядро и система устанавливаются:

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

Если было собрано собственное ядро, KERNCONF также должен быть установлен для использования нового собственного ядра:

# cd /usr/src
# make installkernel KERNCONF=STORAGESERVER
# shutdown -r now
# cd /usr/src
# make installworld
# shutdown -r now

26.6.6. Завершение обновления

Для окончания обновления выполняется несколько завершающих задач. Изменённые конфигурационные файлы объединяются с новыми версиями, устаревшие библиотеки находятся и удаляются, после чего система перезагружается.

26.6.6.1. Объединение конфигурационных файлов с помощью etcupdate(8)

etcupdate(8) — это инструмент для управления обновлениями файлов, которые не обновляются в процессе выполнения installworld, таких как файлы в /etc/. Он управляет обновлениями, выполняя трёхстороннее слияние изменений, внесённых в эти файлы, с локальными версиями. etcupdate(8) разработан для минимизации вмешательства пользователя.

В общем, etcupdate(8) не требует специальных аргументов для своей работы. Однако есть удобная промежуточная команда для проверки того, что будет сделано при первом использовании etcupdate(8):

# etcupdate diff

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

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

# etcupdate resolve

При переходе с mergemaster(8) на etcupdate(8) первый запуск может некорректно объединить изменения, создавая ложные конфликты. Чтобы избежать этого, выполните следующие действия перед обновлением исходных кодов и сборкой нового мира:

# etcupdate extract (1)
# etcupdate diff (2)
1Загрузите базы данных стандартных файлов /etc; дополнительную информацию смотрите в etcupdate(8).
2Проверьте изменения после начальной настройки. Удалите все локальные изменения, которые больше не нужны, чтобы уменьшить вероятность конфликтов при будущих обновлениях.

26.6.6.2. Проверка устаревших файлов и библиотек

Некоторые устаревшие файлы или каталоги могут остаться после обновления. Эти файлы могут быть найдены:

# make check-old

и удалены:

# make delete-old

Некоторые устаревшие библиотеки также могут остаться. Их можно обнаружить с помощью:

# make check-old-libs

и удалить

# make delete-old-libs

Программы, которые всё ещё использовали эти старые библиотеки, перестанут работать после удаления библиотек. Эти программы необходимо пересобрать или заменить после удаления старых библиотек.

Когда известно, что все старые файлы или каталоги можно безопасно удалить, нажатие y и Enter для подтверждения удаления каждого файла можно избежать, установив параметр BATCH_DELETE_OLD_FILES в команде. Например:

# make BATCH_DELETE_OLD_FILES=yes delete-old-libs

26.6.6.3. Перезагрузка после обновления

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

# shutdown -r now

26.7. Распространение обновлений на несколько машин

Когда несколько машин должны отслеживать одно и то же дерево исходных кодов, это приводит к расточительному использованию дискового пространства, пропускной способности сети и процессорного времени, если каждая система загружает исходные коды и пересобирает всё самостоятельно. Решение заключается в том, чтобы одна машина выполняла основную часть работы, а остальные монтировали результаты через NFS. В этом разделе описывается метод организации такого процесса. Дополнительные сведения об использовании NFS см. в Network File System (NFS).

Сначала определите набор машин, которые будут запускать один и тот же набор бинарных файлов, известный как набор сборки. На каждой машине может быть своё собственное ядро, но пользовательские бинарные файлы должны быть одинаковыми. Из этого набора выберите машину, которая будет машиной для сборки, на которой будут собираться система и ядро. В идеале это должна быть производительная машина с достаточным количеством свободных ресурсов CPU для выполнения команд make buildworld и make buildkernel.

Выберите машину, которая будет тестовой машиной для проверки обновлений программного обеспечения перед их внедрением в производство. Это должна быть машина, которая может позволить себе длительный простой. Она может быть той же машиной, что и сборщик, но это не обязательно.

Все машины в этом наборе сборки должны монтировать /usr/obj и /usr/src сборочной машины через NFS. Для нескольких наборов сборки /usr/src должен находиться на одной сборочной машине и монтироваться по NFS на остальных.

Убедитесь, что файлы /etc/make.conf и /etc/src.conf на всех машинах в наборе сборки соответствуют таковым на машине сборки. Это означает, что машина сборки должна собирать все части базовой системы, которые будут устанавливаться на любой машине из набора сборки. Кроме того, каждая машина сборки должна иметь имя ядра, указанное с помощью KERNCONF в /etc/make.conf, а машина сборки должна перечислить их все в своем KERNCONF, указав собственное ядро первым. Машина сборки должна иметь конфигурационные файлы ядра для каждой машины в своем каталоге /usr/src/sys/arch/conf.

На машине для сборки соберите ядро и систему, как описано в Обновление FreeBSD из исходного кода, но не устанавливайте ничего на машину для сборки. Вместо этого установите собранное ядро на тестовую машину. На тестовой машине смонтируйте /usr/src и /usr/obj через NFS. Затем выполните shutdown now, чтобы перейти в однопользовательский режим для установки нового ядра и системы, а также запустите etcupdate как обычно. По завершении перезагрузитесь, чтобы вернуться к обычной многопользовательской работе.

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

Тот же метод можно применить к дереву портов. Первый шаг — предоставить общий доступ через NFS к /usr/ports для всех машин в наборе сборки. Чтобы настроить /etc/make.conf для совместного использования distfiles, установите DISTDIR в общий каталог, доступный для записи пользователем, в которого отображается root при монтировании NFS. Каждая машина должна установить WRKDIRPREFIX в локальный каталог сборки, если порты собираются локально. В качестве альтернативы, если система сборки предназначена для создания и распространения пакетов на машины в наборе сборки, установите PACKAGES в системе сборки в каталог, аналогичный DISTDIR.

26.8. Сборка на хостах, отличных от FreeBSD

Исторически для сборки требовался хост с FreeBSD. В настоящее время FreeBSD можно собирать на Linux и macOS.

Для сборки на хосте, отличном от FreeBSD, рекомендуется использовать скрипт tools/build/make.py. Этот скрипт служит обёрткой для bmake — реализации make, используемой в FreeBSD. Он обеспечивает загрузку необходимых инструментов, включая make(1) из FreeBSD, и правильную настройку среды сборки. В частности, он устанавливает переменные внешнего инструментария, такие как XCC, XLD и другие. Кроме того, скрипт может передавать дополнительные аргументы командной строки, например -j 4 для параллельной сборки или конкретные цели make, в bmake.

Вместо скрипта tools/build/make.py также можно использовать свежую версию bmake. Однако в этом случае необходимые переменные окружения нужно задавать вручную (проще всего получить их список, выполнив tools/build/make.py --debug).

В противном случае список требований для сборки FreeBSD довольно короткий. Фактически, он сводится к установке нескольких зависимостей.

На macOS единственная зависимость — LLVM. Необходимые зависимости можно установить с помощью менеджера пакетов (например, Homebrew):

brew install llvm

На дистрибутивах Linux установите Clang версии 10.0 или новее, а также заголовочные файлы для libarchive и libbz2 (обычно поставляются в пакетах libarchive-dev и libbz2-dev).

После установки зависимостей система должна быть способна собрать FreeBSD.

Например, следующая команда tools/build/make.py собирает систему (world):

MAKEOBJDIRPREFIX=/tmp/obj tools/build/make.py -j 8 TARGET=arm64 TARGET_ARCH=aarch64 buildworld

Он собирает систему для целевой архитектуры aarch64:arm64 на 8 CPU и использует /tmp/obj для объектных файлов. Обратите внимание, что переменные MAKEOBJDIRPREFIX, TARGET и TARGET_ARCH обязательны при сборке на хостах, отличных от FreeBSD. Также убедитесь, что создан каталог для объектных файлов, указанный в переменной окружения MAKEOBJDIRPREFIX.

Обратитесь к arch(7) и build(7) для получения дополнительной информации.

Изменено: 20 октября 2025 г. by Vladlen Popolitov

Главная