path: root/documentation/content/ja/books/handbook/cutting-edge/_index.adoc

---
title: 第16章 FreeBSD のアップデートとアップグレード
part: パートIII. システム管理
prev: books/handbook/l10n
next: books/handbook/partiv
description: freebsd-update もしくは Git を使った FreeBSD システムを最新の状態に更新する方法、ベースシステム全体を再構築しインストールする方法などの説明
tags: ["updating", "upgrading", "documentation", "FreeBSD-STABLE", "FreeBSD-CURRENT", "Security Patches"]
showBookMenu: true
weight: 20
path: "/books/handbook/cutting-edge/"
aliases: ["/ja/books/handbook/updating-upgrading-freebsdupdate/","/ja/books/handbook/updating-upgrading-documentation/","/ja/books/handbook/current-stable/","/ja/books/handbook/makeworld/","/ja/books/handbook/small-lan/"]
---

[[updating-upgrading]]
= FreeBSD のアップデートとアップグレード
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 16
: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-update もしくは Git を使った FreeBSD システムの更新方法
* インストールされているシステムと、変更が行われていない状態との比較方法
* Git またはドキュメント用の ports を使って、 インストールされているドキュメントを最新版にアップデートする方法
* 2 つの開発ブランチ、FreeBSD-STABLE と FreeBSD-CURRENT の違いについて
* ベースシステム全体を再構築しインストールする方法

この章を読む前に、以下の準備をしましょう。

* ネットワーク接続の適切な設定 (crossref:advanced-networking[advanced-networking,高度なネットワーク])
* サードパーティ製のソフトウェアのインストール方法の習得 (crossref:ports[ports,アプリケーションのインストール - packages と ports])

[NOTE]
====
この章を通じて、FreeBSD のソースコードのダウンロードやアップデートに `git` が使われています。
必要に応じて package:devel/git[] port または package が使われることもあります。
====

[[updating-upgrading-freebsdupdate]]
== FreeBSD Update

すみやかにセキュリティパッチを適用し、 オペレーティングシステムをアップグレードして、 最新のリリースに保つことは、システム管理における重要な側面です。
これらの処理を行うために FreeBSD には `freebsd-update` と呼ばれるユーティリティが用意されています。

このユーティリティを用いると、FreeBSD のセキュリティおよび eratta アップデートをバイナリによって行うことができます。
手動でパッチもしくは新しいカーネルをコンパイルし、インストールする必要はありません。
バイナリアップデートは、セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。
https://www.FreeBSD.org/ja/security/[https://www.FreeBSD.org/ja/security/] には、サポートが行われているリリースや保守終了予定日の一覧があります。

このユーティリティは、マイナーリリースであったり、他のリリースブランチへのアップグレードにも対応しています。
新しいリリースにアップデートする前に、アップデートしようとしているリリースのアナウンスに目を通し、重要な情報がないかどうかを確認してください。
リリースのアナウンスは https://www.FreeBSD.org/ja/releases/[https://www.FreeBSD.org/ja/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:mergemaster[8] と同様 man:diff[1] パッチの連続ですが、選択肢は少なく、マージを承認するか、エディタを起動するか、`freebsd-update` を中断するかどうかを選んでください。
もし、心配な点があれば、[.filename]#/etc# をバックアップしてからマージを承認してください。
`mergemaster` の詳細な情報については、man:mergemaster[8] で確認してください。

[.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 のセキュリティパッチがダウンロードされ、インストールされます。
最初のコマンドは、未対応のパッチがあるかどうかを調べます。
もし未対応のパッチがある場合には、パッチが当てられた際に変更されるファイルのリストが作成されます。
2 番目のコマンドはパッチを適用します。

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

アップデートによってカーネルにパッチが適用された場合には、システムを再起動して新しいカーネルで起動する必要があります。
もし、実行中のバイナリにパッチが適用された場合には、パッチが当てられたバイナリが使われるように、影響するアプリケーションを再起動する必要があります。

[NOTE]
====
通常、ユーザはシステムを再起動する必要があります。
カーネルアップデートによりシステムの再起動が必要かどうかを調べるには、`freebsd-version -k` と `uname -r` を実行してください。
これら 2 つのコマンドの結果が異なる場合には、システムを再起動してください。
====

毎日一度アップデートがないかどうかを自動的に確認するように設定するには、 以下のエントリを [.filename]#/etc/crontab# に追加してください。

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

パッチが存在すると、自動的にダウンロードされますが、適用はされません。
``root``宛てにメールで、ダウンロードされたパッチを確認し、`freebsd-update install` とともに手動でインストールする必要のあることが通知されます。

うまく行かなかった場合には、`freebsd-update` を以下のように実行すると、最後の変更までロールバックできます。

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

カーネルまたはカーネルモジュールがアップデートされた場合には、 完了後にもう一度システムを再起動して、 影響のあったバイナリを再起動してください。

`freebsd-update` ユーティリティが自動的にアップデートするカーネルは [.filename]#GENERIC# のみです。
カスタムカーネルをインストールしている場合には、`freebsd-update` によりインストールした後、カーネルを再構築し、もう一度インストールする必要があります。
デフォルトのカーネルの名前は _GENERIC_ です。
man:uname[1] コマンドを使ってインストールされているかどうかを確認できます。

[NOTE]
====
[.filename]#GENERIC# カーネルを、常に [.filename]#/boot/GENERIC# に置いておいてください。
さまざまな問題を解決する際や、バージョンをアップグレードする際に助けとなります。
[.filename]#GENERIC# カーネルを用意する方法については、<<freebsd-update-custom-kernel-9x>> を参照してください。
====

[.filename]#/etc/freebsd-update.conf# のデフォルトの設定を変更しない限り、`freebsd-update` は、他の更新と共にカーネルソースをアップデートします。
新しいカスタムカーネルの再構築と再インストールは、通常通り行うことができます。

`freebsd-update` は、常にカーネルをアップデートするとは限りません。
`freebsd-update install` によってカーネルソースが変更されなかった場合には、カスタムカーネルを再構築する必要はありません。
しかしながら `freebsd-update` は、[.filename]#/usr/src/sys/conf/newvers.sh# を常にアップデートします。
これは、現在のシステムのパッチレベルを `uname -r` が `-p` で表示する時にこのファイルが参照されます。
そのため、何も変更されていない場合でも、カスタムカーネルを再構築することにより、`uname` がシステムの正確なパッチレベルを報告するようになります。
各システムにインストールされているアップデートをすばやく把握できるようになるので、特に複数のシステムを管理するときに助けとなります。

[[freebsdupdate-upgrade]]
=== メジャーおよびマイナーバージョンのアップグレード

FreeBSD のマイナーバージョン間のアップグレード、たとえば、FreeBSD 9.0 から FreeBSD 9.1 へのアップグレードは、_マイナーバージョン_ アップグレードと呼ばれます。
_メジャーバージョン_ アップグレードは、FreeBSD 9.X から FreeBSD 10.X へのアップグレードといった、FreeBSD のメジャーバージョンが変わるようなアップグレードのことです。
どちらのアップグレードも、`freebsd-update` のターゲットにリリース番号を指定する事で実行できます。

[NOTE]
====
カスタムカーネルを使っているシステムでは、アップグレードを行う前に [.filename]#GENERIC# カーネルが、[.filename]#/boot/GENERIC# に置かれている事を確認してください。
[.filename]#GENERIC# カーネルを用意する方法については、<<freebsd-update-custom-kernel-9x>> を参照してください。
====

以下のコマンドを実行すると、FreeBSD 9.0 のシステムを FreeBSD 9.1 にアップグレードします。

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

コマンドを実行すると、`freebsd-update` は設定ファイルと現在のシステムを評価し、 アップデートするために必要な情報を収集します。
画面には、どのコンポーネントが認識され、どのコンポーネントが認識されていないといったリストが表示されます。
たとえば以下のように表示されます。

[source,shell]
....
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` はアップグレードに必要なすべてのファイルをダウンロードします。
何をインストールし、どのように進むかといった質問をされることもあります。

カスタムカーネルを使っていると、上記のステップ中に以下のような警告が表示されます。

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

この時点ではこの警告を無視してもかまいません。
アップデートされた [.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]#/boot/loader.conf# の機能を用いて、[.filename]#GENERIC# に読み込んでください。
アップグレードプロセスが終わるまでは、重要ではないサービスを無効にするとともに、必要のないディスクやネットワークのマウントなども避けることが推奨されています。
====

アップデートされたカーネルでコンピュータを再起動してください。

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

システムがオンラインに戻ったら、以下のコマンドを使って `freebsd-update` を再び実行してください。
アップデートプロセスの状態は保存されているので、`freebsd-update` を実行すると、古い共有ライブラリおよびオブジェクトファイルを削除するステップに進みます。

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

[NOTE]
====
使用しているライブラリのバージョン番号の付けられ方によって、 3 つのインストールフェーズが 2 つになる場合もあります。
====

アップグレードはこれで終了です。
もしメジャーアップグレードを行った場合には、<<freebsdupdate-portsrebuild>> で説明されているようにすべての ports および package を再構築してください。

[[freebsd-update-custom-kernel-9x]]
==== FreeBSD 9.X 以降のシステムにおけるカスタムカーネル

`freebsd-update` を使う前に、[.filename]#GENERIC# カーネルが [.filename]#/boot/GENERIC# に置かれていることを確認してください。
ただ一度だけカスタムカーネルを構築したのであれば、[.filename]#/boot/kernel.old# は [.filename]#GENERIC# カーネルそのものです。
このディレクトリの名前を [.filename]#/boot/GENERIC# へと変更してください。

もし、2 回以上カスタムカーネルを構築した後であったり、カスタムカーネルを構築した回数がわからなければ、現在のオペレーティングシステムのバージョンの [.filename]#GENERIC# カーネルを入手してください。
コンピュータへの物理的なアクセスが可能であれば、インストールメディアから [.filename]#GENERIC# カーネルをインストールできます。

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

別な方法としては、 [.filename]#GENERIC# カーネルをソースから再構築して、 インストールしてください。

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

`freebsd-update` がこのカーネルを [.filename]#GENERIC# カーネルとして認識するために、[.filename]#GENERIC# コンフィグレーションファイルは、とにかく変更してはいけません。
また、特別なオプションを指定しないで構築してください。

`freebsd-update` は、[.filename]#/boot/GENERIC# が存在する事だけを必要とするので、[.filename]#GENERIC# カーネルで再起動する必要はありません。

[[freebsdupdate-portsrebuild]]
==== メジャーバージョンアップグレード後の package のアップグレード

一般的に、マイナーバージョンアップグレードの後では、インストールされているアプリケーションは、問題なく動作するでしょう。
メジャーバージョンが異なるとアプリケーションバイナリーインタフェース (ABI) が異なるため、サードパーティ製のアプリケーションの多くは動作しなくなるでしょう。
メジャーバージョンアップグレード後には、インストールされているすべての packages, ports をアップグレードする必要があります。
package は、`pkg upgrade` を使ってアップグレードできます。
インストールされている ports をアップグレードする場合には、package:ports-mgmt/portmaster[] といったユーティリティを使ってください。

すべての package の強制的なアップグレードでは、バージョン番号が上がらない package に対しても、リポジトリから最新のバージョンで、インストールされている package を置き換えます。
FreeBSD のメージャーバージョンが変わるようなアップグレードでは、ABI のバージョンも変わるため、このようなアップグレードが必要になります。
強制的なアップグレードを行うには、以下のように実行してください。

[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-update` を用いて、インストールされている FreeBSD の状態と、正しく動作することが分かっている状態とを比較できます。
このコマンドは、現在のシステムのユーティリティ、ライブラリ、設定ファイルを評価するので、組み込みの侵入検知システム (IDS) として使うことができます。

[WARNING]
====
このコマンドは、package:security/snort[] のような本当の IDS の置き換えになるものではありません。
`freebsd-update` はデータをディスクに保存するので、不正な変更が行われる可能性があります。
`kern.securelevel` と、`freebsd-update` のデータを使用しないときに、読み取りのみの許可属性に設定されているファイルシステムに置くことで、不正な変更の可能性を低くできますが、よりよい解決方法は、DVD または安全に保存されている外部 USB ディスクのような安全なディスクとシステムを比較することです。
組み込まれているユーティリティを用いた、別の方法による IDS 機能については、crossref:security[security-ids,FreeBSD バイナリによる検出] の節をご覧ください。
====

比較を行うには、 結果の出力先のファイル名を指定してください。

[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` によりアップデートされるため、変更されます。
このような特別なファイルやディレクトリを除外するには、それらを [.filename]#/etc/freebsd-update.conf# の `IDSIgnorePaths` オプションに追加してください。

[[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/[Documentation Portal]) から入手できますが、 FreeBSD ウェブサイト、ハンドブック、FAQ および文書の最新版をローカルに用意しておくと便利です。

この章では、ソースまたは Ports Collection を使って、ローカルの FreeBSD ドキュメントを最新に保つ方法を説明します。

ドキュメントを編集したり、ドキュメントの誤りを報告する方法については、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門 (extref:{fdp-primer}[FreeBSD Documentation Project Primer]) をご覧ください。

[[updating-installed-documentation]]
=== ソースから FreeBSD ドキュメントをインストールする

ソースから FreeBSD ドキュメントを構築するのに必要なツールは、FreeBSD のベースシステムには含まれていません。
必要なツールは、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門で extref:{fdp-primer}[説明されているステップ, overview-quick-start] に従ってインストールしてください。

インストールしたら、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-CURRENT をソースからほぼ毎日コンパイルしている人はたくさんいますが、短い期間ではコンパイルさえできない状態になっている時期もあります。
これらの問題は可能な限り迅速に解決されますが、FreeBSD-CURRENT が不幸をもたらすか、それとも新しい機能をもたらすかは、まさにソースコードを同期した瞬間によるのです!

FreeBSD-CURRENT は、次の 3 つの重要なグループを対象としています。

. ソースツリーのある部分に関して活発に作業している FreeBSD コミュニティのメンバ。
. 活発にテストしている FreeBSD コミュニティのメンバ。 彼らは、種々の問題を解決するのに時間を惜しまない人々であり、 さまざまな変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている人々でもあり、 パッチも提出します。
. さまざまな事に目を向け、 参考のために最新のソースを使いたいと思っていたり、 時々コメントやコードを寄稿したいと考えているユーザ。

FreeBSD-CURRENT は、次のリリースの前に、最も早く新しい機能を入手する手段として、期待しては__いけません__。
リリース前の機能は十分にテストされていないため、バグを含んでいる可能性が大いにあるためです。
また、バグを修正するための素早い方法でもありません。
いかなるコミットは、元からあるバグを修正するのと同じく、新しいバグを生み出すおそれがあります。
FreeBSD-CURRENT には "公式のサポート" はありません。

FreeBSD-CURRENT を追いかけるには

. {freebsd-current} と {dev-commits-src-main} メーリングリストに加わってください。
さまざまな人がシステムの現在の状態について述べているコメントを見たり、FreeBSD-CURRENT の現在の状態に関する重要な情報を見逃さないために、 _必須の_ ことです。
+
{dev-commits-src-main} メーリングリストでは、それぞれの変更についての commit ログが記録されています。
また、それに関して起こり得る副作用の情報を得ることができますので、参加する価値のあるメーリングリストです。
+
これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。
FreeBSD-CURRENT だけでなく、ソースツリー全体の変更点を追いかけるのであれば、 {dev-commits-src-all} メーリングリストを購読してください。
. FreeBSD-CURRENT のソースを同期してください。
通常は `git` を使って FreeBSD Git リポジトリの `main` ブランチから -CURRENT コードをチェックアウトしてください (crossref:mirrors[git,「Git を使う」] を参照してください)。
. リポジトリのサイズが大きいため、興味のある部分や、パッチを当てる部分のソースのみを同期するユーザもいます。
しかしながら、ソースからオペレーティングシステムをコンパイルしようと思っているユーザは、一部分だけではなく、FreeBSD-CURRENT の _すべて_ をダウンロードする必要があります。
+
FreeBSD-CURRENT をコンパイルする前に [.filename]#/usr/src/Makefile# を注意深く読み、<<makeworld>> に書かれている手順に従ってください。
{freebsd-current} と [.filename]#/usr/src/UPDATING# を読めば、次のリリースへ向けて移ってゆくに当たって、ときどき必要となる既存システムからの新システムの構築手順についての最新情報が得られるでしょう。
. アクティブになってください! FreeBSD-CURRENT のユーザには、 拡張やバグ潰しに関して提案することが勧められています。 コードを伴う提案はいつでも歓迎されます!

[[stable]]
=== FreeBSD-STABLE を使う

FreeBSD-STABLE とは定期的に公開されるリリースを作成するための開発ブランチです。
このブランチに加えられる変更は FreeBSD-CURRENT よりゆっくりで、原則として、事前に FreeBSD-CURRENT で試験ずみであるという特徴があります。
ただ__そうであっても__、これは開発用ブランチの一つであり、ある時点における FreeBSD-STABLE のソースがどんな場合にも使えるものであるとは限りません。
このブランチはもう一つの開発の流れというだけであって、エンドユーザ向けのものではありません。
もし試験をする資源的な余裕がない場合は、代わりに最新の FreeBSD リリースを使ってください。

FreeBSD の開発プロセスに興味があったり、それに対する貢献を考えていて、特にそれが次回の FreeBSD のリリースに関係するものであるなら FreeBSD-STABLE を追うことを考えると良いでしょう。

FreeBSD-STABLE ブランチはいつもコンパイルができ、安定に動作すべきですが、それが保証されているというわけではありません。
FreeBSD-STABLE のユーザは FreeBSD-CURRENT よりも多いため、FreeBSD-CURRENT で発見されなかったバグが FreeBSD-STABLE で発見され、ときどきそれが問題となることがあるのは避けることができません。
このような理由から、盲目的に FreeBSD-STABLE を追いかけるべきではありません。
特に、開発環境もしくはテスト環境でコードを十分に試験せずに、プロダクション品質が要求されるサーバを FreeBSD-STABLE にアップグレードしては__いけません__。

FreeBSD-STABLE を追いかけるには

. FreeBSD-STABLE の構築に関連する事柄や、その他の注意すべき点 に関する情報を得るために、 {freebsd-stable} メーリングリストに加わってください。
また開発者は議論の余地がある修正や変更を考えている場合に、このメーリングリストで公表し、提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。
+
追いかけているブランチに関連する git メーリングリストに参加してください。
たとえば、{betarel-current-major}-STABLE ブランチを追いかけているユーザは {dev-commits-src-branches} メーリングリストに参加してください。
このリストでは、変更がなされるごとに作成される commit log やそれに伴う起こりうる副作用についての情報が記録されています。
+
これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。
ソースツリー全体の変更点を追いかけるには、 {dev-commits-src-all} メーリングリストを購読してください。
. 新しい FreeBSD-STABLE システムをインストールするには、 crossref:mirrors[mirrors,ミラーサイト] から最近の FreeBSD-STABLE リリースをインストールするか、毎月公開されている FreeBSD-STABLE からビルドされたスナップショットを使ってください。
スナップショットの詳細については、link:https://www.FreeBSD.org/ja/snapshots/[www.freebsd.org/ja/snapshots] をご覧ください。
+
既に FreeBSD が動いているシステムを FreeBSD-STABLE にアップグレードするには、`git` を使って、希望する開発ブランチのソースをチェックアウしてください。
`stable/9` といったブランチ名は、link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng] で説明されています。
. FreeBSD-STABLE をコンパイルしたり FreeBSD-STABLE へとアップグレードする前に、 [.filename]#/usr/src/Makefile# を注意深く読み、 <<makeworld>> に書かれている手順に従ってください。
{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-番号の比較は、FreeBSD プロジェクトで作成されたブランチ
 (`main`, `stable/XX` および `releng/XX`) でのみ有効です。
ローカルブランチでは、親ブランチのコミットと n-番号が重複してしまいます。
<.> n-番号は、ハッシュ値が含まれるようになった git リポジトリの使用開始からのコミットを数えたものです。
<.> チェックアウトしたツリーのハッシュ値。
<.> `-dirty` が表示されることがあります。
変更点がコミットされていないツリーでカーネルが構築された場合に表示されます。
この例では、チェックアウトから変更なく FRED カーネルが構築されたため、出力されていません。

`git rev-list` コマンドを使って、ハッシュ値に対応する n-番号を調べることができます。
以下はその例です。
[source,shell]
....
% git rev-list --first-parent --count 031260d64c18 <.>
247514 <.>
....
<.> 変換する git ハッシュ値 (ここでは先の例のハッシュ値を使用しています)
<.> n-番号

この数字は通常それほど重要ではありません。
しかしながら、バグの修正がコミットされた時には、この数字を使うことで、使用しているシステムでバグが修正されているかどうかを簡単に調べることができます。
ハッシュ値は簡単に目にする識別子である一方で n-番号はそうではありません。
そのため、開発者は通常 n-番号ではなくコミットのハッシュ値
(または、ハッシュ値を含む URL) を参照します。
セキュリティ勧告および errata 情報では n-番号が示されており、使用しているシステムの番号と直接比較できます。
`git rev-list` コマンドは、レポジトリのリビジョンをすべてカウントしますが、git の shallow clone はその情報を取得しないため、shallow clone を使用しなければならない場合には、n-番号は信頼できません。

[[makeworld]]
== ソースを用いた FreeBSD のアップデート

ソースをコンパイルしてFreeBSD をアップデートする方法は、 バイナリを用いたアップデートに比べ、いくつもの利点があります。 特定のハードウェアをうまく利用するためのオプションを設定してコードを構築できます。
ベースシステムの特定の箇所の設定をデフォルトの設定から変更したり、必要がない部分を完全に削除して構築することもできます。
システムを構築することによるアップデートは、バイナリアップデートをインストールするだけのアップデートに比べ時間がかかりますが、利用環境に合わせた FreeBSD を作成するような完全なカスタマイズが可能です。

[[updating-src-quick-start]]
=== クィックスタート

以下は FreeBSD をソースから構築してアップデートする典型的な方法についてのクイックリファレンスです。
その後の節では、各プロセスをより詳細に説明します。

[WARNING]
====
man:mergemaster[8] から man:etcupdate[8] に移行する際に、初めて man:etcupdate[8] を実行すると、変更点が不適切にマージされ、衝突が起きてしまうことがあります。
これを避けるには、ソースを更新して新しく buildworld を行う *前に* 以下のステップを行ってください。

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

<.> [.filename]#/etc# ファイルを保存するデータベースをブートストラップしてください。
詳細については、 man:etcupdate[8] を参照してください。

<.> ブートストラップ後、差分を確認してください。
不必要なローカルでの変更点をなくし、将来的なアップデートにおいて、衝突が起きる可能性が低くなるようにしてください。
====

[.procedure]
====
* アップデートおよびビルド
+
[source,shell]
....
# git pull /usr/src  <.>
/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      <.>
....

<.> 最新版のソースを入手してください。 ソースの入手およびアップデートに関する情報については <<updating-src-obtaining-src>> をご覧ください。

<.> ソースの構築の前後で必要となる手動の作業について、 [.filename]#/usr/src/UPDATING# を確認してください。

<.> ソースが置かれているディレクトリに移動してください。

<.> world (カーネルを除くすべて) をコンパイルしてください。

<.> カーネルをコンパイルしてインストールしてください。 ここに書かれているコマンドは、`make buildkernel installkernel` と同じです。

<.> 新しいカーネルを使うため、 システムを再起動してください。

<.> installworld を行う前に、[.filename]#/etc/# に置かれている設定ファイルのアップデートとマージを行ってください。

<.> ソースが置かれているディレクトリに移動してください。

<.> 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] を使ってアップデートできることを示しています。

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

このディレクトリをアップデートしていない期間が長いと、アップデートのプロセスには時間がかかります。
このプロセスが終わると、ソースコードは最新となり、次節以降で説明する構築のプロセスを実行できます。

.ソースコードの入手
[NOTE]
====
`fatal: not a git repository` と出力された場合には、ファイルがなかったり、別な方法によりインストールされているので、新しくソースコードをチェックアウトする必要があります。

[[updating-src-obtaining-src-repopath]]
.FreeBSD のバージョンおよびリポジトリブランチ
[cols="1,1,1", options="header"]
|===
| uname -r の出力
| リポジトリパス
| 説明

|`_X.Y_-RELEASE`
|`releng/_X.Y_`
|このリリースバージョンに対する重大なセキュルティへの対応およびバグの修正パッチのみが適用されています。 このブランチは、ほとんどのユーザに推奨されます。

|`_X.Y_-STABLE`
|`stable/_X_`
|

リリースバージョンに対し、そのブランチにおけるすべての開発の成果が反映されたものです。
_STABLE_ では、Applications Binary Interface (ABI) は変更されないため、このブランチのシステムであれば、以前のバージョンでコンパイルされたソフトウェアを実行できます。
たとえば、FreeBSD 10.1 で実行するようにコンパイルされたソフトウェアは、その後構築された FreeBSD 10-STABLE 上でも実行できます。

STABLE ブランチは、 時期によってはユーザに影響するようなバグや非互換性を持つことがあります。 これらは通常すぐに修正されます。

|`_X_-CURRENT`
|`main`
|リリースが行われていない最新の FreeBSD の開発バージョンです。 CURRENT ブランチは大きなバグや非互換があることもあるので、 高度な知識を持ったユーザのみ使用が推奨されます。
|===

man:uname[1] を使って FreeBSD のバージョンを確認してください。

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

<<updating-src-obtaining-src-repopath>> から分かるように、`10.3-RELEASE` のアップデートのためのソースコードのパスは、`releng/10.3` です。
このパスは、ソースコードをチェックアウトする時に使います。

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

<.> この古いディレクトリを、 邪魔にならないように移動してください。 このディレクトリ以下に対して変更を行ってなければ、 削除しても構わないでしょう。
<.> リポジトリの URL に <<updating-src-obtaining-src-repopath>> に記載されているパスを追加します。 3 番目のパラメータには、 ローカルシステム上でソースコードが置かれるディレクトリを指定します。
====

[[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]
====
以下は 4 つのジョブで world とカーネルを構築する例です。

[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# カーネルには、最も良く使われるデバイスドライバやオプションが含まれています。
しかしながら、特定の目的に合わせてデバイスドライバやオプションを削除したり追加するためには、カスタムカーネルを構築することが有用であったり、必要となることがあります。

たとえば、極端に RAM が制限されているような小さな組み込みのコンピュータを開発しているユーザであれば、 必要のないデバイスドライバやオプションを削除することで、 カーネルを少しでも小さくできるでしょう。

カーネルのコンフィグレーションファイルは、 [.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` が完了したら、 新しいカーネルと world をインストールしてください。

[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] は、[.filename]#/etc/# 以下のファイルのように installworld のプロセスで更新されないファイルをアップデートするツールです。
このツールは、ローカルにあるファイルに対する変更点を 3-way マージでアップデートします。
man:mergemaster[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] に移行する際に、
最初に man:etcupdate[8] を実行すると、不適切に変更点がマージされ、誤った衝突が起こる可能性があります。
これを避けるには、ソースを更新して新しく buildworld を行う *前に* 以下のステップを行ってください。

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

<.> [.filename]#/etc# ファイルを保存するデータベースをブートストラップしてください。
詳細については、 man:etcupdate[8] を参照してください。

<.> ブートストラップ後、差分を確認してください。
不必要なローカルでの変更点をなくし、将来的なアップデートにおいて、衝突が起きる可能性が低くなるようにしてください。
====

[[updating-src-completing-merge-mergemaster]]
==== man:mergemaster[8] を用いた設定ファイルのマージ

man:mergemaster[8] を用いることで、システムの設定ファイルに行われている変更を、これらのファイルの新しいバージョンにマージできます。
man:mergemaster[8] は、設定ファイルのアップデートで推奨されている man:etcupdate[8] の代価のツールです。
`-Ui` オプションを使って man:mergemaster[8] を実行すると、 ユーザが手を加えていないファイルのアップデートおよび新しく追加されたファイルのインストールを自動的に行います。

[source,shell]
....
# mergemaster -Ui
....

ファイルのマージを手動で行う必要がある時は、ファイルの中で残す箇所の選択を対話的におこなうようなインタフェースが表示さます。
詳細については、man:mergemaster[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]
====

古いファイルとディレクトリのすべてを削除しても問題ないことを確認したら、コマンドに `BATCH_DELETE_OLD_FILES` を設定することで、各ファイルを削除する際に kbd:[y] および kbd:[Enter] を押さなくても済むようにできます。
以下はその例です。

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

====

[[updating-src-completing-restart]]
==== アップデート後の再起動

コンピュータを再起動して、すべての変更を反映させることが、 アップデートの最後におこなう作業です。

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

[[small-lan]]
== 複数のマシンで追いかける

複数のコンピュータで同じソースツリーを追いかけていて、全部のマシンにソースをダウンロードして全部を再構築するのは、ディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いです。
解決策は 1 つのマシンに仕事のほとんどをさせ、残りのマシンは NFS 経由でそれをマウントする、というものです。
このセクションではそのやり方を概観します。NFS の使い方の詳細については、crossref:advanced-networking[network-nfs,「NFS」] をご覧下さい。

まず初めに、同じバイナリで動かそうとするマシンたちを決めます。
このマシンたちのことを__ビルドセット__と呼びます。
それぞれのマシンはカスタムカーネルを持っているかもしれませんが、同じユーザランドバイナリを動かそうというのです。
このビルドセットから、 __ビルドマシン__となるマシンを 1 台選びます。
ベースシステムとカーネルを構築するのはこのマシンになります。
理想的には、このマシンは `make buildworld` と `make buildkernel` を実行するのに十分な CPU を持った速いマシンであるべきです。

_テストマシン_ となるべきマシンも選んでください。
更新されたソフトウェアを使う前にそのマシンでテストするのです。
テストマシンはかなり長い時間落ちていても だいじょうぶなマシン__であったほうがいいでしょう__。
ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。

このビルドセットのマシンはすべて [.filename]#/usr/obj# と [.filename]#/usr/src# をビルドマシンから FTP 経由でマウントする必要があります。
ビルドセット自体が複数ある場合は、[.filename]#/usr/src# はひとつのビルドマシン上にあるべきです。
他のマシンからはそれを NFS マウントするようにしましょう。

ビルドセットのすべてのマシン上の [.filename]#/etc/make.conf# と [.filename]#/etc/src.conf# がビルドマシンと一致していることを確認してください。
つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしているベースシステムを全部ビルドしなければならないということです。
また、各ビルドマシンは [.filename]#/etc/make.conf# にそれぞれのビルドマシンのカーネル名を `KERNCONF` で指定し、ビルドマシンは自分自身のカーネルから順に全部のカーネル名を `KERNCONF` にリストアップしてください。
ビルドマシンは各マシンのカーネル設定ファイルを [.filename]#/usr/src/sys/arch/conf# に持っていなければなりません。

ビルドマシンにて、<<makeworld>> に書いてあるようにカーネルとベースシステムを構築してください。
でも、まだビルドマシンにはインストールしないでください。
そのかわり、ビルドしたカーネルをテストマシンにインストールしてください。
FTP 経由で [.filename]#/usr/src# および [.filename]#/usr/obj# をテストマシンにマウントしてください。
その後、`shutdown now` を実行してシングルユーザモードに移行し、新しいカーネルとベースシステムをインストールし、いつもするように `mergemaster` を実行してください。
終わったら、再起動して通常のマルチユーザ動作に戻します。

テストマシンにあるものすべてがちゃんと動いている確信が得られたら、同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。

ports ツリーにも同じ方法が使えます。
最初のステップは、ビルドセットのすべてのマシンが NFS 経由で [.filename]#/usr/ports# をマウントすることです。
そして、distfiles を共有するように [.filename]#/etc/make.conf# を設定します。
NFS マウントによってマップされる `root` ユーザが何であれ、`DISTDIR` はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。
ports をローカルでビルドする場合には、各マシンは `WRKDIRPREFIX` を自分のマシンのビルドディレクトリに設定しなければなりません。
また、ビルドシステムが packages をビルドしてビルドセットのコンピュータに配布するのであれば、`DISTDIR` と同じようにビルドシステム上の `PACKAGES` ディレクトリも設定してください。