diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml index 5e6ea6883e..91dd708bc5 100644 --- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml @@ -1,608 +1,750 @@ FreeBSD の起動のプロセス この章では 起動 - ブートストラップ(bootstrap) + ブートストラップ (bootstrap) + + 計算機を起動しオペレーティングシステムをロードするプロセスは, + ブートストラッププロセス, + もしくは単に 起動 と呼ばれます. + FreeBSD の起動プロセスを使えば, + システムをスタートするときに起きることを + かなり柔軟にカスタマイズすることができます. + 同じ計算機にインストールされた + 別のオペレーティングシステムを選択することもできますし, + 同じオペレーティングシステムの違うバージョンを選択することも, + インストールされた別のカーネルを選択することさえできます. + + この章では, 指定できる設定オプションと FreeBSD + の起動プロセスのカスタマイズ方法について詳しく述べます. + この章では FreeBSD カーネルがスタートし, デバイスを検出し, + &man.init.8; を起動するまでに起きることすべてを扱います. + どの最中のことだかはっきりしていない人のために補足すると, + テキストの色が明るい白から灰色に変わるまでに起きていることです. + + この章を読むと, 以下のことが分かります. + + + + どのように FreeBSD のブートストラップシステムが構成され, + そしてそれらが互いにどう関係しているのか + + + + 起動プロセスを制御するために FreeBSD + のブートストラップの各要素に付加できるオプション + + - FreeBSD は通常, 起動(bootstrap)を三段階に分けて行ないます. - これには基本的に, 互いに順番に呼び出される三つのプログラム(二つの - 起動ブロック(boot block)と - ローダ(loader))が使われています. - これらのプログラムはそれぞれ, - その前に呼び出されるプログラムの情報に基づいて動作し, - より洗練された機能を提供します. + + x86 限定 + + この章では Intel x86 システム上で動作する FreeBSD + の起動プロセスだけを扱います. + + + + + 起動時の問題 + + 計算機の電源を入れ, オペレーティングシステムをスタートさせるのには, + おもしろいジレンマがあります. + 定義により, 計算機は + オペレーティングシステムがスタートするまで何もする方法を知りません. + ディスクからプログラムを動かすのも含みます. + では, 計算機はオペレーティングシステムなしに + ディスクからプログラムを実行することができず, + オペレーティングシステムのプログラムがディスク上にあるのなら, + どうやってオペレーティングシステムをスタートさせるのでしょう? + + この問題はほらふき男爵の冒険という本の中に + 書かれている問題ととてもよく似ています. + 登場人物がマンホールの下に半分落っこちて, + 靴紐 (ブートストラップ) をつかんで自分を引っぱり, 持ち上げるのです. + 計算機の黎明期には, ブートストラップ + という用語でオペレーティングシステムをロードする + 機構のことを指していたのですが, + いまは短く 起動 (ブート) と言います. + + x86 ハードウェアでは, 基本入出力システム + (Basic Input/Output System: BIOS) + にオペレーティングシステムをロードする責任があります. + オペレーティングシステムをロードするために, + BIOS がハードディスク上のマスターブートレコード + (Master Boot Record: MBR) + を探します. + MBR はハードディスク上の特定の場所になければなりません. + BIOS には MBR をロードし起動するのに十分な知識があり, + オペレーティングシステムをロードするために必要な作業の残りは + MBR が実行できることを仮定しています. - カーネル(kernel) + + BIOS + 基本入出力システム (Basic Input/Output System) + + + ディスク上にオペレーティングシステムを一つだけ + インストールしているなら, 標準の MBR で十分です. + この MBR はディスク上の最初の起動可能なスライスを探し, + そのスライスにあるコードを起動して + 残りのオペレーティングシステムをロードします. + + ディスク上にオペレーティングシステムを複数インストールしているなら, + 別の MBR — + 複数のオペレーティングシステムのリストを表示できて, + 起動するオペレーティングシステムを選択できるような MBR — + をインストールすることができます. + FreeBSD はそのような MBR とともに配布されており, + この MBR をインストールすることもできます. + 他のオペレーティングシステムのベンダも + 標準 MBR に代わる MBR を提供しています. + + FreeBSD ブートストラップシステムの残りは 3 段階に分かれます. + 第 1 ステージは MBR によって起動されるもので, + MBR は計算機を特定の状態にするために必要なことだけ知っていて, + 第 2 ステージを起動します. + 第 2 ステージでは, 第 3 ステージを起動する前に, + もうちょっとやることができます. + 第 3 ステージでオペレーティングシステムのロード作業を完了します. + 起動作業がこれらの 3 段階に分かれているのは, + PC の規格がステージ 1 とステージ 2 + で実行できるプログラムのサイズに制限を課しているからです. + これらの作業をつなぎ合わせることによって, + FreeBSD はより柔軟なローダ (loader) を提供しているのです. + + カーネル (kernel) init - その後カーネルが起動し, デバイスの検出と初期化を行ないます. + その後カーネルが起動し, デバイスの検出と初期化を開始します. そしてカーネルの起動が終わると, 制御はユーザープロセスの &man.init.8; へ移されます. &man.init.8; はまず ディスクが利用可能であることを確かめ, ファイルシステムのマウント, ネットワークで利用するネットワークカードのセットアップ, そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動, - といったユーザーレベルでのリソース(資源)設定を行ないます. + といったユーザーレベルでのリソース (資源) 設定を行ないます. - 起動ブロック: 起動ステージ 1 および 2 - - 起動(bootstrap)とは, - コンピュータが接続されたデバイスを検出, 初期化し, - 必要となるプログラムを動作させることを指します. - - 起動には起動の際の動作が記録された, - 特殊な読み出し専用メモリチップを利用します. - その動作は通常, - メモリテストやデバイスの設定を行なう他のチップに制御を渡し, - そして設定された内容をプログラムに提供するというものです. - - BIOS - CMOS - 標準的な個人向けコンピュータでは, - BIOS (起動を行なう部分) と - CMOS (設定を記録する部分) によって起動を実現しています. - これらはディスクが存在すること, - そしてオペレーティングシステムをロードするためのプログラムが - ディスク上のどこにあるのかを認識しています. - - この章では上に述べたような起動の初期の過程については扱いません. - 焦点を合わせるのは, - ディスク上のプログラムに制御が移された後の内容についてです. - - 起動ブロックは(通常), ローダを見つけて実行する役割を持っています. - したがって, ファイルシステム上のプログラムを見つけること, - 実行できること, - そしてその動作に関して最低限の設定が可能である必要があります. + MBR, 起動ステージ 1, 2 および 3 - <filename>boot0</filename> + MBR, <filename>/boot/boot0</filename> マスターブートレコード (MBR) - まず実際に最初にあるのは boot0 - と呼ばれる起動ブロックです. - これは マスターブートレコード(MBR; Master Boot - Record) という, - システムが起動時にプログラムを検索するディスク上の特殊な部分に存在します. - この部分は, 単に起動可能なスライスのリストが格納されています. + FreeBSD の MBR は /boot/boot0 + にあります. これは MBR のコピーであり, + 本当の MBR はディスク上の特別な部分, + つまり FreeBSD 領域の外に置く必要があります. boot0 は非常に単純なプログラムです. - これは, MBR にあるプログラムは - 512 バイトの大きさでなければならないという制限があるためです. - - boot0 は, 下のような出力をします. + これは, MBR にあるプログラムは + 512 バイトの大きさでなければならないという制限があるためです. + FreeBSD の MBR をインストールし, + かつハードディスク上に複数のオペレーティングシステムをインストールした場合, + 起動時にこれと同じような画面が出るでしょう. <filename>boot0</filename> のスクリーンショット F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 + + 他のオペレーティングシステム, 特に Windows 95 は, + 既存の MBR を自らの MBR で上書きしてしまうことで知られています. + もしそうなってしまったら, + もしくは既存の MBR を FreeBSD の MBR で置き換えたいのなら, + 次のコマンドを使ってください. + + &prompt.root; fdisk -B -b /boot/boot0 device + + device は起動するデバイス名で, + 例えば 1 番目の IDE ディスクは + ad0, + 2 番目の IDE コントローラに接続されている 1 番目の IDE ディスクは + ad2, + 1 番目の SCSI ディスクは + da0 + などとなります. + + しかしながら, もしあなたが Linux ユーザで, + LILO + で起動プロセスを制御したいのなら, + FreeBSD 用に /etc/lilo.conf を編集して, + FreeBSD のインストールの際 + + を選択します. + FreeBSD のブートマネジャをインストールしたのであれば, + Linux を起動し直して + LILO の設定ファイル + /etc/lilo.conf を変更し, + 次のオプションを加えることができます: + + other=/dev/hdXY +table=/dev/hdb +loader=/boot/chain.b +label=FreeBSD + + こうすれば, LILO から + FreeBSD と Linux を起動することができます. + この例では, ドライブ番号とパーティションを示すために + XY を使っています. + SCSI ドライブを使っているのであれば, + /dev/hdXY を + /dev/sdXY のように読み替えてください. + XY の指定方法は同じです. + + は同じドライブ上に両方のオペレーティングシステムを置いてあるのであれば不要です. + これで /sbin/lilo -v を実行すると + システムに新しい変更が反映されるので, + 画面のメッセージを見て確認します. - <filename>boot1</filename> + 起動ステージ 1 <filename>/boot/boot1</filename> と起動ステージ 2 + <filename>/boot/boot2</filename> + + 概念上, 第 1 ステージと第 2 ステージは + ハードディスクの同じ領域上の同一のプログラムの部分部分です. + スペースの制約のため 2 つに分割されていますが, + いつも一緒にインストールします. - boot1 は起動スライス (slice) の起動セクタにあります. + 第 1 ステージと第 2 ステージは起動スライス (slice) + の起動セクタにあります. 起動セクタとは, MBR 上にある boot0 もしくは他のプログラムが, 起動のプロセスを続けるために - 必要なプログラムがあると想定している場所です. + 必要なプログラムがあると想定している場所です. + /boot + ディレクトリにあるファイルは実際に使われるファイルのコピーで, + 実際のファイルは + FreeBSD ファイルシステムの外部に格納されています. boot1 も非常に単純なプログラムです. これは boot0 同様に, 512 バイトの大きさでなければならないという制限があるためです. - boot1 は boot2 を検索し, + boot1 は boot2 を検索し, 実行するため, そのスライスの情報を保持する FreeBSD - のディスクラベル(disklabel) + のディスクラベル (disklabel) に関する最低限の情報を持っています. - - - - <filename>boot2</filename> boot2 はもう少し高機能です. これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち, - 実行するカーネルやローダを指定するための簡単なインタフェイスを提供する事ができます. + 実行するカーネルやローダを指定するための + 簡単なインタフェイスを提供します. - ローダ(loader)はさらに高機能なもので, + ローダ (loader) + はさらに高機能なもので, 使いやすく簡単な起動設定が行なえる手段を提供します. boot2 は通常それを起動します. - 以前の boot2 は, + 以前の boot2 には, カーネルを直接起動する機能しかありませんでした. <filename>boot2</filename> のスクリーンショット >> FreeBSD/i386 BOOT -Default: 0:wd(0,a)/kernel +Default: 0:ad(0,a)/kernel boot: + + もし仮にインストールされた boot1 と + boot2 を変更したいのであれば, + &man.disklabel.8; を使ってください. + + &prompt.root; disklabel -B diskslice + + diskslice は起動するディスクとスライスで, + 例えば最初の IDE ディスクの 1 番目のスライスは + ad0s1 となります. + + + Dangerously Dedicated Mode + + &man.disklabel.8; を使うとき, + ad0 のようにディスク名だけを指定すると, + スライスを持たない危険な専用ディスクを作成してしまいます. + たぶん間違いなく, そうしたいわけではないでしょうから, + 必ず Return キーを押す前に + &man.disklabel.8; コマンドを二重にチェックしてください. + - - - ローダ(loader): 起動ステージ 3 + + 起動ステージ 3 <filename>/boot/loader</filename> - ブートローダ(boot-loader) + ブートローダ (boot-loader) ローダは三段階の起動プロセスの最終段階です. ローダは通常, ファイルシステム上の /boot/loader として存在しています. - - /boot/boot0, - /boot/boot1, - /boot/boot2 というファイルがありますが, - これらは MBR, - 起動セクタ, ディスクラベルの実際のコピーではありません. - - ローダは, よりさまざまなコマンド群をサポートした 強力なインタプリタによって提供される簡易組み込みコマンド群を利用することで, ユーザが利用しやすい設定手段となるように設計されています. - + ローダプログラムの処理の流れ ローダは初期化の際にコンソールとディスクの検出を行ない, どのディスクから起動しているかを調べます. そして必要な変数を設定してからインタプリタを起動し, - 簡易コマンドを解釈します. + スクリプトからコマンドを送ったり手でコマンドを入力したりできます. ローダ ローダの設定 ローダは次に /boot/loader.rc を読み込み, 通常, 変数の標準値を定義した /boot/defaults/loader.conf と, そのマシンにローカルな変数を定義した /boot/loader.conf を読み込みます. loader.rc はそれらの変数にもとづき, 選択されたモジュールとカーネルをロードします. ローダは最後に, 標準設定で 10 秒のキー入力待ち時間を用意し, 入力がなければカーネルを起動します. 入力があった場合, 簡易コマンド群が使えるプロンプトが表示され, ユーザは変数を調整したり, すべてのモジュールをアンロードしたり, モジュールをロードしたりすることができます. その後, 最終的な起動や再起動へ移行します. - この処理に関するより技術的な説明は - &man.loader.8; にあります. - + - + ローダの組み込みコマンド - 簡易コマンド群は, 次のようなもので構成されています. + もっともよく使われるローダのコマンドを以下に示します. + 利用可能なコマンドをすべて知りたい場合, + &man.loader.8; を参照してください. autoboot seconds seconds で与えられた時間内に入力がなければ, カーネルの起動へと進みます. カウントダウンを表示し, 標準設定では 10 秒間です. boot -options kernelname すぐにカーネルの起動へ進みます. オプション, カーネル名が指定されている場合は, それらが使われます. boot-conf すべてのモジュールの設定を, 起動時と同じように変数にもとづいて自動的に行ないます. このコマンドは, まず unload を行なって, 変数—普通 kernel など—を変更した場合にのみ有効に働きます. help topic /boot/loader.help を読み込み, ヘルプメッセージを表示します. topic に index 指定された場合, 利用可能な topic を表示します. include filename … 指定されたファイル名のファイルを処理します. ローダはファイルを読み込み, 行単位で解釈します. エラーが発生した場合, include コマンドの実行はその時点で停止します. load type filename 指定されたファイル名のカーネル, カーネルモジュール, あるいは type に指定された種類のファイルをロードします. ファイル名以降に指定された引数はファイルへと渡されます. ls path 指定された path にあるファイルを表示します. path が指定されていなければ, ルートディレクトリを表示します. が指定されていればファイルサイズも表示されます. lsdev モジュールがロード可能なすべてのデバイスを表示します. もし が指定されていれば, より詳細な出力がされます. lsmod ロード済みのモジュールを表示します. が指定されていれば, より詳細な内容が出力されます. more filename LINES 単位でスクロールを停止しながら指定されたファイルを表示します. reboot すぐにシステムを再起動します. set variable set variable=value ローダの環境変数を設定します. unload すべてのロード済みモジュールを削除します. - + - + ローダの使用例 次にあげるのは, ローダの実践的な使用例です. シングルユーザモード 普段使っているカーネルをシングルユーザモードで起動します. boot -s 普段使っているカーネルとモジュールをアンロードし, - 古い(もしくは別の)カーネルをロードします. + 古い (もしくは別の) カーネルをロードします. kernel.old unload load kernel.old kernel.GENERIC とすると, インストールディスクに入っていた generic カーネルを指定することができます. - また, 直前にインストールされていたカーネル(たとえば, + また, 直前にインストールされていたカーネル (たとえば, カーネルを自分で設定したり, - アップグレードしたりした場合)を指定するには + アップグレードしたりした場合) を指定するには kernel.old とします. 普段のカーネルで使っているモジュールを 指定したカーネルでロードする場合は, 下のようにします. unload set kernel="kernel.old" boot-conf - カーネルの設定スクリプト(通常, - カーネル起動時に設定される内容を自動化するスクリプト)をロードします. + カーネルの設定スクリプト (通常, + カーネル起動時に設定される内容を自動化するスクリプト) をロードします. - load -t userconfig_script - /boot/kernel.conf + load -t userconfig_script /boot/kernel.conf + カーネル起動時の応答 - カーネル(kernel) + カーネル (kernel) 起動時の応答 - カーネルがローダ(通常は) - かboot2 - (ローダを迂回して)によってロードされると, + カーネルがローダ (通常は) + かboot2 + (ローダを迂回して) によってロードされると, 起動フラグを調べます. もし起動フラグがあれば, それに応じて動作を調整します. カーネル起動フラグ - カーネル(kernel) + カーネル (kernel) 起動フラグ 良く使われる起動フラグは次のとおりです. カーネル初期化中に, ルートファイルシステムとしてマウントするデバイスを尋ねます. CDROM から起動します. 起動時にカーネルコンフィグレーションを行なう UserConfig を実行します. シングルユーザモードで起動します. カーネル起動時により詳細な情報を表示します. 起動フラグはこの他にもあります. それらについては &man.boot.8; を参照してください. init: プロセス制御の初期化 init カーネルの起動が完了すると, init というユーザプロセスに制御が移されます. これは /sbin/init, もしくは loader の init_path 変数で指定される場所にあります. - 自動再起動(automatic reboot)の動作 + 自動再起動 (automatic reboot)の動作 自動再起動では, システム上で利用できるファイルシステムの一慣性を確認します. もしそれに問題があって fsck がその不一致を修復できなければ, 管理者に直接に処置させるため init はシステムをシングルユーザモードへと移行させます. シングルユーザモード シングルユーザモード - コンソール(console) + コンソール (console) このモードには, 自動再起動の処理中か, - ユーザが起動時に を指定た場合, + ユーザが起動時に オプションを指定した場合, あるいは loader で boot_single 変数を設定することによって移行します. また, マルチユーザモードから - 再起動オプション() - や停止(halt)オプション()なしで + 再起動オプション () + や停止 (halt) オプション () なしで shutdown を呼び出すとこのモードに移行します. /etc/ttys でシステムコンソール console が insecure に設定されている場合, システムはシングルユーザモードに移行する前に - root のパスワードを入力するように求めます. + root のパスワードを入力するように求めます. /etc/ttys の insecure コンソール # name getty type status comments # -# This entry needed for asking password when init goes to single-user mode -# If you want to be asked for password, change "secure" to "insecure" here +# If console is marked "insecure", then init will ask for the root password +# when going to single-user mode. # -# 訳) このエントリは init がシングルユーザモードへ移行する際にパスワードを要 -# 求させるために必要です. もし, パスワードの要求を望む場合, ここの "secure" を -# "insecure" へ変更してください. +# 訳) console に "insecure" という印をつけると, シングルユーザモードへ移行する +# 際に init が root のパスワードを要求するようになります. # console none unknown off insecure insecure コンソールとは, あなた自身, コンソールが物理的に安全でないと考えていて, - root パスワードを知る人だけがシングルユーザモードを使えるようにしたいという意味であり, + root + のパスワードを知る人だけがシングルユーザモードを + 使えるようにしたいという意味であり, コンソールを安全でない状態で使いたいという意味ではありません. そのため, 安全性を求めるならば secure でなく insecure を選んでください. マルチユーザモード マルチユーザモード init がファイルシステムが正常であると判断するか, ユーザがシングルユーザモードを終了すると, システムはマルチユーザモードへ移行し, リソースの設定を始めます. - リソース設定(rc) + リソース設定 (rc) rc ファイル群 リソース設定システムはデフォルト設定を /etc/defaults/rc.conf から, そのシステム独自の細かな設定を /etc/rc.conf から読み込みます. そして /etc/fstab に記述されるシステムファイルシステムをマウントし, ネットワークサービスの開始, さまざまなシステムデーモンの開始, そして最後に, ローカルにインストールされた package の起動スクリプトの実行へと進みます. リソース設定システムのに関する参考資料は, &man.rc.8; にあります. これはスクリプトそのものを調べることと同じくらい優れたものです. シャットダウン動作 shutdown shutdown を用いてシステムを意図的にシャットダウンした場合, init は /etc/rc.shutdown というスクリプトの実行を試みます. そして, すべてのプロセスへ TERM シグナルを送り, 続いてうまく終了できなかったプロセスへ KILL シグナルを送ります. diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index 5131dd0298..c79c6150f0 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,1790 +1,2064 @@ - 開発の最前線 - - 改訂: &a.jim;, 2000 年 3 月. + + + + Jim + Mock + 再構成, 再編成および改訂 + + + + + + Jordan + Hubbard + 原作 + + + Poul-Henning + Kamp + + + John + Polstra + + + Nik + Clayton + + + + - 原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;, - およびたくさんのフィードバック. + 開発の最前線 この章では あるリリースから次のリリースまでの期間にも, &os; の開発は休みなく続けられています. この開発の最前線に興味を持っている人のために, 手元のシステムを最新の開発ツリーに同期させておくための, とても使いやすい仕掛けが何種類も用意されています. 注意: 開発の最前線は, 誰もが扱えるという性質のものではありません! もしもあなたが, 開発途中のシステムを追いかけようか, それともリリースバージョンのどれかを使い続けようかと迷っているのなら, きっとこの章が参考になるでしょう. + + この章を読んで分かるのは: + + + 2つの開発ブランチ, &os.stable; と &os.current; の違い + + CVSup, + CVS, もしくは + CTM + を使ったシステム更新方法 + + make world + を使ってベースシステム全体を再構築しインストールする方法 + + + + + この章を読む前に, 以下の準備をしましょう. + + + ネットワーク接続の適切な設定 () + + サードパーティ製のソフトウェアのインストール方法の習得 + () + &os.current; vs. &os.stable; -CURRENT -STABLE FreeBSD には二つの開発ブランチがあります. それは &os.current; と &os.stable; です. この章ではそれぞれについて簡単に説明し, どのようにしてあなたのシステムを対応するツリーに対して, どうやって常に最新の状態に保つかについて扱います. まずは &os.current;, 次に &os.stable; について説明します. 訳: &a.hanai;, 1996 年 11 月 6 日. 最新の &os; を追いかける これを読む前に, 心にとめておいて欲しいことがあります. - &os.current; とは &os; の開発の最前線だということです. + &os.current; とは &os; の開発の 最前線 だということです. + &os.current; のユーザは高い技術力を持つことが要求され, + 自分のシステムが抱える困難な問題を自力で解決できなければなりません. もし &os; を使い始めたばかりなら, これを運用することについて十分検討を重ねた方が良いでしょう. &os.current; ってなに? - &os.current; とは文字通り, - 日々変更されている - &os; のソースのスナップショット以外の何ものでもありません. + &os.current; は &os; の最新の, そして作業進行中のソースです. 中には現在開発途上のソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて, 次の公式リリースに入るとは限りません. &os.current; をソースからほぼ毎日コンパイルしている人は たくさんいますが, 時期によってはコンパイルさえできない状態になっていることもあります. - 一般的に, これらの問題は可能な限り迅速に解決されますが, - &os.current; のソースが不幸をもたらすか, - それとも非常に素晴らしい機能をもたらすかというのは文字通り, - ある与えられた 24 - 時間の間の, - どの部分であなたがソースを手に入れたかによる場合もあるのです. + これらの問題は可能な限り迅速に解決されますが, + &os.current; が不幸をもたらすか, + それとも非常に素晴らしい機能をもたらすかは, + まさにソースコードを手に入れた瞬間によるのです! 誰が &os.current; を必要としてるの? &os.current; は, - 主に次の三つの重要なグループを対象としています. + 次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している &os; グループのメンバ. - 彼らにとっては最新のものにしておくのが + 彼らにとっては 最新のもの にしておくのが 絶対に必要なことなのです. 活発にテストしている &os; グループのメンバ. 彼らは, &os.current; - が健全であることを可能な限り確認するために, - 種々の問題と戦う時間を惜しまない人々です. + が 健全である ことを可能な限り保証するために, + 種々の問題を解決するのに時間を惜しまない人々です. 彼らはまた, 様々な変更に関する提案や &os; の大まかな方向付けを行ないたいと思っている - 人々でもあります. + 人々でもあり, それを実装するためのパッチを提示します. 単に, 様々な事に目を向け, 参考のために (たとえば動かすためではなく読むために) - 最新のソースを使いたいと思っている &os; - (または他の) グループのまわりにいるメンバ. + 最新のソースを使いたいと思っている人々. これらの人々はまた, 時々コメントやコードを寄稿してくれます. &os.current; に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では一番にそれを持ちたいがために, - リリース前のコードの断片を追いかけること. + リリース前のコードの断片を追いかけること. + 新しい機能を得るために一番乗りになるということは, + 新しいバグに最初にぶち当たるということです. - バグを修正するための素早い方法. + バグを修正するための素早い方法. + いかなるバージョンの &os.current; であれ, + 元からあるバグを修正するのと同じく, + 新しいバグを生み出すおそれがあります. - わたしたちが公式にサポートすること. - わたしたちは 3 つの公式な + 公式にサポートする こと. + わたしたちは 3 つの 公式な &os.current; のグループの一つに, 実際に属する人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには, 単に「時間が足りない」のです. これはわたしたちが外の人を助けるの好まない, - ケチで意地悪い人間だということではなく - (もしそうなら &os; なんかやっていません), - 文字通りわたしたちは一日に 400 ものメッセージに答え, + ケチで意地悪い人間だということではありません + (もしそうなら &os; なんてやっていません). + わたしたちは一日に何百通ものメッセージに答え, かつ &os; の作業をすることなど出来ない! - ということなのです. + というだけのことなのです. もし, &os; の改良作業を続けるか, - それともたくさんの質問に答えるか, - という二者択一が与えられたとしたら, - 開発者とユーザのほとんどは前者を支持するでしょう. + それとも実験的なコードに関するたくさんの質問に答えるか, + という二つの選択を迫られたら, 開発者は前者を選ぶでしょう. &os.current; を使う &a.current; と &a.cvsall; に加わってください. これは単に良い考えであるというだけでなく, 必須のことなのです. もし &a.current; メーリングリストに入っていなければ, さまざまな人がシステムの現在の状態について 述べているコメントを見ることは決してありませんし, 従って他の人が既に見つけて解決している 多くの問題に戸惑ってあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. &a.cvsall; メーリングリストでは, それぞれの変更についての commit ログを見ることができます. また, それに関して起こり得る副作用の情報を得ることができますので, 参加する価値のあるメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all majordomo と書いたメールを送ってください. オプションとして本文に help と書けば, Majordomo からあなたへ, わたしたちがサポートする様々なメーリングリストに参加 - /脱退する方法に関する, 詳しいヘルプが送られます. + /脱退する方法に関する詳しいヘルプが送られます. ftp.FreeBSD.org からのソースの入手. 以下の 3 つの方法で行なうことができます. cvsup cron -CURRENT CVSup を使った同期 cvsup を この supfile を用いて使用する. - これは 2 番目に推薦される方法です. + これがもっとも推奨される方法です. なぜなら, cvsup によって一度全体を入手し, 後は変更されたところだけを入手することができるからです. たくさんの人が自動的にソースを最新のものに保つために cvsup を cron から起動しています. - これを行なうための非常に簡単な方法は, 単に - -
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
- とタイプすることです. + 上に挙げたサンプル supfile はカスタマイズして, 環境に合わせて + cvsup を設定する必要があります. + その設定を行なうのにヘルプが必要であれば, 単に + &prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/All/cvsupit-3.1.tgz + とタイプしてください. -CURRENT ftp によるダウンロード ftp を使う. &os.current; のソースツリーは常に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ - で公開されています. - わたしたちはまた, 全体を compress/tar して入手できる - wu-ftpd を使っています. + で 公開 されています. + 全体を compress/tar して入手できる FTP ミラーもあります. たとえば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を tar ファイルとして入手することができます. -CURRENT CTM を使った同期 CTMを用いる. (接続料が高額だったり, email でのアクセスしかできないような) あまり良質でない TCP/IP 接続の場合には, CTM を利用すると良いでしょう. ただし, これには多くの手間がかかりますし, 壊れたファイルを受けとってしまう可能性もあります. そのため, 最近ではあまり使われなくなっており, 長い間使用できなくなってしまう事態が発生する可能性があります (訳注: 保守する人が少ないためです). 9600bps 以上の速度で接続しているなら, CVSup を利用されることを推奨します. もし, ソースを眺めるだけでなく, 走らせるために入手しているのであれば, 一部だけ選ぶのではなく, &os.current; の全体を手に入れてください. なぜなら, ソースのさまざまな部分が他の部分の更新に依存しており, 一部のみをコンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. &os.current; をコンパイルする前に /usr/src にある Makefile を良く読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて時々必要になる他のブートストラップの方法に関して, 常に最新情報を得ることが出来ます. アクティブになって下さい! もし &os.current; を走らせているなら, わたしたちはそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲しています. コードを伴う提案はもっとも歓迎されるものです! 安定版の &os; を使う 訳: &a.jp.iwasaki;. &os.stable; ってなに? -STABLE &os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです. このブランチに加えられる変更は原則として, 事前に &os.current; で試験ずみであるという特徴があります. ただそうであっても, これは開発用ブランチの一つであるということに注意してください. つまり, ある時点における &os.stable; のソースが どんな場合にも使えるものであるとは限らないということです. このブランチはもう一つの開発の流れというだけであって, エンドユーザ向けのものではありません. 誰が &os.stable; を必要としているの? もしあなたが FreeBSD の開発過程に興味があるとか, それに対する貢献を考えていて, 特にそれが - 次回のポイントリリースに関係するもの + 次回の ポイント リリースに関係するもの であるなら &os.stable; を追うことを考えると良いでしょう. セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが, そのために &os.stable; を追う必要はありません. すべての FreeBSD セキュリティ勧告には - 影響のあるリリースで問題点を修正する方法が説明されており, + 影響のあるリリースで問題点を修正する方法が説明されており + これは正確ではありません. + 実際わたしたちは何年もの間古いリリースの FreeBSD + をサポートしてはいるのですが, + 永遠にサポートし続けることはできません. + 現時点での古いリリースの FreeBSD のセキュリティポリシーの全説明を知るには, + http://www.FreeBSD.org/security/ + を参照してください + + , セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは, 同時に望ましくない変更点まで取り込んでしまう可能性があるからです. わたしたちは &os.stable; ブランチがいつも安定に動作するように 努めていますが, それが保証されているというわけではありません. また, コードは &os.stable; に加えられる前に &os.current; で開発されるのですが, &os.stable; のユーザは &os.current; よりも多いため, &os.current; で発見されなかった バグが &os.stable; で発見され, 時々それが問題となることがあるのは 避けることができません. このような理由から, わたしたちは盲目的に &os.stable; を追いかけることを推奨しません. 特に, 最初に開発環境でコードを十分に試験せずに プロダクション品質が要求されるサーバを &os.stable; にアップグレードしてはいけません. もしそうするための資源的な余裕がない場合は, リリース間のバイナリアップデート機能を利用して, 最新の FreeBSD リリースを使うことを推奨します. &os.stable; を使う -STABLE 利用する &a.stable; へ加わってください. このメーリングリストでは, &os.stable; の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更を考えている場合に, このメーリングリストで公表し, 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます. また, &a.cvsall; メーリングリストでは, それぞれの変更がなされると, 起こりうる副作用に関するすべての適切な情報と一緒に commit log を読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo; へメッセージの本文に次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all majordomo オプションとして本文に `help' と書けば, Majordomo はわたしたちがサポートするさまざまなメーリングリストに参加 / 脱退する方法に関する詳しいヘルプを送付します. もし, あなたが新しいシステムをインストールしようとしていて それを可能な限り安定なものにしておきたいなら, 最新のブランチの snapshot を ftp://releng4.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様にインストールしてください. もし, 既に &os; の以前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.org より簡単に これを行う事が出来ます. これには次の 3 つの方法があります. - CTM - - - -STABLE - CTM を使った同期 - - - CTM - 機能を使用する. 転送レートが安定している TCP/IP - 接続でない場合は, この方法が適しています. - - - -STABLE CVSup を使った同期 cvsup を この supfile を用いて使用する. - 一度コレクション全体を入手してしまえば, - 前回からの変更部分だけですむので, 2 - 番目に推奨される方法です. + 一度コレクション全体を入手してしまえば前回からの変更部分だけですむので, + もっとも推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコードを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください.
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 -STABLE FTP を使ったダウンロード ftp を使用する. &os.stable; 用のソースツリーは - 常に次のところで公開されています: + 常に次のところで 公開 されています: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ - 私たちはまた, tar/compress - でツリー全体を入手できる wu-ftpd - を使用しています. 例えば : + compress/tar でツリー全体を入手できる + FTP ミラーもあります. + 例えば: usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体を tar ファイルとして入手することができます. - - + + -STABLE + CTM を使って同期する + + + CTM 機能を使います. + インターネットへの接続に高速で安価な回線を利用できないのであれば, + この方法を検討してみましょう. + + + 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. -STABLE 構築, コンパイル &os.stable; をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. ソースの同期 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対象によって &os; プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: ソースツリーの一部を最新のものに更新することは可能です. ただし, サポートされているアップデート手順は, ソースツリー全体を最新のものに更新して, ユーザランド (/bin や /sbin にあるような, ユーザが実行するプログラム全体のこと) およびカーネルのソースから再構築することのみであることに注意してください. カーネルだけ, あるいはユーザランドだけというように, ソースツリーの一部を更新した場合は, 問題が生じることがよくあります. この時に発生する問題はコンパイル時のエラーからカーネルパニック, データの破壊とさまざまです. anonymous CVS Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. CTM 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの CTM のデルタ は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS - ベースデルタから) 一からやり直し, CTM か anoncvs + ベースデルタ から) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. - - Anonymous CVS, - CTM, CVSup - についての 詳しい情報については, - 以下の節を参照してください. <command>make world</command> の利用 make world FreeBSD のどれか特定のバージョン &os; (&os.stable;, &os.current; など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. バックアップを作成する システムを再構築する前にバックアップを 作成することの重要性は, いくら強調してもし過ぎると言うことはありません. システム全体の再構築とは (以降に書かれた手順に従っている限り)難しい作業ではありませんが, どんなに注意していたとしても, あなた自身, あるいはソースツリーで作業している他の人達に手違いがあった時には, システムが起動しなくなってしまう状態になることがあるのです. まず, バックアップがきちんと作成されていることを確認して, fix-it フロッピーを用意してください. 多分, それを使うことはないと思いますが, あとで後悔することのないよう, 念のため用意しておきましょう. メーリングリストに参加する メーリングリスト もともと, &os.stable; と &os.current; のコードブランチは, 開発中のものです. &os; の作業に貢献してくださっている人達も人間ですから, 時にはミスをすることだってあるでしょう. そのような間違いは, 単に警告を示す見慣れない 診断メッセージをシステムが,表示するような, 全く害のないものであることもあれば, システムを起動できなくしたり, ファイルシステムを破壊してしまうような, 恐ろしい結果を招くものかも知れません. 万が一, このような問題が生じた場合, 問題の詳細と, どのようなシステムが影響を受けるかについて書かれた - 注意(heads up)の記事が + 注意 (heads up) の記事が 適切なメーリングリストに投稿され, そして, その問題が解決されると, - 問題解決(all clear)のアナウンス記事が同様に + 問題解決 (all clear) のアナウンス記事が同様に 投稿されます. - &os.stable; や &os.current; ブランチを試したり, それらに - 追随していくときに - FreeBSD-stable@FreeBSD.ORG や - FreeBSD-current@FreeBSD.ORG - を読まないというのは, 自ら災難を招くことになるでしょう. - + &os.stable; や &os.current; ブランチに追随するために試そうとするのに, + &a.stable; や &a.current; を過去にさかのぼって読まないというのは, + 自ら災難を招くことになるでしょう. 訳注: これらのメーリングリストは英語でやりとりされているため, 日本語での投稿は歓迎されません. 英語でのやりとりができない人は, FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう. <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ, まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう. このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり, あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです. UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します. UPDATING を読むということは, 前述の 適切なメーリングリストを購読する代わりにはなりません. 二つの要求は相補的なもので排他的なものではないのです. <filename>/etc/make.conf</filename> の確認 make.conf まず, /etc/defaults/make.conf と /etc/make.conf を調べてください. そこには 最初から標準的なものが (多くのものはコメントアウトされていますが) 含まれています. ソースからシステムを再構築するときに make が /etc/make.conf に付け加えられた設定を使用します. /etc/make.conf に追加された設定は make を実行したときに常に使われることを覚えておいてください. そのため, システムに必要な設定を書いておくと良いでしょう. 標準的なユーザならおそらく, /etc/defaults/make.conf の CFLAGS と NOPROFILE のコメントをはずすことを考えると思います. 他の定義 (COPTFLAGS, NOPORTDOCS など) の定義行についても, コメントを外す必要があるかどうか調べておきましょう. - <filename>/etc/group</filename> の更新 + <filename>/etc</filename> にあるファイルの更新 /etc ディレクトリには, システム起動時に実行されるスクリプトだけでなく, あなたのシステムの設定に関連する情報の大部分が 含まれています. そのディレクトリに含まれる スクリプトは, FreeBSD のバージョンによって多少異なります. また, 設定ファイルのなかには, 稼働中のシステムが日々利用している ものもあります. 実際には, /etc/group などがそれに該当します. make world のインストールの段階では, 特定のユーザ名, あるいはグループが存在していることを 要求する場面があります. システムのアップグレードを行なう際には, - それらのグループが削除, あるいは変更されて存在していない可能性が + それらのユーザ名やグループが削除, あるいは変更されて存在していない可能性が 考えられますが, そういった場合, システムのアップグレードを 行なっている間に, 問題が発生する原因になります. - この種の例でもっとも記憶に新しいのは, - ppp サブシステムがインストールされる時, - そのサブシステムが利用する + この例で記憶に新しいのは, + smmsp ユーザが追加された時です. + mtree が + /var/spool/clientmqueue + を作成しようとする時, + そのユーザ名 (およびグループ) + が存在しないためにインストールに失敗してしまったのです. 解決方法は, /usr/src/etc/group を調べ, 自分のシステムのグループ名リストと比較することです. 最新のファイルに含まれていて, あなたのファイルに含まれていない グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい. 同様に, 名前が異なるにも関わらず, /etc/group と /usr/src/etc/group で同じ GID を持っているグループ名があれば, /etc/group に含まれる, 該当するすべてのグループ名を変更しておかなければなりません. + 4.6-RELEASE からは, buildworld の前に + をつけて &man.mergemaster.8; を実行してもよいです. + これを実行すると, buildworld や + installworld + が成功するために必要なファイルだけを比較します. + 古いバージョンの mergemaster + を使っていて, がサポートされていない場合, + 最初に実行するときソースツリーにある新しいバージョンのものを使ってください. + + &prompt.root; cd /usr/src/usr.sbin/mergemaster +&prompt.root; ./mergemaster.sh -p + もし, あなたがもっと神経質な人なら, あなたが名前を変更したり, 削除してしまったグループが所有しているファイルを, 次のようにして調べることもできます. &prompt.root; find / -group GID -print これは GID(グループ名もしくは数字で示されたグループ ID)で 指定されたグループが所有するすべてのファイルを表示します. シングルユーザモードへの移行 シングルユーザモード コンパイルは, シングルユーザモードで行なった方が良いでしょう. そうすることで多少速度が向上する, というちょっとした利点が あるだけでなく, システムの再インストールは重要なシステムファイル, 標準コマンド, ライブラリ, インクルードファイルなどを操作します. 稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に) そのような変更を加えることは, トラブルを引き起こす原因となります. マルチユーザモード もう一つの方法として, マルチユーザモードでシステムを再構築して, シングルユーザモードに移行してからそれをインストールする, というのがあります. もしこのような方法で行ないたい場合は, 以下の手順を構築が完了するところまで飛ばしてください. 稼働中のシステムでシングルユーザモードに移行するには, スーパユーザ(root)権限で次のコマンドを実行します. &prompt.root; あるいはシステムを再起動し, ブートプロンプトから フラグを設定することで, シングルユーザモードで システムを起動させることができます. 起動後, シェルプロンプトから 次のように実行して下さい. &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後, / を読み書き可能にして再マウント, /etc/fstab に指定されている, それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします. + + + + CMOS クロックが地域時間に設定されていて + GMT ではない場合, + 次のコマンドを実行する必要があるかもしれません. +&prompt.root; adjkerntz -i + + こうすれば, + 確実に地域時刻が正しく設定されます — これを怠ると, + あとあと問題になるかもしれません. + + <filename>/usr/obj</filename> の削除 システムが再構築される時, 構築されたものは(デフォルトで) /usr/obj 以下のディレクトリに格納され, そのディレクトリの下は /usr/src と同じ構造となります. このディレクトリをあらかじめ削除しておくことにより, make world の行程にかかる時間を短縮させ, 依存問題に悩まされるようなトラブルを回避することができます. /usr/obj 以下のファイルには, 変更不可(immutable)フラグ(詳細は &man.chflags.1; 参照)がセットされているものがある可能性があります. そのため, まず最初にそのフラグを変更しなければなりません. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * ソースの再構築 出力メッセージの保存 実行される &man.make.1; からの出力は, ファイルに保存すると良いでしょう. もし, 何か障害が発生した場合, エラーメッセージのコピーを手元に残すことができます. 何が悪かったのか, あなた自身がそれから理解することはできないかも 知れませんが, &os; メーリングリストに投稿して, 誰か他の人からの助言を得るために利用することができます. ファイルに保存する最も簡単な方法は, &man.script.1; コマンドを 使い, 引数に出力を保存したいファイル名を指定することです. これを make world の直前に行ない, 再構築が終了してから exit と入力すると, 出力を保存することができます. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合, /tmp ディレクトリの中に 保存してはいけません. このディレクトリは, 次の再起動で削除されてしまう可能性があります. 出力の保存には, (上の例のように)/var/tmpや root のホームディレクトリが適しています. - + ベースシステムの構築とインストール まず, カレントディレクトリを /usr/src に 変更しなければなりません. 次のように実行して下さい. &prompt.root; cd /usr/src (もちろん, ソースコードが他のディレクトリにある場合には, /usr/src ではなく, ソースコードのあるディレクトリに移動して下さい). make make world を行なうには, &man.make.1; コマンドを使用します. このコマンドは, Makefile というファイルから, FreeBSD を構成するプログラムの再構築方法や, どういう順番でそれらを構築すべきかといったような 指示を読み込みます. コマンドラインの一般的な書式は, 次のとおりです. &prompt.root; make この例では, が &man.make.1; に渡されるオプションになります. どのようなオプションが利用できるかについては, マニュアルページを 参照して下さい. は, Makefile に渡される変数であり, この変数は Makefile の動作をコントロールします. また, /etc/make.conf で設定される変数も 同様です. これは変数を設定するもう一つの方法として用意されています. &prompt.root; make -DNOPROFILE=true target は, プロファイル版のライブラリを構築しないことを指定する もう一つの記法で, /etc/make.conf 中の NOPROFILE= true # Avoid compiling profiled libraries の行に対応します. target は, &man.make.1; に どのように動作するのかを指示するためのものです. 各々の Makefile には, 数多くの異なる ターゲット(target) が定義されていて, - 指定されたターゲットによって, 動作が決まります. + 指定されたターゲットによって動作が決まります. Makefile に書かれているターゲットには, あなたが指定しても意味を持たないものも含まれます. これらは, システムの再構築に必要な段階を, 多くの さらに細かい段階に分割するため, 構築の過程で利用されるものです. 大抵の場合, &man.make.1; にパラメータを指定する必要はないでしょうから, コマンドラインは次のようなものになるでしょう. &prompt.root; make target &os; の 2.2.5 から(実際には, &os.current; ブランチで最初に作成され, 2.2.2 と 2.2.5 の間の時点で &os.stable; に導入されたのですが), world ターゲットは buildworld と installworld の二つに分割されました. その名前が示すように, buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し, installworld は, そのツリーを 現在のマシンにインストールします. これは, 二つの理由から非常に有用です. まず第一に, 稼働中のシステムに全く影響を与えることなく, 安全にシステムの構築作業を行えることです. - 構築作業は何にも依存せず独立して行なわれるため, + 構築作業は 何にも依存せず独立して行なわれる ため, マルチユーザモードで稼働中のシステムでも, 何一つ 悪影響を与えずに buildworld を 実行することができます. ただし, installworld は シングルユーザモードで行なうことをおすすめします. 第二に, NFS マウントを利用することで, ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます. 例えば三台のマシン, マシン A, マシン B, マシン C をアップグレードしたい場合には, まず マシン A で make buildworld と make installworld を実行します. それから, マシン B とマシン C でマシン A の /usr/src と /usr/obj を NFS マウントし, make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです. world ターゲットも利用可能ですが, このターゲットの利用は推奨されていません. 次のコマンド &prompt.root; make buildworld を実行してください. ここで make に - -j オプションをつけると, 同時にいくつかのプロセスを生成させることが - できます. この機能はマルチ CPU マシンで特に効果を発揮します. + オプションをつけると, + 同時にいくつかのプロセスを生成させることができます. + この機能はマルチ CPU マシンで特に効果を発揮します. 構築過程の大部分では CPU 性能の限界より I/O 性能の限界の方が問題となるため, シングル CPU マシンにも効果があります. 普通のシングル CPU マシンで以下のコマンド &prompt.root; make -j4 buildworld を実行すると, &man.make.1; は最大 4 個までのプロセスを同時に実行します. メーリングリストに投稿された経験的な報告によると, 4 個という指定が最も良いパフォーマンスを示すようです. もし, 複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら, 6 から 10 の間の値を設定し, 速度がどれくらい 向上するか確認してみて下さい. ただし, この機能はまだ実験段階であるということに注意してください. そのため, ソースツリーへ変更が加えられたときに これが正常に機能しなくなる可能性があります. もし, このオプションを用いてシステムの構築に失敗した場合には, 障害を報告する前に, もう一度オプションを付けずに試してみて下さい. システムの構築にかかる時間 make world 時間 構築時間を決める要素はさまざまありますが, - 現時点では Pentium 3 の 500MHz, 128MB の RAM という構成で + 現時点では Pentium III の 500 MHz, 128 MB の RAM という構成で トリックや近道を使わずに普通に構築した場合, - &os.current; の構築に約 3 時間半かかります. - &os.stable; の構築は, もう少し早く終わります. + &os.stable; の構築に約 2 時間かかります. + &os.current; の構築は, もう少し時間がかかります. 新しいカーネルの構築とインストール カーネル(kernel) 構築, コンパイル 新しいシステムの全機能を完全に利用できるようにするには, カーネルの再構築をする必要があります. 再構築は, ある種のメモリ構造体が変更された時には特に必須であり, &man.ps.1; や &man.top.1; のようなプログラムは, カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう. 最も簡単で安全にカーネルの再構築を行なう方法は, GENERIC を使ったカーネルを構築・インストールすることです. GENERIC にはあなたが必要とするデバイスがすべて含まれていない かも知れませんが, あなたのシステムをシングルユーザモードで 起動させるのに必要なものはすべて入っています. これは新しいバージョンのシステムがきちんと動作するかどうか 調べる良い方法の一つです. GENERIC で起動してから, あなたがいつも使っているカーネルコンフィグレーションファイルを 使って新しいカーネルを構築することで, システムが正常に動作しているかどうか確かめることができます. もし &os; 4.0 以降のシステムにアップグレードする場合, ( に記載されている) - 標準的なカーネル構築手順は使えません. - 代わりに, 以下のコマンドを実行する必要があります. + 古いカーネル構築手順はおすすめできません. + 代わりに, + buildworld + を使ってシステムを構築したあとに, + 以下のコマンドを実行してください. &prompt.root; cd /usr/src &prompt.root; make buildkernel &prompt.root; make installkernel &os; の 4.0 以前にアップグレードする場合は, - 標準的なカーネル構築手順に従う必要があります. + 古いカーネル構築手順に従う必要があります. ただし, 以下のコマンドを使って新しいバージョンの &man.config.8; を利用することが推奨されています. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME シングルユーザモードで再起動する single-user mode 新しいカーネルが動作するかどうかテストするために, シングルユーザモードで再起動するべきです. シングルユーザモードでの起動は, に書かれている手順に従ってください. 新しいシステムバイナリのインストール 十分最近のバージョンの &os; を make buildworld で構築しているなら, 次にここで installworld を 使うことで新しいシステムバイナリのインストールを行ないます. それには, 以下のコマンドを実行してください. - &prompt.root; make installworld + &prompt.root; cd /usr/src +&prompt.root; make installworld make buildworld でコマンドラインから 変数を指定した場合は, 同じ指定を make installworld のコマンドラインにも 指定しなければなりません. ただし, オプションについてはその限りではありません. たとえば は installworld で絶対に使ってはいけません. たとえば以下のように実行したなら, &prompt.root; make -DNOPROFILE=true buildworld 以下のようにしてインストールしなければなりません. &prompt.root; make -DNOPROFILE=true installworld もしそうしなかった場合, make buildworld の段階で構築されていない プロファイル版ライブラリをインストールしようとしてしまうでしょう. <command>make world</command> で更新されないファイルの更新 システムの再構築は, いくつかのディレクトリ ( 特に, /etc, や /var や /usr) において, 新規に導入されたり, 変更された設定ファイルによる ファイルの更新は行なわれません. - mergemaster これらのファイルを更新するもっとも簡単な方法は, &man.mergemaster.8; を使うことです. これは自分でやることも可能なので, そうしても かまいません. - &man.mergemaster.8; は簡単に使えるので, こちらを使うことを - お勧めします. その場合には - 次のセクション に進んでください. - まず最初にマニュアルページを読んで, /etc + いずれの方法に従うにせよ, + 必ず /etc のバックアップを取って不測の事態に備えてください. + + <command>mergemaster</command> + mergemaster + + &man.mergemaster.8; ユーティリティは Bourne シェルスクリプトで, + /etc にある設定ファイルとソースツリーの + /usr/src/etc にある設定ファイルの違いを確認するのを手伝ってくれます. + これを使うのが, ソースツリーにある設定ファイルにシステムの設定ファイルを + 更新するために推奨される方法です. + + mergemaster は + 3.3-RELEASE と 3.4-RELEASE の間に FreeBSD + のベースシステムに統合されました. + つまり, 3.3 以降の -STABLE と -CURRENT のシステムにはすべて + これがあるということです. + + 始めるには, プロンプトから単に + mergemaster と入力して, + ファイルの比較を開始するのを見てください. + mergemaster は + / を起点とした一時的なルート環境を構築し, + さまざまなシステム設定ファイルを + (訳注: デフォルトでは /var/tmp/temproot に) + 置いていきます. + 次にこれらのファイルは現在システムにインストールされているファイルと比較されます. + この時点で, 異なるファイルは &man.diff.1; 形式で示され, + の記号は追加または変更された行を表し, + は完全に削除されたか新しく置き換えられた行を表します. + &man.diff.1; の書式とファイルの違いの表示方法についてのより詳しい情報は, + &man.diff.1; を参照してください. + + &man.mergemaster.8; は食い違いが起きているファイルをそれぞれ示します. + ここでは新しいファイル (一時ファイルとして参照されています) を削除するか, + 一時ファイルをそのままインストールするか, + 一時ファイルと現在インストールされているファイルを統合するか, + もしくは &man.diff.1; の結果をもう一度見るか選択できます. + + 一時ファイルの削除を選ぶと, &man.mergemaster.8; + に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます. + この選択は, 現在のファイルを変更する理由が分からないのであれば, + お勧めできません. + mergemaster のプロンプトで とタイプすれば, + いつでもヘルプが見られます. + ファイルのスキップを選ぶと, 他のすべてのファイルを終えたあと, + もう一度そのファイルが提示されます. + + 一時ファイルをそのままインストールすることを選ぶと, + 現在のファイルを新しいファイルで置き換えます. + ほとんどの手を加えていないファイルは, + これが一番よい選択です. + + ファイルの統合を選んだ場合, + テキストエディタが起動され, 両方のファイルの中身が提示されます. + 画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し, + 2 つのファイルを統合することができます. + 並んでいるファイルを比較するとき, + キーで左側の中身を選択し, + キーで右側の中身を選択します. + 最終出力は左右両方の部分でできたファイルになるでしょう. + このファイルをインストールすることができます. + たいてい, このオプシュンはユーザが設定を変更したファイルに使われます. + + diff の結果をもう一度見る, を選択すると, + ちょうど先ほど &man.mergemaster.8; が選択肢を表示する前と同じように, + ファイルの相異点を見ることができます. + + &man.mergemaster.8; がシステムファイルの比較を終えたあと, + 他のオプションについてもプロンプトが表示されます. + &man.mergemaster.8; パスワードファイルを再構築したいかどうか, + MAKEDEV を実行するかどうかを訊かれることがあります. + 最後に残った一時ファイルを削除するかどうかを尋ねて終了します. + + + + 手動での更新 + 手動で更新することを選んだ場合, 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません. これらのファイルには, インストールという - 手順を踏まなければならないものが含まれています. + 手順を踏まなければならないもの が含まれています. /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです. また, /etc にあるべきファイルのうちで /usr/src/etc にないものもあります. + &man.mergemaster.8; を使っているのであれば (お勧めです), + 次のセクションまで飛ばしてもかまいません. + 手動で行う際の 一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから, 以前のものと異なっている部分を調べて更新作業を行なうことです. 既存の <filename>/etc</filename> をバックアップする 理論的に考えて, このディレクトリが自動的に 処理されることはありませんが, 念には念を入れておいて 損はありません. たとえば以下のようにして, 既存の /etc ディレクトリを どこか安全な場所にコピーしておきましょう. &prompt.root; cp -Rp /etc /etc.old は再帰的なコピーを行ない, はファイルの更新時間や所有者などを保存します. また, 新しい /etc やその他のファイルを インストールするための, 仮のディレクトリを作っておく必要があります. 仮ディレクトリは /var/tmp/root に置くのが良いでしょう. 同様に, 必要なサブディレクトリもこの下に置きます. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution 上の例は, 必要なディレクトリ構造をつくり, ファイルをインストールします. /var/tmp/root 以下に作られる, たくさんの空のディレクトリは削除する必要があります. 一番簡単なやり方は, 次のとおりです. &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null これは空ディレクトリをすべて削除します. (空でないディレクトリに関する警告を避けるために, 標準エラー出力は /dev/null に リダイレクトされます) この段階の /var/tmp/root には, 本来 / 以下にあるべきファイルが すべて含まれています. 各ファイルを順に見て, 既存のファイルと異なる部分を 調べて下さい. /var/tmp/root 以下に インストールされているファイルの中には, - . から始まっているものがあります. これを書いている時点で, それに該当するファイルは /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップ ファイルだけですが, 他のものがあるかも知れません. (これは, あなたがこれをどの時点で読んでいるかに依存するので, もっとも簡単な方法は, 二つのファイルを比較するコマンド &man.diff.1; を使うことです. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは, あなたの /etc/shells ファイルと 新しい /etc/shells ファイルの 異なる部分を表示します. これらを, あなたが書き換えたものに変更点をマージするか, それとも既存のファイルを新しいもので上書きするかを 判断する材料にして下さい. 新しい root ディレクトリ (<filename>/var/tmp/root</filename>) の名前に タイムスタンプを付けておくと, 異なるバージョン間の比較を楽に行なうことができます. 頻繁にシステムの再構築を行なうということは, /etc の更新もまた, 頻繁に行う必要がある ということです. これはちょっと手間のかかる作業です. この作業は, あなたが /etc にマージした, 新しく変更されたファイルの最新のセットのコピーを保存しておくことで 素早く行なうことができます. 下の手順は, それを実現するための一つの方法です. 普通に make world します. /etc や 他のディレクトリを更新したくなったときは, ターゲット ディレクトリに, そのときの日付に基づく名前をつけてください. たとえば 1998 年 2 月 14 日 だとすれば, 以下のようにします. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution 上に説明されているように, このディレクトリから変更点をマージします. その作業が終了しても, /var/tmp/root-19980214 を 削除してはいけません. 最新版のソースをダウンロードして再構築したら, ステップ 1 にしたがって下さい. 今度は, /var/tmp/root-19980221 (更新作業が一週間おきだった場合) のような名前の, 新しいディレクトリをつくることになるでしょう. この段階で &man.diff.1; を使用し, 二つのディレクトリを比較する再帰的 diff を作成することで, 一週間の間に行なわれたソースへの変更による相違点を調べます. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 これによって報告される相違点は, 大抵の場合, /var/tmp/root-19980221/etc と /etc との場合に比べて 非常に少ないものになります. 相違点が少ないため, 変更点を既存の /etc ディレクトリにマージすることは, 比較的容易になります. ここまで終了したら, /var/tmp/root-* の 二つのうち, 古い方のディレクトリは削除して構いません. &prompt.root; rm -rf /var/tmp/root-19980214 この工程を, /etc へ変更点をマージする 必要があるたび, 毎回繰り返します. ディレクトリ名の生成を自動化するには, &man.date.1; を利用することができます. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` + <filename>/dev</filename> の更新 DEVFS DEVFS もし DEVFS を利用しているなら, この作業は必要ありません. ほとんどの場合, &man.mergemaster.8; は デバイスの再構築が必要であることを検出して自動的にそれを実行するのですが, ここではデバイスの再構築を手動で行なう方法について説明します. 安全のため, これはいくつかの段階に分けて行ないます. /var/tmp/root/dev/MAKEDEV を /dev にコピーします. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev MAKEDEV /etc を更新するのに &man.mergemaster.8; を使った場合, MAKEDEV スクリプトは既に更新 されているでしょうが, (&man.diff.1; を使って) チェックすることは無駄ではありませんし, 必要なら自分でコピーしてください. ここで, /dev のファイル一覧を記録しておきます. この一覧は, 各ファイルの許可属性, 所有者, メジャー番号, マイナー番号が 含まれている必要がありますが, タイムスタンプは含まれていてはいけません. これを行なう簡単な方法は, &man.awk.1; を使って, いくつかの情報を取り除くことです. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out デバイスファイルをつくり直します. &prompt.root; もう一度, ディレクトリのファイル一覧を記録します. 今回は /var/tmp/dev2.out です. この段階で, この二つのファイル一覧を調べて 作成に失敗したデバイスを探して下さい. 違いは一つもないはずなのですが, 安全のために一応チェックして下さい. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out 次のようなコマンドを使用し, ディスクスライスエントリを 再作成することで, ディスクスライスの矛盾を検出することができます. &prompt.root; sh MAKEDEV sd0s1 適当な組み合わせは, 環境によって異なります. <filename>/stand</filename> の更新 この段階は, 完全な更新を行なう場合にだけ必要な内容を含んでいます. 悪影響はありませんので, 省略しても構いません. 完全な更新を行なうために, /stand にあるファイルも同じように 更新したいと考えるかも知れません. これらのファイルは, /stand/sysinstall という バイナリファイルへのハードリンクです. このバイナリファイルは, 他のファイルシステム(特に /usr)が マウントされていない場合にも動作できるよう, 静的にリンクされていなければなりません. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install 再起動 これで, 作業はおしまいです. すべてがあるべき正しい場所に存在することをチェックしたら, システムを再起動します. これは, 単に &man.fastboot.8; を実行するだけです. &prompt.root; fastboot 作業の完了 ここまで来れば, &os; システムのアップグレードは成功です. おめでとうございます. もしちょっとした問題があった場合でも, システムの一部を再構築するのは簡単です. たとえば, アップグレードの途中で誤って /etc/magic を削除して /etc にマージしてしまい, その結果 file コマンドが動作しなくなってしまったような場合を考えてみてください. これを修復するには, 次のコマンドを実行すれば修復することができます. &prompt.root; cd /usr/src/usr.bin/file &prompt.root; 質問ですか? 変更が行なわれたら, その度にシステムの再構築が必要になるのでしょうか? それは変更の性質によるので, なんとも言えません. - 例えば, CVSup を実行したとき, 最後に実行したときから比べて + 例えば, CVSup を実行したとき, 最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします. src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk このときには, 改めてシステム全体を再構築する必要はないでしょう. 適切なサブディレクトリに移って make all install を行うだけで更新することができます. しかし, もし何らかの大きな変更が行なわれているとき, 例えば src/lib/libc/stdlib が変更されている場合には, システム全体を再構築するか, もしくはそのうち, 少なくとも静的にリンクされているもの(と, あなたが追加した 静的にリンクされたプログラム)を作り直す必要があります. 結局のところ, どの時点で現在のシステムをアップグレードするかは あなたが決めることです. 2 週間ごとにシステムを再構築し, その 2 週間の変更を取り込めば 幸せかもしれませんし, 変更のあった部分だけ再構築し, 依存関係を確かめたいと考えるかも知れません. もちろん, それらはどのくらいの頻度でアップグレードしたいか, そして &os.stable; か &os.current; のどちらを追いかけているのかによります. signal 11(もしくは他のシグナル番号)のエラーがたくさん出て コンパイルが失敗します. 何が起こっているんでしょうか? signal 11 これは通常, ハードウェアに問題があることを示しています. システムの再構築は, ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで, メモリに関係する問題がよく報告されます. その大部分は, コンパイラが奇妙なシグナルを受け取り, 不可解な異常終了となることで発見されます. 本当にこの問題によるものかどうかは, 再構築をもう一度実行し, 異なる段階で異常終了が発生するか, ということから確認できます. この場合には, マシンの部品を交換して, どの部分が悪いのかを 調べてみることくらいしかできることはありません. 終了したら /usr/obj を削除しても かまいませんか? 一言で答えるなら「削除しても構わない」です. /usr/obj には, コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています. - 通常 make world の最初の段階では, このディレクトリを削除して新しくつくり直すようになっています. その場合には, 構築終了後の /usr/obj を保存しておいても, あまり意味はありません. 削除すれば, 大きなディスクスペースを (現在はだいたい 340MB あります) 解放することができます. しかし, もしあなたが何を行なおうとしているのか理解しているなら, - この段階を省略して make world を行なうことができます. こうすると, ほとんどのソースは再コンパイルされないため, 構築はかなり高速化されます. これは裏をかえせば, デリケートな依存関係の問題によって, システムの構築が奇妙な失敗に終わる可能性があるということです. &os; メーリングリストではしばしば, 構築の失敗が, この段階の省略によるものだということを理解せずに 不満の声をあげる人がいます. - - もし, このような危険を承知した上でシステムの再構築を行なう場合には, - 次のように変数 NOCLEAN を定義して構築します. - - &prompt.root; make -DNOCLEAN world 構築を中断した場合, その構築を途中から再開することはできますか? それは, あなたが問題に気付く前に, どれだけの作業を終えているかによって変わります. 一般的に (そしてこれは確実でしっかりした 規則ではありませんが), make world の過程では, 基本的なツール ( &man.gcc.1;, や &man.make.1; のようなもの) や, システムライブラリの新しいコピーが作成されます. その後まず, これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ, もう一度, インストールされます. 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は, その新しいシステムファイルを用いて作り直されることになります. もし, 再構築が最終段階に入っていること が(記録しておいた出力を見たりすることで)わかっていたら, (全く悪影響を与えることなく)次のようにすることができます. … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNOCLEAN all これは, 前回の make world の作業をやり直しません. 次のメッセージ -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- が make world の出力にある場合には, 上のようにしてもほとんど悪影響が現れることはありません. もしこのメッセージがないとか, よく分からないという場合には, 安全を確保し, 後悔するようなことがないよう, システムの再構築を最初からやり直しましょう. - NFS - - - あるマシンを - - - - この作業を行なうのは簡単で, - たくさんのマシンをアップグレードする場合に時間を節約することができます. - これには, 中心となるマシンで buildworld を実行し, - 終了後にリモートマシンで - /usr/src と /usr/obj - を NFS マウントしてから, そこで - installworld します. - - - どのようにすれば make world を高速化できますか? シングルユーザモードで動かしてください. /usr/src と /usr/obj ディレクトリを, 異なるディスク上の別のファイルシステムに置いてください. また可能ならば, 異なるディスクコントローラに接続された ディスクを使って下さい. さらに高速化するには, これらのファイルシステムを &man.ccd.4; (連結ディスクドライバ) デバイスを 使って, 複数のディスク上に置いてください. プロファイル版の作成を無効化して下さい. (/etc/make.conf で NOPROFILE=true をセットします) 普通, それが必要になることはありません. また, /etc/make.conf の中の CFLAGS を, - -O -pipe のように指定しましょう. - -O2 の最適化はさらに多くの時間を必要とし, - しかも -O と -O2 の + のように指定しましょう. + の最適化はさらに多くの時間を必要とし, + しかも と の 最適化には, ほとんど差はありません. - -pipe を指定することで, + を指定することで, コンパイラはテンポラリファイルの代わりにパイプを利用します. その結果, (メモリの利用は増えますが)ディスクアクセスが減ります. - make に オプションを指定して, + &man.make.1; に オプションを指定して, 複数のプロセスを並列に実行させてください. これはプロセッサが単一か複数かによらず, どちらも同様に恩恵を得ることができます. /usr/src のある ファイルシステムを, オプションを付けてマウント(もしくは再マウント)してください. これは, そのファイルシステムにおいて, 最後にアクセスされた時刻の書き込みを抑制します. おそらく, この情報が必要になることはないでしょう. &prompt.root; mount -u -o noatime /usr/src 上の例は, /usr/src 自身が独立したファイルシステムで あることを想定しています. もしそうでないときには (例えば /usr の 一部である場合には), /usr/src ではなく 適切なマウントポイントを指定する必要があります. /usr/obj のあるファイルシステムを, async オプションをつけてマウント (もしくは 再マウント) してください. これによって, ディスクへの書き込みが非同期になります. つまり, 書き込み命令はすぐに完了するのに対し, 実際にデータがディスクに書き込まれるのは, その数秒後になります. これによって, 書き込み処理の一括化が可能になるため, 劇的なパフォーマンスの向上が期待できます. このオプションを指定すると, ファイルシステムは 壊れやすくなってしまうことに注意してください. このオプションを付けていて, 突然電源が落ちた場合には, 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります. もし, /usr/obj 自身が独立した ファイルシステムであるならば, これは問題になりません. しかし, 同じファイルシステムに, 他の貴重なデータを置いているときには, このオプションを有効にする前に, バックアップをきちんと取っておきましょう. &prompt.root; mount -u -o async /usr/obj もし /usr/obj 自身が ファイルシステムでない場合には, 適切なマウントポイントを指すように, 上の例の名前を置き換えて下さい. + + + + なにか悪いことがあったらどうすればいいですか? + + + + 自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください. + とても簡単です. + + &prompt.root; chflags -R noschg /usr/obj/usr +&prompt.root; rm -rf /usr/obj/usr +&prompt.root; cd /usr/src +&prompt.root; make cleandir +&prompt.root; make cleandir + + ええ, make cleandir + は本当に 2 回実行するのです. + + そして, make buildworld を行い, + 全プロセスを最初からやり直してください. + + まだ問題があれば, エラーと uname -a + の出力を &a.questions; に送ってください. + 自分の設定についてさらに質問されても答えられるよう用意してください! + + + + + + + + Mike + Meyer + + + + 複数のマシンで追っかける + + NFS + 複数のマシンにインストール + + + 同じソースツリーを追いかけたいマシンを複数の持っているなら, + 全部のマシンにソースをダウンロードして全部再構築するのは資源, + つまりディスクスペース, ネットワーク帯域, そして CPU サイクルの無駄使いに思えます. + 実際これは無駄で, 解決策は 1 つのマシンに仕事のほとんどをさせ, + 残りのマシンは NFS 経由でそれをマウントする, というものです. + このセクションではそのやり方を概観します. + + + 準備 + + まず初めに, 同じバイナリで動かそうとするマシンたちを決めます. + このマシンたちのことをビルドセットと呼びましょう. + それぞれのマシンはカスタムカーネルを持っているかもしれませんが, + 同じユーザランドバイナリを動かそうというのです. + このビルドセットから, + ビルドマシンとなるマシンを 1 台選びます. + ベースシステムとカーネルを構築するのはこのマシンになります. + 理想的には, このマシンは make world + を実行するのに十分な CPU を持った速いマシンであるべきです. + テストマシンとなるべきマシンも選びたいでしょう. + 更新されたソフトウェアを使う前にそのマシンでテストするのです. + テストマシンはかなり長い時間落ちていても + だいじょうぶなマシンであったほうがいいでしょう. + ビルドマシンでもかまいませんが, ビルドマシンである必要はありません. + + このビルドセットのマシンはすべて + /usr/obj と + /usr/src + を同じマシンの同じ場所からマウントする必要があります. + 理想的にはビルドマシンの 2 つの違うドライブ上にあるとよいのですが, + ビルドマシンに NFS マウントされていてもかまいません. + ビルドセット自体が複数ある場合は, + /usr/src はひとつのビルドマシン上にあるべきです. + 他のマシンからはそれを NFS マウントするようにしましょう. + + 最後にビルドセットの全てのマシン上の + /etc/make.conf + がビルドマシンと一致していることを確認してください. + つまり, ビルドマシンはビルドセットのどのマシンもインストールしようとしている + ベースシステムを全部ビルドしなければならないということです. + また, 各ビルドマシンは /etc/make.conf + にそれぞれのビルドマシンのカーネル名を + KERNCONF で指定し, + ビルドマシンは自分自身のカーネルから順に全部のカーネル名を + KERNCONF にリストアップしてください. + 各マシンのカーネルもビルドするのであれば, + ビルドマシンは各マシンのカーネル設定ファイルを + /usr/src/sys/arch/conf + に持っていなければなりません. + + + + ベースシステム + + さて, 準備は整ったので, ビルドしましょう. + + に書いてあるようにカーネルとベースシステムを構築してください. + でも, まだインストールしないでください. + ビルドが終わったら, テストマシンに移り, + ビルドしたばかりのカーネルをインストールしてください. + テストマシンが NFS 経由で + /usr/src と + /usr/obj をマウントしているなら, + シングルユーザで再起動したときネットワークを使えるようにしてマウントする必要があります. + もっとも簡単な方法は, + マルチユーザモードで起動して, shutdown now + を実行してシングルユーザモードに移行することです. + そうしたら, カーネルとベースシステムをインストールし, + いつもするように + mergemaster を実行できます. + 終わったら, + テストマシンを再起動して通常のマルチユーザ動作に戻します. + + テストマシンにあるものすべてがちゃんと動いている確信が得られたら, + 同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします. + + + + Ports + + ports ツリーにも同じアイデアが使えます. + 最初に重要な点は, + ビルドセットのすべてのマシンに同じマシンの + /usr/ports をマウントすることです. + そして, distfiles を共有するために, + /etc/make.conf を適切に設定します. + NFS マウントによってマップされる root + ユーザが何であれ, DISTDIR + はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります. + 各マシンは WRKDIRPREFIX + を自分のマシンのビルドディレクトリに設定しなければなりません. + 最後に, パッケージをビルドして配布しようとしているなら, + DISTDIR と同じように + PACKAGES ディレクトリも設定してください. + +