From 12f81ec349b2c5e85f06fb4402d3a82328bf7c83 Mon Sep 17 00:00:00 2001 From: Ryusuke SUZUKI Date: Thu, 17 Aug 2017 08:07:42 +0000 Subject: [PATCH] - Merge the following from the English version: r50201 -> r50602 head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml --- .../books/handbook/cutting-edge/chapter.xml | 1428 +++++------------ 1 file changed, 387 insertions(+), 1041 deletions(-) diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml index d1a68e07be..4299d1fc2e 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml @@ -3,7 +3,7 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: r50201 + Original revision: r50602 $FreeBSD$ --> /etc をバックアップしてからマージを承認してください。 mergemaster の詳細な情報については、 - で確認してください。 + &man.mergemaster.8; で確認してください。 # Directory in which to store downloaded updates and temporary # files used by &os; Update. @@ -961,8 +961,8 @@ before running "/usr/sbin/freebsd-update install" 以下は、上記の変数を用いてハンガリー語のドキュメントを PDF 形式でインストールする方法です。 - &prompt.root; cd /usr/ports/misc/freebsd-doc-hu -&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean + &prompt.root; cd /usr/ports/misc/freebsd-doc-hu +&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean に書かれている手順を使って、 ドキュメンテーション package または port @@ -1115,1120 +1115,466 @@ before running "/usr/sbin/freebsd-update install" - - - &os.stable; を使う - - 訳: &a.jp.iwasaki; - - &os.stable; - とは定期的に公開されるリリースを作成するための開発ブランチです。 - このブランチに加えられる変更は &os.current; よりゆっくりで、 - 原則として、事前に &os.current; で試験ずみであるという特徴があります。 - ただそうであっても、 - これは開発用ブランチの一つであり、ある時点における &os.stable; - のソースがどんな場合にも使えるものであるとは限りません。 - このブランチはもう一つの開発の流れというだけであって、 - エンドユーザ向けのものではありません。 - もし試験をする資源的な余裕がない場合は、代わりに最新の - &os; リリースを使ってください。 - - &os; の開発プロセスに興味があったり、 - それに対する貢献を考えていて、特にそれが次回の - &os; のリリースに関係するものであるなら - &os.stable; を追うことを考えると良いでしょう。 - - &os.stable; ブランチはいつもコンパイルができ、 - 安定に動作すべきですが、 - それが保証されているというわけではありません。 - &os.stable; のユーザは &os.current; よりも多いため、&os.current; - で発見されなかったバグが &os.stable; で発見され、 - ときどきそれが問題となることがあるのは避けることができません。 - このような理由から、盲目的に &os.stable; - を追いかけるべきではありません。 - 特に、開発環境もしくはテスト環境でコードを十分に試験せずに、 - プロダクション品質が要求されるサーバを &os.stable; - にアップグレードしてはいけません。 - - &os.stable; を追いかけるには - - - -STABLE - 利用する - - - - - &os.stable; の構築に関連する事柄や、 - その他の注意すべき点 に関する情報を得るために、 - &a.stable.name; メーリングリストに加わってください。 - また開発者は議論の余地がある修正や変更を考えている場合に、 - このメーリングリストで公表し、 - 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。 - - 追いかけているブランチに関連する - svn メーリングリストに参加してください。 - たとえば、9-STABLE ブランチを追いかけているユーザは - &a.svn-src-stable-9.name; メーリングリストに参加してください。 - このリストでは、変更がなされるごとに作成される commit log - やそれに伴う起こりうる副作用についての情報が記録されています。 - - これらのメーリングリストに入るには、&a.mailman.lists.link; - をたどって参加したいメーリングリストをクリックし、 - 手順の説明にしたがってください。 - ソースツリー全体の変更点を追いかけるには、 - &a.svn-src-all.name; メーリングリストを購読してください。 - - - - 新しい &os.stable; システムをインストールするには、 - ミラーサイト から最近の - &os.stable; リリースをインストールするか、 - 毎月公開されている &os.stable; - からビルドされたスナップショットを使ってください。 - スナップショットの詳細については、www.freebsd.org/ja/snapshots - をご覧ください。 - - 既に &os; が動いているシステムを - &os.stable; にアップグレードするには、 - svn - - Subversion - を使って、 - 希望する開発ブランチのソースをチェックアウしてください。 - stable/9 といったブランチ名は、 - www.freebsd.org/releng - で説明されています。 - - - - &os.stable; をコンパイルしたり &os.stable; へとアップグレード - - -STABLE - 構築、コンパイル - する前に、 - /usr/src/Makefile を注意深く読み、 - - に書かれている手順に従ってください。 - &a.stable; と /usr/src/UPDATING を読んで、 - 次のリリースへ向けて移ってゆくに当たって、 - ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。 - - - - - - - ソースの同期 - - 訳: &a.jp.iwasaki;、1997 年 9 月 13 日 - - &os; のソースの最新を追いかける方法は色々あります。 - この節では、基本的なサービスである - Subversion - について説明します。 - - - ソースツリーの一部を最新のものに更新することは可能です。 - ただし、サポートされているアップデート手順は、 - ソースツリー全体を最新のものに更新し、 - /bin, /sbin - といったユーザ空間で動作するもの、 - およびカーネルソースを再構築することのみです。 - ソースツリーの一部だけであったり、カーネルだけ、 - もしくはユーザランドのプログラムだけを更新した場合は、 - 問題が生じることがよくあります。 - この時に発生する問題はコンパイル時のエラーからカーネルパニック、 - データの破壊とさまざまです。 - - - - Subversion - - - Subversion - は pull 同期モデルを採用しています。 - ユーザ (または cron スクリプト) が - svn プログラムを起動し、 - ローカルにあるソースを最新状態にします。 - 更新情報はその時点の最新のものであり、 - いつダウンロードするかはユーザがコントロールするので、 - Subversion - はローカルのソースツリーをアップデートする好ましい方法です。 - 特定のファイルやディレクトリに限定して更新することも簡単にできます。 - 更新情報はサーバによって素早く生成されます。 - Subversion によるソースの同期方法については、 - で説明されています。 - - Subversion であれば、 - うっかりローカルのアーカイブの一部を消してしまっても、 - 壊れた部分を検出して再構築してくれます。 - world の再構築 + ソースを用いた &os; のアップデート - - world の再構築 - - &os.stable;、&os.current; などの - &os; のどれか特定のバージョンについて、 - ローカルのソースツリーを同期させたら、 - そのソースツリーを使ってシステムを再構築できます。 - このプロセスは world の再構築と呼ばれます。 + ソースをコンパイルして&os; をアップデートする方法は、 + バイナリを用いたアップデートに比べ、いくつもの利点があります。 + 特定のハードウェアをうまく利用するためのオプションを設定してコードを構築できます。 + ベースシステムの特定の箇所の設定をデフォルトの設定から変更したり、 + 必要がない部分を完全に削除して構築することもできます。 + システムを構築することによるアップデートは、 + バイナリアップデートをインストールするだけのアップデートに比べ時間がかかりますが、 + 利用環境に合わせた &os; + を作成するような完全なカスタマイズが可能です。 - world を再構築する前に、 - 以下を行ってください。 + + クィックスタート - - world の構築<emphasis>前</emphasis>に行う作業 - - - 重要なデータを他のシステムやリムーバブルメディアにバックアップし、 - きちんとバックアップが作成されていることを確認したら、 - 起動可能なインストールメディアを用意してください。 - システムを再構築する前に、 - バックアップを作成することの重要性は、 - いくら強調してもし過ぎると言うことはありません。 - システム全体の再構築は難しい作業ではありませんが、 - どんなに注意していたとしても、 - ソースツリーそのものに手違いがあった時には、 - システムが起動しなくなってしまう状態になることがあるのです。 - 多分、それを使うことはないと思いますが、 - あとで後悔することのないよう、念のため用意しておきましょう! - - - - メーリングリスト - 追いかけているブランチに応じて、 - &a.stable.name; もしくは &a.current.name; - の最近のエントリを調べて、 - 既知の問題や影響を受けるシステムを確認してください。 - 既知の問題が同期しているバージョンのコードに影響する場合は、 - その問題が解決されたことを報告する - 問題解決 (all clear) - のアナウンスが投稿されるまで待ってから、ソースを同期して、 - ローカルのソースに必要な修正を入れてください。 - - - - /usr/src/UPDATING を読み、 - 同期しているソースのバージョンで必要となるステップがないかどうかを調べて下さい。 - このファイルには潜在的な問題や特定のコマンドを実行する順番などの重要な情報が含まれています。 - 大きなアップグレードでは、world - をインストールする前に特定のファイルの名前を変更したり、 - 削除するといった、特別なステップが追加で必要となることがあります。 - ファイルの最後には、 - 現在推奨されているアップグレードの手順が詳しく正確に説明されています。 - もし、UPDATING に書かれている手順が、 - この節に書かれているものと矛盾していたら、 - UPDATING の手順を採用してください。 - - - - - <command>make world</command> は使わないこと - - 古いドキュメントの中には、 - make world を使うことを薦めているものがあります。 - これは、重要な手順をいくつか抜かしてしまうので、 - エキスパートでなければ使うべきではありません。 - ほぼあらゆる場合において、make world - を実行するのは間違っており、 - ここで説明されている手順を用いるべきです。 - - - - システム更新の概要 - - world の構築では、 - に書かれている手順で入手したソースを用いて、 - 古い &os; のバージョンをアップデートします。 - - &os; では、world は、 - カーネル、コアシステムのバイナリ、 - ライブラリ、プログラミングファイル、組み込みのコンパイラを意味します。 - これらのコンポーネントの構築およびインストールの順番は重要です。 - - 例えば、古いコンパイラは、 - バグを含み、新しいカーネルをコンパイルできない可能性があります。 - そのため、 - 新しいカーネルは新しいコンパイラを使って構築しなければならず、 - 新しいコンパイラの構築が必要となります。 - ただし、必ずしも、 - 新しいコンパイラがインストールされている必要はありません。 - - 新しい world は、 - 新しいカーネルの機能に依存している可能性があるので、 - 新しい world をインストールする前に、 - 新しいカーネルがインストールされている必要があります。 - 古い world は、新しいカーネルでは正しく動かないかも知れません。 - そのため、新しいカーネルをインストールしたら、 - 直ちに新しい world をインストールしてください。 - - 設定の中には、新しい world - をインストールする前に変更すべきものがありますが、 - 古い world を壊す可能性があります。 - そのため、設定のアップデートは 2 つの手順で行われます。 - 多くの場合、アップデートのプロセスは、ファイルを置き換えたり、 - 追加のみを行い、古いファイルを削除しません。 - このことが問題を引き起こす可能性があるため、 - /usr/src/UPDATING には、 - 手動で削除すべきファイルをどのステップで削除すべきかが書かれています。 - - これらを配慮した結果、以下で説明するアップグレードの推奨手順が作られました。 - - - make を実行したときの出力は、 - ファイルに保存すると良いでしょう。 - 何か障害が発生した場合には、エラーメッセージのコピーを - &os; メーリングリストに投稿してください。 - - ファイルに保存する最も簡単な方法は、 - 引数として出力の保存先のファイル名を指定して - script コマンドを使うことです。 - /tmp は、 - 再起動をすると削除されてしまう可能性があるので、 - このディレクトリには出力を保存しないようにしてください。 - 出力の保存には /var/tmp が適しています。 - 次のコマンドを world の構築の直前に実行し、再構築が終了したら - exit と入力してください。 - - &prompt.root; script /var/tmp/mw.out -Script started, output file is /var/tmp/mw.out - + 以下は、&os; のアップデートをソースを構築することにより行う典型的な方法のクイックリファレンスです。 + その後の節では、このプロセスについてより詳細に説明します。 - world の構築プロセスの概要 - - world の構築プロセスで用いられるコマンドは、 - ここで示されている順番で実行してください。 - この節では各コマンドの機能についてまとめます。 - - システム上で world の構築が一度でも行われていると、 - 前回の構築の際のコピーが - /usr/obj - に存在するはずです。 - このディレクトリが存在しているのであれば、 - このディレクトリを削除することで - make buildworld の行程にかかる時間を短縮し、 - 依存問題に悩まされるようなトラブルを回避できます。 + アップデートおよびビルド - &prompt.root; chflags -R noschg /usr/obj/* -&prompt.root; rm -rf /usr/obj - + &prompt.root; svn update /usr/src +check /usr/src/UPDATING +&prompt.root; cd /usr/src +&prompt.root; make -j4 buildworld +&prompt.root; make -j4 kernel +&prompt.root; shutdown -r now +&prompt.root; cd /usr/src +&prompt.root; make installworld +&prompt.root; mergemaster -Ui +&prompt.root; shutdown -r now - - 新しいコンパイラと関連ツールを最初にコンパイルし、 - その後、新しいコンパイラで、 - 新しい world の残りの部分をコンパイルします。 - コンパイルされたものは、 - /usr/obj に格納されます。 + + + 最新版のソースを入手してください。 + ソースの入手およびアップデートに関する情報については + + をご覧ください。 + - &prompt.root; cd /usr/src -&prompt.root; make buildworld - + + ソースの構築の前後で必要となる手動の作業について、 + /usr/src/UPDATING + を確認してください。 + - - コンパイラとカーネルのミスマッチを防ぐため、 - /usr/obj - にある新しいコンパイラを用いて新しいカーネルを構築します。 - 再構築は、ある種のメモリ構造体が変更されたような場合には必須で、 - ps や top - のようなプログラムは、 - カーネルとソースコードのバージョンが一致しないと正常に動作しないことがあります。 + + ソースが置かれているディレクトリに移動してください。 + - &prompt.root; make buildkernel - + + world (カーネルを除くすべて) + をコンパイルしてください。 + - - 新しくアップデートされたカーネルで起動できるように、 - 新しいカーネルとカーネルモジュールをディスク上に配置します。 - kern.securelevel を 1 より大きくしていて、 - かつ カーネルのバイナリファイルに - noschg のようなフラグを設定している場合は、 - まず、シングルユーザモードに移行してください。 - それ以外の場合は、 - マルチユーザモードでこれらのコマンドを問題なく動かせるはずです。 - kern.securelevel の詳細については - &man.init.8;、ファイルに対するさまざまなフラグの詳細については - &man.chflags.1; をご覧ください。 + + カーネルをコンパイルしてインストールしてください。 + ここに書かれているコマンドは、make buildkernel + installkernel + と同じです。 + - &prompt.root; make installkernel - + + 新しいカーネルを使うため、 + システムを再起動してください。 + - - すでに実行されているソフトウェアをアップデートする際の問題を最小限にするため、シングルユーザモードに移行してください。 - シングルユーザモードに移行することにより、 - 新しいカーネル上で古い world - が実行される際の問題を最小限にします。 + + ソースが置かれているディレクトリに移動してください。 + - &prompt.root; shutdown now + + world をインストールしてください。 + - シングルユーザモードに移行したら、UFS - でフォーマットされているシステムでは、 - 以下のコマンドを実行してください。 + + /etc/ + に置かれている設定ファイルをアップデートしたりマージしてください。 + - &prompt.root; mount -u / -&prompt.root; mount -a -t ufs -&prompt.root; swapon -a - - もしシステムが ZFS でフォーマットされている場合には、 - 以下の 2 つのコマンドを実行してください。 - この例では、zpool の名前は zroot - であると仮定しています。 - - &prompt.root; zfs set readonly=off zroot -&prompt.root; zfs mount -a - - - - オプション: もし、デフォルトの US English - 以外のキーボードマップが必要であれば、 - &man.kbdmap.1; で変更してください。 - - &prompt.root; kbdmap - - - - その後、どちらのファイルシステムでも、 - CMOS クロックが地域時間に設定されていて - GMT ではない場合 - (&man.date.1; が正しい時間と地域を表示しないなら当てはまります) - には、次のコマンドを実行してください。 - - &prompt.root; adjkerntz -i - - - - システムの再構築では、 - /etc, - /var や - /usr - といったディレクトリに新規に導入されたファイルや、 - 変更された設定ファイルに対する更新は行なわれません。 - 次に、新しい world - に対する /etc - の最初の設定ファイルのアップデートを行います。 - 以下のコマンドは - installworld - を成功するために本質的なファイルのみを比較します。 - たとえば、 - このステップでは、最後のアップデート後に &os; に追加された、 - 新しいグループや新しいシステムアカウント、 - もしくはスタートアップスクリプトがシステムに追加されることがあります。 - 次のコマンドに関する詳細な情報については、 - を参照してください。 - - &prompt.root; mergemaster -iF - - - - /usr/obj - にある新しい world - およびシステムのバイナリをインストールします。 - - &prompt.root; cd /usr/src -&prompt.root; make installworld - - - - 残りの設定ファイルをアップデートします。 - - &prompt.root; mergemaster -p - - - - 使われなくなったファイルを削除します。 - もし使われなくなったファイルがディスクに残っていると、 - 問題が起きる可能性があるので重要な作業です。 - - &prompt.root; make delete-old - - - - 再起動を行い、新しいカーネル、 - world そして設定ファイルをロードします。 - - &prompt.root; reboot - - - - 古いライブラリを削除する前に、 - - に書かれている手順にしたがって、 - すべての ports を再構築する必要があります。 - 再構築が終わったら、新しいライブラリと競合することを避けるため、 - 使われなくなったライブラリを削除します。 - この過程に関する詳細は、 - を参照して下さい。 - - &prompt.root; make delete-old-libs + + 新しく構築された world およびカーネルを利用するため、 + システムを再起動してください。 + + - - シングルユーザモード - - もしシステムがダウンタイムを持つことができるのであれば、 - システムのコンパイルをマルチユーザモードでおこない、 - インストールのためにシングルユーザモードに移行するという方法ではなく、 - コンパイルをシングルユーザモードで行うことを考えてください。 - システムの再インストールでは、たくさんの重要なシステムファイル、 - すべての標準的なシステムバイナリ、ライブラリ、 - インクルードファイルが変更されるので、 - 実際に動作しているシステムにおいて、 - 特にアクティブなユーザは、トラブルに見舞われる可能性があります。 - - 設定ファイル + + ソースを用いたアップデートのための準備 - - make.conf - - - world - の構築プロセスでは、いくつかの設定ファイルが使われます。 - - /usr/src に置かれている - Makefile には、 - &os; を構成するプログラムの構築方法や、 - どういう順番でそれらを構築すべきかといった指示が記述されています。 - - make で利用可能なオプションの説明は、 - &man.make.conf.5; で説明されています。また、 - /usr/share/examples/etc/make.conf には、 - 良く使われる例が書かれています。 - これらの設定を /etc/make.conf に追加すると、 - make の実行やプログラムの構築方法を設定できます。 - これらのオプションは、 - make が使われる際には常に有効となるため、 - Ports Collection でのアプリケーションのコンパイル時、 - ユーザが書いた C プログラムや &os; - オペレーティングシステムを構築する際にも影響を及ぼします。 - ある設定を変更したことにより、影響が広い範囲におよび、 - 驚くべき結果をもたらす可能性があります。 - 両方のファイルに書かれているコメントを読むことと、 - デフォルトの設定は、パフォーマンスと安全性の観点から選ばれていることを覚えておいてください。 - - - src.conf - - - /etc/src.conf は、 - ソースコードを用いたオペレーティングシステムの構築をコントロールします。 - /etc/make.conf とは異なり、 - /etc/src.conf に書かれた設定は、 - &os; オペレーティングシステムそのものを構築するときにのみ影響します。 - このファイルで設定可能な多くのオプションについては、 - &man.src.conf.5; に記述されています。 - 一見したところ無効にされている、 - 使われていないカーネルモジュールやビルドオプションに注意してください。 - ときどき予期しなかったり、わずかな影響を与えることがあります。 + /usr/src/UPDATING を読んでください。 + このファイルには、 + アップデートの前後で必要となる手動の作業について書かれています。 - - 変数とターゲット + + ソースコードのアップデート - make の使用における一般的な書式は、 - 次のとおりです。 + &os; のソースコードは + /usr/src/ に置かれています。 + このソースコードのアップデートには、 + Subversion + バージョン管理システムを利用する方法が推奨されています。まず、 + ソースコードがバージョン管理下にあることを確認してください。 - &prompt.root; make -x -DVARIABLE target + &prompt.root; svn info /usr/src +Path: /usr/src +Working Copy Root Path: /usr/src +... - この例では、 が - make に渡されるオプションになります。 - 利用可能なオプションについては、&man.make.1; - を参照してください。 + この結果は、/usr/src/ + がバージョン管理下にあり、&man.svn.1; + を使ってアップデートできることを示しています。 - 変数を渡すには、変数の名前を - - のように指定してください。 - この変数は Makefile の動作をコントロールします。 - 変数の指定は、/etc/make.conf で設定するか、 - make の実行時に指定するかのどちらかで行います。 - たとえば、以下の変数は、プロファイル版のライブラリを構築しないことを指定します。 + &prompt.root; svn update /usr/src - &prompt.root; make -DNO_PROFILE target + このディレクトリをアップデートしていない期間が長いと、 + アップデートのプロセスには時間がかかります。 + このプロセスが終わると、ソースコードは最新となり、 + 次節以降で説明する構築のプロセスを実行できます。 - これは、/etc/make.conf - の中で以下のように設定することに対応します。 + + ソースコードの入手 - NO_PROFILE= true # Avoid compiling profiled libraries + '/usr/src' is not a working copy + という出力が出た場合には、 + ファイルがなかったり、別な方法によりインストールされているので、 + 新しくソースコードをチェックアウトする必要があります。 - target は、make に - どのように動作するのかを指示するためのものです。 - Makefile は利用可能なターゲットを定義しています。 - ターゲットには、 - システムの再構築に必要な段階を、 - 多くのさらに細かい段階に分割するため、 - 構築の過程で利用されるものがあります。 + + &os; のバージョンおよびリポジトリパス - 選択肢が分けられていることは、二つの理由から有用です。 - まず第一に、構築作業は稼働中のシステムにまったく影響を与えません。 - そのため、マルチユーザモードで稼働中のシステムでも、安全に - buildworld を実行できます。 - ただし、installworld は - シングルユーザモードで行なうことをおすすめします。 + + + + uname -r の出力 + リポジトリパス + 説明 + + - 第二に、NFS マウントを利用することで、 で説明されているように、 - ネットワーク上の複数のマシンをアップグレードすることが可能な点があげられます。 + + + X.Y-RELEASE + base/releng/X.Y + このリリースバージョンに対する重大なセキュルティへの対応およびバグの修正パッチのみが適用されています。 + このブランチは、ほとんどのユーザに推奨されます。 + - make に - をつけると、 - 同時に複数のプロセスを生成できます。 - 構築過程の大部分では CPU 性能の限界より - I/O 性能の限界の方が問題となるため、 - シングル CPU とマルチ CPU - マシンの両方に効果があります。 + + X.Y-STABLE + base/stable/X + + リリースバージョンに対し、 + そのブランチにおけるすべての開発の成果が反映されたものです。 + STABLE は、 + Applications Binary Interface + (ABI) + が変更されないことを意味しており、 + このブランチの以前のバージョンでコンパイルされたソフトウェアは、 + このバージョンでも実行できることを意味しています。 + たとえば、&os; 10.1 + で実行するようにコンパイルされたソフトウェアは、 + &os; 10-STABLE においても実行できます。 - 普通のシングル CPU マシンで以下のコマンド - を実行すると、最大 4 個までのプロセスを同時に実行します。 - メーリングリストに投稿された経験的な報告によると、 - 4 個という指定が最も良いパフォーマンスを示すようです。 + STABLE ブランチは、 + 時期によってはユーザに影響するようなバグや非互換性を持つことがあります。 + これらは通常すぐに修正されます。 + + - &prompt.root; make -j4 buildworld + + X-CURRENT + base/head/ + リリースが行われていない最新の &os; + の開発バージョンです。 + CURRENT ブランチは大きなバグや非互換があることもあるので、 + 高度な知識を持ったユーザのみ使用が推奨されます。 + + + +
- マルチ CPU マシンでは、 - 6 から 10 の間の値を設定し、 - 速度がどれくらい向上するか確認してみてください。 + &man.uname.1; を使って &os; + のバージョンを確認してください。 - - world の再構築 - 時間 - + &prompt.root; uname -r +10.3-RELEASE - - make buildworld - に変数を指定した場合は、同じ指定を - make installworld にも指定しなければなりません。 - ただし installworld - では、 を - 絶対に使ってはいけません。 + + から分かるように、10.3-RELEASE + のアップデートのためのソースコードのパスは、 + base/releng/10.3 です。 + このパスは、ソースコードをチェックアウトする時に使います。 - たとえば、以下のコマンドを実行したなら、 + &prompt.root; mv /usr/src /usr/src.bak +&prompt.root; svn checkout https://svn.freebsd.org/base/releng/10.3 /usr/src - &prompt.root; make -DNO_PROFILE buildworld + + + この古いディレクトリを、 + 邪魔にならないように移動してください。 + このディレクトリ以下に対して変更を行ってなければ、 + 削除しても構わないでしょう。 + - 以下のようにしてインストールしなければなりません。 - - &prompt.root; make -DNO_PROFILE installworld - - もしそうしなかった場合、2 番目のコマンドは、 - make buildworld - の段階で構築されていないプロファイル版ライブラリをインストールしようとしてしまうでしょう。 + + リポジトリの URL に + + に記載されているパスを追加します。 + 3 番目のパラメータには、 + ローカルシステム上でソースコードが置かれるディレクトリを指定します。 + + - - - 設定ファイルの同期 + + ソースからの構築 - - - - Tom - Rhodes - - 寄稿: - - - - - - - mergemaster - - - - &os; の &man.mergemaster.8; Bourne シェルスクリプトは、 - /etc にある設定ファイルと、 - /usr/src/etc - にある設定ファイルの違いを確認するためのものです。 - システムの設定ファイルをソースツリーにある設定ファイルにアップデートするには、 - この方法が推奨されています。 - - mergemaster を使う前に、 - 既存の /etc - をどこか安全な場所にコピーしておきましょう。 - 再帰的なコピーを行なう と、 - ファイルの更新時間や所有者などを保存する - と共に実行してください。 - - &prompt.root; cp -Rp /etc /etc.old - - mergemaster を実行すると、 - / を起点とした一時的なルート環境を構築し、 - さまざまなシステム設定ファイルを - (訳注: デフォルトでは /var/tmp/temproot に) - 置いていきます。 - これらのファイルは現在システムにインストールされているファイルと比較されます。 - 異なるファイルは &man.diff.1; 形式で示され、 - の記号は追加または変更された行を表し、 - は完全に削除されたか新しく置き換えられた行を表します。 - ファイルの違いの表示方法についてのより詳しい情報は、 - &man.diff.1; を参照してください。 - - 次に mergemaster - は違いのあるファイルをそれぞれ示し、 - 選択可能なオプションを表示します。 - ここでは、一時ファイルと呼ばれる新しいファイルを削除するか、 - 一時ファイルをそのままインストールするか、 - 一時ファイルと現在インストールされているファイルを統合するか、 - もしくは結果をもう一度見るか、 - といったオプションから選択できます。 - - 一時ファイルの削除を選ぶと、mergemaster - は現在のファイルを変更しないで新しいバージョンを削除します。 - この選択は、お勧めできません。 - mergemaster - のプロンプトで ? とタイプすれば、 - いつでもヘルプが見られます。 - ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、 - もう一度そのファイルが提示されます。 - - 一時ファイルをそのままインストールすることを選ぶと、 - 現在のファイルを新しいファイルで置き換えます。 - ほとんどの手を加えていないファイルは、 - これが一番よい選択です。 - - ファイルの統合を選んだ場合、 - テキストエディタが起動され、両方のファイルの中身が提示されます。 - 画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、 - 2 つのファイルを統合することができます。 - 並んでいるファイルを比較するとき、 - l で左側の中身を選択し、 - r で右側の中身を選択します。 - 最終出力は左右両方の部分でできたファイルになるでしょう。 - このファイルをインストールすることができます。 - たいてい、このオプションはユーザが設定を変更したファイルに使われます。 - - 結果をもう一度見る、を選択すると、 - ファイルの相異点をもう一度見ることができます。 - - mergemaster - がシステムファイルの比較を終えたあと、 - 他のオプションについてのプロンプトが表示されます。 - たとえば、 - パスワードファイルを再構築するかどうかを尋ねることがあります。 - 最後に残った一時ファイルを削除するかどうかを尋ねて終了します。 - - - - - - - 使われなくなったファイル、ライブラリの削除 - - - - - Anton - Shterenlikht - - ベースとなったノートの提供: - - - - - - Deleting obsolete files and directories - - - &os; の開発サイクルにおいて、 - ファイルやシステムの一部が使われなくなることがあります。 - それらの機能が別の場所で実装されたり、 - ライブラリのバージョン番号が変わったり、 - システムから完全に削除されることがあるためです。 - システムのアップデート時に削除が必要になるのは、 - 古いファイル、ライブラリそしてディレクトリです。 - これらのファイルを削除することで、 - 記憶媒体やバックアップ媒体において不必要な容量を占めている古いファイルが、 - システム上に散乱することがなくなります。 - また、古いライブラリのセキュリティや安定性に問題があると、 - ライブラリを新しくしてシステムを安定な状態にし、 - 古いライブラリによりシステムがクラッシュすることを防がなければなりません。 - 使われなくなったファイル、ディレクトリ、ライブラリは - /usr/src/ObsoleteFiles.inc - にまとめられています。以下の手順により、 - アップグレードの過程でこれらのファイルを削除できます。 - - - make installworld - と、その後の mergemaster が無事に終わったら、 - 使われなくなったファイルやライブラリを確認してください。 + まず最初に world + (カーネルを除くオペレーティングシステムのすべて) をコンパイルします。 + このステップを最初に実行するのは、 + カーネルの構築を最新のツールを使って行うようにするためです。 + このステップが終わったら、カーネルそのものを構築します。 &prompt.root; cd /usr/src -&prompt.root; make check-old +&prompt.root; make buildworld +&prompt.root; make buildkernel - 見つかった古いファイルは、以下のコマンドで削除できます。 + コンパイルされたコードは + /usr/obj に書き出されます。 - &prompt.root; make delete-old + これは基本のステップです。 + 構築をコントロールする追加のオプションについては、 + 以下で説明します。 - 使われなくなったファイルを削除する際、 - ファイルごとに確認が求められます。 - 確認を省略し、自動的にファイルを削除するには、 - 以下のように BATCH_DELETE_OLD_FILES - を設定してください。 + + クリーンビルドの実行 - &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old + &os; ビルドシステムのいくつかのバージョンは、 + オブジェクトが一時的に置かれるディレクトリ + /usr/obj + に前回のコンパイルされたコードを残します。 + これにより、変更されていないコードを再コンパイルせずにすむので、 + その後の構築時間を短縮できます。 + すべてを再構築するには、構築を開始する前に、 + cleanworld を実行してください。 - yes - をコマンドへパイプでつなげても省略できます。 + &prompt.root; make cleanworld + - &prompt.root; yes|make delete-old + + ジョブの数の設定 - - Warning + マルチコアプロセッサを搭載するシステムでは、 + 構築のためのジョブの数を増やすことで、 + 構築にかかる時間を短縮できます。 + sysctl hw.ncpu を使って、 + コアの数を確認してください。 + ジョブの数がどのように構築の速さに影響するかを確実に知るには、 + プロセッサにより異なりますし、&os; + のバージョンにより使用されるビルドシステムも変わるため、 + 実際に試してみるしか方法はありません。 + 試してみる最初のジョブの数の候補としては、 + コアの数の半分から倍の数の間で検討してみてください。 + ジョブの数は、 を使って指定します。 - 使われなくなったファイルを削除すると、 - 削除したファイルに依存していたアプリケーションは動かなくなってしまいます。 - 特に、古いライブラリを削除する場合に起こり得ます。 - 通常、make delete-old-libs - を実行する前に、 - これらの古いライブラリを使っているプログラム、ports、 - ライブラリを再構築する必要があります。 - + + 構築のジョブの数を増やす - 共有ライブラリの依存をチェックするユーティリティとして、 - sysutils/libchk や - sysutils/bsdadminscripts - が用意されています。 + 以下は 4 つのジョブで world とカーネルを構築する例です。 - 使われなくなった共有ライブラリは、 - 新しいライブラリと競合し、 - 以下のようなメッセージを表示することがあります。 + &prompt.root; make -j4 buildworld buildkernel + + - /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 + + カーネルのみを構築する - この問題を解決するには、 - ライブラリがどの port によってインストールされたかを調べて下さい。 + ソースコードが変更された場合には、 + buildworld を完了しなければいけません。 + その後、いつでも + buildkernel でカーネルを構築できます。 + カーネルだけを構築するには、以下のように実行してください。 - &prompt.root; pkg which /usr/local/lib/libtiff.so - /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 -&prompt.root; pkg which /usr/local/lib/libXext.so - /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 + &prompt.root; cd /usr/src +&prompt.root; make buildkernel + - 見つかった port をアンインストールし、 - 再構築、再インストールしてください。 - この過程は ports-mgmt/portmaster - で自動化できます。 - すべての ports が再構築され、 - 古いライブラリがどこにも使われていないことを確認したら、 - 以下のコマンドで古いライブラリを削除してください。 + + カスタムカーネルの構築 - &prompt.root; make delete-old-libs + &os; 標準のカーネルは、 + GENERIC と呼ばれる + カーネルコンフィグレーションファイル + に基づいています。 + GENERIC カーネルには、 + 最も良く使われるデバイスドライバやオプションが含まれています。 + しかしながら、 + 特定の目的に合わせてデバイスドライバやオプションを削除したり追加するためには、 + カスタムカーネルを構築することが有用であったり、 + 必要となることがあります。 - もしちょっとした問題があった場合でも、 - システムの一部を再構築するのは簡単です。 - たとえば、アップグレードや /etc - のマージの途中で誤って - /etc/magic を削除してしまい、 - その結果 file - が動作しなくなってしまったような場合には、 - 次のコマンドを実行して修復してください。 + たとえば、極端に RAM + が制限されているような小さな組み込みのコンピュータを開発しているユーザであれば、 + 必要のないデバイスドライバやオプションを削除することで、 + カーネルを少しでも小さくできるでしょう。 - &prompt.root; cd /usr/src/usr.bin/file -&prompt.root; make all install + カーネルのコンフィグレーションファイルは、 + /usr/src/sys/arch/conf/ + に置かれています。ここで、 + arch は + uname -m の出力です。 + ほとんどのコンピュータは + amd64 であり、 + コンフィグレーションファイルが置かれているディレクトリは + /usr/src/sys/amd64/conf/ + です。 + + + /usr/src は、 + 削除されたり作り直されたりする可能性があるため、 + カスタムカーネルのコンフィグレーションファイルは、 + /root + のような別のディレクトリで管理することが好ましいです。 + カーネルコンフィグレーションファイルは、 + conf ディレクトリにリンクします。 + このディレクトリが削除されたり、上書きされた場合には、 + カーネルコンフィグレーションファイルを新しいディレクトリにもう一度リンクしてください。 + + + カスタムコンフィグレーションファイルは、 + GENERIC + コンフィグレーションファイルをコピーして作成できます。 + たとえば、 + ストレージサーバ用の STORAGESERVER + という名前の新しいカスタムカーネルは、 + 以下のようにして作成できます。 + + &prompt.root; cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER +&prompt.root; cd /usr/src/sys/amd64/conf +&prompt.root; ln -s /root/STORAGESERVER . + + その後 /root/STORAGESERVER を編集し、 + &man.config.5; + で示されるデバイスやオプションを追加したり削除してください。 + + コマンドラインからカーネルコンフィグレーションファイルを + KERNCONF に指定することで、 + カスタムカーネルを構築できます。 + + &prompt.root; make buildkernel KERNCONF=STORAGESERVER + - - よくある質問 + + コンパイルされたコードのインストール - - - 変更が行なわれたら、 - その度にシステムの再構築が必要になるのでしょうか? + buildworld および + buildkernel が完了したら、 + 新しいカーネルと world をインストールしてください。 - - それは変更の内容によります。 - たとえば、svn を実行したとき、 - 次にあげるようなファイルが更新されていたとします。 - - src/games/factor/factor.c -src/games/fortune/fortune/fortune.c -src/usr.sbin/bsdinstall/distextract/distextract.c -src/usr.sbin/bsdinstall/partedit/diskeditor.c -src/share/man/man7/intro.7 - - このときには、改めてシステム全体を再構築する必要はないでしょう。 - そのかわり、適切なサブディレクトリに移って - make all install を行ってください。 - しかし、たとえば src/lib/libc/stdlib - のような大きな変更が行なわれた場合には、 - システム全体の完全な再構築が強く推奨されます。 - - 2 週間ごとにシステムを再構築して、 - その 2 週間分の変更を取り込むユーザもいますし、 - 変更のあった部分だけ再構築し、 - すべての依存関係を確かめたいと考えるユーザもいます。 - それらはどのくらいの頻度でアップグレードしたいか、 - そして &os.stable; か &os.current; - のどちらを追いかけているのかにもよります。 - - - - - どうして - signal 11 - signal 11 - - (もしくは他のシグナル番号) - のエラーがたくさん出てコンパイルが失敗するのでしょうか？ - - - これは通常、ハードウェアに問題があることを示しています。 - world の再構築は、 - ハードウェア (特にメモリ) - に対する負荷耐久試験を行なうための有効な手段です。 - 本当にこの問題によるものかどうかは、 - make - をもう一度実行し、異なる段階で異常終了が発生するか、 - ということから確認できます。 - - このエラーに対応するには、RAM を始めとして、 - マシンの部品をメモリから交換して、 - どの部分が悪いのかを調べてみてください。 - - - - - 終了したら /usr/obj - を削除してもかまいませんか? - - - このディレクトリには、 - コンパイルの段階で生成された - すべてのオブジェクトファイルが含まれています。 - 通常 make buildworld の最初の段階では、 - このディレクトリを削除して新しくつくり直すようになっています。 - 構築終了後も /usr/obj - を保存しておいても、あまり意味はありません。 - 削除すれば、だいたい 2GB - のディスクスペースを解放することができます。 - - - - - 構築を中断した場合、 - その構築を途中から再開することはできますか? - - - それは、問題が起こるまでに、 - どれだけの作業を終えているかによります。 - 一般的に make buildworld は、 - 基本的なツールや、 - システムライブラリの新しいコピーを作成します。 - その後、これらのツールやライブラリがインストールされてから、 - 自分自身の再構築に使われ、もう一度、インストールされます。 - システムの残りの部分がその新しいシステムファイルを用いて作り直されます。 - - 再構築の最終段階では、 - まったく安全に以下のコマンドを実行することができます。 - これは、前回の make buildworld - の作業をやり直しません。 - - &prompt.root; cd /usr/src -&prompt.root; make -DNO_CLEAN all - - 次のメッセージ - - -------------------------------------------------------------- -Building everything.. --------------------------------------------------------------- - - が make buildworld の出力にある場合には、 - 上のようにしてもほとんど悪影響が現れることはありません。 - - もしこのメッセージがない場合には、 - 安全を確保し、後悔するようなことがないよう、 - システムの再構築を最初からやり直しましょう。 - - - - - make world を高速化できますか? - - - いくつかの方法で build world のプロセスを高速化できます。 - たとえば、全体のプロセスは、 - シングルユーザモードで動かすことで高速になります。 - しかしながら、この方法では、プロセスが完了するまで、 - ユーザがシステムにアクセスすることはできません。 - - ファイルシステムを注意深く設計したり、 - ZFS データセットを使うことでも変わります。 - /usr/src と - /usr/obj - を、異なるディスク上の別のファイルシステムに置くことを検討してください。 - また可能ならば、 - 異なるディスクコントローラに接続された異なるディスクにファイルシステムを置いてください。 - /usr/src - をマウントする時には、 - 最後にアクセスされた時刻の書き込みを抑制するように、 - - オプションを付けてマウントしてください。 - もし、/usr/src が、 - 独立したファイルシステムではないときには、 - オプションで、/usr - を再マウントしてください。 - - /usr/obj - のあるファイルシステムを、 - オプションをつけてマウントもしくは再マウントしてください。 - これによって、ディスクへの書き込みが非同期になります。 - つまり、書き込み命令はすぐに完了するのに対し、 - 実際にデータがディスクに書き込まれるのは、その数秒後になります。 - これによって、書き込み処理の一括化が可能になるため、 - 劇的なパフォーマンスの向上が期待できます。 - - - - - - このオプションを指定すると、ファイルシステムは - 壊れやすくなってしまうことに注意してください。 - このオプションを付けていて、突然電源が落ちた場合には、 - 再起動後にファイルシステムが復旧不能になる可能性が - 非常に高くなります。 - - もし、/usr/obj - が、ファイルシステムにある唯一のディレクトリであれば、 - これは問題になりません。 - しかし、同じファイルシステムに、 - 他の貴重なデータを置いているときには、 - このオプションを有効にする前に、 - バックアップをきちんと取っておきましょう。 - - - /etc/make.conf に - NO_PROFILE=true をセットして、 - プロファイル版の作成を無効化してください。 - - &man.make.1; に - - を指定して、複数のプロセスを並列に実行させてください。 - これは、単一のプロセッサでも複数のプロセッサでも、 - 同様に恩恵を得ることができます。 - - - - - なにか悪いことがあったらどうすればいいですか? - - - まず、自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。 - - &prompt.root; chflags -R noschg /usr/obj/usr -&prompt.root; rm -rf /usr/obj/usr + &prompt.root; cd /usr/src +&prompt.root; make installkernel +&prompt.root; shutdown -r now &prompt.root; cd /usr/src -&prompt.root; make cleandir -&prompt.root; make cleandir +&prompt.root; make installworld +&prompt.root; shutdown -r now - ええ、make cleandir - は本当に 2 回実行するのです。 + カスタムカーネルを構築した場合は、 + 新しいカスタムカーネルを KERNCONF + に設定して実行してください。 - そして、make buildworld を行い、 - 全プロセスを最初からやり直してください。 + &prompt.root; cd /usr/src +&prompt.root; make installkernel KERNCONF=STORAGESERVER +&prompt.root; shutdown -r now +&prompt.root; cd /usr/src +&prompt.root; make installworld +&prompt.root; shutdown -r now + - まだ問題があれば、エラーと uname -a - の出力を &a.questions; に送ってください。 - 設定についてさらに質問されても答えられるよう用意してください! - - - + + アップデートの完了 + + アップデートの完了までに、いくつかの最終作業が残されています。 + デフォルトから変更した設定ファイルを新しいバージョンのファイルにマージし、 + 古くなったライブラリを見つけて削除した後に、 + システムを再起動します。 + + + &man.mergemaster.8; を用いた設定ファイルのマージ + + &man.mergemaster.8; を用いることで、 + システムの設定ファイルに行われている変更を、 + 簡単にこれらのファイルの新しいバージョンにマージできます。 + + オプションを使って + &man.mergemaster.8; を実行すると、 + ユーザが手を加えていないファイルのアップデートおよび新しく追加されたファイルのインストールを自動的に行います。 + + &prompt.root; mergemaster -Ui + + ファイルのマージを手動で行う必要がある時は、 + ファイルの中で残す箇所の選択を対話的におこなうようなインタフェースが表示さます。 + 詳細については、&man.mergemaster.8; をご覧ください。 + + + + 使われなくなったファイルやライブラリの確認 + + アップデート後に、 + 使われなくなったファイルやディレクトリが残ることがあります。 + これらのファイルは、 + + &prompt.root; make check-old + + で確認でき、以下のようにして削除できます。 + + &prompt.root; make delete-old + + 同様に使われなくなったライブラリが残ることもあります。 + これらのライブラリは、 + + &prompt.root; make check-old-libs + + で確認でき、以下のようにして削除できます。 + + &prompt.root; make delete-old-libs + + これらの古いライブラリを利用しているプログラムは、 + ライブラリが削除されると動かなくなります。 + これらのプログラムは、古いライブラリを削除した後に、 + 再構築もしくは置き換える必要があります。 + + + 古いファイルとディレクトリのすべてを削除しても問題ないことを確認したら、 + コマンドに BATCH_DELETE_OLD_FILES + を設定することで、各ファイルを削除する際に + y および Enter + を押さなくても済むようにできます。以下はその例です。 + + &prompt.root; make BATCH_DELETE_OLD_FILES=yes delete-old-libs + + + + + アップデート後の再起動 + + コンピュータを再起動して、すべての変更を反映させることが、 + アップデートの最後におこなう作業です。 + + &prompt.root; shutdown -r now +