---
description: 'Информация о том, как поддерживать систему FreeBSD в актуальном состоянии с помощью `freebsd-update` или Git, как пересобрать и переустановить всю базовую систему и так далее'
next: books/handbook/dtrace
params:
  path: /books/handbook/cutting-edge/
part: 'Часть III. Администрирование системы'
prev: books/handbook/l10n
showBookMenu: 'true'
tags: ["updating", "upgrading", "documentation", "FreeBSD-STABLE", "FreeBSD-CURRENT", "Security Patches"]
title: 'Глава 26. Обновление и смена версии FreeBSD'
weight: 30
---

[[updating-upgrading]]
= Обновление и смена версии FreeBSD
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 26
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/cutting-edge/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[updating-upgrading-synopsis]]
== Обзор

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

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

* Как поддерживать систему FreeBSD в актуальном состоянии с помощью freebsd-update или Git.
* Как сравнить состояние установленной системы с известной чистой копией.
* Как поддерживать установленную документацию в актуальном состоянии с помощью Git или портов документации.
* Разница между двумя ветвями разработки: FreeBSD-STABLE и FreeBSD-CURRENT.
* Как пересобрать и переустановить всю базовую систему.

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

* Правильно настроить сетевое подключение (crossref:advanced-networking[advanced-networking,Сложные вопросы работы в сети]).
* Знать, как устанавливать дополнительное стороннее программное обеспечение (crossref:ports[ports,Установка приложений: Пакеты и Порты]).

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

[[updating-upgrading-freebsdupdate]]
== Обновление FreeBSD

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

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

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

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

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

[[freebsdupdate-config-file]]
=== Файл конфигурации

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

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

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

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

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

[.programlisting]
....
# 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` сохранять изменения во время слияния.

[.programlisting]
....
# 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` должен попытаться объединить. Процесс объединения файлов представляет собой серию патчей man:diff[1]. Объединения могут быть приняты, открыты в редакторе или привести к прерыванию работы `freebsd-update`. В случае сомнений создайте резервную копию [.filename]#/etc# и просто примите объединения.

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

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

[.programlisting]
....
# 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`.

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

[[freebsdupdate-security-patches]]
=== Применение обновлений безопасности

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

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

[source, shell]
....
# freebsd-update fetch
# freebsd-update install
....

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

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

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

[.programlisting]
....
@daily                                  root    freebsd-update cron
....

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

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

[source, shell]
....
# freebsd-update rollback
Uninstalling updates... done.
....

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

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

[NOTE]
====
Всегда сохраняйте копию ядра [.filename]#GENERIC# в [.filename]#/boot/GENERIC#. Оно может быть полезно при диагностике различных проблем и при обновлении версий. Инструкции по получению копии ядра [.filename]#GENERIC# можно найти в crossref:cutting-edge[freebsd-update-custom-kernel-9x, Custom Kernels with FreeBSD 9.X and Later].
====

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

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

[[freebsdupdate-upgrade]]
=== Выполнение обновлений с изменением младших и старших версий

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

- FreeBSD 13.1 до 13.2.

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

- FreeBSD 13.2 до 14.0.

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

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

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

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

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

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

* *будьте готовы собрать модуль из исходного кода*

====

[NOTE]
====
Если система работает на собственном ядре, убедитесь перед началом обновления, что копия ядра [.filename]#GENERIC# осталась в [.filename]#/boot/GENERIC#. Обратитесь к разделу crossref:cutting-edge[freebsd-update-custom-kernel-9x, Собственные ядра системы в FreeBSD 9.X и более поздних версиях] для получения инструкций о том, как получить копию ядра [.filename]#GENERIC#.
====

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

[source, shell]
....
# freebsd-update fetch
# freebsd-update install
....

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

[source, shell]
....
# freebsd-update -r 13.2-RELEASE upgrade
....

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

[source, shell]
....
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` попытается загрузить все файлы, необходимые для обновления. В некоторых случаях пользователю могут быть заданы вопросы относительно того, что установить или как продолжить.

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

[source, shell]
....
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"
....

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

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

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

[source, shell]
....
# freebsd-update install
....

====

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

[source, shell]
....
# nextboot -k GENERIC
....

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

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

[source, shell]
....
# shutdown -r now
....

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

[source, shell]
....
# freebsd-update install
....

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

Обновление завершено. Если было выполнено обновление старшей версии, переустановите все порты и пакеты, как описано в crossref:cutting-edge[freebsdupdate-portsrebuild,Обновление пакетов после обновления старшей версии].

[[freebsd-update-custom-kernel-9x]]
==== Собственные ядра в FreeBSD 9.X и более поздних версиях

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

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

[source, shell]
....
# mount /media
# cd /media/usr/freebsd-dist
# tar -C/ -xvf kernel.txz boot/kernel/kernel
....

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

[source, shell]
....
# cd /usr/src
# make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null
....

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

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

[[freebsdupdate-portsrebuild]]
==== Обновление пакетов после обновления старшей версии

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

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

[source, shell]
....
# pkg-static upgrade -f
....

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

[source, shell]
....
# portmaster -af
....

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

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

[source, shell]
....
# freebsd-update install
....

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

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

[[freebsdupdate-system-comparison]]
=== Сравнение состояния системы

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

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

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

[source, shell]
....
# freebsd-update IDS >> outfile.ids
....

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

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

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

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

[[updating-bootcode]]
== Обновление загрузочного кода

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

[[updating-upgrading-documentation]]
== Обновление документации

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

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

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

[[updating-installed-documentation]]
=== Обновление документации из исходных текстов

Пересборка документации FreeBSD из исходных текстов требует набора инструментов, которые не входят в базовую систему FreeBSD. Необходимые инструменты можно установить, следуя extref:{fdp-primer}overview[этим шагам, overview-quick-start] из вводного руководства Проекта документации FreeBSD.

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

[source, shell]
....
# git clone https://git.FreeBSD.org/doc.git /usr/doc
....

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

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

[source, shell]
....
# git pull
....

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

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

[source, shell]
....
# cd /usr/doc
# make
....

[[current-stable]]
== Отслеживание ветки разработки

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

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

[[current]]
=== Использование FreeBSD-CURRENT

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

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

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

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

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

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

. Присоединитесь к спискам рассылки {freebsd-current} и {dev-commits-src-main}. Это _важно_ для того, чтобы видеть комментарии пользователей о текущем состоянии системы и получать важные уведомления о состоянии FreeBSD-CURRENT.
+
Список {dev-commits-src-main} фиксирует запись журнала изменений для каждого внесённого изменения, а также любую сопутствующую информацию о возможных побочных эффектах.
+
Чтобы присоединиться к этим спискам, перейдите на {mailing-lists}, выберите список, к которому хотите подписаться, и следуйте инструкциям. Для отслеживания изменений во всём дереве исходного кода, а не только в FreeBSD-CURRENT, подпишитесь на {dev-commits-src-all}.
. Синхронизация с исходным кодом FreeBSD-CURRENT. Обычно для получения кода -CURRENT из ветки `main` репозитория FreeBSD Git используется `git` (подробности см. в crossref:mirrors[git,“Использование Git”]).
. Из-за размера репозитория некоторые пользователи предпочитают синхронизировать только те разделы исходного кода, которые их интересуют или для которых они готовят патчи. Однако пользователи, планирующие собирать операционную систему из исходных кодов, должны загрузить _весь_ FreeBSD-CURRENT, а не только отдельные его части.
+
Перед компиляцией FreeBSD-CURRENT внимательно прочитайте [.filename]#/usr/src/Makefile# и следуйте инструкциям в crossref:cutting-edge[makeworld,Обновление FreeBSD из исходного кода]. Ознакомьтесь с {freebsd-current} и [.filename]#/usr/src/UPDATING#, чтобы быть в курсе других процедур начальной загрузки, которые иногда становятся необходимыми на пути к следующему выпуску.
. Будьте активными! Пользователям FreeBSD-CURRENT рекомендуется предлагать свои идеи по улучшению или исправлению ошибок. Предложения с приложенным кодом всегда приветствуются.

[[stable]]
=== Использование 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:

. Присоединяйтесь к рассылке {freebsd-stable}, чтобы быть в курсе зависимостей сборки, которые могут появиться в FreeBSD-STABLE, или других вопросов, требующих особого внимания. Разработчики также будут объявлять в этой рассылке о рассмотрении спорных исправлений или обновлений, давая пользователям возможность высказаться, если у них есть замечания по предлагаемым изменениям.
+
Присоединяйтесь к соответствующему списку рассылки git для отслеживаемой ветки. Например, пользователи, отслеживающие ветку {betarel-current-major}-STABLE, должны подписаться на {dev-commits-src-branches}. Этот список рассылает сообщения с комментарием коммита для каждого внесённого изменения, как только оно сделано, а также любую соответствующую информацию о возможных побочных эффектах.
+
Чтобы присоединиться к этим спискам, перейдите на {mailing-lists}, выберите список для подписки и следуйте инструкциям. Для отслеживания изменений во всём дереве исходного кода подпишитесь на {dev-commits-src-all}.
. Для установки новой системы FreeBSD-STABLE установите последний выпуск FreeBSD-STABLE с crossref:mirrors[mirrors,сайтов зеркал FreeBSD] или используйте ежемесячный снимок, собранный из FreeBSD-STABLE. Дополнительную информацию о снимках можно найти на link:https://www.FreeBSD.org/snapshots/[www.freebsd.org/snapshots].
+
Для компиляции или обновления существующей системы FreeBSD до FreeBSD-STABLE используйте `git` для получения исходного кода нужной ветки. Имена веток, например `stable/13`, перечислены на сайте link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng].
. Перед компиляцией или обновлением до FreeBSD-STABLE внимательно прочитайте файл [.filename]#/usr/src/Makefile# и следуйте инструкциям в crossref:cutting-edge[makeworld,Обновление FreeBSD из исходного кода]. Ознакомьтесь с {freebsd-stable} и файлом [.filename]#/usr/src/UPDATING#, чтобы быть в курсе других процедур начальной загрузки, которые иногда становятся необходимыми на пути к следующему выпуску.

[[translate-n-number]]
=== N-номер
При поиске ошибок важно знать, какие версии исходного кода использовались для создания системы, в которой обнаружена проблема. FreeBSD предоставляет информацию о версии, встроенную в ядро. man:uname[1] извлекает эту информацию, например:
[source, shell]
....
% 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-е поле, можно увидеть, что оно состоит из нескольких частей:
[source, shell]
....
main-n247514-031260d64c18

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

Команда `git rev-list` используется для нахождения n-номера, соответствующего хэшу Git. Например:
[source, shell]
....
% git rev-list --first-parent --count 031260d64c18 <.>
247514 <.>
....
<.> Хеш git для перевода (используется тот же хеш из приведённого выше примера)
<.> n-номер.

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

[[makeworld]]
== Обновление FreeBSD из исходного кода

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

[[updating-src-quick-start]]
=== Быстрый старт

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

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

[source, shell]
....
# etcupdate extract <.>
# etcupdate diff <.>
....

<.> Загрузите базы данных стандартных файлов [.filename]#/etc#; дополнительную информацию смотрите в man:etcupdate[8].

<.> Проверьте изменения после начальной настройки. Удалите все локальные изменения, которые больше не нужны, чтобы уменьшить вероятность конфликтов при будущих обновлениях.
====

[.procedure]
====
* Обновление и сборка
+
[source, shell]
....
# git -C /usr/src pull <.>
check /usr/src/UPDATING  <.>
# cd /usr/src          <.>
# make -j4 buildworld  <.>
# make -j4 kernel      <.>
# shutdown -r now      <.>
# etcupdate -p         <.>
# cd /usr/src          <.>
# make installworld    <.>
# etcupdate -B         <.>
# shutdown -r now      <.>
....

<.> Получите последнюю версию исходного кода. Подробнее о получении и обновлении исходного кода см. в crossref:cutting-edge[updating-src-obtaining-src, Обновление исходного кода].

<.> Проверьте [.filename]#/usr/src/UPDATING# на наличие необходимых действий перед или после сборки из исходного кода.

<.> Перейдите в исходный каталог.

<.> Соберите систему (world), всё кроме ядра системы.

<.> Скомпилируйте и установите ядро системы. Это эквивалентно `make buildkernel installkernel`.

<.> Перезагрузите систему с новым ядром.

<.> Обновите и объедините конфигурационные файлы в [.filename]#/etc/#, это обязательно перед выполнением installworld.

<.> Перейдите в исходный каталог.

<.> Установить систему (world).

<.> Обновите и объедините конфигурационные файлы в [.filename]#/etc/#.

<.> Перезагрузите систему для использования новой собранной системы (world) и ядра.
====

[[updating-src-preparing]]
=== Подготовка к обновлению исходного кода

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

[[updating-src-obtaining-src]]
=== Обновление исходного кода

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

[source, shell]
....
# cd /usr/src
# git remote --v
origin  https://git.freebsd.org/src.git (fetch)
origin  https://git.freebsd.org/src.git (push)
....

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

[[synching]]
[source, shell]
....
# git -C /usr/src pull
....

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

[NOTE]
====
Получение исходного кода:

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

[[updating-src-obtaining-src-repopath]]
.Версии FreeBSD и ветви репозиториев
[cols="10%,10%,80%", options="header"]
|===
| uname&#160;&#8209;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 с помощью man:uname[1]:

[source, shell]
....
# uname -r
13.2-RELEASE
....

На основе crossref:cutting-edge[updating-src-obtaining-src-repopath,Версии FreeBSD и ветви репозиториев], исходный код для обновления `13.2-RELEASE` имеет путь в репозитории `releng/13.2`. Этот путь используется при проверке исходного кода:

[source, shell]
....
# mv /usr/src /usr/src.bak <.>
# git clone --branch releng/13.2 https://git.FreeBSD.org/src.git /usr/src <.>
....

<.> Переместите старый каталог в другое место. Если в этом каталоге нет локальных изменений, его можно удалить.

<.> Путь из crossref:cutting-edge[updating-src-obtaining-src-repopath,Версии FreeBSD и ветви репозитория] добавляется к URL репозитория. Третий параметр — это целевой каталог для исходного кода в локальной системе.

[[updating-src-building]]
=== Сборка из исходного кода

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

[source, shell]
....
# cd /usr/src
# make buildworld
# make buildkernel
....

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

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

[[updating-src-building-clean-build]]
==== Выполнение чистой сборки

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

[source, shell]
....
# make cleanworld
....

[[updating-src-building-jobs]]
==== Установка количества задач

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

[[updating-src-building-jobs-example]]
.Увеличение количества заданий сборки
[example]
====
Сборка системы и ядра с использованием четырёх задач:

[source, shell]
....
# make -j4 buildworld buildkernel
....

====

[[updating-src-building-only-kernel]]
==== Сборка только ядра

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

[source, shell]
....
# cd /usr/src
# make buildkernel
....

[[updating-src-building-custom-kernel]]
==== Сборка собственного ядра

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

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

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

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

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

[source, shell]
....
# cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER
# cd /usr/src/sys/amd64/conf
# ln -s /root/STORAGESERVER .
....

Затем отредактируйте файл [.filename]#/root/STORAGESERVER#, добавляя или удаляя устройства или параметры, как показано в man:config[5].

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

[source, shell]
....
# make buildkernel KERNCONF=STORAGESERVER
....

[[updating-src-installing]]
=== Установка скомпилированного кода

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

[source, shell]
....
# cd /usr/src
# make installkernel
# shutdown -r now
# cd /usr/src
# make installworld
# shutdown -r now
....

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

[source, shell]
....
# cd /usr/src
# make installkernel KERNCONF=STORAGESERVER
# shutdown -r now
# cd /usr/src
# make installworld
# shutdown -r now
....

[[updating-src-completing]]
=== Завершение обновления

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

[[updating-src-completing-merge-etcupdate]]
==== Объединение конфигурационных файлов с помощью man:etcupdate[8]

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

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

[source, shell]
....
# etcupdate diff
....

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

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

[source, shell]
....
# etcupdate resolve
....

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

[source, shell]
....
# etcupdate extract <.>
# etcupdate diff <.>
....

<.> Загрузите базы данных стандартных файлов [.filename]#/etc#; дополнительную информацию смотрите в man:etcupdate[8].

<.> Проверьте изменения после начальной настройки. Удалите все локальные изменения, которые больше не нужны, чтобы уменьшить вероятность конфликтов при будущих обновлениях.
====

[[updating-src-completing-check-old]]
==== Проверка устаревших файлов и библиотек

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

[source, shell]
....
# make check-old
....

и удалены:

[source, shell]
....
# make delete-old
....

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

[source, shell]
....
# make check-old-libs
....

и удалить

[source, shell]
....
# make delete-old-libs
....

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

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

[source, shell]
....
# make BATCH_DELETE_OLD_FILES=yes delete-old-libs
....

====

[[updating-src-completing-restart]]
==== Перезагрузка после обновления

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

[source, shell]
....
# shutdown -r now
....

[[pkgbase]]
== Обновление FreeBSD пакетами

Начиная с версии 14.0-RELEASE, проект FreeBSD публикует набор пакетов базовой системы, используя man:pkg[8]. Теперь удобством pkg можно пользоваться не только в коллекции портов FreeBSD, но и для самой системы. man:pkg[8] применим и к FreeBSD. Базовые пакеты и их использование традиционно называют _pkgbase_.

Публикаци официальных пакетов началась в с link:https://lists.freebsd.org/archives/freebsd-pkgbase/2023-October/000221.html[октябре 2023 года]. Их использование в настоящее время считаются экспериментальным для выпуска FreeBSD 14.

Начиная с версии 15.0-RELEASE, man:freebsd-base[7] будет поддерживаться в режиме предварительной (tech preview) версии для:

* установки
* незначительных обновлений
* крупных обновлений

freebsd-base в конечном итоге заменит:

* распределительные наборы в виде tar-архивов, такие как `base.txz` или `kernel.txz`, которые традиционно используются для установки ОС с помощью man:bsdinstall[8]
* man:freebsd-update[8] для обновлений операционной системы.

Текущий план заключается в том, чтобы freebsd-update работал с pkg.

[WARNING]
====
Замена наборов дистрибуции займёт некоторое время, пока freebsd-base не станет полностью стабильным!
====

Пакеты базовой системы дополняют crossref:cutting-edge[makeworld,"сборку и установку из исходных кодов"], которая по-прежнему доступна для тех, кто желает собирать собственные ядра или пользовательское пространство. Также возможно собирать пользовательские пакеты базовой системы из локальных исходных кодов, равно как и просто полагаться на официально предоставляемые пакеты.

=== Преобразование хоста для использования freebsd-base

FreeBSD 14.0-RELEASE или новее может быть преобразована для использования пакетов Базовой Системы. Более ранние версии должны сначала обновиться с помощью freebsd-update, а затем выполнить преобразование.

Для преобразования рекомендован инструмент под названием link:https://github.com/FreeBSDFoundation/pkgbasify[pkgbasify], спонсированный Фондо FreeBSD. Следуйте инструкции приведенной там.

man:freebsd-update[8] будет усовершенствован для использования pkg и pkgbasify.

[WARNING]
====
Обратите внимание, что для данной миграции требуется до 5 ГиБ дополнительного свободного пространства для загрузки, распаковки и перемещения конфликтующих файлов. Инструмент pkgbasify не проверяет это, и пользователь обязан самостоятельно убедиться в наличии достаточного пространства перед запуском миграции.
====

man:pkgbasify[8] (или любой результат, который даст link:https://reviews.freebsd.org/D51594[D51594] или link:https://wiki.freebsd.org/WantedPorts#O-P[запрос порта]) выполняет 6 основных задач:

* Создает резервную среду загрузки (только для ZFS) с помощью man:bectl[8]
* Создает новые файлы конфигурации репозитория пакетов
* Обновляет существующие компоненты системы, такие как базовая система, ядро, lib32, отладочные файлы
* Объединяет существующие и новые файлы конфигурации
* Обновляет базы данных passwd и capabilities
* Перезапускает sshd немедленно

=== Обновление хоста с использованием freebsd-base

[WARNING]
====
Это все ещё находится в разработке, поэтому, пожалуйста, будьте осторожны, особенно при преобразовании существующей системы для использования freebsd-base.
====

Создайте папку для пользовательских конфигурационных файлов репозитория pkg, если она ещё не существует.

[source, shell]
....
# mkdir -p /usr/local/etc/pkg/repos/
....

Для использования репозитория freebsd-base создайте файл конфигурации репозитория пакетов с именем `FreeBSD-base.conf`:

[[pgk-base-repo-configuration]]
[.programlisting]
....
FreeBSD-base {
    url = "pkg+https://pkg.freebsd.org/${ABI}/base_release_${VERSION_MINOR}";
    mirror_type = "srv";
    signature_type = "fingerprints";
    fingerprints = "/usr/share/keys/pkg";
    enabled = yes;
}
....

для получения дополнительной информации о конкретных параметрах конфигурации см. man:pkg.conf[5].

Существуют различные ветки на выбор (путем соответствующего изменения url):

[[table-of-packagebase-branches]]
.Ветки пакетов базовой системы
[cols="10%,20%,70%, options=", header"]
|===
| Ветка
| Периодичность
| URL

| main
| дважды в день - 12:00 и 00:00 по UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_latest`

| main
| еженедельно – воскресенье в 12:00 UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_weekly`

| stable/14
| дважды в день – 12:00 и 00:00 по UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_latest`

| stable/14
| еженедельно – воскресенье в 12:00 UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_weekly`

| releng/14.3
| дважды в день – 12:00 и 00:00 по UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_release_3`

| releng/15.0
| дважды в день – 12:00 и 00:00 по UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_release_0`

| stable/15
| дважды в день – 12:00 и 00:00 по UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_latest`

| stable/15
| еженедельно – воскресенье в 12:00 UTC
| `pkg+https://pkg.freebsd.org/${ABI}/base_weekly`
|===

Для обновления системы измените файл конфигурации в соответствии с желаемым выпуском и выполните:

[source, shell]
....
# pkg update -r FreeBSD-base
# pkg upgrade -r FreeBSD-base
....

проверьте, корректны ли эти пакеты, и примите изменения.

Перезагрузите операционную систему, выполнив следующую команду:

[source, shell]
....
# shutdown -r now
....

[[pkgbase-major-upgrade]]
==== Крупные обновления
С ZFS загрузочные среды позволяют выполнить обновление без прерывания работы программного обеспечения. Если система не использует root-on-ZFS: сделайте резервную копию перед обновлением.

===== Подготовка
Измените `/usr/local/etc/pkg/repos/FreeBSD-base.conf`, чтобы указать на правильный основной выпуск, например `base_release_0 ` для 15.0-RELEASE, чтобы он выглядел так:

[WARNING]
====
Этот файл может быть изменен для включения в RELEASE с другим путем.
====

[.programlisting]
....
FreeBSD-base {
    url = "pkg+https://pkg.freebsd.org/${ABI}/base_release_0";
    mirror_type = "srv";
    signature_type = "fingerprints";
    fingerprints = "/usr/share/keys/pkg";
    enabled = yes;
....

[WARNING]
====
Поскольку pkgbase в FreeBSD 14 является экспериментальным, то и крупное обновление pkgbase до версии 15 также носит экспериментальный характер. На момент написания в некоторых крайних случаях крупное обновление удаляет pkg, что приводит к ошибкам сегментации. Это считается (link:https://github.com/freebsd/pkg/issues/2475[известной проблемой]) для 15.0-RELEASE. Чтобы обойти эту проблему, заблокируйте pkg перед обновлением.

[source, shell]
....
# pkg -c /mnt/upgrade lock pkg
....

Экспериментальное основное обновление с FreeBSD 14 до 15 (или 16.0-CURRENT) должно сопровождаться установкой метапакета `FreeBSD-set-minimal`.
====


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

[source, shell]
....
pkg prime-origins | sort -u > /var/tmp/pkg-prime-origins.txt
....

[[pkgbase-major-zfs]]
===== переход на новую основную версию с zfs
Создайте загрузочное окружение с помощью man:bectl[8] и назовите его в соответствии с версией, на которую выполняется обновление
[source, shell]
....
# bectl create 15.0-RELEASE
....

Создайте каталог, затем смонтируйте новую загрузочную среду туда, чтобы обеспечить работу с pkg man:chroot[8] и rootdir.

[source, shell]
....
# mkdir /mnt/upgrade
# bectl mount 15.0-RELEASE /mnt/upgrade
....

Следующий шаг обновит загрузочное окружение до указанной версии.

[WARNING]
====
Этот шаг может удалить пакеты, не входящие в базовую систему, включая запущенную среду рабочего стола.
====

Установите переменную окружения ABI для обновления основной версии (замените amd64 на архитектуру и 15 на целевую версию). Задайте для pkg-static каталог chroot, указывающий на точку монтирования загрузочного окружения.

[source, shell]
....
# env ABI=FreeBSD:15:amd64 pkg-static -c /mnt/upgrade upgrade -r FreeBSD-base
....

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

[source, shell]
....
Newer FreeBSD version for package FreeBSD-zoneinfo:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1500058
- running userland: 1500000
Ignore the mismatch and continue? [y/N]:
....

Проверьте и подтвердите это.

Чтобы проверить успешность операции, выполните chroot в точку монтирования загрузочного окружения и выполните команду `freebsd-version -kru`.

[source, shell]
....
# chroot /mnt/upgrade
# freebsd-version -ku
# exit
....

Временно активируйте загрузочную среду и перезагрузитесь.
[source, shell]
....
# bectl activate -t 15.0-RELEASE
# shutdown -r now
....

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

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

[source, shell]
....
bectl activate 15.0-RELEASE
....

[[pkgbase-major-non-zfs]]
===== переход на новую основную версию без zfs
Установите переменную окружения ABI для обновления основной версии (замените amd64 на архитектуру и 15 на целевую версию).

[source, shell]
....
# env ABI=FreeBSD:15:amd64 pkg-static upgrade -r FreeBSD-base
....

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

[source, shell]
....
Newer FreeBSD version for package FreeBSD-zoneinfo:
To ignore this error set IGNORE_OSVERSION=yes
- package: 1500058
- running userland: 1500000
Ignore the mismatch and continue? [y/N]:
....

Проверьте и подтвердите это.

Чтобы проверить успешность обновления, выполните команду `freebsd-version -kru`.

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

===== Задачи после обновления
Если pkg был заблокирован во время обновления, то в качестве временного решения удалите блокировку следующим образом:
[source, shell]
....
# pkg unlock pkg
....

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

[source, shell]
....
# pkg upgrade
....

Рассмотрите возможность получения помощи по ссылке link:https://www.freebsd.org/support/[Поддержка FreeBSD], если возникли проблемы.

[[build-pkgbase-packages-locally]]
=== Ручная сборка pkgbase и публикация в локальной сети

При создании пользовательских пакетов pkgbase клонируйте дерево исходного кода FreeBSD:

[source, shell]
....
# cd /usr/src
# git clone https://github.com/freebsd/freebsd-src.git /usr/src
....

Перейдите на ветку (checkout) релиза, для которого будут собираться пакеты:

[source, shell]
....
# git checkout releng/14.3
....

Запустите процесс сборки, в зависимости от доступных ресурсов это может занять некоторое время. Установите количество параллельных процессов в соответствии с числом ядер процессора.

Этот пример написан для 8-ядерного процессора:

[source, shell]
....
# make -j8 buildworld && make -j8 buildkernel && make -j8 packages
....

При частой сборке рекомендуется использовать package:devel/ccache[] для ускорения последующих сборок из кэша.

После сборки пакеты будут сохранены в `/usr/obj/usr/src/repo/FreeBSD:14:amd64/14.3p2` или аналогичный каталог, в зависимости от версии сборки.

Чтобы опубликовать эти пакеты в сети, настройте службу nginx и используйте следующую конфигурацию location в настройках HTTP-сервера:

[.programlisting]
....
 location /FreeBSD:14:amd64 {
   alias /usr/obj/usr/src/repo/FreeBSD:14:amd64/;
   autoindex on;
 }
....

И перезагрузите службу nginx.

Если не используется https, используйте небольшой файл конфигурации на клиентах для указания только что собранной версии pkgbase, отредактировав `/usr/local/etc/pkg/repos/upgrade.conf`:

[.programlisting]
....
upgrade: {
	url         = http://ip.of.the.server/FreeBSD:14:amd64/14.3p2
	enabled     = yes
}
....

и используйте его, как описано выше (но используйте обновление -r вместо FreeBSD-base).

[[small-lan]]
== Распространение обновлений на несколько машин

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

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

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

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

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

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

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

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

[[building-on-non-freebsd-hosts]]
== Сборка на хостах, отличных от FreeBSD

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

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

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

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

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

[source, shell]
....
brew install llvm
....

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

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

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

[source, shell]
....
MAKEOBJDIRPREFIX=/tmp/obj tools/build/make.py -j 8 TARGET=arm64 TARGET_ARCH=aarch64 buildworld
....

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

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