diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml
index f71848d995..96f883c938 100644
--- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml
@@ -1,610 +1,608 @@
FreeBSD の起動のプロセス
この章では
起動
ブートストラップ(bootstrap)FreeBSD は通常, 起動(bootstrap)を三段階に分けて行ないます.
これには基本的に, 互いに順番に呼び出される三つのプログラム(二つの
起動ブロック(boot block)と
ローダ(loader))が使われています.
これらのプログラムはそれぞれ,
その前に呼び出されるプログラムの情報に基づいて動作し,
より洗練された機能を提供します.
カーネル(kernel)
init
その後カーネルが起動し, デバイスの検出と初期化を行ないます.
そしてカーネルの起動が終わると, 制御はユーザープロセスの
&man.init.8; へ移されます. &man.init.8; はまず
ディスクが利用可能であることを確かめ,
ファイルシステムのマウント,
ネットワークで利用するネットワークカードのセットアップ,
そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動,
といったユーザーレベルでのリソース(資源)設定を行ないます.
起動ブロック: 起動ステージ 1 および 2
起動(bootstrap)とは,
コンピュータが接続されたデバイスを検出, 初期化し,
必要となるプログラムを動作させることを指します.
起動には起動の際の動作が記録された,
特殊な読み出し専用メモリチップを利用します.
その動作は通常,
メモリテストやデバイスの設定を行なう他のチップに制御を渡し,
そして設定された内容をプログラムに提供するというものです.
BIOS
CMOS
標準的な個人向けコンピュータでは,
BIOS (起動を行なう部分) と
CMOS (設定を記録する部分) によって起動を実現しています.
これらはディスクが存在すること,
そしてオペレーティングシステムをロードするためのプログラムが
ディスク上のどこにあるのかを認識しています.
この章では上に述べたような起動の初期の過程については扱いません.
焦点を合わせるのは,
ディスク上のプログラムに制御が移された後の内容についてです.
起動ブロックは(通常), ローダを見つけて実行する役割を持っています.
したがって, ファイルシステム上のプログラムを見つけること,
実行できること,
そしてその動作に関して最低限の設定が可能である必要があります.
- boot0
-
+ <filename>boot0</filename>
マスターブートレコード (MBR)
- まず実際に最初にあるのは boot0 と呼ばれる起動ブロックです.
+ まず実際に最初にあるのは boot0
+ と呼ばれる起動ブロックです.
これは マスターブートレコード(MBR; Master Boot
Record) という,
システムが起動時にプログラムを検索するディスク上の特殊な部分に存在します.
この部分は, 単に起動可能なスライスのリストが格納されています.
- boot0 は非常に単純なプログラムです.
+ boot0 は非常に単純なプログラムです.
これは, MBR にあるプログラムは
512 バイトの大きさでなければならないという制限があるためです.
- boot0 は, 下のような出力をします.
+ boot0 は, 下のような出力をします.
- boot0 のスクリーンショット
+ <filename>boot0</filename> のスクリーンショット
F1 DOS
F2 FreeBSD
F3 Linux
F4 ??
F5 Drive 1
Default: F2
- boot1
+ <filename>boot1</filename>
- boot1 は起動スライス (slice) の起動セクタにあります.
+ boot1 は起動スライス (slice) の起動セクタにあります.
起動セクタとは,
MBR 上にある boot0
もしくは他のプログラムが, 起動のプロセスを続けるために
必要なプログラムがあると想定している場所です.
- boot1 も非常に単純なプログラムです.
- これは boot0 同様に,
+ boot1 も非常に単純なプログラムです.
+ これは boot0 同様に,
512 バイトの大きさでなければならないという制限があるためです.
boot1 は boot2 を検索し,
実行するため, そのスライスの情報を保持する FreeBSD
のディスクラベル(disklabel)
に関する最低限の情報を持っています.
- boot2
+ <filename>boot2</filename>
- boot2 はもう少し高機能です.
+ boot2 はもう少し高機能です.
これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち,
実行するカーネルやローダを指定するための簡単なインターフェイスを提供する事ができます.
ローダ(loader)はさらに高機能なもので,
使いやすく簡単な起動設定が行なえる手段を提供します.
- boot2 は通常それを起動します. 以前の boot2 は,
+ boot2 は通常それを起動します.
+ 以前の boot2 は,
カーネルを直接起動する機能しかありませんでした.
- boot2 のスクリーンショット
+ <filename>boot2</filename> のスクリーンショット
>> FreeBSD/i386 BOOT
Default: 0:wd(0,a)/kernel
boot:
ローダ(loader): 起動ステージ 3
ブートローダ(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; にあります.
ローダの組み込みコマンド
簡易コマンド群は, 次のようなもので構成されています.
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
+load kernel.old
kernel.GENERIC とすると,
インストールディスクに入っていた
generic カーネルを指定することができます.
また, 直前にインストールされていたカーネル(たとえば,
カーネルを自分で設定したり,
アップグレードしたりした場合)を指定するには
kernel.old とします.
普段のカーネルで使っているモジュールを
指定したカーネルでロードする場合は, 下のようにします.
unload
set kernel="kernel.old"
-boot-conf
-
+boot-conf
カーネルの設定スクリプト(通常,
カーネル起動時に設定される内容を自動化するスクリプト)をロードします.
load -t userconfig_script
/boot/kernel.conf
カーネル起動時の応答
カーネル(kernel)
起動時の応答
カーネルがローダ(通常は)
かboot2
(ローダを迂回して)によってロードされると,
起動フラグを調べます.
もし起動フラグがあれば, それに応じて動作を調整します.
カーネル起動フラグ
カーネル(kernel)
起動フラグ
良く使われる起動フラグは次のとおりです.
カーネル初期化中に,
ルートファイルシステムとしてマウントするデバイスを尋ねます.
CDROM から起動します.
起動時にカーネルコンフィグレーションを行なう
UserConfig を実行します.
シングルユーザモードで起動します.
カーネル起動時により詳細な情報を表示します.
起動フラグはこの他にもあります.
それらについては &man.boot.8; を参照してください.
-
-
+
init: プロセス制御の初期化
init
カーネルの起動が完了すると, init
というユーザプロセスに制御が移されます.
これは /sbin/init,
もしくは loader の
init_path 変数で指定される場所にあります.
自動再起動(automatic reboot)の動作
自動再起動では,
システム上で利用できるファイルシステムの一慣性を確認します.
もしそれに問題があって fsck がその不一致を修復できなければ,
管理者に直接に処置させるため init
はシステムをシングルユーザモードへと移行させます.
シングルユーザモード
シングルユーザモード
コンソール(console)
このモードには,
自動再起動の処理中か,
ユーザが起動時に を指定た場合,
あるいは loader で
boot_single 変数を設定することによって移行します.
また,
マルチユーザモードから
再起動オプション()
や停止(halt)オプション()なしで
shutdown を呼び出すとこのモードに移行します.
/etc/ttys
でシステムコンソール console
が insecure に設定されている場合,
システムはシングルユーザモードに移行する前に
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
#
# 訳) このエントリは init がシングルユーザモードへ移行する際にパスワードを要
# 求させるために必要です. もし, パスワードの要求を望む場合, ここの "secure" を
# "insecure" へ変更してください.
#
console none unknown off insecure
insecure コンソールとは,
あなた自身, コンソールが物理的に安全でないと考えていて,
root パスワードを知る人だけがシングルユーザモードを使えるようにしたいという意味であり,
コンソールを安全でない状態で使いたいという意味ではありません.
そのため, 安全性を求めるならば
secure でなく
insecure を選んでください.
マルチユーザモード
マルチユーザモード
init がファイルシステムが正常であると判断するか,
ユーザがシングルユーザモードを終了すると,
システムはマルチユーザモードへ移行し,
リソースの設定を始めます.
リソース設定(rc)
rc ファイル群
リソース設定システムはデフォルト設定を
/etc/defaults/rc.conf から,
そのシステム独自の細かな設定を
/etc/rc.conf から読み込みます.
そして /etc/fstab
に記述されるシステムファイルシステムをマウントし,
ネットワークサービスの開始,
さまざまなシステムデーモンの開始,
そして最後に, ローカルにインストールされた package
の起動スクリプトの実行へと進みます.
リソース設定システムのに関する参考資料は, &man.rc.8; にあります.
これはスクリプトそのものを調べることと同じくらい優れたものです.
シャットダウン動作
shutdown
shutdown
を用いてシステムを意図的にシャットダウンした場合,
init は
/etc/rc.shutdown
というスクリプトの実行を試みます.
- そして, すべてのプロセスへ終了(terminate)シグナルを送り,
- 続いてうまく終了できなかったプロセスへ
- 強制終了(kill)シグナルを送ります.
-
+ そして, すべてのプロセスへ 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 52d169347c..159f7f90a9 100644
--- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml
@@ -1,1784 +1,1789 @@
開発の最前線
改訂: &a.jim;, 2000 年 3 月.
原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;,
およびたくさんのフィードバック.
この章では
あるリリースから次のリリースまでの期間にも,
&os; の開発は休みなく続けられています.
この開発の最前線に興味を持っている人のために,
手元のシステムを最新の開発ツリーに同期させておくための,
とても使いやすい仕掛けが何種類も用意されています.
注意: 開発の最前線は,
誰もが扱えるという性質のものではありません!
もしもあなたが, 開発途中のシステムを追いかけようか,
それともリリースバージョンのどれかを使い続けようかと迷っているのなら,
きっとこの章が参考になるでしょう.
&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; を使い始めたばかりなら,
これを運用することについて十分検討を重ねた方が良いでしょう.
&os.current; ってなに?
&os.current; とは文字通り,
日々変更されている
&os; のソースのスナップショット以外の何ものでもありません.
中には現在開発途上のソフトウェア,
実験的な変更, あるいは過渡的な機能などが含まれています.
また, この中に入っている機能がすべて,
次の公式リリースに入るとは限りません.
&os.current; をソースからほぼ毎日コンパイルしている人は
たくさんいますが,
時期によってはコンパイルさえできない状態になっていることもあります.
一般的に, これらの問題は可能な限り迅速に解決されますが,
&os.current; のソースが不幸をもたらすか,
それとも非常に素晴らしい機能をもたらすかというのは文字通り,
ある与えられた 24
時間の間の,
どの部分であなたがソースを手に入れたかによる場合もあるのです.
誰が &os.current; を必要としてるの?
&os.current; は,
主に次の三つの重要なグループを対象としています.
ソースツリーのある部分に関して活発に作業している
&os; グループのメンバ.
彼らにとっては最新のもの
にしておくのが
絶対に必要なことなのです.
活発にテストしている &os; グループのメンバ.
彼らは, &os.current;
が健全である
ことを可能な限り確認するために,
種々の問題と戦う時間を惜しまない人々です.
彼らはまた, 様々な変更に関する提案や
&os; の大まかな方向付けを行ないたいと思っている
人々でもあります.
単に, 様々な事に目を向け, 参考のために
(たとえば動かすためではなく読むために)
最新のソースを使いたいと思っている &os;
(または他の) グループのまわりにいるメンバ.
これらの人々はまた,
時々コメントやコードを寄稿してくれます.
&os.current;
に期待しては<emphasis>いけない</emphasis>ことは?
なにか新しくカッコイイモノがあると聞き,
自分の周囲では一番にそれを持ちたいがために,
リリース前のコードの断片を追いかけること.
バグを修正するための素早い方法.
わたしたちが公式にサポートする
こと.
わたしたちは 3 つの公式な
&os.current; のグループの一つに,
実際に属する人々を助けるのにベストを尽くしますが,
技術的なサポートを行なうには, 単に「時間が足りない」のです.
これはわたしたちが外の人を助けるの好まない,
ケチで意地悪い人間だということではなく
(もしそうなら &os; なんかやっていません),
文字通りわたしたちは一日に 400 ものメッセージに答え,
かつ &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 によって一度全体を入手し,
後は変更されたところだけを入手することができるからです.
たくさんの人が自動的にソースを最新のものに保つために
- cvsup を cron から起動しています.
+ cvsup を cron から起動しています.
これを行なうための非常に簡単な方法は, 単に
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです.
-CURRENT
ftp によるダウンロード
ftp を使う.
&os.current; のソースツリーは常に
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/
で公開
されています.
わたしたちはまた, 全体を compress/tar して入手できる
wu-ftpd を使っています.
たとえば,
usr.bin/lex
があったとすると,
ftp> cd usr.bin
ftp> get lex.tar
とすることにより, ディレクトリ全体(この場合,
usr.bin/lex以下全体) を tar
ファイルとして入手することができます.
-CURRENT
CTM を使った同期
CTMを用いる.
(接続料が高額だったり, e-mail でのアクセスしかできないような)
あまり良質でない 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.current; で試験ずみであるという特徴があります.
+ ただそうであっても,
+ これは開発用ブランチの一つであるということに注意してください.
+ つまり, ある時点における &os.stable; のソースが
+ どんな場合にも使えるものであるとは限らないということです.
+ このブランチはもう一つの開発の流れというだけであって,
+ エンドユーザ向けのものではありません.
-
-
誰が &os.stable; を必要としているの?
もしあなたが FreeBSD の開発過程に興味があるとか,
- 次回のポイント
リリースに含まれる予定の
- 新機能を一足早く使ってみたいと考えているなら,
- &os.stable; を追うことを考えるべきでしょう.
+ それに対する貢献を考えていて, 特にそれが
+ 次回のポイント
リリースに関係するもの
+ であるなら &os.stable; を追うことを考えると良いでしょう.
- &os.stable; を追うと, FreeBSD 向けのセキュリティ上の修正を
- 入手することも簡単にできるようになります.
- ただし, そのために &os.stable; を追う必要は
- ありません. すべての FreeBSD セキュリティ勧告には,
- 影響のあるリリースで問題点を修正する方法が説明されているからです.
+ セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが,
+ そのために &os.stable; を追う必要はありません.
+ すべての FreeBSD セキュリティ勧告には
+ 影響のあるリリースで問題点を修正する方法が説明されており,
+ セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは,
+ 同時に望ましくない変更点まで取り込んでしまう可能性があるからです.
わたしたちは &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 を実行し,
+ 多くの人が 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
を使用しています. 例えば :
usr.bin/lex
に対して:
ftp> cd usr.bin
ftp> get lex.tar
とすることにより, ディレクトリ全体を tar
ファイルとして入手することができます.
基本的には,
ソースに迅速でオンデマンドなアクセスが必要で,
接続のバンド幅が問題でなければ, 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
+ (または 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
を使って悪い部分を消去し, 再同期させることによって
すべてを再構築しなければなりません.
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)
の記事が
適切なメーリングリストに投稿され, そして, その問題が解決されると,
問題解決(all clear)
のアナウンス記事が同様に
投稿されます.
&os.stable; や &os.current; ブランチを試したり, それらに
追随していくときに
FreeBSD-stable@FreeBSD.ORG や
FreeBSD-current@FreeBSD.ORG
を読まないというのは, 自ら災難を招くことになるでしょう.
訳注:
これらのメーリングリストは英語でやりとりされているため,
日本語での投稿は歓迎されません. 英語でのやりとりができない人は,
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 など) の定義行についても,
+ 他の定義 (COPTFLAGS,
+ NOPORTDOCS など) の定義行についても,
コメントを外す必要があるかどうか調べておきましょう.
<filename>/etc/group</filename> の更新
/etc ディレクトリには,
システム起動時に実行されるスクリプトだけでなく,
あなたのシステムの設定に関連する情報の大部分が
含まれています. そのディレクトリに含まれる
スクリプトは, FreeBSD のバージョンによって多少異なります.
また, 設定ファイルのなかには, 稼働中のシステムが日々利用している
ものもあります. 実際には, /etc/group
などがそれに該当します.
make world
のインストールの段階では,
特定のユーザ名, あるいはグループが存在していることを
要求する場面があります. システムのアップグレードを行なう際には,
それらのグループが削除, あるいは変更されて存在していない可能性が
考えられますが, そういった場合, システムのアップグレードを
行なっている間に, 問題が発生する原因になります.
この種の例でもっとも記憶に新しいのは,
ppp サブシステムがインストールされる時,
そのサブシステムが利用する
解決方法は, /usr/src/etc/group を調べ,
自分のシステムのグループ名リストと比較することです.
最新のファイルに含まれていて, あなたのファイルに含まれていない
グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい.
同様に, 名前が異なるにも関わらず,
/etc/group と
/usr/src/etc/group で同じ GID を持っているグループ名があれば,
/etc/group に含まれる,
該当するすべてのグループ名を変更しておかなければなりません.
もし, あなたがもっと神経質な人なら, あなたが名前を変更したり,
削除してしまったグループが所有しているファイルを,
次のようにして調べることもできます.
&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 ファイルシステムをすべてマウントしてから
スワップを有効にします.
<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 で /usr/src を
NFS マウントし, make installworld とすることで
構築済みのシステムを各マシンにインストールすることができるのです.
world ターゲットも利用可能ですが,
このターゲットの利用は推奨されていません.
次のコマンド
&prompt.root; make buildworld
を実行してください. ここで make に
-j オプションをつけると, 同時にいくつかのプロセスを生成させることが
できます. この機能はマルチ 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 という構成で
トリックや近道を使わずに普通に構築した場合,
&os.current; の構築に約 3 時間半かかります.
&os.stable; の構築は, もう少し早く終わります.
新しいカーネルの構築とインストール
カーネル(kernel)
構築, コンパイル
新しいシステムの全機能を完全に利用できるようにするには,
カーネルの再構築をする必要があります.
再構築は, ある種のメモリ構造体が変更された時には特に必須であり,
&man.ps.1; や &man.top.1; のようなプログラムは,
カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう.
最も簡単で安全にカーネルの再構築を行なう方法は,
GENERIC を使ったカーネルを構築・インストールすることです.
GENERIC にはあなたが必要とするデバイスがすべて含まれていない
かも知れませんが, あなたのシステムをシングルユーザモードで
起動させるのに必要なものはすべて入っています.
これは新しいバージョンのシステムがきちんと動作するかどうか
調べる良い方法の一つです.
GENERIC で起動してから,
あなたがいつも使っているカーネルコンフィグレーションファイルを
使って新しいカーネルを構築することで,
システムが正常に動作しているかどうか確かめることができます.
もし &os; 4.0 以降のシステムにアップグレードする場合,
( に記載されている)
標準的なカーネル構築手順は使えません.
代わりに, 以下のコマンドを実行する必要があります.
&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
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
のバックアップを取って不測の事態に備えてください.
手動で更新することを選んだ場合,
単にファイルを
/usr/src/etc から /etc に
コピーしただけでは正常に動作させることはできません.
これらのファイルには, インストールという
手順を踏まなければならないもの
が含まれています.
/usr/src/etc ディレクトリは
/etc
ディレクトリにそのまま置き換えられるような
コピーではないからです.
また, /etc にあるべきファイルのうちで
/usr/src/etc にないものもあります.
手動で行う際の
一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから,
以前のものと異なっている部分を調べて更新作業を行なうことです.
既存の <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 を実行したとき, 最後に実行したときから比べて
次にあげるようなファイルが更新されていたとします.
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 には,
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています.
通常 /usr/obj
を保存しておいても, あまり意味はありません.
削除すれば, 大きなディスクスペースを
(現在はだいたい 340MB あります) 解放することができます.
しかし, もしあなたが何を行なおうとしているのか理解しているなら,
この段階を省略して
もし, このような危険を承知した上でシステムの再構築を行なう場合には,
次のように変数 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 を実行し,
+ これには, 中心となるマシンで buildworld を実行し,
終了後にリモートマシンで
/usr/src と /usr/obj
- を NFS マウントしてから, そこで installworld します.
+ を NFS マウントしてから, そこで
+ installworld します.
どのようにすれば make world を高速化できますか?
シングルユーザモードで動かしてください.
/usr/src と
/usr/obj ディレクトリを,
異なるディスク上の別のファイルシステムに置いてください.
また可能ならば, 異なるディスクコントローラに接続された
ディスクを使って下さい.
さらに高速化するには, これらのファイルシステムを
- ccd
(連結ディスクドライバ) デバイスを
+ &man.ccd.4; (連結ディスクドライバ) デバイスを
使って, 複数のディスク上に置いてください.
プロファイル版の作成を無効化して下さい.
(/etc/make.conf で
NOPROFILE=true
をセットします)
普通, それが必要になることはありません.
また, /etc/make.conf の中の
- CFLAGS
を,
+ CFLAGS を,
-O -pipe
のように指定しましょう.
-O2
の最適化はさらに多くの時間を必要とし,
しかも -O
と -O2
の
最適化には, ほとんど差はありません.
-pipe
を指定することで,
コンパイラはテンポラリファイルの代わりにパイプを利用します.
その結果, (メモリの利用は増えますが)ディスクアクセスが減ります.
make に オプションを指定して,
複数のプロセスを並列に実行させてください.
これはプロセッサが単一か複数かによらず,
どちらも同様に恩恵を得ることができます.
/usr/src のある
- ファイルシステムを, noatime
+ ファイルシステムを,
オプションを付けてマウント(もしくは再マウント)してください.
これは, そのファイルシステムにおいて,
最後にアクセスされた時刻の書き込みを抑制します.
おそらく, この情報が必要になることはないでしょう.
&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 自身が
ファイルシステムでない場合には, 適切なマウントポイントを指すように,
上の例の名前を置き換えて下さい.