Глава 21. Обновление системы и смена версии FreeBSD

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

21.1. Краткий обзор

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

После чтения этой главы вы будете знать:

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

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

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

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

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

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

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

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

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

Эта программа используется для установки распространяемых в двоичном виде обновлений безопасности и исправлений для FreeBSD без необходимости ручной компиляции и установки патчей или нового ядра. Двоичные обновления доступны для всех архитектур и версий, поддерживаемых группой безопасности. Перечень поддерживаемых версий и их ожидаемые даты окончания поддержки указаны на странице http://www.FreeBSD.org/security/.

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

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

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

21.2.1. Конфигурационный файл

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

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

Данный параметр определяет, какие части FreeBSD будут обновлены. По умолчанию обновляется вся базовая система (world) и ядро (kernel). Вместо этого можно указать отдельные компоненты, такие как 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), похожую на mergemaster(8), но с меньшим количеством параметров. Результат слияния принимается, открывается редактор или freebsd-update прекращает работу. В случае сомнений сделайте резервную копию /etc и просто согласитесь со всеми изменениями. Для получения подробной информации по команде mergemaster смотрите Объединение файлов конфигурации.

# 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.

21.2.2. Обновления безопасности

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

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

# freebsd-update fetch
# freebsd-update install

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

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

@daily                                  root    freebsd-update cron

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

На случай, если что-то пошло не так, в freebsd-update предусмотрен механизм возврата последнего набора изменений с использованием следующей команды:

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

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

Команда freebsd-update позволяет автоматически обновлять только ядро GENERIC. Если используется ядро с собственной конфигурацией, его понадобится пересобрать и переустановить после того, как freebsd-update завершит установку обновлений. Тем не менее, freebsd-update обнаружит и обновит ядро GENERIC при наличии /boot/GENERIC, даже если оно не является текущим используемым ядром в системе.

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

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

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

21.2.3. Обновления со сменой старшей и младшей версий

Обновление с FreeBSD 9.0 на FreeBSD 9.1, называется обновлением со сменой младшего номера версии. Смена старшего номера версии происходит, когда FreeBSD переходит с одной значительной версии на другую, как, например, при обновлении с FreeBSD 9.X на FreeBSD 10.X. Оба типа обновлений можно произвести, указав freebsd-update версию, на которую нужно перейти.

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

Следующая команда, будучи запущенной на FreeBSD 9.0, выполнит обновление до версии FreeBSD 9.1:

# freebsd-update -r 9.1-RELEASE upgrade

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

Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 9.0-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 9.0-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

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

# nextboot -k GENERIC

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

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

# shutdown -r now

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

# freebsd-update install

Количество этапов установки обновлений может быть два вместо трёх и зависит от того, были ли изменены номера версий каких-либо совместно используемых библиотек.

На этом процесс завершён. Если было выполнено обновление со сменой старшего номера версии, переустановите все порты и пакеты в соответствии с описанием, которое предоставляет Обновление пакетов после смены старшей версии системы.

21.2.3.1. Собственная конфигурация ядра в FreeBSD 9.X и более поздних версиях

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

Если ядро с собственной конфигурацией было собрано более одного раза, получите копию ядра 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.

21.2.3.2. Обновление пакетов после смены старшей версии системы

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

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

# pkg-static upgrade -f

Перестроение всех установленных приложений можно выполнить этой командой:

# portmaster -af

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

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

# freebsd-update install

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

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

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

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

Эта команда не является заменой IDS, такой как 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.

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

Документация является неотъемлемой частью операционной системы FreeBSD. И хотя актуальная версия документации FreeBSD всегда доступна на сайте FreeBSD (http://www.freebsd.org/doc/), может быть удобно иметь под рукой актуальную локальную копию сайта FreeBSD, руководств, FAQ и статей.

В этом разделе описывается, как использовать исходный текст или Коллекцию Портов FreeBSD для организации актуальной локальной копии документации FreeBSD.

За информацией о редактировании и отправке изменений для документации обращайтесь к FreeBSD Documentation Project Primer for New Contributors (FreeBSD Documentation Project Primer).

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

Для перестроения документации FreeBSD из исходного текста требуется набор инструментов, который не является частью основной системы FreeBSD. Требуемые инструменты, включая svn, можно установить из пакета или порта textproc/docproj, разработанного в рамках проекта документации FreeBSD.

После установки используйте svn для получения копии исходных текстов документации:

# svn checkout https://svn.FreeBSD.org/doc/head /usr/doc

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

Последующие обновления можно получить, выполнив:

# svn update /usr/doc

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

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

# cd /usr/doc
# make install clean

Для обновления только указанной языковой версии команду make можно запустить в соответствующем подкаталоге /usr/doc:

# cd /usr/doc/en_US.ISO8859-1
# make install clean

Альтернативный способ обновления документации заключается в запуске следующей команды из из /usr/doc или подкаталога с желаемой языковой версией:

# make update

Используемый при установке формат можно указать через FORMATS:

# cd /usr/doc
# make FORMATS='html html-split' install clean

Для упрощения процесса частичного обновления документации и построения только нужных переводов имеется несколько параметров. Их можно задать как на общесистемном уровне, указав в /etc/make.conf, так и непосредственно в команде make.

Данные параметры включают:

DOC_LANG

Перечень языков и кодировок для построения и установки, например, en_US.ISO8859-1 для англоязычной документации.

FORMATS

Единый формат или набор форматов для построения. На данный момент поддерживаются html, html-split, txt, ps и pdf.

DOCDIR

Путь для установки документации. По умолчанию /usr/shared/doc.

Для получения других переменных make, также работающих во FreeBSD в качестве общесистемных, обратитесь к make.conf(5).

21.3.2. Обновление документации из портов

В предыдущем разделе был представлен метод обновления документации FreeBSD из исходных текстов. В этом разделе описывается альтернативный метод с использованием Коллекции Портов, который позволяет:

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

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

Данный метод обновления документации FreeBSD предоставляется портами и пакетами документации, которые ежемесячно обновляет Группа Менеджеров Дерева Документации <doceng@FreeBSD.org>. Они перечислены в Коллекции Портов FreeBSD в категории docs (http://www.freshports.org/docs/).

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

  • Пакет или порт misc/freebsd-doc-en устанавливает всю англоязычную документацию.

  • Метапакет или порт misc/freebsd-doc-all устанавливает всю документацию на всех доступных языках.

  • Имеются пакеты и порты для каждого перевода, например, misc/freebsd-doc-hu для венгерской документации.

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

# pkg install hu-freebsd-doc

Для пакетов используется другая схема наименования, которая отличается от названия соответствующего порта: lang-freebsd-doc, где lang соответствует сокращённому языковому коду, такому как hu для венгерского или zh_cn для упрощённого китайского.

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

# cd /usr/ports/misc/freebsd-doc-en
# make install clean

В порте имеется меню конфигурации, в котором можно указать нужный формат. По умолчанию выбирается HTML с разделителями, такой как на http://www.FreeBSD.org, а также PDF.

Иначе, при построении порта документации можно указать параметры make, которые включают в себя:

WITH_HTML

Документ в формате HTML на одной странице. Сформированная документация сохраняется в файле article.html или book.html.

WITH_PDF

Сформированная документация сохраняется в файле article.pdf или book.pdf.

DOCBASE

Указывает место размещения документации. По умолчанию /usr/local/shared/doc/freebsd.

В примере ниже демонстрируется использование переменных для установки венгерской документации в PDF в указанный каталог:

# cd /usr/ports/misc/freebsd-doc-hu
# make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean

Пакеты или порты документации обновляются согласно инструкциям в Установка приложений. порты и пакеты. Например, следующая команда выполняет обновление установленной документации на венгерском языке с помощью ports-mgmt/portmaster в режиме использования только готовых пакетов:

# portmaster -PP hu-freebsd-doc

21.4. Использование ветви разработки

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

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

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

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

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

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

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

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

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

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

Чтобы отслеживать изменения во FreeBSD-CURRENT:

  1. Подпишитесь на списки рассылки Список рассылки, посвящённый обсуждению FreeBSD-CURRENT и Список рассылки сообщений об изменениях в репозитории SVN для ветки head/-current дерева исходных текстов. Это необходимо для того, чтобы получать сообщения и важные бюллетени относительно текущего состояния FreeBSD-CURRENT.

    Список рассылки Список рассылки сообщений об изменениях в репозитории SVN для ветки head/-current дерева исходных текстов содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.

    Чтобы подписаться на эти списки рассылки, перейдите по ссылке https://lists.freebsd.org, щёлкните на нужном списке и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, а не только FreeBSD-CURRENT, подпишитесь на Список рассылки сообщений об изменениях в репозитории SVN для всего дерева исходных текстов (за исключением <quote>user</quote> и <quote>projects</quote>).

  2. Загрузите исходные тексты FreeBSD-CURRENT. Обычно для этого используется svn, с помощью которого можно загрузить исходные тексты -CURRENT из ветки head с одного из зеркал Subversion, перечисленных в Сайты зеркала Subversion.

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

  3. Вследствие больших размеров репозитория некоторые пользователи для ознакомления или изготовления патчей выбирают частичную загрузку. Тем не менее, для компиляции операционной системы из исходных текстов требуется загрузить FreeBSD-CURRENT полностью, а не только лишь выбранные части.

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

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

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

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

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

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

Чтобы отслеживать изменения во FreeBSD-STABLE:

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

    Подпишитесь на список рассылки svn, соответствующий используемой ветви. Например, при использовании 9-STABLE следует подписаться на Список рассылки сообщений об изменениях в репозитории SVN для ветки 9-stable дерева исходных текстов. Этот список рассылки содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.

    Чтобы подписаться на эти списки рассылки, перейдите по ссылке https://lists.freebsd.org, щёлкните на нужном списке, и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, подпишитесь на Список рассылки сообщений об изменениях в репозитории SVN для всего дерева исходных текстов (за исключением <quote>user</quote> и <quote>projects</quote>).

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

    Чтобы скомпилировать новую или обновить существующую систему FreeBSD до FreeBSD-STABLE, используйте svn для загрузки исходных текстов нужной ветки. Имена веток вида stable/9 перечислены на странице www.freebsd.org/releng. При отсутствии надёжного Интернет-соединения можно воспользоваться CTM (Использование CTM).

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

21.5. Синхронизация исходных текстов

Имеются различные способы синхронизации с исходными текстами FreeBSD. В этом разделе сравниваются основные из них, Subversion и CTM.

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

Subversion для обновления исходных текстов использует модель pull. Пользователь или сценарий cron запускают программу svn, которая обновляет локальную версию исходных текстов. Subversion является предпочтительным способом обновления локального дерева исходных текстов, поскольку обновления являются актуальными с точностью до минуты и пользователь управляет временем их загрузки. Загрузку определённых файлов и каталогов легко ограничить, а запрашиваемые обновления формируются на лету на стороне сервера. О том, как актуализировать исходные тексты с использованием Subversion, описано в svn.

CTM не выполняет интерактивное сравнение имеющихся исходных текстов с находящимися в главном архиве, и не выполняет их загрузку. Вместо этого несколько раз в день на главной машине CTM запускается скрипт, находящий изменения в файлах с момента своего предыдущего запуска. Все обнаруженные изменения сжимаются, помечаются последовательным номером и кодируются для передачи по электронной почте в печатном формате ASCII. После получения эти "дельта-файлы CTM" могут быть переданы утилите ctm.rmail, которая осуществляет автоматическое декодирование, проверку и применение изменений к пользовательской копии исходных текстов. Этот процесс более эффективен по сравнению с используемым в Subversion и требует меньше ресурсов сервера, так как он выполнен по модели push, а не pull. Инструкции по использованию CTM для синхронизации исходных текстов даны в Использование CTM.

Если пользователь случайно уничтожил часть своего архива, Subversion обнаружит и перестроит повреждённую часть. CTM этого не делает, поэтому если пользователь удалил часть дерева исходных текстов и не имеет архивной копии, то нужно будет начать с самого начала (с последнего "базового дельта-файла"), перестроив всё с помощью CTM.

21.6. Пересборка мира

После того, как локальное дерево исходных текстов было синхронизировано с некоторой версией FreeBSD (FreeBSD-STABLE или FreeBSD-CURRENT), его можно использовать для перестроения системы. Этот процесс известен как перестроение мира.

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

Procedure: Перед тем как приступать к построению мира

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

  2. Проверьте последние сообщения в списке рассылки Список рассылки, посвящённый обсуждению FreeBSD-STABLE; или Список рассылки, посвящённый обсуждению FreeBSD-CURRENT (в зависимости от отслеживаемой ветки). Будьте в курсе любых известных проблем, и тех систем, которые они затрагивают. В случае возникновения подобной проблемы, дождитесь сообщения о том, что эта проблема решена. После этого повторите синхронизацию исходных текстов для получения необходимого исправления.

  3. Прочтите /usr/src/UPDATING для получения информации о дополнительных шагах, необходимых для данной версии исходных текстов. В этом файле содержится важная информация о возможных проблемах и может быть указан порядок выполнения соответствующих команд. При большинстве обновлений требуются дополнительные шаги, например, переименование или удаление определённых файлов перед установкой нового мира. Эти шаги будут перечислены в конце файла, где в явном виде описывается текущая рекомендуемая последовательность действий при обновлении. Если содержимое UPDATING противоречит каким-либо шагам в этой главе, руководствуйтесь инструкциями в файле UPDATING, которые имеют больший приоритет.

Не используйте make world

В некоторой устаревшей документации рекомендуется использование make world. Эта команда пропускает некоторые важные шаги, поэтому использовать её следует лишь в том случае, если вы точно знаете, что делаете. Почти во всех случаях make world - это неправильный способ, вместо этого следует использовать описанную здесь процедуру.

21.6.1. Обзор процесса

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

Во FreeBSD термин "world" обозначает ядро, исполняемые файлы основой системы, библиотеки, файлы для программирования и встроенный компилятор. Имеет значение порядок, при котором эти компоненты собираются и устанавливаются.

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

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

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

Исходя из этих соображений в следующей процедуре описана рекомендуемая последовательность обновления.

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

Проще всего использовать для этого script с параметром, задающим имя файла для сохранения всего вывода. Не сохраняйте вывод в /tmp, так как этот каталог может быть очищен при следующей перезагрузке. Более подходящим местом является /var/tmp. Запустите команду непосредственно перед перестроением мира, а после завершения процесса наберите exit:

# script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out

Procedure: Обзор процесса построения мира

Команды для построения мира должны запускаться в указанном здесь порядке. В этом разделе даётся краткое описание назначения каждой из команд.

  1. Если процесс построения мира уже запускался ранее на этой системе, то в /usr/obj могла остаться копия предыдущей сборки. Удалите этот каталог для ускорения процесса построения нового мира и возможного сокращений работы по разрешению зависимостей.

    # chflags -R noschg /usr/obj/*
    # rm -rf /usr/obj
  2. Скомпилируйте новый компилятор и несколько сопутствующих инструментов и используйте их для компиляции остальной части мира. Результаты сохраняются в /usr/obj.

    # cd /usr/src
    # make buildworld
  3. Для построения нового ядра используйте компилятор, расположенный в /usr/obj, чтобы защититься от ошибок несоответствия между компилятором и ядром. Это необходимо, так как определённые структуры данных могут поменяться, и при использовании различных версий ядра и исходных текстов перестанут работать ps и top.

    # make buildkernel
  4. Установите новое ядро и модули, чтобы их можно было использовать для загрузки. Если используется kern.securelevel со значением выше 1 и на файле ядра установлен noschg или подобный флаг, то для этого сперва придётся дополнительно перейти в однопользовательский режим. В противном случае эту команду можно без проблем запустить в многопользовательском режиме. Смотрите страницу Справочника init(8) для получения информации о kern.securelevel, а также chflags(1) для информации об использовании различных файловых флагов.

    # make installkernel
  5. Переведите систему в однопользовательский режим для минимизации проблем при обновлении уже работающих исполняемых файлов. Это также уменьшит вероятность возникновения проблем при работе старого мира на новом ядре.

    # shutdown now

    После перехода в однопользовательский режим, запустите эти команды, если в системе используется UFS:

    # mount -u /
    # mount -a -t ufs
    # swapon -a

    Если используется ZFS, запустите другие две команды. В данном примере zpool называется zroot:

    # zfs set readonly=off zroot
    # zfs mount -a
  6. Дополнительно: Если желаемая картография клавиатуры отличается от используемой по умолчанию US English, её можно изменить с помощью kbdmap(1):

    # kbdmap
  7. Затем, если часы CMOS установлены на местное время (это так, если вывод date(1) не содержит правильное время и часовой пояс), выполните:

    # adjkerntz -i
  8. Пересборка мира не включает в себя добавление или обновление конфигурационных файлов в /etc, /var, /usr и некоторых других каталогах. Следующим шагом является выполнение первоначального обновления файлов конфигурации в /etc для подготовки к новому миру. Следующая команда ограничивается сравнением файлов, необходимых для успешного выполнения цели installworld. В частности, на этом шаге могут быть добавлены новые пользовательские группы, служебные учётные записи и сценарии автозапуска, которые были добавлены во FreeBSD со времени последнего обновления. Это необходимо для их использования при выполнении шага installworld. Смотрите Объединение файлов конфигурации для получения более подробных инструкций по этой команде:

    # mergemaster -p
  9. Установите новый мир и служебные исполняемые файлы, находящиеся в /usr/obj.

    # cd /usr/src
    # make installworld
  10. Обновите остальные файлы конфигурации.

    # mergemaster -iF
  11. Удалите устаревшие файлы. Это важно, так как в противном случае они могут вызвать проблемы.

    # make delete-old
  12. Теперь нужна полная перезагрузка системы для того, чтобы загрузить новое ядро и мир с использованием новых конфигурационных файлов.

    # reboot
  13. Убедитесь, что перед удалением старых версий библиотек все установленные порты были пересобраны согласно инструкциям в Обновление портов. По завершению удалите все старые библиотеки во избежание конфликтов с их новыми версиями. За подробным описанием этого шага обратитесь к Удаление устаревших файлов и библиотек.

    # make delete-old-libs

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

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

В процессе построения мира используется несколько файлов конфигурации.

Makefile, расположенный в /usr/src, описывает правила и порядок построения программ, составляющих FreeBSD.

В make.conf(5) описаны параметры, доступные для make, а также несколько общих примеров имеется в /usr/shared/examples/etc/make.conf. Добавляемые в /etc/make.conf параметры определяют поведение make при построении программ. Эти параметры действуют при каждом использовании make, включая компиляцию приложений из Коллекции Портов, компиляцию собственных программ на Си и построение операционной системы FreeBSD. Изменение некоторых настроек может иметь далекоидущие и порой неожиданные последствия. Прочтите комментарии в обоих местах и примите к сведению, что значения по умолчанию были выбраны как компромисс между производительностью и надёжностью.

Поведение при сборке операционной системы из исходных текстов задаётся в /etc/src.conf. В отличие от /etc/make.conf, содержимое /etc/src.conf влияет только на сборку самой операционной системы FreeBSD. Описание многих параметров, доступных в этом файле, имеется в src.conf(5). Будьте осторожны при выключении на первый взгляд ненужных модулей ядра или параметров сборки. Иногда между ними имеются неожиданные или неочевидные взаимозависимости.

21.6.3. Переменные и цели выполнения

Общий формат использования make:

# make -x -DVARIABLE target

В этом примере параметр -x передаётся make. Обратитесь к странице Справочника make(1) для получения примеров использования имеющихся параметров.

Чтобы передать переменную, укажите её имя с использованием -D_VARIABLE_. Поведение Makefile зависит от переменных. Они могут быть заданы в /etc/make.conf или указаны при использовании make. Например, эта переменная указывает, что библиотеки для профилирования собирать не нужно:

# make -DNO_PROFILE target

Это соответствует настройке в /etc/make.conf:

NO_PROFILE=    true     #    Обход построения библиотек для профилирования

target указывает программе make на то, что нужно сделать, а Makefile определяет доступные цели. Некоторые цели используются в процессе построения для разбиения его на этапы.

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

Во-вторых, это позволяет использовать монтирование по NFS для обновления многих машин по сети согласно описанию в Отслеживание исходных текстов для нескольких машин.

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

Используйте следующую команду на машине с одним CPU, чтобы иметь до 4 одновременно работающих процессов. Опубликованные в списке рассылки практические замеры показывают, что в среднем это даёт наибольший выигрыш в производительности.

# make -j4 buildworld

На многопроцессорной машине попробуйте подобрать значение между 6 и 10, и посмотрите, как это отразится на скорости работы.

Если при выполнении команды make buildworld были заданы значения каких-либо переменных, то при выполнении make installworld нужно задать те же самые переменные. При этом -j нельзя использовать совместно с installworld.

Например, если выполнялась эта команда:

# make -DNO_PROFILE buildworld

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

# make -DNO_PROFILE installworld

В противном случае вторая команда попытается установить библиотеки для профилирования, которые не компилировались на этапе выполнения команды make buildworld.

21.6.4. Объединение файлов конфигурации

FreeBSD предоставляет утилиту mergemaster(8), которая является скриптом для оболочки Боурна и предназначена для определения разницы между конфигурационными файлами в каталоге /etc и конфигурационными файлами из дерева исходных текстов /usr/src/etc. Это является рекомендуемым способом синхронизации системных конфигурационных файлов с теми, что размещены в дереве исходных текстов.

Перед использованием mergemaster рекомендуется скопировать имеющийся каталог /etc в какое-нибудь безопасное место. -R задает выполнение рекурсивного копирования, а -p сохраняет даты и владельца файлов:

# cp -Rp /etc /etc.old

При запуске mergemaster строит временное корневое окружение, начиная с /, и заполняет его различными системными конфигурационными файлами. Затем эти файлы сравниваются с текущими установленными в системе. Файлы, которые имеют отличия, будут выданы в формате diff(1), где знак + означает добавленные или изменённые строки, а знак - означает строки, которые будут либо полностью удалены, либо заменены на новый файл. Обратитесь к страницам справочной системы по команде diff(1) для получения более полной информации о формате выдачи отличий в файлах.

Затем mergemaster выдаст каждый файл, в котором есть изменения, с вариантами действий: удалить новый файл, упоминаемый здесь как временный, установить временный файл в его неизменённом виде, объединить временный файл с установленным на данный момент, либо просмотреть результат ещё раз.

Выбор удаления временного файла укажет mergemaster оставить текущий файл без изменений и удалить его новую версию. Делать это не рекомендуется. Чтобы получить помощь в любое время, наберите ? в приглашении mergemaster. Если пользователь выбирает пропуск файла, запрос появится снова, после того как будут обработаны все остальные файлы.

Выбор установки немодифицированного временного файла приведёт к замене текущего файла новым. Для большинства немодифицированных файлов это является подходящим вариантом.

Выбор варианта с объединением файла приведёт к вызову текстового редактора, содержащего текст обоих файлов. Файлы можно объединить, просматривая оба файла на экране и выбирая те части из обоих, которые подходят для окончательного варианта. При сравнении файлов нажатие l выбирает содержимое слева, нажатие r выбирает содержимое справа. В окончательном варианте будет файл, состоящий из обеих частей, который и будет установлен. Этот вариант обычно используется для файлов, настройки в которых изменялись пользователем.

Выбор повторного просмотра результатов выдаст разницу между файлами.

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

21.6.5. Удаление устаревших файлов и библиотек

В ходе жизненного цикла разработки FreeBSD файлы с их содержимым иногда становятся устаревшими. Это может быть вызвано тем, что функциональность реализуется в другом месте, сменился номер версии библиотеки или файл был целиком удалён из системы. Такие устаревшие файлы, библиотеки и каталоги следует удалять вместе с обновлением системы. Это не даст захламить систему старыми файлами, которые занимают место на диске и на архивных носителях. Кроме того, если в старой библиотеке имеется проблема безопасности или стабильности, такую систему следует обновить до более новой библиотеки, чтобы предотвратить крахи, вызванные работой старой версии. Файлы, каталоги и библиотеки, которые признаны устаревшими, перечислены в /usr/src/ObsoleteFiles.inc. Для удаления устаревших файлов в процессе обновления системы следует пользоваться следующими инструкциями.

После выполнения make installworld и последующего mergemaster проверьте наличие устаревших файлов и библиотек:

# cd /usr/src
# make check-old

Если были найдены какие-либо устаревшие файлы, их можно удалить с помощью следующей команды:

# make delete-old

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

# make -DBATCH_DELETE_OLD_FILES delete-old

Аналогичного эффекта можно достичь, пропустив эти команды через yes:

# yes|make delete-old
Предупреждение

Удаление устаревших файлов приведёт к нарушению работы программ, которые всё ещё зависят от этих устаревших файлов. Это особенно верно для старых библиотек. В большинстве случаев программы, порты или библиотеки, использующие такую старую библиотеку, нужно перекомпилировать перед выполнением make delete-old-libs.

Программы для проверки наличия зависимостей от совместно используемых библиотек включают в себя sysutils/libchk и sysutils/bsdadminscripts.

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

/usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5
/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5

Для решения этих проблем выясните, какой именно порт установил данную библиотеку:

# pkg which /usr/local/lib/libtiff.so
  /usr/local/lib/libtiff.so was installed by package tiff-3.9.4
# pkg which /usr/local/lib/libXext.so
  /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1

Затем данный порт нужно удалить, пересобрать и переустановить. Для автоматизации этого процесса можно использовать ports-mgmt/portmaster. После того как все порты пересобраны и более не используют старые библиотеки, удалите эти старые библиотеки с помощью следующей команды:

# make delete-old-libs

Если что-то работает неправильно, можно с лёгкостью перестроить конкретную часть системы. Например, если файл /etc/magic был случайно удалён в процессе обновления или переноса /etc, то команда file перестанет работать. В таком случае это можно исправить вот так:

# cd /usr/src/usr.bin/file
# make all install

21.6.6. Вопросы общего характера

Нужно ли полностью перестраивать систему при каждом изменении?

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

src/games/cribbage/instr.c
src/games/sail/pl_main.c
src/release/sysinstall/config.c
src/release/sysinstall/media.c
src/shared/mk/bsd.port.mk

то перестраивать всю систему возможно незачем. Вместо этого можно перейти в соответствующие подкаталоги и выдать команду make all install. Однако если меняется что-то важное, например, src/lib/libc/stdlib, то вы должны перестроить всю систему.

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

Почему прерывается компиляция с большим количеством ошибок по сигналу 11 (или с другим номером сигнала)?

Как правило, это говорит о проблемах с оборудованием. Построение системы является эффективным стресс-тестом для оборудования, в особенности памяти. Явным указателем на это является то, что при перезапуске make процедура построения прекращается в различные моменты времени.

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

Можно ли удалить /usr/obj после окончания?

В этом каталоге содержатся все объектные файлы, которые создаются во время фазы компиляции. Обычно одним из первых шагов в процессе make buildworld является удаление этого каталога, чтобы начать заново. Сохранение /usr/obj после окончания имеет мало смысла, а его удаление освободит приблизительно 2 ГБ дискового пространства.

Могут ли быть продолжены прерванные процессы построения?

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

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

# cd /usr/src
# make -DNO_CLEAN all

Если в выводе make buildworld появляется такое сообщение:

--------------------------------------------------------------
Building everything..
--------------------------------------------------------------

то делать так вероятно достаточно безопасно.

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

Можно ли ускорить сборку мира?

Ускорить процесс сборки мира может несколько действий. Например, весь процесс можно выполнять в однопользовательском режиме. Однако, это не позволит пользователям иметь доступ к системе, пока этот процесс не завершится.

Тщательный подход к проектированию файловой системы или использование датасетов ZFS позволит почувствовать разницу. Задумайтесь о размещении /usr/src и /usr/obj на различных файловых системах. По возможности размещайте файловые системы на различных дисках и дисковых контроллерах. При монтировании /usr/src используйте параметр noatime, который отключает запись информации о времени доступа к файлу. Если /usr/src не расположен на собственной файловой системе, подумайте о перемонтировании /usr с noatime.

Файловая система, на которой располагается /usr/obj, может быть смонтирована (или перемонтирована) с параметром async. Это приведёт к тому, что операции записи на диск будут выполняться асинхронно. Другими словами, запись будет завершаться немедленно, но данные записываться на диск несколькими секундами позже. Это позволит объединять операции записи и приведёт к значительному приросту производительности.

Файловую систему с /usr/obj можно смонтировать с async для записи на диск в асинхронном режиме. В этом случае операции записи завершаются мгновенно, а сами данные записываются на диск через несколько секунд. Это позволяет писать кластеризованно, что может дать значительный прирост производительности.

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

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

Выключите генерацию профилирующего кода, установив "NO_PROFILE=true" в файле /etc/make.conf.

Передайте утилите make(1) параметр -jn для запуска параллельно нескольких процессов. Обычно это помогает вне зависимости от того, сколько процессоров установлено в машине.

Что делать, если что-то пошло не так?

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

# chflags -R noschg /usr/obj/usr
# rm -rf /usr/obj/usr
# cd /usr/src
# make cleandir
# make cleandir

Да, команду make cleandir действительно нужно выполнять дважды.

После этого повторите весь процесс снова, начиная с make buildworld.

Если у вас всё ещё есть проблемы, пришлите текст ошибки и вывод команды uname -a в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD. Будьте готовы ответить на другие вопросы о конфигурации вашей системы!

21.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.

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

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

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


Изменено: 9 марта 2024 г. by Danilo G. Baio