FreeBSD 3.1-RELEASE 以前では、 インストールの際に必要なのは floppies/boot.flp と名前のついた 一つのフロッピーディスクイメージだけでした。 しかし FreeBSD 3.1-RELEASE 以降、 幅広い種類のハードウェアサポートが基本システムに追加され、 そのサポートが必要とする容量を補うため、 3.X と 4.X の系列では新たに、 floppies/kernel.flp および floppies/mfsroot.flp という、二つのフロッピーディスクイメージを使うようになりました。 これらのイメージをフロッピーディスクに書き込むには、 fdimage や dd(1) といったツールが必要となります。

(DOS ファイルシステムからのインストールなどで) あなた自身が手動で配布ファイルをダウンロードする場合には、 以下の配布ファイルをダウンロードすることをおすすめします。

この手順の完全な説明と、一般的なインストール時の問題については FreeBSD ハンドブックのインストールの節 を参照してください。

3.5 インチ (1.44MB) のフロッピーディスクには、 1474560 バイトのデータを格納できます。 ブートイメージはちょうど 1474560 バイトの大きさです。

ブートフロッピーディスクを準備する際のよくある間違いには、 以下のものがあります。

インストールの説明書はFreeBSD ハンドブックのインストールの章にあります。

386 以上の PC、5MB 以上の RAM、 そして最低 60MB のハードディスク容量が必要となります。 ローエンドの MDA カードでも動作しますが、 X11R6 を使うには VGA かそれ以上のビデオカードが必要となります。

2章ハードウェアコンパチビリティ もご覧ください。

4MB のシステムにインストールできた最後の FreeBSD は FreeBSD 2.1.7 でした。2.2 を含むより新しいバージョンの FreeBSD は新規のインストールに最低 5MB は必要になります。

ただし、インストールプログラムが 4MB では動作しないだけで、 3.0 を含む FreeBSD のすべてのバージョンは 4MB の RAM で動作可能です。 インストールする時だけさらに 4MB 追加しておき、 システムがセットアップされて動作するようになった後、 また 4MB を取り出して元に戻すこともできます。 あるいは 4MB より多くメモリを搭載したシステムにディスクを持っていき、 そのマシンでインストールした後にディスクを戻すこともできます。

また、FreeBSD 2.1.7 であっても、4MB ではインストールできない場合があります。 正確には、640KB のベースメモリ + 3MB の拡張メモリでは、 インストールはできません。もしマシンのマザーボードが 640KB から 1MB の領域で「失われた」メモリを再マップできる場合は、 FreeBSD 2.1.7 をインストールできるかもしれません。

BIOS のセットアップ画面で、「remap」 のオプションを探して有効 (enable) にしてみてください。 また、ROM shadowing を無効 (disable) にする必要もあります。

簡単なやり方としては、インストールする時だけあと 4MB 追加しておく方法があります。 必要なオプションだけを選択してカスタムカーネルを構築し、 また 4MB を取り出してもとに戻せばいいのです。

また、2.0.5 をインストールして、 それから 2.1.7 のインストーラの 「upgrade」 オプションでシステムを 2.1.7 へアップグレード するというやり方もあります。

インストールしたあとでカスタムカーネルの構築をした場合には、 4MB でも動作します。 2MB で起動に成功した人もいます (でもそのシステムは、 ほとんど使いものになりませんでした :-))。

現在はカスタムインストールフロッピーディスク「だけ」を作る方法はありません。 カスタムインストールフロッピーディスクイメージを含む、 release 環境全体を新たに作る必要があります。

カスタムの release 環境をつくるには、 ここの指示にしたがってください。

まず Windows 95/98 をインストールしてから、そのあとで FreeBSD をインストールしてください。FreeBSD のブートマネージャが Win95 と FreeBSD のブート管理をしてくれるようになります。 Windows 95/98 を後にインストールした場合はひどいことに、 問い合わせることもなくブートマネージャを上書きしてしまいます。 そうなってしまった場合は次の節をご覧ください。

ブートマネージャの再インストールの方法として、 FreeBSD では以下に示す三通りの方法が用意されています。

これらのマシンに使われている初期のリビジョンの IBM BIOS にはバグがあり、FreeBSD のパーティションをディスクサスペンド用の FAT 領域だと誤認します。 そのため、BIOS が FreeBSD のパーティションを 検出したところでシステムがハング (停止) してしまいます。

IBM ^[1] によれば、以下のモデル/BIOS リリース番号には修正が含まれています。

それより新しいリビジョンの BIOS にまたバグが入り込んだか もしれないという報告がありました。Jacques Vidrine は <mobile@freebsd.org> メーリングリストにあてた メッセージ で、これ以降の IBM の laptop で FreeBSD が正常に起動しない 場合におそらくうまく行く、BIOS をアップグレードまたは ダウングレードできる手順を説明しています。

もし問題のある BIOS を使っていてアップグレードが選べない場合、 FreeBSD をインストールしてから FreeBSD が使っているパーティション ID を変更し、 変更されたパーティション ID を正しく扱うことのできる 新しい起動ブロックをインストールすることで解決することができます。

それにはまず、 セルフテスト画面を通過する状態にまでマシンを回復させる必要があります。 そのためには、マシンがプライマリディスクから FreeBSD パーティションを見つけないようにして起動しなければなりません。 たとえば、一度ハードディスクを外してしまって、そのディスクを古い ThinkPad (ThinkPad 600 など) やデスクトップ PC に適切な変換ケーブルで接続します。 その後 FreeBSD のパーティションを削除し、 ハードディスクを元の ThinkPad に戻します。 こうすることで ThinkPad は起動可能な状態に戻るはずです。

マシンがちゃんと動くようになったら、 以下の復旧手順に従って FreeBSD をインストールすることができます。

この方法で FreeBSD と OpenBSD をデュアルブートする方法は、読者への練習問題としましょう。

FreeBSD 3.0 以前のシステムでは、 不良ブロックを自動的に再マッピングする bad144 というユーティリティが含まれていましたが、 現在の IDE ドライブはドライブ自身がこの機能を備えているため、 bad144 は FreeBSD ソースツリーから削除されました。 FreeBSD 3.0 かそれ以降をインストールしたいと思っているなら、 比較的新しいディスクドライブを購入することを強くおすすめします。 新しいドライブを購入する気がなければ、FreeBSD 2.x を利用するべきです。

現在の IDE ドライブで不良ブロックによるエラーが発生した場合、 まもなくドライブが故障する可能性があります (それはそのドライブ内蔵の再マッピング機能では 不良ブロックが修正できなくなったということであり、 ディスクがひどく壊れていることを意味します)。 新しいハードディスクドライブに交換しましょう。

不良ブロックのある SCSI ドライブの場合は、 この回答を参照してください。

インストーラから起動しようとしたときに、マシンが固まってし まうとか自然と再起動してしまうといった現象であれば、 次の三つの項目を確認してください。

また、Netscape でブートイメージをダウンロードする場合も問題があることが報告されていますので、 できれば別の FTP クライアントを使うのがよいでしょう。

この問題は通常、CD-ROM ドライブの設定ミスによって発生します。 大部分の PC の CD-ROM ドライブは、 セカンダリ側の IDE コントローラのスレーブデバイスとして接続され、 マスタデバイスがない状態で出荷されています。 この接続方法は ATAPI 規格違反なので、 Windows は規格どおりに動いたり、動かなかったりしますが、 BIOS は起動時に規格違反を無視します。 そのため BIOS は起動時に CD-ROM を見つけられますが、 FreeBSD は CD-ROM を見つけられず、 インストールを完了できないのです。

CD-ROM が 接続されている IDE コントローラのマスタデバイスとなるように設定するか、 もしくはマスタ、 スレーブの両方にデバイスが接続されているようにシステムを再構成してください。

FreeBSD 2.1.7R をテープからインストールする場合、 tar ブロックサイズを 10 (5120 バイト) にしたテープを作る必要があります。 デフォルト の tar ブロックサイズは 20 (10240 バイト) で、 このデフォルトサイズで作られたテープでは FreeBSD 2.1.7R をインストールすることはできません。 もしこうしたテープを使うと、 レコードサイズが大きすぎるというエラーが起きることになります。

Laplink パラレルケーブルを用意して、 両方の PC のカーネルに lpt ドライバが組み込まれていることを確認してください。

% dmesg | grep lp
lpt0 at 0x378-0x37f irq 7 on isa
lpt0: Interrupt-driven port
lp0: TCP/IP capable interface

パラレルインタフェースに Laplink パラレルケーブルを接続します。

root になって、両方で lp0 のネットワークインタフェースパラメータを設定します。 たとえば、ホスト max と moritz を接続したい場合、

                max <-----> moritz
IP Address      10.0.0.1        10.0.0.2

max 側で次のようにして、

# ifconfig lp0 10.0.0.1 10.0.0.2

moritz 側で同様に次のようにします。

# ifconfig lp0 10.0.0.2 10.0.0.1

以上です! lp(4) と lpt(4) のマニュアルページも参照してください。

また、 /etc/hosts にホストの追加もしましょう。

127.0.0.1               localhost.my.domain localhost
10.0.0.1                max.my.domain max
10.0.0.2                moritz.my.domain moritz

動作確認は次のようにします。

max 側:

% ifconfig lp0
lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000

% netstat -r
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use     Netif Expire
moritz              max              UH          4   127592       lp0

% ping -c 4 moritz
PING moritz (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms

--- moritz ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms

次のようにして、二つのコンピュータを Laplink パラレルケーブルで接続してください。

また、 Mobile Computing についてのページもご覧ください。

これについてはある理由のために、誤解されている点が多いようです。 まず最初に、FreeBSD はディスクブロックで動作しているため、 SCSI ドライブの 「物理的」 なジオメトリという言い方は、 まったく見当違いのものです。事実、 セクタの密度はディスクによってまちまちであるため、 物理的なジオメトリというものは存在しません。 製造者が 「本当の」 物理的なジオメトリと公表しているものは通常、 彼らが検査して得た最小の使用不可容量の結果のジオメトリのことです。 IDE の場合、FreeBSD は C/H/S で動作しますが、 最近のドライブはすべて、これを内部で参照するブロックに変換しています。

問題はとなるのは論理的なジオメトリです。 これは BIOS がそのディスクのジオメトリについて調べた際に取得されるものであり、 その後のディスクへのアクセスに使用します。 FreeBSD は起動時に BIOS を使用するため、 これを正しく取得することは非常に重要なことなのです。 実際に、ディスク上に複数のオペレーティングシステムがある場合は、 ジオメトリはどこからでも同じように解釈される必要があります。 そうしないと、起動時に深刻な問題が発生します。

SCSI ディスクでは、 使用するジオメトリはコントローラの拡張 BIOS トランスレーション (「>1GB の DOS ディスクドライブのサポート」 とも呼ばれます) が有効になっているかどうかによります。 無効になっている場合、N シリンダ、64 ヘッド、 32 セクタ/トラックを使用しますが、 ここで `N' は MB 単位のディスク容量です。 たとえば、2GB ディスクは見かけ上 2048 シリンダ、64 ヘッド、 32 セクタ/トラックとなります。

それが「有効」になっており (MS-DOS ではこの方法で、ある制限を回避する場合もあります)、 ディスク容量が 1GB を越える場合は、M シリンダ、 63 セクタ/トラック (64 「ではなく」)、 255 ヘッドを使用します。 `M' は MB 単位のディスク容量を 7.844238(!) で割った値となります。 ということで、2GB ディスクの例では、 261 シリンダ、63 セクタ/トラック、255 ヘッドとなります。 (訳注: 以上は Adaptec 社と NCR 社製の SCSI アダプタの場合です。 SCSI アダプタによって変換の数値が変わってくるのでマニュアルを 参照してください)。

これについてよく分からない場合や FreeBSD がインストール中に正しくジオメトリを取得できない場合、 これを回避するもっとも簡単な方法は、 ディスクに小さな DOS パーティションを作ることです。 そうすると正しいジオメトリが取得されるはずです (そして、 残しておきたくないとか、 ネットワークカードのプログラミング用に使いたい場合などには、 いつでもパーティションエディタで DOS パーティションを削除することができます)。

もう一つの方法として、FreeBSD と一緒に配布されているフリーで使えるユーティリティに pfdisk.exe (FreeBSD CD-ROM の tools ディレクトリや、他のさまざまな FTP サイトにあります)と呼ばれるものがあり、 ディスク上の他のオペレーティングシステムが使用している ジオメトリを調べるのに役立ちます。 このジオメトリ情報は、 パーティションエディタに入力することができます。

はい。 BIOS がカーネルを起動できるようにルートパーティションが 1024 シリンダ以内にあることを確認する必要があります (これは FreeBSD ではなく PC の BIOS の制限です)。

SCSI ドライブでは、通常はルートパーティションが最初の 1024MB に収まっていることが前提となります (または拡張 BIOS トランスレーションが有効になっている場合は最初の 4096MB - 他の質問をご覧ください)。IDE でそれに相当する値は 504MB となります (訳注: E-IDE 対応の BIOS 搭載マシンの場合は IDE の 504MB という制限はありません)。

FreeBSD は Ontrack Disk Manager を認識し、これを考慮にいれます。 他のディスクマネージャはサポートしません。

ディスク全体を FreeBSD で使いたい場合、 ディスクマネージャは必要ありません。 BIOS が扱える容量 (通常 504MB) いっぱいでディスクの設定を行なうと、 FreeBSD は実際の容量を算出するはずです。 MFM コントローラ付きの古いディスクを使っている場合は、 FreeBSD に使用するシリンダ数を詳細に指定する必要があります。

FreeBSD と他のオペレーティングシステムが入っているディスクを使用したい場合は、 ディスクマネージャなしでもできるでしょう。 FreeBSD の起動パーティションと他のオペレーティングシステム用のスライスが、 最初の 1024 シリンダ内に収まっている事を確認するだけです。 気になる方は、起動パーティションを 20 メガバイトぐらいにして大きめにするとよいでしょう。

これは FreeBSD や DOS、 そのほかの OS がディスク領域ジオメトリ のとらえ方で衝突しあっていることから起こる典型的な例です。 こうなったら FreeBSD をインストールし直す以外にはありませんが、 他のところで説明した手順にしたがってやれば、 ほぼ間違いなくうまくいくはずです。

これはすでに前に質問されている問題のもう一つの症状です。 BIOS のジオメトリと FreeBSD のジオメトリ設定が一致していないのです! コントローラや BIOS がシリンダの変換 (>1GB ドライブの サポートとも呼ばれます) をサポートしていたら、 その設定を無効化して FreeBSD をインストールし直してみてください。

一般的には「いいえ」です。 しかし最低でも、base ソースキット (これにはこの FAQ で述べられているファイルのいくつかが含まれています) と、 sys (kernel) ソースキット (これにはカーネルのソースが含まれています) をインストールする事を強くおすすめします。 通常、何かの実行にソースが必要になる事はありません。 しかし、カーネルをコンフィグレーションするためのプログラム config(8) を実行する時は例外です。 カーネルのソースをインストールしなくてもよい例として、 どこか別の場所からカーネルのソースを読み込み専用で NFS マウントすることができます。また、 そこから新しいバイナリを作成できるようにもなっています (カーネルソースの制限があるので、直接 /usr/src をマウントする事はおすすめできません。 それよりもどこか別のディレクトリにマウントして、 ソースツリーの複製ができるように適切にシンボリックリンクを張ってください)。

ソースをネットワーク上に持ち、 そこからシステムをビルドするようにしておけば、 FreeBSD の将来のリリースへのアップグレードがずっと簡単になります。

実際にソースのサブセットを選択するには、 システムインストールツールの「配布ファイル」メニューにある、 「カスタム」メニューを使用します。

カーネルを新しく作り直すのは元々、 FreeBSD のインストール時に必須の作業でした。 でも最近のリリースでは、 とてもユーザフレンドリなカーネル設定ツールの恩恵を受けています。 FreeBSD の起動プロンプト (boot:) で -c とタイプすればビジュアルな設定画面になり、 ほとんどの一般的な ISA カードについてのカーネルの設定をすることができるのです。

今でも、 必要なデバイスドライバだけを組み込んだカーネルを作ることはよい事とされています。 ほんのちょっとだけメモリを節約できますからね。 でもほとんどのシステムでは、 もはやどうしてもやらなくちゃならないことではないのです。

FreeBSD の標準のパスワードフォーマットは MD5 を使ったものです。 これは DES アルゴリズムに基づいた手法を用いる UNIX の伝統的なパスワードフォーマットより安全 (secure) だと 信じられているものです。 DES パスワードは あなたが FreeBSD のパスワードファイルを、 安全性に劣るパスワードフォーマットを利用している古い OS と共有しなければならなくなったときのために 利用可能になっています (これは利用するためには、 sysinstall から 「crypto」 配布物のインストール 選ぶか、ソースから build しているなら、 crypto のソースがインストールされている必要があります)。 新しいパスワードにどちらのパスワードフォーマットを使うかは /etc/login.conf の中の 「passwd_format」 という login ケーパビリティで制御されます。このケーパビリティは 「des」 (利用できるなら) か 「md5」 のどちらかの値を取ります。 login ケーパビリティの詳細については login.conf(5) を 参照してください。

IDE Zip か Jaz ドライブが接続されていたら、 それを取り外してもう一度試してみましょう。 ブートフロッピーはこの種のドライブを誤認してしまうのです。 システムがインストールされた後は、そのドライブを再度接続することができます。 うまくいけばこの問題は将来のリリースで解決されるでしょう。

このエラーはディスクデバイスについて、 起動ブロックとカーネルの認識が混乱しているために起こります。 このエラーは通常、 2 台の IDE ディスクがそれぞれ別の IDE コントローラのマスターに一つずつ接続されているシステムにおいて、 FreeBSD がセカンダリ IDE コントローラに接続されたディスクにインストールされている場合に発生します。 起動ブロックは FreeBSD が wd1 (2 台目の BIOS ディスク) にインストール されていると認識するのに対し、 カーネルはセカンダリ IDE の 1 台目のハードディスクである wd2 にインストールされていると認識するのです。 デバイス検出後で、 カーネルは起動ブロックが起動ディスクだと認識したディスクである wd1 をマウントしようとします。 しかし、実際には起動ディスクは wd2 なので失敗してしまうのです。

この問題を解決するには、以下のどれか一つを行ってください。

認識できるメモリの上限は、4GB です。 この構成は試験済みで、 詳細は wcarchive's configuration をご覧ください。 このようにたくさんのメモリをマシンに導入しようという場合には、 注意が必要です。ECC 機能をサポートし、なおかつ 容量性負荷 (訳注: 多くのメモリ素子は容量性負荷として働きますが、 メモリバス上に容量性負荷が増えると信号の伝達が遅れ、誤動作の原因となります) を 低減させるため、18 チップ構成のメモリモジュールより 9 チップ構成のメモリモジュールを選択することが、おそらく望ましいでしょう。

ffs ファイルシステムの場合、 論理的な最大の上限は 8 TB (2G ブロック)、 デフォルトのブロックサイズを 8K とすると 16 TBとなります。 実際問題として、1 TB のソフトウェアの限界がありますが、 修正すれば 4 TB のファイルシステムが可能です (実際に存在します)。

一つの ffs のファイルの最大のサイズは、ブロックサイズが 4K の場合で 約 1G ブロック (4 TB)です。

fs ブロックサイズが 4K の場合は三重間接ブロックが使用され、 いずれの場合でも三重間接ブロックを使用して表現できる最大の fs ブロック番号 (およそ 1K^3 + 1K^2 + 1K) に制限されるはずなのですが、 実際は fs ブロック番号の (間違った) 上限 1G-1 で制限されます。 fs ブロック番号の制限は 2G-1 となるはずです。2G-1 付近に fs ブロック番号のバグが多少ありますが、fs ブロックサイズが 4K の場合は、ここまでのブロック番号には到達しません。

ブロックサイズが 8K 以上の場合、いずれの場合も fs ブロック番号の上限 2G-1 で制限されるはずですが、 実際は fs ブロック番号の上限 1G-1 で制限されます。 例外的に -STABLE では三重間接ブロックまでは到達しないため、 制限は二重間接ブロックで表現できる最大の fs ブロック番号 (およそ (blocksize/4)^2 + (blocksize/4)) となります。 -CURRENT ではこの制限を超えると問題を引き起こすかもしれません。 正しい制限値である 2G-1 ブロックを使用すると明らかに問題が出ます。

わたしのところでは、 フロッピーにいくつかの実際のファイルを保存しています :-)。 最大のファイルサイズは最大のディスクサイズとはあまり関係はありません。 最大のディスクサイズは 1 TB です。 ファイルサイズがディスクサイズより大きくなりうるというのは仕様です。

以下の例は、32K のディスク容量 (3 つの間接ブロックと 1 つのデータブロック) を使って、 小さなルートパーティションに 8T-1 の大きさのファイルを作成します。 ここでの dd コマンドは大きなファイルが扱えるものが必要です。

% cat foo
df .
dd if=/dev/zero of=z bs=1 seek=`echo 2^43 - 2 | bc` count=1
ls -l z
du z
df .
% sh foo
Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
/dev/da0a         64479    27702    31619    47%    /
1+0 records in
1+0 records out
1 bytes transferred in 0.000187 secs (5346 bytes/sec)
-rw-r--r--  1 bde  bin  8796093022207 Sep  7 16:04 z
32      z
Filesystem  1024-blocks     Used    Avail Capacity  Mounted on
/dev/da0a         64479    27734    31587    47%    /

ローダがスタートする前の | が表示されているときに何かキーを押すことで、 起動のセカンドステージから直接、起動するカーネルを指定して起動することができます。 特に、カーネルのソースを更新し、make world しないで新しいカーネルだけインストールした場合にこの症状が現われます。 こういう操作は動作が保証されません。きちんと make world してください。

アップグレードには、 バイナリスナップショットを使うことを強くおすすめします。 4-STABLE スナップショットは releng4.FreeBSD.org から入手可能です。

ソースを使ってアップグレードする場合は、詳細について FreeBSD ハンドブックを参照するようにしてください。

「セキュリティプロファイル」とは、特定の プログラムやその他の設定を有効にしたり無効にすることで、求める 比率で安全と便利さを実現しようとする構成の選択肢の集まりの ことです。セキュリティプロファイルが厳しいほど、デフォルトで 有効になるプログラムが減ります。これは、動かさなければならない もの以外は、何も動かしてはいけないというセキュリティの 基本的原則の一つです。

セキュリティプロファイルは、単にデフォルトの設定である ということに気をつけてください。FreeBSD をインストールした あとに /etc/rc.conf に適切な行を編集したり 追加すれば、どのプログラムでも有効にしたり無効にしたりできます。 後者について詳しいことは rc.conf(5) のマニュアルを ご覧ください。

以下に、各セキュリティプロファイルが何を行うかを説明した 表を掲載します。列はセキュリティプロファイルの選択肢で、行は 有効または無効になるプログラムや機能です。

FreeBSD は、EIDE と SCSI ハードディスクドライブをサポートしています (互換コントローラも含みます。 次の節参照)。 また独自の 「Western Digital」 インタフェースを使用しているすべてのドライブ (MFM、 RLL、ESDI、もちろん IDE) もサポートしています。 独自仕様のインタフェースを使用する ESDI コントローラでは動作しないものがあり、 WD1002/3/6/7 とその互換インタフェースと衝突します。

FreeBSD ハンドブックに記されている完全なリストを参照してください。

サポートされている SCSI コントローラに接続できる SCSI ドライブは、すべてサポートされています。

また、以下の専用 CD-ROM インタフェースもサポートしています。

SCSI でないカードはすべて、SCSI ドライブよりも極めて動作速度が 遅いことが知られており、ATAPI CD-ROM には動作しないものもあるようです。

BSDi の FreeBSD 2.2 CD-ROM からは CD からの直接起動が サポートされています。

FreeBSD は ATAPI 互換の IDE CD-R または CD-RW ドライブで あれば対応しています。FreeBSD バージョン 4.0 以降については、 burncd(8) のマニュアルをご覧ください。それ以前の バージョンの FreeBSD では、 /usr/share/examples/atapi にある例を ご覧ください。

また、FreeBSD は SCSI の CD-R または CD-RW ドライブにも 対応しています。ports または packages から cdrecord コマンドをインストールして、 カーネルに pass デバイスが組み込まれて いることを確認してください。

もちろん、 FreeBSD は SCSI ZIP ドライブ (外付け) をサポートしています。 ZIP ドライブは SCSI ID を 5 か 6 に設定した状態でなら使用できますが、 もし SCSI ホストアダプタの BIOS がサポートしてさえいれば ZIP ドライブから起動させることもできます。 どのホストアダプタが SCSI ID を 0 や 1 以外に設定したデバイスから 起動できるのかはわかりません。そうしたい場合は、アダプタの ドキュメントを参照しなければなりません。

ATAPI (IDE) ZIP ドライブは、FreeBSD 2.2.6 以降のバージョンでサポートされています。

バージョン 3.0 以降の FreeBSD では、 パラレルポート接続の ZIP ドライブをサポートしています。 最近のバージョンの FreeBSD をお使いでしたら、 カーネルコンフィグレーションファイルに scbus0、 da0、 ppbus0、 vp0 の各ドライバが記述されていることを確認してください。 (GENERIC カーネルには vp0 を除くすべてのドライバが含まれています)。 これらすべてのドライバがあれば、 パラレルポートのドライブは /dev/da0s4 となります。 ディスクは mount /dev/da0s4 /mnt とするか mount_msdos /dev/da0s4 /mnt (DOS ディスクの場合) とすることでマウントできます。

それからリムーバブルドライブに関する注意および、 「フォーマット」に関する注意についても 確認しておいてください。

FreeBSD では、IDE バージョンの EZ ドライブを除くすべての SCSI デバイスは、 SCSI のディスクと同等に扱われます。 また IDE EZ は IDE ドライブと同等となります。

システム稼働中のメディア交換について FreeBSD がどれほどうまく動くか定かではありません。 もちろんメディアを入れ替える前にそのドライブのマウントを解除しなければいけないでしょうし、 FreeBSD がそれらを認識するには、 起動時に外部ユニットにも電源が投入されていることを確認しなければいけないでしょう。

「フォーマット」に関する注意も参照のこと。

一覧は その他のデバイスの節にあります。

無名のカードにもうまく動くものがあり、 特に AST 互換といわれているものに多く見られます。

カード設定の詳細な情報は、sio(4) のマニュアルページを参照してください。

USB デバイスは FreeBSD 3.1 からサポートされましたが、 実装は FreeBSD 3.2 であってもまだ完全ではないため、 必ずしも安定して動作するとは限りません。 もし、それでも USB キーボードを使ってみたいという人は、 以下の手順を試してみてください。

システムを再起動させた後、 AT、USB 両方のキーボードが接続されていれば、 AT キーボードは /dev/kbd0 に、 USB キーボードは /dev/kbd1になります。 一方、USB キーボードだけが接続されているなら、 /dev/ukbd0 となります。

USB キーボードをコンソールで利用するには、 それをコンソールドライバに対して明示的に指定する必要があります。 システムの初期化の際に、次に示すようなコマンドを実行してください。

# kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null

ただし、USB キーボードしか接続されていない場合、それは /dev/kbd0 としてアクセスされますので、 コマンドは次のようにしなければなりません。ご注意ください。

# kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null

上のコマンドは、/etc/rc.i386 に追加すると良いでしょう。

この設定を一度行なっていれば、 X 環境でも特に他の設定なしに USB キーボードが利用できます。

USB キーボードの活線挿抜 (ホットプラグ機能) は、 まだおそらくきちんと動作しないと思われます。 トラブルを避けるためにも、キーボードはシステムを起動させる前に接続しておき、 シャットダウンするまではずさないようにした方が良いでしょう。

詳細については、ukbd(4) のマニュアルページを参照してください。

FreeBSD は Microsoft、Logitech、 ATI 等のメーカーから出ているバスマウスと InPort バスマウスをサポートしています。FreeBSD 2.X の場合、 バスマウスのデバイスドライバは GENERIC カーネルに標準で含まれますが、 FreeBSD 3.X 以降では標準で含まれていません。もしバスマウスのデバイス ドライバを含むカーネルを自分で構築する場合には、 カーネルコンフィグレーションファイルに以下の行が含まれていることを確認してください。

それは FreeBSD 3.0 を含む、それ以前のリリースの場合は次のとおり、

device mse0 at isa? port 0x23c tty irq5 vector mseintr

FreeBSD 3.X では、次のとおりです。

device mse0 at isa? port 0x23c tty irq5

そして FreeBSD 4.X とそれ以降では、次のようになります。

device mse0 at isa? port 0x23c irq5

通常バスマウスには専用のインタフェースカードが附属しています。 インタフェースカードによってはポートアドレスや割り込み番号を上記の 設定以外に変更できるかもしれません。詳しくはバスマウスのマニュアルと mse(4) のマニュアルページを参照してください。

あなたが 2.2.5 以降のバージョン FreeBSD を使っているのなら、 必要なドライバ psm はカーネルに含まれていて有効になっています。 カーネルは起動時に PS/2 マウスを検出するでしょう。

あなたの使っている FreeBSD が比較的新しいけれど前のバージョン (2.1.x 以降) のものなら、 インストールの時に、単にカーネルのコンフィグレーションのメニュー上で PS/2 マウスを有効化するだけです、あるいは後で boot: プロンプト上で -c を指定することでもメニューは現れます。 デフォルトでは無効に設定されていますので、 明示的に有効化してあげないといけません。

あなたの使っている FreeBSD が比較的古いものなら、 カーネルコンフィグレーションファイルに以下の行を加えて カーネルを再コンパイルする必要があります。

それは FreeBSD 3.0 を含む、それ以前のリリースでは次のとおり、

device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr

FreeBSD 3.1 を含む、それ以降のリリースでは次のとおり、

device psm0 at isa? tty irq 12

FreeBSD 4.0 とそれ以降のリリースでは次のとおりです。

device psm0 at atkbdc? irq 12

カーネルの再構築についてよく知らないのであれば、 カーネルのコンフィグレーションを参照してください。

起動時にカーネルが psm0 を検出したら、 psm0 のエントリが /dev の中にあることを確認してください。それには、以下のようにします。

# cd /dev; sh MAKEDEV psm0

これは root でログインしているときに行なってください。

もしデフォルトのコンソールドライバである syscons を使っているのであれば、 テキストコンソール上でマウスを使って、 テキストのカットアンドペーストができます。 マウスデーモンである moused を起動し、 仮想コンソールでマウスポインタを有効にしてください。

# moused -p /dev/xxxx -t yyyy
# vidcontrol -m on

ここで xxxx はマウスのデバイス名、 yyyy はマウスのプロトコルタイプです。 サポートされているプロトコルタイプについては moused(8) のマニュアルページを参照してください。

システムを起動する時に自動的に moused を起動したい場合には、次のようにします。 FreeBSD 2.2.1 では以下の変数を /etc/sysconfig で設定してください。

mousedtype="yyyy"
mousedport="xxxx"
mousedflags=""

FreeBSD 2.2.2 以降のバージョンでは /etc/rc.conf で以下のように設定します。

moused_type="yyyy"
moused_port="xxxx"
moused_flags=""

FreeBSD 3.1 とそれ以降で PS/2 マウスを利用する場合は、 moused_enable="YES" を /etc/rc.conf に書き加えるだけです。

また、起動時にすべての仮想端末で、 標準のコンソールに加えマウスデーモンも使えるようにしたい、 という場合には、以下の行を /etc/rc.conf に加えます。

allscreens_flags="-m on"

FreeBSD 2.2.6 以降の場合で 比較的新しいシリアルマウスを使っているならば、 マウスデーモンはマウスのプロトコルタイプを自動判別できます。 自動判別を試みるには、プロトコルタイプとして auto を指定します。

マウスデーモンを実行中は、マウスデーモンと他のプログラム (たとえば X Window System) の間でマウスへのアクセスを調整しなければなりません。 この問題については X とマウスをご覧ください。

マウスデーモンを起動 (前の質問に対する答えを参照してください) したあと、 ボタン 1 (左ボタン) を押しながらマウスを動かして範囲を指定します。 ボタン 2 (中ボタン) またはボタン 3 (右ボタン) をクリックするとテキスト カーソルの位置に選択した範囲のテキストがペーストされます。

FreeBSD 2.2.6 以降では、ボタン 2 をクリックするとペーストされ、ボタン 3 をクリックした場合に既存の選択範囲が現在のマウスポインタの位置まで 「延長または短縮」されます。もしマウスに中ボタンがないなら、 moused のオプションを使って中ボタンのエミュレーションをするか、 他のボタンを中ボタンとして使う事ができます。 詳しくは moused(8) のマニュアルページを参照してください。

USB デバイスは FreeBSD 3.1 からサポートされましたが、 実装は FreeBSD 3.2 であってもまだ完全ではないため、 必ずしも安定して動作するとは限りません。 もし、それでも USB マウスを使ってみたいという人は、 以下の手順を試してみてください。

X 環境でのマウスの利用については、 他の項も参照してください。

USB マウスの活線挿抜 (ホットプラグ機能) は、 まだおそらくきちんと動作しないと思われます。 トラブルを避けるためにも、マウスはシステムを起動させる前に接続しておき、 シャットダウンするまではずさないようにした方が良いでしょう。

答えは残念ながら「場合によります」です。 こうしたマウスの付加的な機能は大抵の場合、特殊なドライバを必要とします。 マウスのデバイスドライバやユーザのプログラムが そのマウスに対する固有のサポートをしていない場合には、 標準的な 2 ボタン/3 ボタンマウスのように振舞います。

X ウィンドウシステムの環境でのホイールの使い方については、 X とホイールの項をご覧ください。

FreeBSD 3.2 およびそれ以前の PS/2 マウスドライバ psm には、 Logitech モデル M-S48 とその OEM のホイールマウスで不具合が発生します。 以下のパッチを /sys/i386/isa/psm.c に適用して、カーネルを再構築してください。

Index: psm.c
===================================================================
RCS file: /src/CVS/src/sys/i386/isa/Attic/psm.c,v
retrieving revision 1.60.2.1
retrieving revision 1.60.2.2
diff -u -r1.60.2.1 -r1.60.2.2
--- psm.c	1999/06/03 12:41:13	1.60.2.1
+++ psm.c	1999/07/12 13:40:52	1.60.2.2
@@ -959,14 +959,28 @@
     sc->mode.packetsize = vendortype[i].packetsize;

     /* set mouse parameters */
+#if 0
+    /*
+     * A version of Logitech FirstMouse+ won't report wheel movement,
+     * if SET_DEFAULTS is sent...  Don't use this command.
+     * This fix was found by Takashi Nishida.
+     */
     i = send_aux_command(sc->kbdc, PSMC_SET_DEFAULTS);
     if (verbose >= 2)
 	printf("psm%d: SET_DEFAULTS return code:%04x\n", unit, i);
+#endif
     if (sc->config & PSM_CONFIG_RESOLUTION) {
         sc->mode.resolution
 	    = set_mouse_resolution(sc->kbdc,
-	        (sc->config & PSM_CONFIG_RESOLUTION) - 1);
+				   (sc->config & PSM_CONFIG_RESOLUTION) - 1);
+    } else if (sc->mode.resolution >= 0) {
+	sc->mode.resolution
+	    = set_mouse_resolution(sc->kbdc, sc->dflt_mode.resolution);
+    }
+    if (sc->mode.rate > 0) {
+	sc->mode.rate = set_mouse_sampling_rate(sc->kbdc, sc->dflt_mode.rate);
     }
+    set_mouse_scaling(sc->kbdc, 1);

     /* request a data packet and extract sync. bits */
     if (get_mouse_status(sc->kbdc, stat, 1, 3) < 3) {

FreeBSD 3.2 より新しいリリースではきちんと動作するはずです。

前の質問に対する答えと、 モバイルコンピューティングのページをご覧ください。

FreeBSD は SCSI と QIC-36 (QIC-02 インタフェース付き) をサポートしています。 これらには 8-mm (Exabyte と呼ばれています) や DAT ドライブも含まれています。

初期の 8-mm ドライブの中には SCSI-2 とまったく互換性を持たないものがあります。 これらは FreeBSD 上では動作しません。

FreeBSD 2.2 は ch(4) デバイスと chio(1) コマンドを使用した SCSI チェンジャーをサポートしています。 実際のチェンジャーの制御方法の詳細は、chio(1) のマニュアルページを参照してください。

使用している製品が AMANDA のようにチェンジャーに対応済みのものでない場合は、 次のことについて留意してください。 それらの製品は任意のポイント間のテープの移動を制御するだけなので、 テープがどのスロットに入っているか、現在ドライブにあるテープが どのスロットに戻るべきかを把握しておく必要があります。

FreeBSD は SoundBlaster、SoundBlaster Pro、SoundBlaster 16、 Pro Audio Spectrum 16、AdLib それから Gravis UltraSound サウンドカードを サポートしています。MPU-401 やその互換カードも機能に制限はあるものの サポートされています。マイクロソフトサウンドシステムのスペックに準拠 したカードも、pcm ドライバでサポートされています。

マシンを起動するごとに以下のコマンドを実行してください。

# mixer pcm 100 vol 100 cd 100

より完全な一覧についてはイーサネットカードの節を参照してください。

一般にこれらは問題とはなりません。 しかし、数値演算エミュレーションコードのパフォーマンスか、 正確さのいずれかを選択する状況があります (詳しくは FP エミュレーション についての節をご覧ください)。 とくに、X 上で弧を描く際にとても遅くなることでしょう。 数値演算コプロセッサを購入されることを強くおすすめします。 とても役立つことでしょう。

FreeBSD ハンドブックに記されている、 サポートされている他のデバイスの一覧を参照してください。

FreeBSD は一部のマシンの APM をサポートしています。 LINT カーネルコンフィグファイル の APM の部分をご覧ください。 さらに詳しいことは apm(4) に載っています。

特定の Micron 製のマザーボードの中には、PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります。 その BIOS は、PCI デバイスをあるアドレスで設定したと報告するにも 関わらず、実際にはそうしていないのです。

この問題を回避するには、BIOS の 「Plug and Play Operating System」 を無効に設定してください。また、より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください。

新しい AIC789x シリーズの Adaptec チップは、3.0 でデビューした CAM SCSI フレームワークでサポートされています。 2.2-STABLE のパッチは ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/ にあります。 CAM システムが入っている高機能ブートフロッピーは http://people.FreeBSD.org/~abial/cam-boot/ にあります。 どちらの場合にしても、作業を始める前に README をお読みください。

モデムの PnP ID を シリアルドライバの PnP ID リストに追加する必要があるでしょう。 Plug & Play サポートを有効にするには、 controller pnp0 をコンフィグレーション ファイルに付け加え、 新しいカーネルをコンパイルしてシステムを再起動してください。 カーネルは、検出したすべてのデバイスの PnP ID を表示します。 モデムの欄にある PnP ID を /sys/i386/isa/sio.c の 2777 行目くらいにあるテーブルに書き入れてください。 テーブルを見つけるには、構造体 siopnp_ids[] の文字列 SUP1310 を探します。 カーネルを作り直したらインストールし、システムを再起動してください。 そうすれば、モデムが検出されるはずです。

起動時のコンフィグレーションの際に、pnp コマンドを使用して PnP の設定をマニュアルで行なわなければならないかもしれません。 その場合、モデムを検出させるためのコマンドは

pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8

のようになります。

/usr/src/sys/i386/boot/biosboot/README.serial に、 これに関する情報が書かれています。

特定の Micron 製のマザーボードの中には、PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります。 その BIOS は、PCI デバイスをあるアドレスで設定したと報告するにも 関わらず、実際にはそうしていないのです。

この問題を回避するには、BIOS の 「Plug and Play Operating System」 を無効に設定してください。また、より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を参照してください。

SMP は、3.0-STABLE とそれ以降のリリースでのみサポートされています。 GENERIC カーネルでは SMP は有効化されていませんので、 SMP を有効化するにはカーネルを再構築する必要があります。 /sys/i386/conf/LINT を見て、 カーネルコンフィグファイルにどのオプションを追加すれば良いのか確かめてください。

BIOS セットアップで 「起動時のウィルス保護機能」 を無効化してください。

SCSI ディスクの場合は自動的に再マップする機能があるはずです。 しかし、理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています…。

これを有効化するには、 最初のデバイスのモードページを変更する必要があります。 これは次のコマンドを実行することで、FreeBSD 上で行なうことができます (root 権限で行ないます)。

# scsi -f /dev/rsd0c -m 1 -e -P 3

そして、AWRE と ARRE の値を 0 から 1 へ変更します

AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1

以下は、Ted Mittelstaedt 氏から寄せられたものです。

IDE ドライブの場合は通常、不良ブロックは潜在的な障害の兆候です。 最近の IDE ドライブは、内部の不良ブロック再マッピング機能を有効にした状態で 出荷されています。また、今日の IDE ハードディスクメーカは、 出荷以降に不良ブロックが発生することに関して保証を提供していて、 不良ブロックのあるディスクドライブを交換するサービスを行なっています。

もし、不良ブロックのある IDE ディスクドライブを復旧しようと思うなら、 IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして、 そのドライブに使ってみてください。この種のプログラムは大抵、 ドライブの制御部分に対して不良ブロックを再走査し、 不良ブロックを使用不能にするようにセットすることができます。

ESDI、RLL および MFM ドライブの場合、 不良ブロックはドライブの正常な部分であり、 一般的に言って障害を表すものではありません。 PC では、ディスクドライブコントローラカードと BIOS が不良ブロックの使用不能化の作業を行ないます。 DOS など、ディスクアクセスに BIOS を経由する OS にとっては有効に働きますが、FreeBSD のディスクドライバは BIOS を利用しません。そのため、 代替として bad144 という機構が存在します。 bad144 は、wd ドライバでだけ (つまり FreeBSD 4.0 ではサポートされていない)動作し、SCSI ドライバに利用することは できません。bad144 は、 検出された不良セクタをスペシャルファイルに記録するという機能を持っています。

bad144 を利用する上で、注意しなければならない点が一つあります。 それは、不良ブロックスペシャルファイルは、 ディスクの最終トラックに置かれるということです。 このファイルには、ディスクの先頭の付近、 /kernel ファイルが位置しているであろう部分で発生した不良セクタが記録されています。 したがって、このファイルは BIOS コールを使ってカーネルファイルを読み込む起動プログラムが、 アクセス可能でなければなりません。 これはつまり、bad144 を利用するディスクは 1024 シリンダ、16 ヘッド、63 セクタを超えてはならないということを意味し、 bad144 を利用したディスクが実質 500MB を超えられないことになります。

bad144 を使うには、FreeBSD のインストール時に表示される fdisk 画面で 「Bad Block」 走査を ON に設定するだけです。 これは、FreeBSD 2.2.7 以降で機能します。 ディスクは、1024 シリンダ以内でなければなりません。 ディスクドライブは事前に少なくとも 4 時間、 ディスクが温度によって膨張し、 トラックに曲がりが出るまで回転させることをお薦めします (訳注: 温度変化に対する膨張によって、 ディスクが微小変形することにより発生する不良セクタを確実に検出するためです)。

大容量の ESDI ドライブのように 1024 シリンダを超えるディスクの場合、 DOS 上でそのディスクが利用できるよう、 ESDI コントローラは特殊な変換モードを利用します。 fdisk の 「set geometry」 コマンドを使って 「変換された (translated)」 ジオメトリに切替えると、wd ドライバはこの変換モードを解釈できます。 その際、FreeBSD パーティションを作成するのに 「dangerously dedicated」 モードを利用してはいけません。 このモードは、そのようなジオメトリを無視するからです。 たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても、 依然としてディスクの真の大きさを保持しているため、大きすぎる FreeBSD パーティションを作成しようとしてしまうでしょう。 ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は、 手動でブロック数を入力し、 パーティションを作成する必要があります。

大容量の ESDI ディスクを ESDI コントローラでセットアップするには、 ちょっとしたトリックを使います。まず、DOS のディスクで起動して そのディスクを DOS パーティションとしてフォーマットします。 そして FreeBSD を起動し、インストーラの fdisk 画面で DOS パーティションのブロックサイズとブロック数を読みとり、メモしておきます。 ジオメトリ情報を DOS が利用しているものと同一に再設定し、 DOS パーティションを削除して 「cooperative」 FreeBSD パーティションを 先程記録したブロックサイズを使って作成してください。 そのパーティションを起動可能パーティションに設定し、不良ブロック走査を 有効にします。 実際のインストールでは、ファイルシステムが作成される前に bad144 が最初に実行されます (Alt-F2 を押すことで状況を確認できます)。 不良セクタファイルを作成中に何らかの障害が発生したなら、 システムを再起動して、もう一度最初からやり直しになります。 おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう (やり直しは、DOS によるフォーマットとパーティション確保を含みます)。

もし、不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら、 ドライブの交換を考えてください。不良ブロックは、時間とともに悪化するからです。

この情報は 742a のためのものですが、他の Buslogic カードについても 同様のことが言えます。(Bustek = Buslogic)

742a カードには大きくわけて 2 つの「バージョン」が存在します。 ハードウェアリビジョンの A-G と H 以降です。リビジョンの 文字はカードの隅にあるアセンブリ番号の後ろにあります。 742a は二つの ROM チップを持っており、一つは BIOS チップで もう一つはファームウェアチップです。FreeBSD はあなたの 持っているものがどの BIOS バージョンかは問題ありませんが、 ファームウェアバージョンについては問題となります。 Buslogic の技術サポート部門に連絡すれば、アップグレード版の ROM を送ってくれることでしょう。BIOS チップと ファームウェアチップはペアで出荷されます。 アダプタカードのハードウェアリビジョンにあわせた 最も新しいファームウェア ROM を使用しなければなりません。

リビジョン A-G のカードには、2.41/2.21 までの BIOS/ファームウェアのセットを使用することができます。 リビジョン H 以降のカードには、最新のものである 4.70/3.37 の BIOS/ファームウェアのセットを 使用することができます。これらのファームウェアの違いは、 ファームウェア 3.37 が 「ラウンドロビン方式」 をサポートしているところからきています。

Buslogic のカードには、製造番号も刻印されています。古い ハードウェアリビジョンのカードを持っている場合は、Buslogic の RMA 部門に問い合わせて製造番号を伝えると、新しいハードウェアリビジョンの カードに交換することもできます。もしカードが十分新しければ、彼らは 交換に応じてくれるでしょう。

FreeBSD 2.1 は ファームウェアリビジョン 2.21 以降のものをサポートしています。 これよりも古いファームウェアリビジョンのものは、 Buslogic カードとして正常に認識されません。 しかし、Adaptec 1540 として認識されるかもしれません。 初期の Buslogic のファームウェアは AHA1540 「互換」モードを 持っています。しかし、EISA カードにとってこれは よいことではありません。

古いハードウェアリビジョンのカードを持っていてファームウェア 2.21 を入手するのであれば、ジャンパ W1 の位置をデフォルトの A-B から B-C に合わせる必要があるでしょう。

基本的にこれは既知の問題です。HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが、「本当の」EISA スロットはすべてそれよりも前のアドレスに配置されているのです。 残念ながら、 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間と衝突し、FreeBSD の自動コンフィグレーションは、 現状ではうまくこの状況を処理できていないのです。

ですから現時点での最良の方法は、カーネルオプションの EISA_SLOTS を 12 に変え、 アドレス空間の衝突がないかの ようなふりをさせることです :) カーネルの再構築に記述されているようにしてカーネルを再構築してください。

もちろん、これはこのようなマシンにインストールする際に 「卵が先か、 鶏が先か」といった問題を生み出すことになります。 この問題を回避するために、 ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています。 このとき 「visual」 インタフェースは使用せず、 コマンドラインインタフェースを使用してください。単純に

eisa 12
quit

とプロンプト上から打ち込み、 後は普通にインストールを行なってください。 とにかくカスタムカーネルのコンパイルとインストールを行なうことを おすすめします。

うまくいけば、将来のバージョンではこの問題が解決していることでしょう。

それは壊れているのです。両方のチャンネルを同時に制御できないのです。

現在、このチップを使っているシステムを自動的に検出して、 うまく動かすためのしくみが使えるようになっています。 くわしくは wd(4) のマニュアルページを参照してください。

CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使い、 かつセカンダリのチャネルを使いたいのであれば、 options "CMD640" を有効にしてカーネルを作り直してください。 FreeBSD 2.2.5 以降では、デフォルトでそうなっています。

たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ を使用しているなど)。FreeBSD 2.0.5R 以前はこれに関して寛大で、 IRQ の衝突があってもネットワークドライバは機能していました。 しかし 2.0.5R 以降はもはや、IRQ の衝突に寛大ではありません。 -c オプションをつけて起動し、 ed0/de0/... のエントリをボードの設定に合わせてください。

ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプのインタフェース) を使っている場合、 デバイスのタイムアウトはターミネーションの不良によっても起きます。 これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します。そしてエラーメッセージが消えるかどうか 確認します。

NE2000 コンパチブルカードのなかには、 UTP ポートのリンクがなかったりケーブルが接続されていない場合に このエラーを出すものがあります。

mount(8) にマウントしたいデバイスのタイプを指定する必要があります。 デフォルトでは mount(8) はファイルシステムを ufs とみなします。CDROM のファイルシステムを マウントしたいのであれば -t cd9660 と mount(8) にオプションをつけて明示する必要があります。 これはもちろん CDROM が ISO 9660 ファイルシステムである場合です。ほとんどの CDROM はこの形式です。1.1R の FreeBSD では (訳注: 2.1.5R、 2.2R でも同様です) 自動的に Rock Ridge 拡張 (長いファイル名への対応) をうまく解釈します。

CDROM のデバイス /dev/cd0c を /mnt にマウントしたい場合の例では、次のようにします。

# mount -t cd9660 /dev/cd0c /mnt

デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください (/dev/cd0c はこの場合の例です)。 オプション -t cd9660 によって mount_cd9660 コマンドが実行されることに注意してください。 このため例は次のようにすることもできます。

# mount_cd9660 /dev/cd0c /mnt

これは 一般的に CDROM ドライブの中に CDROM が入っていないか、 ドライブがバス上に見えないことを意味します。ドライブに CDROM を入れるか、IDE (ATAPI) であれば master/slave の状態をチェックしてください。 また、CDROM ドライブに CDROM を入れてから認識するまでには数秒かかりますので、 少し待ってみてください。

SCSI CDROM ではバスリセットへの応答時間が遅いために、 失敗することがあるかもしれません。 SCSI CDROM を持っている場合は、 カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください。

options "SCSI_DELAY=15"

もっともありそうなのは、その CDROM が 「Joliet」 拡張を利用してファイルおよび ディレクトリに関する情報を保存しているということです。この拡張は、 すべてのファイル名を Unicode の 2 バイト文字で保存するように 規定しています。現在、FreeBSD カーネルに汎用的な Unicode インタフェースを導入する作業が行われていますが、 まだ完了していません。したがって、CD9660 ドライバはファイル名の文字を解読できません。

一時的な解決策として、FreeBSD 4.3R 以降では、CD9660 ドライバに特別な仕掛けを施して、ユーザーがその場で適切な 変換表を読み込めるようにしました。一般的なエンコーディングに 対応したいくつかのモジュールが sysutils/cd9660_unicode port で提供されています。

パラレルインタフェースで、問題はとんでもなく遅いだけであるなら、 プリンタボートを 「polled」 モードに設定してみてください。

# lptcontrol -p

HP の新しいプリンタには、 割り込みモードで使えないものがあるようです (完全にわかったわけではありませんが)。 タイミングの問題のように思われます。

Signal 11 エラーはオペレーティングシステムが 許可を与えていないメモリにアクセスしようとしたときに発生します。 このようなことがランダムな間隔で起っているようなら、 注意深く調査していった方が良いです。

この手の問題はたいていの場合、以下のどちらかです。

それが FreeBSD のバグでは「ない」という決定的なケースとして、 その問題の発生がプログラムをコンパイルしているときであり、 コンパイル毎に毎回、コンパイラの挙動が変るというものがあります。

たとえば、あなたが 「make buildworld」 を実行していて、 コンパイラが ls.c から ls.o をコンパイルしようとしたときに コンパイルに失敗したとします。もう一度 「make buildworld」 を実行したときに、まったく同じ場所でコンパイルが失敗したのなら、 それは build が壊れている (訳注: つまりソースにバグがある) と言うことです -- ソースを更新してやりなおしてみてください。 もしコンパイルが別の場所でしくじっていたら、 それはハードウェアの問題です。

あなたのやるべき事は:

前者の場合は、 そのプログラムの間違ったアドレスへアクセスしようとしている部分を、 gdb 等のデバッガで見つけて修正します。

後者の場合は、 ハードウェアに問題がないことを確かめる必要があります。

その一般的な原因として :

SIG11 FAQ (下に示します) にはこれらの問題のすべてが 詳しく説明されています。Linux の視点に基づくものですが、 これも読んでおいた方がいいでしょう。そこではまた、 メモリのテストを行うソフトウェアや、 ハードウェアがなぜ問題のあるメモリを見逃してしまうかについても 議論されています。

最後に、これらがどれも助けにならなかったら、 FreeBSD のバグを発見した可能性があります。 以下の説明を読んで障害報告を送ってください。

詳細な FAQ は、 the SIG11 problem FAQ にあります。

これは ATI Mach 64 ビデオカードの既知の問題です。 この問題はカードがアドレス 2e8 を使い、 4 番目のシリアルポートもここを使うということにあります。 sio(4) ドライバのバグ (仕様?) のため、 4 番目のシリアルポートがなくても、 通常このアドレスを使う sio3 (4 番目のポートにあたります) を無効にしても、ドライバはこのアドレスをさわります。

バグが修正されるまでは、次のようにして対処してください。

もしシリアルポートを有効にしたいのであれば以下の変更を行なって 新しいカーネルを作る必要があります。 /usr/src/sys/i386/isa/sio.c の中で 1 ヵ所ある 0x2e8 という文字列を探し、 この文字列とその手前にあるコンマを削除します (後ろのコンマは残します)。 後は通常の手続きにしたがって新しいカーネルを作ります。

この対処を行なった後でもまだ X ウィンドウシステムはうまく動かないかもしれません。 その場合は、 使用している XFree86 がすくなくとも XFree86 3.3.3 以降であることを確かめてください。 それ以降のバージョンでは、 Mach64 カードやそれらのカードのためにつくられた X サーバ の組込みをサポートします。

FreeBSD がメモリのサイズを BIOS から取得する方法の制限により、 KB 単位で 16 ビット分までしか検出できません (すなわち最大 65535KB=64MB です。これより少ない場合もあります。 ある BIOS の場合はメモリサイズが 16MB に制限されます)。 64MB 以上のメモリを積んでいる場合、 FreeBSD はそれを検出しようとします。 しかしその試みは失敗するかもしれません。

この問題を回避するには、 以下に示すカーネルオプションを使用する必要があります。 完全なメモリ情報を BIOS から取得する方法もありますが、 起動ブロックに空きが無いため実装できません。 起動ブロックの問題が解決されれば、 いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう。 とりあえず現在は、カーネルオプションを使ってください。

options "MAXMEM=n"

n には、 キロバイト単位でメモリの量を指定します。128MB の場合は、131072 となります。

このパニックは、ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します。 以下のオプションをカーネルコンフィグファイルに追加して mbuf クラスタに使用できる仮想メモリの量を増やしてください。

options "NMBCLUSTERS=n"

n には、 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます。 とりあえず 2048 を試してみるのをおすすめします。 これでパニックは完全の予防できるはずです。 mbuf クラスタの割り当て、使用状況については、 netstat -m で知ることができます (netstat(1) をご覧ください)。 NMBCLUSTERS のデフォルト値は 512 + MAXUSERS * 16 です。

ファイル /var/db/kvm_*.db において範囲外のデータを検出するためのロジックは失敗することがあり、 こうした矛盾のあるファイルを使用することでパニックを引き起こすことがあります。

これが起こったなら、シングルユーザで再起動した後に、 以下のコマンドを実行してください。

# rm /var/db/kvm_*.db

これは Ultrastor SCSI Host Adapter と衝突しています。

起動時に kernel configuration メニューに入り、 問題を起こしている uha0 を disable にしましょう。

この事は、sendmail FAQ に次のように書いてあります。

もはや現在の sendmail FAQ は sendmail release とは一緒には保守されていません。 しかし次のネットニュースに定期的に投稿されてます。 comp.mail.sendmail、 comp.mail.misc、 comp.mail.smail、 comp.answers、 news.answers。 また、メール経由でコピーを入手する場合は mail-server@rtfm.mit.edu 宛まで本文に send usenet/news.answers/mail/sendmail-faq と書いて送ります。

リモートマシンのターミナルタイプが FreeBSD のコンソールで必要とされている cons25 以外のものです。

この問題を解決しうる方法はいろいろあります:

これは、割り込みに関連するさまざまな不具合によって発生します。 あるいは、あるデバイスが元々持っているバグが表面化したのかも知れません。 この症状を再現させる一つの方法として、パラレルポート上で、 TCP/IP を 大きな MTU で走らせるというものがあります。 グラフィックアクセラレータがこの症状を起こすことがありますが、 その場合はまず、カードの割り込み設定を確認してください。

この問題の副作用として、 プロセスが 「SIGXCPU exceeded cpu time limit」 というメッセージとともに終了してしまう、というものがあります。

1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で この問題が解決しないなら、次の sysctl 変数をセットしてください。

# sysctl -w kern.timecounter.method=1

これは、パフォーマンスへ強い影響を与えますが、 問題の発生に比べればおそらく気にならない程度でしょう。 もし、これでもまだ問題が残るようなら、 カーネルオプションの NTIMECOUNTER を大きな値に増やしてください。 NTIMECOUNTER=20 にまで増やしても解決しない場合は、 計時処理の信頼性が保てない程の割り込みが、 そのマシン上で起こっていることを意味します。

これは FreeBSD 3.x で PCI のサウンドカードを使っているときに 発生します。pcm0 デバイスは ISA のカード専用に予約されているものです。このため、 あなたが PCI カードを持っているときはこのエラーが表示され、 カードは pcm1 として検出されます。

PCI のサウンドカードを持っているのならば、以下のようにして snd0 デバイスのかわりに snd1 を作る必要があります。

# cd /dev
# ./MAKEDEV snd1

この状況は FreeBSD 4.x では生じません。多くの努力の結果より PnP 中心に作り替えられ、 現在、pcm0 デバイスは ISA カード専用に予約されたものではなくなりました。

現在の FreeBSD 4.x はより PnP 中心に なっています。その副作用の影響で、FreeBSD 3.x で動いていた PnP デバイス (たとえばサウンドカードや内蔵モデム) の中には、 動かなくなってしまったものもあります。

この挙動の原因は Peter Wemm が freebsd-questions メーリングリストに書いた、以下の 「FreeBSD 4.x にアップグレードしたところ内蔵モデムが 見つからなくなった」というメールで解説されています。 (わかりやすくするために [] 内に コメントを加えました)。

3.0 で動作していたデバイスを 4.0 でも動作するようにするには、 それの PnP ID を調べ、ISA デバイスの検索が PnP デバイスの識別に使っているリストにそれを追加する必要があります。 デバイスの検索に使われる pnpinfo(8) を用いて、 PnP ID を得ることができます。 たとえば、内蔵モデムに関する pnpinfo(8) の出力は、 以下のようになります。

# pnpinfo
Checking for Plug-n-Play devices...

Card assigned CSN #1
Vendor ID PMC2430 (0x3024a341), Serial Number 0xffffffff
PnP Version 1.0, Vendor Version 0
Device Description: Pace 56 Voice Internal Plug & Play Modem

Logical Device ID: PMC2430 0x3024a341 #0
        Device supports I/O Range Check
TAG Start DF
    I/O Range 0x3f8 .. 0x3f8, alignment 0x8, len 0x8
        [16-bit addr]
    IRQ: 4  - only one type (true/edge)

[more TAG lines elided]

TAG End DF
End Tag

Successfully got 31 resources, 1 logical fdevs
-- card select # 0x0001

CSN PMC2430 (0x3024a341), Serial Number 0xffffffff

Logical device #0
IO:  0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8 0x03e8
IRQ 5 0
DMA 4 0
IO range check 0x00 activate 0x01

必要な情報は、出力の冒頭にある 「Vendor ID」 行にあります。 かっこの中の 16 進数 (例の中では 0x3024a341) が PnP ID で、 直前の文字列 (PMC2430) はユニークな ASCII ID です。 この情報はファイル /usr/src/sys/isa/sio.c に 追加する必要があります。

まず失敗したときに備えて sio.c の バックアップを取るべきです。障害報告を送るために修正パッチを 作る時にも必要になるでしょう (send-pr しようとしていますよね?)。 sio.c を編集して以下の行を探してください。

static struct isa_pnp_id sio_ids[] = {

そしてあなたのデバイスのエントリを追加する正しい場所を探します。 エントリは以下のような形をしていて、pnpinfo(8) の 出力にある デバイスの説明の全部 (もし収まれば) か一部とともに行の右の方のコメント領域に書かれている ASCII ベンダ ID でソートされています。

{0x0f804f3f, NULL},     /* OZO800f - Zoom 2812 (56k Modem) */
{0x39804f3f, NULL},     /* OZO8039 - Zoom 56k flex */
{0x3024a341, NULL},     /* PMC2430 - Pace 56 Voice Internal Modem */
{0x1000eb49, NULL},     /* ROK0010 - Rockwell ? */
{0x5002734a, NULL},     /* RSS0250 - 5614Jx3(G) Internal Modem */

あなたのデバイスの16進数のベンダ ID を正しい場所に 追加し、ファイルをセーブしてカーネルを作り直して再起動します。 あなたのデバイスは FreeBSD 3.x の時と同じように sio として見つかるようになっているはずです。

このエラーは、 実行しようとしたアプリケーションが あるカーネルシンボルを検索した結果、 何らかの理由でその検索に失敗した、ということを意味しています。 これは、以下に示すいずれかの理由によるものです。

症状: TCP コネクションが確立してから、 クライアントソフトウェアがパスワードを尋ねてくるまで (telnet(1) の場合は、ログインプロンプトが表示されるまで) に長い時間がかかる、というもの。

問題: おそらく、サーバソフトウェアがクライアントの IP アドレスからホスト名を解決しようとして、遅れが生じている のでしょう。FreeBSD に付属する SSH や Telnet を含む多くの サーバソフトウェアは、この名前解決をおこないます。これは、 管理者が後日参照するログファイルに、その他の情報と一緒に ホスト名を記録できるようにするのが目的です。

対処法: もし、あなたのコンピュータ (クライアント) からどのサーバに接続する場合にも問題が起こるのであれば、 クライアントに問題があります。そして、誰かがあなたの コンピュータ (サーバ) に接続するときだけ問題が起こるのであれば、 そのサーバの問題です。

問題がクライアントにある場合、唯一の対処法は サーバがそのクライアントの名前を解決できるように DNS を修正することです。 症状がローカルネットワークで発生しているなら、サーバの設定に 原因がありますので、このまま続きを読みましょう。 そうではなく、グローバルなインターネット環境で発生しているなら、 ISP に連絡して問題の修正をお願いしなければならない可能性が高いでしょう。

問題がサーバにあって、症状がローカルネットワークで 発生しているなら、ローカルのアドレス範囲にあるアドレスを、 それに対応するホスト名に解決する問合せを処理できるように、 サーバを設定する必要があります。 詳しくは、hosts(5) および named(8) のマニュアルをご覧ください。グローバルなインターネット環境の場合は、 サーバのリゾルバが正しく動作していないのが原因かもしれません。 確認するには、他のホスト (たとえば www.yahoo.com) を引いてみてください。 うまくいかなければ、あなたのコンピュータの問題です。

このエラーは、システムのファイル記述子を使い果たして しまった時に発生します。メモリ中のファイルテーブルが一杯に なっているのです。

解決法:

手動で sysctl 変数 kern.maxfiles の限界値を調整します。

# sysctl -w kern.maxfiles=n

n は、システム要件に合わせてください。 オープンされたファイル、ソケットまたは fifo のそれぞれが ファイル記述子を消費します。規模の大きなサーバは、 同時に実行されるサービスに応じて、いともたやすく何万もの ファイル記述子を要求します。

カーネルに設定されたデフォルトのファイル記述子の 数を決定するのは、次の

maxusers        32

カーネル設定ファイルの maxusers 行 です。kern.maxfiles はこの値に比例して 増加します。

現在設定されている kern.maxfiles の 値は、次のコマンドで調べることができます。

# sysctl kern.maxfiles
kern.maxfiles: 1064
          

laptop には二つ以上の時計が内蔵されていますが、FreeBSD が間違った方を選択して使用しています。

dmesg(8) を実行して Timecounter を含む行を確認してください。 最後に出力された行が FreeBSD が選択したもので、まず間違い なく TSC でしょう。

# dmesg | grep Timecounter
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 595573479 Hz

sysctl(3) 変数 kern.timecounter.hardware を確認すれば 裏付けがとれます。

# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC

バッテリ駆動している時に、BIOS が CPU の速度を変えるために TSC クロックを変更したり、電力節約モードに入ることがあります。 しかし、FreeBSD はそういった調整を関知しないので、 時間が早まったり遅れたりするようです。

上記の例では、i8254 クロックも利用できます。 sysctl(3) 変数 kern.timecounter.hardware にその名称を書き込んで選択できます。

# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254

これで、laptop はより正確な時間を刻むでしょう。

この変更を起動時に自動で行うには、次の行を /etc/sysctl.conf に追加してください。

kern.timecounter.hardware=i8254

FreeBSD のブートローダがハードディスクのジオメトリを正しく 認識していないようです。FreeBSD のスライスを fdisk によって手動で作成したり変更したりする際に、 ジオメトリを誤って指定してしまったのでしょう。

ハードディスクのジオメトリの正しい値は、マシンの BIOS から 得られます。そのハードディスクのシリンダ、ヘッド、セクタの 数を探してください。

sysinstall(8) の fdisk において、 G を入力してハードディスクのジオメトリを 設定してください。

シリンダ、ヘッド、セクタの数を入力するダイアログが出てきます。 BIOS から得た値を斜線 (/) で区切って入力してください。

5000 シリンダ、250 ヘッド、60 セクタなら、 5000/250/60 と入力します。

リターンキーを押して値を設定してください。それから W を入力してハードディスクに新しいパーティ ションテーブルを書き込んでください。

sysinstall(8) を立ち上げて Configure (設定)、Fdisk の順に選択してください。ブートマネージャが置かれていた ディスクを選択して、スペースキーを 押してください。W を押して変更を ディスクに書き込んでください。どのブートローダを インストールするか尋ねられます。ここで選択すれば戻せます。

FreeBSD 用の廉価版 ELF Motif 2.1.20 (i386 版、Alpha 版) に関する情報はApps2go から 手に入れることができます。

この製品には、「開発者版 (development edition)」 と、 より安価な「ランタイム版 (runtime edition)」 の二つの版があります。これらの製品は以下の物が含まれています。

注文する際には FreeBSD 用の Motif であることをきちんと 確認してください (あなたの欲しいアーキテクチャを指定するのも 忘れないでください!)。NetBSD や OpenBSD 用の Motif もまた、 Apps2goから販売されています。現在、FTP による ダウンロードのみ利用可能です。

他の FreeBSD 用 Motif 2.1 (ELF 版、a.out 版) に関する情報は Metro Link から手に入れることができます。

この製品は以下の物が含まれています。

注文する際には FreeBSD 用の Motif であることをきちんと 確認してください。Linux 用の Motif も Metro Link から販売されています。現在、CDROM および FTP によるダウンロードが利用可能です。

FreeBSD 用の a.out 版 Motif 2.0 に関する情報は Xi Graphics から 手に入れることができます。

この製品には以下の物が含まれています。

注文する際には FreeBSD 用の Motif であることをきちんと 確認してください。BSDI や Linux 用の Motif もまた、Xi Graphics から販売されています。現在フロッピーディスク 4枚組ですが、 将来的には CDE のように統合された CD に変わるでしょう。

以前 Xi Graphics より FreeBSD 用の CDE が 販売されていましたが、現在は既に販売が終了しています。

KDE 多くの点で CDE と類似しているオープンソースの X11 デスクトップ環境です。 xfce の ルック & フィール (訳注: 外観や操作方法のこと) も気に入るかも知れません。 KDE、xfce は、いずれも FreeBSD Ports Collection に含まれています。

はい、Xi Graphics と Metro Link から、FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています。

Metro Link は、FreeBSD のパッケージ操作ツールを利用することで 容易に設定が行なえるほか、数多くのビデオボードをサポートした 高機能な X サーバを提供しています。配布はバイナリ形式のみで、 FTP が利用可能です。もちろん、とても安価 ($39) に手に入れることができます。

また、Metro Link は ELF 版、a.out 版の FreeBSD 用 Motif も販売しています (前を参照)。

Xi Graphics が提供している高性能な X サーバは楽に設定を行なえるほか、 数多くのビデオボード をサポートしています。サーバはバイナリのみが含まれます。 FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています。 Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています。

バージョン 5.0 の「互換デモ」が無料で入手できます。

また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照)。

もちろんです。FreeBSD のウェブサイトにある 商用ベンダー というセクションをご覧ください。

また、FreeBSD Ports Collection のデータベースのセクションも参考になるでしょう。

はい。Linux 版 Oracle を FreeBSD でセットアップするための方法は、 次に示すページに詳しく書かれています。

FreeBSDに移植されたソフトウェアパッケージについては、 FreeBSD Ports Collection のページをご覧ください。 このリストには現在 3400 を越える項目があり、 しかも毎日更新されています。このページをこまめに訪れるか、 freebsd-announce メーリングリストを購読すると、 新しく入った ports を定期的にチェックすることができます。

大部分の ports は 2.2 と 3.x および 4.x ブランチで利用できるはずです。 多くは 2.1.x 系のシステムでも同様に動作するでしょう。 FreeBSD のリリースが出る度に、そのリリースの時点での ports ツリーの スナップショットが撮られ、ports/ ディレクトリに 納められることになっています。

また、「package」 という考えも採用されています。これは基本的には gzip で圧縮されたバイナリディストリビューションに、 インストール時に環境に合わせた作業が必要になった場合、 行う機能を多少付け加えたものです。 package を使えば、どのようなファイルが配布物として含まれているか、 と言った細かい事柄にいちいち煩わされることなく、 簡単にインストールやアンインストールを繰り返すことができます。

インストールしたい package があるなら、 /stand/sysinstallの、 「インストール後の FreeBSD の設定を行う」の下にある package のインストールメニューを使うか、 package のファイル名を指定して pkg_add(1) を使用してください。 package のファイル名には、 通常末尾に .tgz がついています。 CDROM をご使用の方は、CD の packages/All ディレクトリからそれらのファイルを利用することができます。 また、以下の場所から、 FreeBSD の各種バージョンにあわせた package をダウンロードする こともできます。

お近くのミラーサイトもご利用ください。

新しい ports が続々と追加されている状態なので、すべての ports に 対応する package が存在するわけではないことを覚えておいてください。 定期的に ftp.FreeBSD.org マスターサイトを訪れて、どのような package が利用できるのかチェックするのも良いでしょう。

それは、POSIX がそのようなシェルがあることを規定しているからです。

もっと込み入った回答: 多くのユーザは、多くのシステムで同じように動作できるシェルスクリプトを書く必要があります。 これが、POSIX でシェルやユーティリティコマンドが細く規定されている理由です。 ほとんどすべてのスクリプトは Bourne shell で書かれているのですが、 それは、数多くの重要なプログラミングインタフェイス (make(1)、 system(3)、popen(3)、や Perl や Tcl 等の類似の 高水準スクリプト言語) が、コマンドの解釈に Bourne shell を使うからです。 このように Bourne shell が極めて頻繁にかつ広範囲で使われているため、 素早く起動できて確実に動作し、メモリを少ししか消費しないということが 重要になります。

既存の実装は、 私たちに可能な限りこれらの多くの要求を同時に満足することができる最良のものです。 /bin/sh を小さいままに保つため、 私たちは他のシェルが持つ様々な便利な機能を提供していません。 Ports コレクションが bash や scsh、tcsh、zsh などの 多機能なシェルを含んでいるからです (これらのシェルすべての メモリ使用状況は、ps -u の 「VSZ」 や 「RSS」 の行で、あなた自身が確認することができます)。

FreeBSD 2.1.x のシステムで 2.2 以降用の package を動かそうとしていますね? 前のセクションを読んで、システムに合った正しい port/package を入手してください。

何かの手違いで、4.X と 5.X のシステム用 package をダウンロードし、 FreeBSD 2.X、もしくは 3.X のシステムにインストールしてしまったのでしょう。 対応する正しいバージョンの package をダウンロードしてください。

あなたのマシンには数値演算プロセッサが搭載されていませんね? カーネルにコプロセッサの代わりとなる数値演算エミュレータを追加する必要があります。 以下のオプションをカーネルのコンフィグレーションファイルに追加して、 カーネルを再構築してください。

options GPL_MATH_EMULATE

まず最初に /etc/sysconfig (または /etc/rc.conf, rc.conf(5) 参照) の最後のセクションを編集し、 以下の変数を YES に直します。

# Set to YES if you want ibcs2 (SCO) emulation loaded at startup
ibcs2=NO

これでシステムの起動時に ibcs2 カーネルモジュールが読み込まるようになります。

次に /compat/ibcs2/dev/ を以下のように編集します。

lrwxr-xr-x  1 root  wheel         9 Oct 15 22:20 X0R@ -> /dev/null
lrwxr-xr-x  1 root  wheel         7 Oct 15 22:20 nfsd@ -> socksys
-rw-rw-r--  1 root  wheel         0 Oct 28 12:02 null
lrwxr-xr-x  1 root  wheel         9 Oct 15 22:20 socksys@ -> /dev/null
crw-rw-rw-  1 root  wheel   41,   1 Oct 15 22:14 spx

open や close の処理は、 socksys から /dev/null (null(4) 参照) へシンボリックリンクを張ることで代用します。 残りの処理は、-CURRENT に入っているコードが担当しています。 これは以前のものより ずっとスッキリした方法です。

inn の package や port をインストールしたあとに Dave Barr's INN Page を見てみましょう。初心者向けの INN FAQ があります。

ルーク、ports を使うのだ! パッチ処理済みの Apache が ports ツリーから入手できます。

はい。 http://www.FreeBSD.org/java/ をご覧ください。 日本語訳 もあります。

もし、その時点の -CURRENT か -STABLE に比べてずっと古いバージョンの FreeBSD を利用しているなら、 http://www.FreeBSD.org/ports/ にある ports アップグレードキットが必要です。 最新の FreeBSD を利用しているのに発生する場合はおそらく、 -CURRENT では正常なのに -STABLE ではうまく動かなくなるような変更がその port に対して行なわれ、受理されてしまっているのでしょう。 ports コレクションは -CURRENT と -STABLE、 両方のブランチで動かなければならないものですので、 もしそれを発見したら send-pr(1) コマンドを使ってバグレポートの提出をお願いします。

3.1-R 以降などの Elf 化されたマシンで Netscape Navigator などの aout 形式のアプリケーションを動かすときには、 /usr/libexec/ld.so と aout ライブラリのファイルが必要です。 それらは配布物の compat22 に納められています。 /stand/sysinstall や compat22 サブディレクトリ内の install.sh を使って compat22 をインストールしてください。 合わせて 3.1-R と 3.2-R の ERRATA もお読みください。

残念ながら、インストール済みの ports を更新する簡単な 方法はありません。pkg_version コマンドを 用いて ports ツリー中の新しいバージョンに更新する スクリプトを次のように生成することができます。

# pkg_version -c > /tmp/myscript

出力されたスクリプトを使う前に、手で 編集しなければなりません。現在のバージョンの pkg_version では、スクリプトの先頭に exit を挿入して強制しています。

スクリプトの出力には、更新された packages に依存する packages が記載されているので、保存しておきましょう。これらも やはり更新する必要があるかもしれません。通常、更新が 必要となるのは、共有ライブラリのバージョンが変化し、 そのライブラリを利用している ports が新しいライブラリを用いるために 再構築する必要がある場合です。

システムが常時稼動しているならば、 /etc/periodic.conf に weekly_status_pkg_enable="YES" を 設定して、periodic(8) システムによって毎週更新が必要な ports の一覧を生成できます。

全然難しくありません。 カーネルの再構築を調べてください。

推測ですが、数値演算コプロセッサを持ってないからと思って、 npx0 (npx(4) 参照) をカーネルコンフィグファイルから削除してしまったのではないでしょうか? npx0 は必須です。 コプロセッサがなくても、npx0 デバイスは削除してはいけません。

これはデバッグモードでカーネルを構築していることが原因です。 デバッグモードで構築されたカーネルは、 デバッグに用いられる膨大なシンボル情報を含んでいるため、 カーネルのサイズが非常に大きくなります。 ただし FreeBSD 3.0 とそれ以降のシステムの場合は カーネルのサイズは小さくなりますし、 デバッグカーネルを実行する時のパフォーマンスの低下もありません。 また、そのカーネルはシステムがパニックした場合に有用です。

しかし、容量の小さなディスクでシステムを運用していたり、 単にデバッグカーネルを実行したくない場合は、 以下の両方が当てはまっているかどうか確認してください。

上に書かれた指定は両方ともカーネルをデバッグモードで構築するためのものです。 上の手順を従っている限り、カーネルを普通に構築してサイズの小さなカーネルを得ることができます。 その場合のカーネルサイズは、およそ 1.5MB から 2MB 程度になります。

マルチポートシリアルを サポートするコードを含んだカーネルをコンパイルしようとすると、 最初のポートだけ検出され、 残りのポートは割り込みの競合のためスキップされたと言われます。 どうやったらいいでしょうか?

ここでの問題は、FreeBSD にはハードウェアまたはソフトウェアの競合により、 カーネルがクラッシュするのを防ぐコードが含まれているという点です。 解決するには、最初のポートにだけ IRQ の設定を書き、 残りは IRQ の設定を削除します。 以下に例を示します。

# Multiport high-speed serial line - 16550 UARTS
#
device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr
device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr
device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr
device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr

さまざまな理由が考えられます。以下、順に列記します。

FreeBSD 2.0.5R から 2.2.1R までは、 プライマリコンフィグレーションファイルは /etc/sysconfig にあります。 オプションはすべてこのファイルで設定され、他の /etc/rc (rc(8) 参照) および /etc/netstart といった ファイルはこれを読み込むだけです。

ファイル /etc/sysconfig を見て、システムに適合するように変更してください。 このファイルには、 それぞれの場所に何を書けばいいのかを表すコメントがたくさん書かれています。

FreeBSD 2.2.2 から 3.0 までのシステムでは、 /etc/sysconfig は、 より分りやすい名前の rc.conf(5) に改名され、それに従って書式もいくぶん改められています。 /etc/netstart も /etc/rc.network に改名され、 全部のファイルを cp /usr/src/etc/rc* /etc で一度にコピーすることが出来るようになります。

FreeBSD 3.1 とそれ以降では、 /etc/rc.conf が /etc/defaults/rc.conf に移動しました。 このファイルを編集してはいけません! 代わりに、 /etc/defaults/rc.conf の中で変えたいエントリの行を /etc/rc.conf にコピーし、 そこで変更するようにしてください。

たとえば named を起動したいとしましょう。 FreeBSD 3.1 かそれ以降のシステムで FreeBSD 付属の DNS サーバを起動するには、次のようにするだけです。

# echo named_enable="YES" >>
              /etc/rc.conf

FreeBSD 3.1 かそれ以降でローカルサービスを起動するためには、 /usr/local/etc/rc.d ディレクトリにシェルスクリプトを置きます。 シェルスクリプトは起動可能に設定し、ファイル名が .sh で終わっていなければなりません。 FreeBSD 3.0 とそれ以前のリリースでは、 /etc/rc.local を編集する必要があります。

ファイル /etc/rc.serial はシリアルポートの初期化 (たとえばポートの設定を固定したり等々) のためにあります。

ファイル /etc/rc.i386 は iBCS2 エミュレーションのような Intel アーキテクチャ固有の設定や、 PC システムコンソール設定のためにあります。

adduser(8) コマンドを使用してください。 また、pw(8) コマンドを用いることで、さらに細かい操作が可能です。

ユーザを削除するには rmuser(8) コマンドを使用してください。 繰り返しになりますが、pw(8) でも構いません。

そのリムーバブルドライブが ZIP であれ EZ drive であれ (あるいはもしそういう風に使いたいのなら、フロッピーであれ)、 またハードディスクであれ、一旦システムにインストールされて認識され、 カートリッジ、フロッピー等々が挿入されていれば、 ことはどのデバイスでも全く同じように進みます。

(このセクションはMark Mayo's ZIP FAQ に基づいています)

ZIP ドライブやフロッピーで、すでに DOS のファイルシステムで フォーマットしてある場合、次のコマンドを使うことができます。 これはフロッピーの場合です。

# mount -t msdos /dev/fd0c /floppy

出荷時の設定の ZIP ディスクではこうです。

# mount -t msdos /dev/da2s4 /zip

その他のディスクに関しては、fdisk(8) や /stand/sysinstall を使って、 どのようにレイアウトされているか確かめてください。

以降は ZIP ドライブが 3 番目の SCSI ディスクで、 da2 と認識されている場合の例です。

他人と共有しなければならないフロッピーやリムーバブルディスク でなければ、BSD ファイルシステムを載せてしまうのが良い考えでしょう。 ロングファイル名もサポートされ、パフォーマンスは少なくとも 2 倍は向上しますし、おまけにずっと安定しています。 まず最初に、DOS レベルでのパーティション / ファイルシステムを無効にしておく必要があります。使用するのは fdisk でも /stand/sysinstall でも結構です。 複数のオペレーティングシステムを入れることを考慮する 必要がないような容量の小さなドライブの場合は、 次のように FAT パーティションテーブル (スライス) 全体を飛ばして、BSD のパーティション設定を行うだけで良いでしょう。

# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto

複数の BSD パーティションをつくる場合、 disklabel か /stand/sysinstall を使います。 固定ディスク上にスワップ領域を加える場合、 そういうことをしたいと思うのはもっともですが、 ZIP のようなリムーバブルドライブの上ではそういう考えは不適切 でしょう。

最後に、新しいファイルシステムをつくります。ディスク全体を使用する ZIP ドライブの場合は、以下のようにします。

# newfs /dev/rda2c

次にマウントします。

# mount /dev/da2c /zip

また、次のような行を /etc/fstab (fstab(5) 参照) に入れておくのも良い考えでしょう。 mount /zip と入力するだけでマウントできるようになります。

/dev/da2c /zip ffs rw,noauto 0 0

これは通常、システム crontab (/etc/crontab) を編集し、crontab(1) を使ってインストールした場合に起こります。

# crontab /etc/crontab

この方法は正しくありません。 システム crontab のフォーマットは crontab(1) が更新する各ユーザの crontab とは異なります (フォーマットの相違点の詳細は crontab(5) で説明されています)。

もしこのような操作をしてしまったなら、 あらたな crontab は誤ったフォーマットの /etc/crontab のコピーになってしまっているからです。 以下のコマンドで削除してください。

# crontab -r

今度 /etc/crontab を編集する時は、 その変更を cron(8) に伝えるような操作をしてはいけません。 cron(8) は、自動的にその変更を認識するからです。

もしあなたが何かを一日一回、あるいは一週間や一ヶ月に一回だけ 実行させたいなら、シェルスクリプトを /usr/local/etc/periodic に追加し、 periodic(8) コマンドにシステムの cron スケジュールから 他の定期的なシステムのタスクとともに 実行させたほうが良いかもしれません。

このエラーの実際の原因は、システム crontab には どのユーザ権限でコマンドを実行するかを指定する余分なフィールドがあることによるものです。 FreeBSD に添付されている標準のシステム crontab には、 すべてのエントリに root が書かれています。 この crontab が root ユーザの crontab (システム crontab とは 異なります) として使われた場合、cron(8) は root を実行するコマンドの最初の単語だと認識しますが、 そのようなコマンドは存在しないのです。

これは、セキュリティ上の機能です。su コマンドを実行して root (またはスーパーユーザ権限を持つ 他のアカウント) になるには、wheel グループに所属していなければなりません。この機能がないと、 システムにアカウントがあって root の パスワードを見つけさえすれば、誰でもスーパーユーザ権限で システムにアクセスできてしまいます。この機能がある場合は、 必ずしもそうはなりません。wheel グループに 所属していなければ、su(1) がパスワードの入力すら 拒否するからです。

誰かが root に su できるように するには、その人を wheel グループに追加してください。

シェルのパス名を入力するプロンプトが表示されたときに、 単に ENTER を押し、mount / を 実行してそルートファイルシステムを再マウントさせます。 また、お気に入りのエディタがあるファイルシステムを マウントするために mount -a -t ufs を する必要があるかも知れません。あなたのお気に入りのエディタが ネットワークファイルシステム上にある場合は、 ネットワークファイルシステムをマウントする前にネットワークを 手動で設定するか、ed(1) のようなローカルファイルシステムにある エディタを使うかしなければなりません。

vi(1) や emacs(1) の様なフルスクリーンエディタを 使うつもりなら export TERM=cons25 と やってエディタが termcap(5) データベースから正しい データを読み取れるようにしなければなりません。

これを行ったあとはいつもと同様、 /etc/rc.conf を編集して間違いを訂正することができるようになります。 カーネル起動メッセージの直後に表示されたエラーメッセージには、 問題の起こったファイル内での行番号を表示されているはずです。

DOS 拡張パーティションは、 すべての基本パーティションの後に認識されます。 たとえば、2台目の SCSIドライブの拡張パーティションに 「E」 パーティションがあるとしますと、 これは /dev に「スライス 5 」のスペシャルファイルを作る必要があり、 /dev/da1s5 としてマウントされます。

# cd /dev
# ./MAKEDEV da1s5
# mount -t msdos /dev/da1s5 /dos/e

Digital UNIX: UFS CDROM は直接 FreeBSD でマウントすることができます。 Digital UNIX やそれ以外のシステムのサポートする UFS のディスクパーティションをマウントすることはもっと複雑なことで、 オペレーティングシステムのディスクパーティションの詳細に依存します。

Linux: 2.2 以降は ext2fs パーティションをサポートします。 詳しくは、mount_ext2fs(8) を見てください。

NT: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります。 詳しくは、Mark Ovens 氏によって書かれたチュートリアル http://ukug.uk.freebsd.org/~mark/ntfs_install.html をご覧ください。

この問題について他の情報があれば、他の人から感謝されるでしょう。

この手順は 2.2.x と (起動が 3 つのステージに分かれている) 3.x のシステムとで多少異なります。

FreeBSD のネイティブルートパーティションの最初のセクタをファイルにして DOS/NT パーティション上に置くという画期的なアイディアがあります。 ファイル名を c:\bootsect.bsd (c:\bootsect.dos からの発想です) としたとします。 c:\boot.iniファイルを次のように編集します。

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT"
C:\BOOTSECT.BSD="FreeBSD"
C:\="DOS"

この手順は、利用しているシステムが 2.2.x であり、DOS、NT、FreeBSD あるいはその他のオペレーティングシステムがすべて、 同じディスクのそれぞれの fdisk パーティションにインストールされていることを想定しています。 この例は、DOS と NT を最初の fdisk パーティションにおき、 FreeBSD は 2 番目においたシステムで確認しています。 また、FreeBSD は MBR を使わずに、 ネイティブパーティションから起動するように設定してあります (訳注: FreeBSD のインストールで、ブートマネジャを使わずに標準 MBR を使う場合に相当します)。

(もし NTFS に変換してしまっているなら)DOS フォーマットのフロッピーディスクか FAT パーティションを /mnt に DOS マウントします。

# dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1

再起動して DOS か NT に切替えます。NTFS ユーザは bootsect.bsd や bootsect.lnx をフロッピーディスクから C:\ へコピーします。 boot.ini のファイル属性 (パーミッション) の変更を以下のように行ないます。

> attrib -s -r c:\boot.ini

上の例の boot.ini で示したような正しいエントリを加え、 ファイル属性を元に戻します。

> attrib +s +r c:\boot.ini

FreeBSD が MBR から起動するようになっている場合、 それぞれのネイティブパーティションから起動するように設定した後で、 DOS から fdisk コマンドを実行して元に戻してください。

FreeBSD 3.X における手順は、これよりいくぶん簡単です。

FreeBSD が NT 起動パーティションとして同じディスクにインストールされている場合には、 /boot/boot1 を単純に C:\BOOTSECT.BSD へコピーします。 もし FreeBSD が異なったディスクにインストールされている場合には、 /boot/boot1 では動作しませんので、 /boot/boot0 が必要です。

/boot/boot0 をインストールするには、 sysinstall のブートマネージャを利用するかどうか尋ねられる画面で FreeBSD ブートマネージャを選択する必要があります。 /boot/boot0 のパーティションテーブル部分は NULL 文字で埋められているのですが、 sysinstall は /boot/boot0 を MBR にコピーする前にパーティションテーブルをきちんとコピーしてくれるからです。

FreeBSD ブートマネージャは最後に起動した OS を記録するために パーティションテーブルの最後に起動した OS のエントリにあるアクティブフラグをセットし、512 バイト全体を MBR に書き戻します。 これは /boot/boot0 を C:\BOOTSECT.BSD にコピーし、 エントリの一つにアクティブフラグをセットして空のパーティションテーブルを MBR に書き込むことと同じです。

FreeBSD と Linux が同じディスクにインストールされている場合、 単に Linux 以外の OS を起動するための LILO のインストール手順に 従えばいいだけです。非常に簡単にではありますが、記してみましょう。

Linux を起動し、/etc/lilo.conf に以下の行を加えて ください。

other=/dev/hda2
        table=/dev/hda
        label=FreeBSD

(上記の手順は FreeBSD のスライスが Linux から /dev/hda2 という名前で見えていると仮定しています。 あなたの設定にあわせてください) その後、lilo を root で実行すれば完了です。

FreeBSD が別のディスクにインストールされているのなら、 LILO のエントリに loader=/boot/chain.b を追加してください。たとえば、このようになります。

other=/dev/dab4
        table=/dev/dab
        loader=/boot/chain.b
        label=FreeBSD

場合によっては、二つ目のディスクを正しく起動するために FreeBSD ブートローダに BIOS ドライブ番号を指定する必要があるかもしれません。 たとえば、FreeBSD SCSI ディスクが BIOS によって BIOS ディスク 1 として認識されるのなら、 FreeBSD のブートローダのプロンプトで、次のように指定する必要があります。

Boot: 1:da(0,a)/kernel

FreeBSD 2.2.5 やそれ以降の版では、boot(8) を設定すれば 起動時に上記のことが自動的に行えます。

Linux+FreeBSD mini-HOWTO が FreeBSD と Linux とを相互に使えるようにするためのよい参考資料になるでしょう。

LILO をマスターブートレコード (MBR) ではなく Linux の起動パーティションにインストールしてください。 これで BootEasy から LILO を起動できるようになります。

Windows95 と Linux を使用している場合は、 いずれにせよ後者の方がおすすめです。 Windows95 を再インストールする必要にかられたとき、 Linux を起動可能に戻す手続きが簡単ですむからです (Windows95 は偏屈なオペレーティングシステムで、 マスターブートレコード (MBR) から他のオペレーティングシステムを追い払ってしまうのです)。

インストール作業中、 ハードディスクのパーティションを切る際に 2 つの方法を選ぶことができます。 デフォルトの方法では、fdisk のテーブルエントリ (FreeBSD ではスライスと呼ばれる) を使って、 自身のパーティションを使用する FreeBSD のスライスを、 同じマシンの他のオペレーティングシステムと互換性のある形にします。 それに付随して、ブートセレクタをインストールすれば、 ディスク上の使用可能なオペレーティングシステムを切り替えることができます。 もう一つの方法はディスクすべてを FreeBSD で使うというもので、 この場合ほかのオペレーティングシステムとの互換性を考慮しないことになります。

では、なぜこれが 「危険覚悟の」と言われるのでしょう? このモードのディスクが、通常の PC のユーティリティが有効な fdisk テーブルと見なす情報を持っていないからです。 ユーティリティの出来如何によりますが、 そのようなディスクを発見したとき、 警告を出すものもあります。また、もっと悪い場合、 確認も通告もなしに BSD のブートストラップにダメージを与えるものもあるでしょう。 さらには、「危険覚悟の」ディスクレイアウトは多数の BIOS、 AWARD (たとえば HP Netserver や Micronics システム、 他多数で使用されていた) や Symbios/NCR (人気のあるSCSI コントローラ 53C8xx 用) などを混乱させることが分かっています。 これは完全なリストではありません。 他にもまだまだあります。この混乱の兆候は、 起動時にシステムがロックするというだけでなく、 FreeBSD のブートストラップが自分自身を見つけられないために表示する 「read error」 というメッセージなどにも現れることでしょう。

そもそもいったいなぜこのモードがあるのでしょうか? これはわずかに数キロバイトのディスク容量を節約するのみであり、 新規インストールで実際に問題を生ずるのです。 「危険覚悟の」モードの起源は新しい FreeBSD インストーラでの、 BIOS から見えるディスクの 「ジオメトリ」の値とディスク自身との整合性という、 もっとも一般的な問題のひとつを回避したいという要求が背景にあります。

「ジオメトリ」は時代遅れの概念ですが、 未だに PC BIOS とディスクへの相互作用の中核をなしています。 FreeBSD のインストーラがスライスを作る時、 ディスク上のスライスを BIOS が見つけられるように、 スライス位置をディスク上に記録します。それが誤っていれば、 起動できなくなってしまうでしょう。

「危険覚悟の」モードはこれを、 問題を単純にすることで回避しようとします。 状況によってはこれでうまくいきます。 しかし次善の策として使われているに過ぎません。 この問題を解決するもっと良い方法はいくらでもあるのです。

では、 インストール時に「危険覚悟の専用」モードが必要になる 状況を回避するにはどうすればよいのでしょうか? まず BIOS が報告するディスクのジオメトリの値を覚えておくことからはじめましょう。 「boot:」 プロンプトで 「-v」 を指定するか、ローダで 「boot -v」 と指定して、 起動時にカーネルにこの値を表示させることができます。 インストーラが起動する直前に、 カーネルがジオメトリ値のリストを表示するでしょう。 パニックを起こさないでください。 インストーラが起動するのを待ち、 逆スクロールでさかのぼって値を確認してください。 普通は BIOS ディスクユニット番号は、 FreeBSD がディスクを検出する順序と同様であり、 最初に IDE、次に SCSI となります。

ディスクをスライシングする際に、 FDISK の画面で表示されるディスクのジオメトリが正しいこと (BIOS の返す値と一致しているか) を確認してください。 万一異なっていたら 「g」 を押して修正してください。 ディスクにまったくなにもない場合や、 他のシステムから持ってきたディスクの場合は これを行なう必要があるかもしれません。 これはそのディスクから起動させようとしている場合にのみ、 問題になることに注意してください。 FreeBSD はそのディスクをうまい具合いに他のディスクと区別してくれます。

ディスクのジオメトリについて BIOS と FreeBSD 間で一致させることができたら、この問題はほぼ解決したと思ってよいでしょう。 そしてもはや「危険覚悟の専用」モードは必要ありません。 しかし、まだ起動時に恐怖の 「read error」 メッセージが出るようであれば、 お祈りを捧げて新しいディスクを買いましょう。 もう失うものは何もありません。

「危険覚悟の専用ディスク」を通常の PC での使用法に戻すには、 原則として 2 つ方法があります。1 つは十分な NULL バイトを MBR に書き込んで、 きたるべきインストーラにディスクはまっさらだと思い込ませる方法です。 たとえば、こんな感じです。

# dd if=/dev/zero of=/dev/rda0 count=15

また、マニュアルには書かれていない DOS の「機能」

> fdisk /mbr

は、BSD ブートストラップを追い払ってくれる上に、 新しいマスターブートレコードをインストールしてくれます。

スワップパーティションのサイズを増やすのが最良の方法ですが、 別のディスクを追加しなくて済むという利点のある方法があります。 経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を とるというものです。しかしごく小さなメインメモリしかない場合は、 それ以上のスワップを構成したいと思うでしょう。また、将来のメモリの アップグレードに備え、後でスワップの構成を変更する必要がないように 十分なスワップを構成しておくことは良い考えです。

スワップを別のディスク上に追加することは、単純に同じディスク上 にスワップを追加する場合よりも高速に動作するようになります。 例に挙げれば、あるディスク上のソースをコンパイルしているとして、 スワップが別のディスク上に作られていれば、これらが同じディスク上 にある場合よりも断然速いです。SCSI ディスクの場合は特にそうだと言えます。

ディスクが複数ある場合、スワップパーティションを各ディスクに 作るように構成すると、使用中のディスク上にスワップを置いたとしても、 通常の場合は有益です。一般的に、システムにある高速なディスクには スワップを作るようにすべきでしょう。 FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで サポートします。複数のスワップパーティションを構成する際に、 普通はそれらを大体同じくらいの大きさにして作りたいところですが、 カーネルのコアダンプを取るのに都合が良いようにメインの スワップパーティションを大きめにとる人もいます。 メインのスワップパーティションはカーネルのコアがとれるように 最低でも実メモリと同じ大きさにすべきでしょう。

IDE ドライブは同時に同じチャネル上の複数のドライブには アクセスできません (FreeBSD は mode 4 をサポートしていないので、 すべての IDE ディスク I/O は 「programmed」 です)。 IDE の場合であってもやはり、スワップを別のハードディスク上に 作成することをおすすめします。 ドライブは実に安いものです、心配するだけ無駄です。

NFS 越しにスワッピングさせる方法は、 スワップ用のローカルディスクが無い場合にのみ推奨されます。 NFS 越しのスワッピングは遅く、FreeBSD 4.x より前のリリースでは 効率が悪いのですが、4.0 以降ではそれなりに高速になります。 そうはいっても、利用できるネットワークの太さに制限されますし、 NFS サーバに余計な負荷がかかります。

これは 64MBの vn-swap を作る例です (ここでは /usr/swap0 としますが、もちろん好きな名前を使うことができます)。

カーネルが次の行を含むコンフィグファイルから構成されているかを 確認します。GENERIC カーネルには、この行が含まれています。

pseudo-device   vn 1   #Vnode driver (turns a file into a device)

スワップファイルをすぐに有効化させたいのなら以下のようにタイプします。

# vnconfig -e /dev/vn0b /usr/swap0 swap

ハンドブックのプリンタの部分を参照してください。 探している問題のほとんどが書かれているはずです。 FreeBSD ハンドブックの「プリンタの利用」をご覧ください。

プリンタによっては、印刷するのにホスト側にドライバが 必要です。これら 「WinPrinters」 と呼ばれるものは、 素の FreeBSD では使えません。DOS や Windows NT 4.0 で動作しない なら、そのプリンタはおそらく WinPrinter でしょう。 ただし、唯一の希望が残されています。 ports/print/pnm2ppa の port が 対応しているかどうか確認してみてください。 パッケージの説明にはこう書いてあります。

kbdcontrol プログラムは、 キーボードマップファイルを読み込むためのオプションを備えています。 /usr/share/syscons/keymaps の下にたくさんのマップファイルがあります。 システムに関連のあるものを一つ選んで、ロードしてください。

# kbdcontrol -l uk.iso

/usr/share/syscons/keymaps と拡張子 .kbd は、どちらも kbdcontrol(1) によって使用されます。

これは /etc/sysconfig (または rc.conf(5)) 中で設定することができます。 このファイル中にあるそれぞれのコメントを参照してください。

FreeBSD 2.0.5R やそれ以降の版では、 テキストフォントやキーボードマッピングに関係のあるものはすべて、 /usr/share/examples/syscons の中におさめられています。

現在以下のマッピングがサポートされています。

以下は、freebsd-current メーリングリストへの投稿からの 抜粋です。

次のような症状が現れます。

# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format

通常この現象はタイプを「未使用 (unused)」のまま放っておかれた c パーティションをつなげようとした場合に現れます。ccd ドライバは FS_BSDFFS タイプをベースとするパーティションを要求します。 つなげようとしているディスクのディスクラベルを編集して、 パーティションのタイプを 4.2BSD に変更してください。

次のような症状が現れます。

# disklabel ccd0
(it prints something sensible here, so let's try to edit it)
# disklabel -e ccd0
(edit, save, quit)
disklabel: ioctl DIOCWDINFO: No disk label on disk;
use "disklabel -r" to install initial label

これは ccd から返されるディスクラベルが、 実はディスク上にはないまったくの偽の情報だからです。 これを明示的に書き直すことで問題を解消できます、 それには、つぎのようにします。

# disklabel ccd0 > /tmp/disklabel.tmp
# disklabel -Rr ccd0 /tmp/disklabel.tmp
# disklabel -e ccd0
(this will work now)

はい。 FreeBSD は System-V スタイルの IPC をサポートします。 共有メモリ、メッセージ、セマフォが含まれます。 以下の行をカーネルコンフィグファイルに加えると、 サポートが有効になります。

options    SYSVSHM          # enable shared memory
options    SYSVSEM          # enable for semaphores
options    SYSVMSG          # enable for messaging

カーネルを再構築してインストールしてください。

FreeBSD に付属している sendmail は、 インターネットに直接つながっているサイトにあわせて設定してあります。 UUCP 経由で mail を交換したい場合には sendmail の設定ファイルを改めてインストールしなければなりません。

/etc/sendmail.cf を自分の手で改造するのは純粋主義者のやるような事です。 sendmail の version 8 は m4(1) のようなプリプロセッサを通して設定ファイルを生成する新しいアプローチを取っており、 より抽象化されたレベルの設定ファイルを編集します。 /usr/src/usr.sbin/sendmail/cf ディレクトリの中にある設定ファイルを使用してください。

もしすべてのソースをインストールしていない場合には sendmail の設定ツールは、別の tar ファイルにまとめてあります。CD-ROM が mount されている場合には、次のようにしてください。

# cd /cdrom/src
# cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail

これはたった数 100Kbyte ですから心配ないでしょう。 cf ディレクトリにある README に、m4 での設定の基本的な説明があります。

UUCP での配送のためには、mailertable を使用すれば よいでしょう。これによって、sendmail が配送方式を決定するデータベースを 作成することができます。

まずはじめに、 .mc ファイルを作成しなければなりません。 /usr/src/usr.sbin/sendmail/cf/cf というディレクトリが、 これらのファイルを作成する場所です。既にいくつか例があると思います。 これから作成するファイルの名前を foo.mc とすると、 sendmail.cf を求めているような形式に変換するには、 次のようにしてください。

# cd /usr/src/usr.sbin/sendmail/cf/cf
# make foo.cf
# cp foo.cf /etc/sendmail.cf

標準的な .mc ファイルは次のようになります。

include(`../m4/cf.m4')
VERSIONID(`Your version number')
OSTYPE(bsd4.4)

FEATURE(nodns)
FEATURE(nocanonify)
FEATURE(mailertable)

define(`UUCP_RELAY', your.uucp.relay)
define(`UUCP_MAX_SIZE', 200000)

MAILER(local)
MAILER(smtp)
MAILER(uucp)

Cw    your.alias.host.name
Cw    youruucpnodename.UUCP

nodns と nocanonify という指定をすることで、 mail の配送に DNS を使用しなくなります。 UUCP_RELAY という 行に関しては、 ある理由から必要ですがそれは聞かないでください。 .UUCP で終わる仮想ドメインを処理することのできるインターネット上での ホスト名をここに書いてください。通常は、ISP の mail リレーホストを 書くことになると思います。

これが終了したら、次に /etc/mailertable というファイルが必要です。標準的な例は次のとおりです。

#
# makemap hash /etc/mailertable.db < /etc/mailertable
#
horus.interface-business.de   uucp-dom:horus
.interface-business.de        uucp-dom:if-bus
interface-business.de         uucp-dom:if-bus
.heep.sax.de                  smtp8:%1
horus.UUCP                    uucp-dom:horus
if-bus.UUCP                   uucp-dom:if-bus
.                             uucp-dom:

見れば分かるように、これは実在する設定のファイルです。はじめの 3 行はドメイン名で指定されたメールが default の経路で配送されずに、 「近道」するために UUCP で隣りのサイトに送るための特別な状況を 処理するものです。 次の行は Ethernet でつながっているローカルのドメインに対しては SMTP で送るための設定です。 最後に、UUCP での隣りのサイトが .UUCP で終わる仮想ドメインの書式で 指定されており、default の rule を uucp-neighbour! recipient で上書きするためのものです。一番最後の行はいつもドットを一つ書きます。 これは、ここまでの行でマッチしなかったすべてのホストにマッチし、 このサイトから世界に向けて出ていくための mail gateway に UUCP で配送するためのものです。 uucp-dom: に続けて書かれているノード名は、 uuname コマンドで指定することによって UUCP で直接配送される正しいノード名でなければなりません。

最後に、このファイルは使用する前に DBM データベースのファイルに 変換する必要があります。これを行なうコマンドラインは mailertable の最初のコメントに書いてあります。mailertable を変更した時には、 必ずこのコマンドを実行してください。

最後のヒントです: もし特定のメール配送がうまく作動するかどうか 確かめたい場合には、sendmail の-bt オプションを 使用してください。このオプションによって sendmail は アドレステストモードで起動します。 0 の後に配送したいアドレスを書いてください。最後の行に、実際に使用される mail agent、この mail agent で送られる送信先のホスト、そして (多分変換されている) アドレスが表示されます。このモードを抜けるには Control-D を押してください。

% sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 0 foo@interface-business.de
rewrite: ruleset  0   input: foo @ interface-business . de
...
rewrite: ruleset  0 returns: $# uucp-dom $@ if-bus $: foo \
< @ interface-business . de >
> ^D

静的に IP アドレスが割り当てられる場合は、 デフォルトの状態を変更する必要はありません。 割り当てられた名前をホストネームと するだけで、sendmail が後のことを引き受けてくれます。

ダイアルアップ ppp を インターネット接続に使用し、動的に IP アドレスが割り当てられる場合は、 インターネットサービスプロバイダ (ISP) のメールサーバにメールボックスがあるはずです。 ISP のドメインが myISP.com で、あなたのユーザ名が user だと仮定します。 また、あなたが自分のマシンを bsd.home と呼んでおり、ISP が relay.myISP.com をメールリレーとして使用できると言っているとしましょう。

メールボックスからメールを取ってくるためには、 回収 (retrieval) エージェントをインストールする必要があります。 Fetchmail は多種多様なプロトコルをサポートしているのでお勧めです。 ISP が使用しているのは、大抵 POP3 プロトコルです。 ユーザ ppp を使用している場合、 /etc/ppp/ppp.linkup に以下のように記述すると、 インターネットと接続が完了した時点で自動的にメールを取得するようになります。

MYADDR:
        !bg su user -c fetchmail

ローカルでないアカウントにメールを配送するのに sendmail を使用している場合 (後述)、 上に示したエントリの後に

        !bg su user -c "sendmail -q"

を記述します。これはネットワーク接続が確立したらすぐに sendmail に溜っている mailqueue を強制的に処理させるようにします。

この例では、user が bsd.home にアカウントを持ち、 bsd.home 上の user のホームディレクトリに、以下のような .fetchmailrc ファイルがつくられていることを想定しています。

poll myISP.com protocol pop3 fetchall pass MySecret;

言うまでもなく、このファイルは user 以外のユーザが読むことが出来ないようにしなくてはなりません。 内容にパスワード MySecret が含まれているからです。

正しい from: ヘッダをつけてメールを送るためには、 sendmail に user@bsd.home ではなく user@myISP.com を使用するよう教える必要があります。 メールをより早く転送するために、すべてのメールを relay.myISP.com へ送るように sendmail に 指示しておくのも良いでしょう。

上の要件を満たすには、以下のような .mc ファイルが適しています。

VERSIONID(`bsd.home.mc version 1.0')
OSTYPE(bsd4.4)dnl
FEATURE(nouucp)dnl
MAILER(local)dnl
MAILER(smtp)dnl
Cwlocalhost
Cwbsd.home
MASQUERADE_AS(`myISP.com')dnl
FEATURE(allmasquerade)dnl
FEATURE(masquerade_envelope)dnl
FEATURE(nocanonify)dnl
FEATURE(nodns)dnl
define(`SMART_HOST', `relay.myISP.com')
Dmbsd.home
define(`confDOMAIN_NAME',`bsd.home')dnl
define(`confDELIVERY_MODE', `deferred')dnl

.mc ファイルから sendmail.cf への変換方法については、 前のセクションを参照してください. sendmail.cf を更新した後に sendmail をリスタートするのもお忘れなく。

心配無用です。toor は 「代替の」 スーパーユーザーアカウントです (toor は root を逆に綴ったものです)。 以前は、bash(1) シェルがインストールされた時に 作成されていましたが、現在は標準で作成されています。 このユーザーが作成されるのは、 スーパーユーザが非標準のシェルを使う場合を想定しており、 root の標準のシェルを変更しなくてもよくなっています。 基本配布に含まれていないシェル (たとえば ports や packages からインストールされるシェル) は、デフォルトでは別のファイルシステムに存在する 可能性のある /usr/local/bin に インストールされることが多いので、これは重要です。 root のシェルが /usr/local/bin にあり、 /usr (または、/usr/local/bin があるいずれかのファイルシステム) が何らかの理由でマウントされていないとすると、 root は問題を解決するために ログインすることができません (シングルユーザーモードで再起動すれば、 シェルのパスの入力を促されるのですが)。

toor を日々の root の仕事を 非標準のシェルで行うために使い、root は シングルユーザーモードや緊急時のために、標準のシェルのままに している人がいます。何もしなければ、パスワードを無効にしてあるので toor ではログインできません。 使いたいなら、root でログインして toor の パスワードを設定しましょう。

慌てないでください! 単にシステムを再起動し、 シングルユーザモードに移るために Boot: と表示されるプロンプトで boot -s と入力してください (FreeBSD の 3.2 より前のリリースでは -sとなります)。 どのシェルを使うのかという質問には、ENTER キーを押してください。# に移ることができるでしょう。 mount -u / と入力して ルートファイルシステムの読み書きを再マウントし、 mount -a と入力して、 すべてのファイルシステムをマウントし直した後、 passwd root と入力して root のパスワードを設定し直してください。 その後、exit と入力すれば、起動が続けられます。

FreeBSD 2.2.7-RELEASE 以降で syscons (デフォルトのコンソールドライバ) を使用している場合には、次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し、インストールしてください。

options SC_DISABLE_REBOOT

FreeBSD 2.2.5-RELEASE 以降で PCVT コンソールドライバを使用している 場合には、同様に次の行をカーネルコンフィグレーションファイルに追加して カーネルを再構築し、インストールしてください。

options PCVT_CTRL_ALT_DEL

上にあげたものよりも古い FreeBSD の場合、 現在コンソールが使用しているキーマップを編集し、 キーワード boot を nop に書き換えてください。 /usr/share/syscons/keymaps/us.iso.kbd にあります。 その変更を反映させようとして、 このキーマップのロードを明示的に行なうために、 /etc/rc.conf を実行すべきかもしれません。 もちろん他の国のキーマップを使っているのであれば、 代わりにそのキーマップファイルを編集してください。

単に次の perl コマンドを実行してください。

% perl -i.bak -npe 's/\r\n/\n/g' file ...

file の部分には処理するファイルを指定してください。 整形後のファイルは元のファイル名で作成され、 整形前のファイルはバックアップとして元の ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます。

あるいは tr(1) コマンドを使うこともできます。

% tr -d '\r' < dos-text-file > unix-file

dos-text-file は DOS 形式のテストファイル、 unix-file には変換された出力が格納されます。 perl を使うよりほんのちょっぴり速くなります。

killall(1) を使ってください。

Kerberos の認証システムからくるエラーです。 この問題は致命的なものではなく、 うっとおしいといったものです。 su に -K オプションをつけて起動するか、 次の質問で説明されている方法で Kerberos をアンインストールしてください。

システムから Kerberos を削除するには、 あなたの動かしているリリースの bin ディストリビューションを再インストールしてください。 もし CDROM を持っているのなら、 その CDROM をマウント (マウントポイントは /cdrom と仮定) して、 次のように入力してください。

# cd /cdrom/bin
# ./install.sh

telnet、ssh、X、screen をたくさん利用されている場合、 疑似ターミナルが足りなくなっている可能性があります。 これを増やすには次のようにします。

snd というデバイスは存在しません。 この名前は、FreeBSD サウンドドライバによって作成されるさまざまなデバイス、 mixer や sequencer、 dsp などを総称したものです。

これらのデバイスを作成するには、次のようにする必要があります。

# cd /dev
# sh MAKEDEV snd0

シングルユーザモードに移行して、 マルチユーザモードに戻ってください。

コンソールで次のように実行します。

# shutdown now(注: -r や -h は付けません)
# return
# exit

「砂場 (Sandbox)」 とはセキュリティ用語の一つで、 次の二つの意味があります。

UNIX は、内部的に二つの砂場 (sandbox) を実装しています。 一つはプロセスレベルのもの、もう一つはユーザ ID レベルのものです。

UNIX プロセスはすべて、他の UNIX プロセスから完全に隔離されています。 どのプロセスも、他のプロセスのアドレス空間を変更することはできません。 これは、あるプロセスが他のプロセスのアドレス空間を上書きできるような、 クラッシュにつながる行為が容易に実現できる Windows とは全く異なるものです。

UNIX プロセスは、特定のユーザ ID が所有します。 もし、実行者のユーザ ID が root ユーザのものでなければ、 ユーザ ID は、他のユーザが所有するプロセスから そのプロセスを守る機能を果たすわけです。 また、そのユーザ ID は、ディスク上にあるデータを 保護するのにも使われています。

セキュアレベルとはカーネルに実装されているセキュリティ機構の一つです。 簡単に言うと、カーネルはセキュアレベルが正の値の時に、 ある特定の操作を制限します。この制限は、たとえスーパユーザ (root のこと) であっても例外ではありません。 この文を書いている時点では、 セキュアレベル機構を使って以下のような操作を制限することができます。

稼働中のシステムでセキュアレベルの状態をチェックするには、 次のコマンドを実行します。

# sysctl kern.securelevel

出力には、sysctl(8) 変数 (今の場合は kern.securelevel) と数字が現れます。 数字が現在のセキュアレベルの値です。 これがもし正の値なら、 何らかのセキュアレベルによる制限が有効になっています。

システム稼働中にセキュアレベルを下げることはできません。 これは、それを可能にするとセキュアレベルの意味がなくなってしまうからです。 セキュアレベルが正の値でないことを要求する操作 (たとえば installworld や日付の変更など) を行なう必要がある場合は、/etc/rc.conf にあるセキュアレベルの設定 (kern_securelevel と kern_securelevel_enable という変数) を変更して再起動する必要があります。

セキュアレベルに関する詳しい情報や、 各レベルで実現される機能に関しては init(8) のマニュアルページを参照してください。

一般ユーザーでもデバイスをマウントできるようにすることができます。 手順は次のとおりです。

これで、すべてのユーザは フロッピー /dev/fd0 を 自身の所有するディレクトリへマウントすることができます。

% mkdir ~/my-mount-point
% mount -t msdos /dev/fd0 ~/my-mount-point

これで、operator グループに所属するユーザは CDROM /dev/cd0c を 自身の所有するディレクトリへマウントすることができます。

% mkdir ~/my-mount-point
% mount -t msdos /dev/cd0c ~/my-mount-point

デバイスのアンマウントは簡単です。

% umount ~/my-mount-point

しかし、 vfs.usermount を有効にすることは、セキュリティ上よいことではありません。 MSDOS 形式のメディアにアクセスには、Ports コレクションにある パッケージ mtools を使用した方がよいでしょう。

一番良いのは新しいディスクに OS を再インストールして、 それからユーザデータを移すことです。特にあなたが -stable を 複数のリリースを跨いで追い掛けている場合にはこの方法をおすすめします。 あなたは boot0cfg(8) を使うことで booteasy を両方の ディスクにインストールでき、新しい配置で満足している間 デュアルブートができます。これを行ったあとデータを移す 方法を探すなら次の段落は読み飛ばしてください。

何もないディスクへインストールしないことに決めたならば /stand/sysinstall、なり fdisk(8) と disklabel(8) なりを使って新しいディスクに パーティションとディスクラベルを作らなければなりません。 また boot0cfg(8) で booteasy を両方のディスクに インストールして、コピーの作業が終わったあとに 古いシステムからでも新しいディスクからでも起動できるように しておく必要があります。この作業の詳細は formatting-media tutorial を見てください。

新しいディスクの立ち上げが終わってデータの移動を 待つばかりになりました。しかし悲しいかな、無闇やたらと コピーすればいいというものではありません。デバイスファイル (/dev) やシンボリックリンクなどは 失敗の元になります。これらを理解するツール、すなわち dump(8) や tar(1) 等を使う必要があります。 データの移転はシングルユーザで行うことをお勧めしますが、 絶対と言うわけではありません。

あなたは dump(8) と restore(8) 以外のもので root ファイルシステムを移行してはなりません。 tar(1) コマンドでもたぶんうまく行くでしょうが、 やらないほうがいいでしょう。パーティション一つを もう一つのからのパーティションに移すときは dump(8) と restore(8) 使うべきです。 パーティションのデータを新しいパーティションに移すのに dump を使うやり方は以下の通りです。

たとえば root を /dev/ad1s1a へ、暫定的なマウントポイントを /mnt として移そうとすると以下のようになります。

# newfs /dev/ad1s1a
# mount /dev/ad1s1a
# cd /mnt
# dump 0uaf - / | restore xf -

もしパーティションの構成を変えようと思っているなら - つまり一つだったものを二つにしたり二つだったものをくっつけたり しようとしているなら、自前であるディレクトリ以下のすべてを 新しい場所へ移す必要が出てくるかも知れません。dump(8) は ファイルシステムに働くのでこの目的には使えません。この場合は tar(1) を使います。一般に /old から /new への移動は tar(1) で 以下のようにします。

# (cd /old; tar cf - .) | (cd /new; tar xpf -)

/old に他のファイルシステムが マウントされていて、そのデータの移動までは考えてないならば 最初の tar(1) に 'l' フラグを追加します。

# (cd /old; tar clf - .) | (cd /new; tar xpf -).

tar(1) のかわりに cpio(1) や pax(1), cpdup (ports/sysutils/cpdup) 等を 使っても構いません。

短い答え: ただの名前です。RC は 「リリース候補 (Release Candidate)」 に 由来するもので、リリースが間近であることを意味します。 また、FreeBSD における -BETA は通常、 リリース前のコードフリーズ期間に入っているという意味になります。

長い答え: FreeBSD はそのリリースを 2 ヶ所あるうちの 一方から派生させます。3.0-RELEASE や 4.0-RELEASE の様な (0 のマイナー番号を持つ) メジャーリリースは、一般に -CURRENT と呼ばれる 開発版の流れから分岐させられてできます。3.1-RELEASE や 4.2-RELEASE などのマイナーリリースはアクティブな -STABLE ブランチ (枝) の スナップショットでした。 4.3-RELEASE からは、リリース毎にブランチが作成されるように なりました。ものすごく保守的な開発速度 (主にセキュリティ 勧告のみ) を求めている人は、このブランチを追跡すると よいでしょう。

リリースを作る時になるとそれを分岐させるブランチは 特定のプロセスへ突入します。そのプロセスの一つは コードフリーズ (コードの凍結) です。コードフリーズが 始まると、そのブランチの名前がリリースになろうとしていることを 反映するものに変えられます。たとえば、4.0-STABLE と 呼ばれていたブランチは名前が 4.1-BETA へと 変えられ、コードフリーズとリリース前のテストが 始まったことを示します。 バグの修正はリリースの一部としてコミットされます。 ソースコードがリリースの形を取ったなら名前が 4.1-RC へと 変えられ、それからリリースが作られることを示します。 ひとたび RC のステージになってしまうと、発見された もっとも致命的なバグの修正しかできなくなります。 ひとたびリリースが (この例では 4.1-RELEASE) 作られれば、 そのブランチは 4.1-STABLE と改名されます。

簡単な回答: 多分、セキュアレベルが 0 より大きくなっているのでしょう。 直接シングルユーザモードで再起動して、 カーネルをインストールしてください。

詳しい回答: FreeBSD では、セキュアレベルが 0 より大きい場合、 システムフラグの変更が禁止されます。 現在のセキュアレベルは、次のコマンドを使って調べることができます。

# sysctl kern.securelevel

セキュアレベルを下げる操作は、できないようになっています。 そのため、カーネルをインストールするには、 シングルユーザモードで起動するか、/etc/rc.conf のセキュリティ設定を変更して再起動する必要があります。 セキュアレベルの詳細は init(8) を、 rc.conf の詳細は /etc/defaults/rc.conf および、 rc.conf(5) のマニュアルページをご覧ください。

簡単な回答: 多分、セキュアレベルが 1 より大きくなっているのでしょう。 直接シングルユーザモードで再起動して、 時刻の変更をしてください。

詳しい回答: FreeBSD では、セキュアレベルが 1 より大きい場合、 1 秒以上の時刻変更が禁止されます。 現在のセキュアレベルは、次のコマンドを使って調べることができます。

# sysctl kern.securelevel

セキュアレベルを下げる操作は、できないようになっています。 そのため、システムの時刻を変更するには、 シングルユーザモードで起動するか、/etc/rc.conf のセキュリティ設定を変更して再起動する必要ばあります。 セキュアレベルの詳細は init(8) を、 rc.conf の詳細は /etc/defaults/rc.conf および、 rc.conf(5) のマニュアルページをご覧ください。

いいえ。それはメモリリークではありませんし、 256 メガバイトのメモリを使っている、ということでもありません。 おそらく (ほとんどの場合)、 処理に都合が良いように非常にたくさんの量のメモリを そのプロセスのアドレス空間にマッピングしているのでしょう。 技術的な見地から考えても、これは大きな害があることではなく、 単に top(1) や ps(1) といったツールの表示に影響がある程度です。

rpc.statd(8) は、(/var にある) ステータスファイルを自分のアドレス空間にマッピングします。 マッピングは、後で大きな空間が必要になった時に再マッピングしないで済むよう、 非常に大きなサイズを指定して行なわれます。 これは、ソースコードに含まれる mmap(2) 関数のマッピング長を示す引数に 0x10000000 が指定されていることからも分かります。 この数字が IA32 アーキテクチャの持つアドレススペース全体の 16 分の 1、すなわち、ちょうど 256 メガバイトに相当するのです。

もっとも簡単な方法は FreeBSD のインストールの際に X を動かすことを指定するだけです。

それから xf86config ツールのドキュメントを読んでこれに従ってください。 このツールはあなたのグラフィックカードやマウスなどに合わせて XFree86(tm) の設定を行うのを助けてくれます。

Xaccel サーバーについて調べてみるのもいいでしょう。 詳しくは Xi Graphics について か Metro Link をご覧ください。

あなたのシステムは高いセキュアレベルで運用されていますね? 実は、高いセキュアレベルで X を起動することはできないのです。 どうしてなのかについては、init(8) のマニュアルページに書かれています。

では、代わりにどうすれば良いのかお答えしましょう。 基本的に 2 つの方法があります。 一つはセキュアレベルを 0 にする (通常、これは /etc/rc.conf で指定します) こと、 もう一つは起動時 (セキュアレベルを上げる前) に xdm(1) を実行するかです。

起動時に xdm(1) を実行する方法の詳細については、 問：〓8.8 を参照してください。

syscons (デフォルトのコンソールドライバ) を使っているのであれば、 それぞれの仮想スクリーンでマウスポインターをサポートするように FreeBSD を設定できます。X でのマウスの衝突を避けるために、syscons は /dev/sysmouse という仮想デバイスをサポートしています。 本物のマウスデバイスから入力されたすべてのマウスのイベントは、 moused を経由して sysmouse デバイスへ出力されます。 一つ以上の仮想コンソールと X の 両方で マウスを使いたい場合、 問：〓2.11 を参照して moused を設定してください。

そして、/etc/XF86Config を編集し、 次のように書かれていることを確認してください。

Section         Pointer
Protocol        "SysMouse"
Device          "/dev/sysmouse"
.....

上の例は、XFree86 3.3.2 以降の場合の例です。 それより前のバージョンでは、 Protocol という部分を MouseSystems と置き換える必要があります。

X で /dev/mouse を使うのを好む人もいます。 この場合は、 /dev/mouse を /dev/sysmouse (sysmouse(4) 参照) にリンクしてください。

# cd /dev
# rm -f mouse
# ln -s sysmouse mouse

はい、もちろん使えますが、そのためには X クライアントプログラムを適切に設定する必要があります。これについては、 Colas Nahaboo 氏のウェブページ(http://www.inria.fr/koala/colas/mouse-wheel-scroll/) を参照してください。

imwheel というプログラムを使う場合は、 次のような簡単な手順にしたがってください。

Num Lock キーをオフにしてください。

Num Lock キーがデフォルトで起動時にオンになる場合は、 XF86Config ファイルの Keyboard セクションに以下の行を加えてもいいでしょう。

# Let the server do the NumLock processing.  This should only be
# required when using pre-R6 clients
    ServerNumLock

仮想コンソールは、簡単にいうと、ネットワークや X を動かすなどの複雑なことを行なわずに、 いくつかのセッションを同時に行なうことを可能にします。

システムのスタート時には、 起動メッセージが出た後に login プロンプトが表示されます。そこで ログイン名とパスワードを入力すると 1 番目の仮想コンソール上で仕事 (あるいは遊び) を始めることができます。

他のセッションを始めたい場合もあるでしょう。 それは動かしているプログラムのドキュメントを見たり、 FTP の転送が終わるまで待つ間、 メールを読もうとしたりすることかもしれません。 Alt-F2 を押す (Alt キーを押しながら F2 キーを押す) と、 2 番目の「仮想コンソール」で ログインプロンプトが待機していることがわかります。 最初のセッションに戻りたいときは Alt-F1 を押します。

標準の FreeBSDインストールでは、 3 枚 (3.3-RELEASE では 8 枚) の仮想コンソールが有効になっていて、 Alt-F1、 Alt-F2、 Alt-F3 で仮想コンソール間の切替えを行ないます。

より多くの仮想コンソールを有効にするには、 /etc/ttys (ttys(5) 参照) を編集して 「Virtual terminals」 のコメント行の後に ttyv4 から ttyvc の手前までのエントリを加えます (以下の例は先頭には空白は入りません)。

# /etc/ttys には ttyv3 がありますので
# "off" を "on" に変更します。
ttyv3   "/usr/libexec/getty Pc"         cons25  on secure
ttyv4   "/usr/libexec/getty Pc"         cons25  on secure
ttyv5   "/usr/libexec/getty Pc"         cons25  on secure
ttyv6   "/usr/libexec/getty Pc"         cons25  on secure
ttyv7   "/usr/libexec/getty Pc"         cons25  on secure
ttyv8   "/usr/libexec/getty Pc"         cons25  on secure
ttyv9   "/usr/libexec/getty Pc"         cons25  on secure
ttyva   "/usr/libexec/getty Pc"         cons25  on secure
ttyvb   "/usr/libexec/getty Pc"         cons25  on secure

多くするか少なくするかはあなたの自由です。 より多くの仮想ターミナルを使うとより多くのリソースを使うことになります。 8MB 以下のメモリしかない場合はこれは重要な問題です。 もし必要があれば secure を insecure に変更してください。

仮想コンソールを無効にするもっとも簡単な方法は、 コンソールを off にすることです。 たとえば 12 個すべてのターミナルを割り当てている状態で X を動かしたいときは、 仮想ターミナル 12 を変更します。

ttyvb   "/usr/libexec/getty Pc"         cons25  on secure

これを次のように変更します。

ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

キーボードにファンクションキーが 10 個しかないのであれば、 次のように設定します。

ttyv9   "/usr/libexec/getty Pc"         cons25  off secure
ttyva   "/usr/libexec/getty Pc"         cons25  off secure
ttyvb   "/usr/libexec/getty Pc"         cons25  off secure

(これらの行を消すだけでもいいです。)

/etc/ttys を編集したら、 次は十分な数の仮想ターミナルデバイスを作らなくてはなりません。 もっとも簡単な方法を示します。

# cd /dev
# ./MAKEDEV vty12 (12 個のデバイスをつくる場合)

さて、仮想コンソールを有効にするもっとも簡単 (そして確実) な方法は、 再起動することです。しかし、再起動したくない場合は、 X ウィンドウシステムを終了させて次の内容を (root権限で) 実行します。

# kill -HUP 1

重要な点は、 このコマンドを実行する前に X ウィンドウシステムを完全に終了させておくことです。 もしそうしないと kill コマンドを実行した後、 システムはおそらくハングアップするでしょう。

仮想コンソールへ戻るには Ctrl+Alt+Fn を使ってください。 最初の仮想コンソールへは Ctrl+Alt+F1 で戻れます。

テキストコンソールへ移った後は、その中で移動するのに 今度はいつもどおり Alt+Fn を使ってください。

X のセッションへ戻るには X の走っている仮想コンソールへ 切り替える必要があります。もしあなたが X をコマンドラインから 実行していたのであれば (たとえば startx を使う) X のセッションはそれを実行したテキストコンソールではなく 最初の使われていない仮想コンソールに割り当てられているはずです。 あなたが仮想端末を 8 個用意している場合は X を 9 番目の コンソールにいるはずで、 Alt+F9 を使うことになります。

xdm の起動方法については二つの流派があります。 一方の流派では提供された例を使用して xdm を /etc/ttys (ttys(5) 参照) から起動し、もう一方の流派では xdm を単に rc.local (rc(8) 参照) または /usr/local/etc/rc.d においた X.sh スクリプトから起動します。 どちらも正しく、片方が動作しない場合は、もう片方が動作するでしょう。 どちらも場合でも結果は同じであり、X はグラフィカルな login: プロンプトを表示します。

ttys を利用する方法の利点は、 どの vty で X が起動したかの記録が残せることと、 ログアウト時に X サーバを再起動する責任を init に押しつけることができることでしょう。

rc.local からロードされる場合、 xdm は引数を持たずに (すなわち、デーモンとして) 起動します。 xdm は getty が起動した後にロードされなければなりません。 そうでないと、xdm は getty と衝突し、コンソールをロックアウトしてしまいます。 この問題に対処する最善の方法は、 起動スクリプト (訳注: rc.local のこと) で 10 秒ほどの sleep を実行させ、 その後に xdm をロードすることです。

/etc/ttys から xdm を起動させている場合には、 xdm と getty が衝突する可能性があります。 この問題を回避するには、/usr/X11R6/lib/X11/xdm/Xservers に vt 番号を追加してください。

:0 local /usr/X11R6/bin/X vt4

上の例は、/dev/ttyv3 を X サーバに対応させます。番号は 1 から始まりますので注意してください。 X サーバは vty を 1 から数えますが、 FreeBSD カーネルは vty を 0 から数えます。

X を startx で起動しますと、/dev/console のパーミッションは 変更できないようになっていますので、 xterm -C や xconsole は動きません。

これはコンソールのパーミッションが、 標準ではそのように設定されているからです。 マルチユーザシステムでは、 ユーザの誰もがシステムコンソールに書き込むことが可能である必要は必ずしもありません。 VTY を使い直接マシンにログインするユーザのために、 このような問題を解決するために fbtab(5) というファイルがあります。

要点を述べると、次のような形式の行を /etc/fbtab (fbtab(5) 参照) に加えます。

/dev/ttyv0 0600 /dev/console

そうすると、 /dev/ttyv0 からログインしたユーザが コンソールを所有することになるでしょう。

すべての X サーバは、 ビデオハードウェアに直接アクセスするために root ユーザで実行される必要があります。 古いバージョンの XFree86 (<= 3.3.6) に含まれるすべてのサーバは、 自動的に root 権限で実行されるように (root ユーザに setuid されて) インストールされます。 X サーバは大きく複雑なプログラムであり、 これは明らかにセキュリティを危険に晒す要因となります。 そのため新しいバージョンの XFree86 では、 サーバを root ユーザに setuid しないでインストールするようになりました。

X サーバを root ユーザで動かすというのは、 明らかにセキュリティ的に不適当で受け入れられないことです。 X を一般ユーザで実行するには、二つの方法があります。 一つは xdm や、その他のディスプレイマネージャ (たとえば kdm など) を使うこと、 もう一つは Xwrapper を使うことです。

xdm は、 グラフィカルなログイン画面を扱うデーモンです。 通常、起動時に実行され、 各ユーザの認証とユーザセションを開始させる機能を実現します。 基本的に、getty と login のグラフィック版、と考えて良いでしょう。 xdm の詳細については、 XFree86 関連文書 および FAQ 項目をご覧ください。

Xwrapper とは、X サーバ用のラッパ (wrapper) のことです。 これは必要なセキュリティを確保しつつ、一般ユーザが X サーバを実行できるようにした小さなユーティリティで、 コマンドライン引数の正当性チェックを行ない、 それを通過すれば適切な X サーバを起動します。 何らかの理由でディスプレイマネージャを使いたくない場合に これを使うと良いでしょう。 Ports Collection 全体をインストールしていれば、 /usr/ports/x11/wrapper にあります。

あなたのマウスとマウスドライバがうまく同期していないからかもしれません。

FreeBSD 2.2.5 までのバージョンでは、X から仮想ターミナルへ切替えて、 また X へ戻ると再同期するかもしれません。 この問題がよく起きるようであれば、カーネルコンフィグレーション ファイルに次のオプションを書いてカーネルを再構成してみてください。

options PSM_CHECKSYNC

もし、カーネルの再構築を行なったことがないのであれば、 カーネルを構築するの項を参照してください。

このオプションにより、 マウスとドライバの同期で問題が起きる可能性は少なくなるでしょう。 もしそれでもこの問題が起きるようならば、 再同期させるにはマウスを動かさないようにしておいて マウスボタンのどれかを押してください。

このオプションは残念ながらすべてのシステムで働くわけではなく、 また、PS/2 マウスポートにつながれているのが タップ (tap) 機能を持つ アルプス社製 GlidePoint デバイスの場合、 タップ機能が無効となってしまいます。

FreeBSD 2.2.6 以降のバージョンでは、 同期のチェック方法が少し改善されたので標準で有効になっています。 GlidePoint でもうまく働きます (同期チェックが標準の機能になったので PSM_CHECKSYNC オプションはこれらのバージョンからは削除されました)。 しかしながら、 まれにドライバが間違って (訳注: 問題がないのに) 同期に関して問題があると報告し、カーネルから

psmintr: out of sync (xxxx != yyyy)

というメッセージが出力されて、マウスが正しく動作していないように見える ことがあるかもしれません。

もしこのようなことが起こる場合には、PS/2 マウスドライバのフラグに 0x100 を指定して同期チェックを無効にしてください。システムの起動時に 「-c」 起動オプションを与えて UserConfig に入ります。

boot: -c

boot: -c

UserConfig のコマンドラインで以下のように入力してください。

UserConfig> flags psm0 0x100
UserConfig> quit

MouseSystems の PS/2 マウスのあるモデルは、 高解像度モードの場合にのみ正しく動作するということが報告されています。 それ以外のモードでは、 マウスカーソルがしょっちゅうスクリーン左上に行ってしまうかもしれません。

残念ながら FreeBSD 2.0.X や 2.1.X のバージョンでは、 この問題を解決する方法はありません。 2.2 から 2.2.5 のバージョンでは、 以下のパッチを /sys/i386/isa/psm.c に適用しカーネルの再構築を行なってください。

もし、カーネルの再構築を行なったことがないのであれば、 カーネルの構築の項を参照してください。

@@ -766,6 +766,8 @@
     if (verbose >= 2)
         log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n",
             unit, i);
+    set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH);
+
 #if 0
     set_mouse_scaling(sc->kbdc);    /* 1:1 scaling */
     set_mouse_mode(sc->kbdc);               /* stream mode */

FreeBSD 2.2.6 以降のバージョンでは、 PS/2 マウスドライバのフラグに 0x04 を指定してマウスを高解像度モードにします。 システムの起動時に -c 起動オプションを与えて UserConfig に入ります。

boot: -c

UserConfig のコマンドラインで以下のように入力してください。

UserConfig> flags psm0 0x04
UserConfig> quit

マウスに関する不具合の他の原因の可能性については、 直前のセクションも見てみてください。

Imake.tmpl は X の標準アプリケーション構築ツールである Imake パッケージの一部です。 Imake.tmpl は、 X アプリケーションの構築に必要な多くのヘッダファイルと同様に、 X のプログラムディストリビューションに含まれています。 sysinstall を使うか、 手動で X のディストリビューションファイルからインストールすることができます。

.xinitrc か .xsession で

xmodmap -e "pointer = 3 2 1"

というコマンドを実行してください。

FreeBSD 3.1 のリリース直前に、起動メッセージの表示期間に いわゆる "スプラッシュ" スクリーンを表示させることができる新しい機能が追加されました。 いまのところスプラッシュスクリーンは 256 色のビットマップ (*.BMP) か ZSoft PCX (*.PCX) ファイルです。 それに加えて、標準の VGA アダプタでの動作させるには 320x200 以下の解像度である必要があります。 カーネルに VESA サポートを追加すれば 1024x768 までのより大きいビットマップを使用できます。 VESA サポートを有効化するにはまず、 カーネルが VM86 カーネルオプションとともにコンパイルされている必要があることに注意してください。 VESA サポートそのものは VESA カーネルコンフィグオプション によって直接カーネル中にコンパイルするか、 起動時に VESA kld モジュールを読み込ませることができます。

スプラッシュスクリーンを使うには、 FreeBSD の起動プロセスをコントロールするスタートアップファイルを書き換える必要があります。 これらのファイルは FreeBSD 3.2 のリリース以前に変更されましたので、 現在は、スプラッシュスクリーンを読み込む方法が二つあります。

さて、あとはスプラッシュスクリーンを用意するだけです。 それには http://www.baldwin.cx/splash/ のギャラリーをサーフしてみてください。

はい、もちろん。 どういう動作をするかについて定義するには xmodmap(1) を使います。

標準的な "Windows(tm)" キーボードの場合、 対応するキーコードは 3 種類あります。

左にある Windows(tm) キーを押すとカンマ記号が入力されるようにするには、 こんな風にします。

# xmodmap -e "keycode 115 = comma"

設定を反映させるには、おそらくウィンドウマネージャを再起動する必要があります。

Windows(tm) キーのキーマップを X 起動時に毎回、 自動的に有効化するには xmodmap コマンドを ~/.xinitrc に追加するか、 もしくはおすすめできる方法として ~/.xmodmaprc というファイルを作成して、 そのファイルの一行一行に xmodmap のオプションを記述し、次の一行

xmodmap $HOME/.xmodmaprc

を ~/.xinitrc に追加するという方法があります。

たとえば、先ほどあげた三つのキーを F13、F14、F15 に割り当てるとします。 こうしておけば、後ほど示すように、アプリケーションや ウィンドウマネージャの便利な機能を その三つのキーに簡単に割り当てることができます。

こうするには、次の内容を ~/.xmodmaprc に追加します。

keycode 115 = F13
keycode 116 = F14
keycode 117 = F15

たとえば fvwm2 を使っていたら、 F13 をカーソル下のウィンドウのアイコン化、 F14 をウィンドウの前面/背面化、 F15 を、あたかもデスクトップにカーソルが存在しないかのように、 メインワークスペース (アプリケーション) のメニューを呼び出せる機能に割り当てられます。 最後の機能は、そのデスクトップがまったく見えないときに便利です。 (また、キートップのロゴにもぴったりです)

~/.fvwmrc の次のエントリは、前述の 設定を実現します。

Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop

「ディスクレスブート (diskless boot)」 というのは、FreeBSD がネットワーク上で起動し、 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです。 詳細については FreeBSD ハンドブックの「ディスクレスブート」を読んでください。

インターネット標準やこれまでのよい経験によって指摘されている通り、 FreeBSD は標準ではパケットを転送 (forward) するように設定されていません。 しかし、 rc.conf(5) の中で次の変数の値を YES とする事によってこの機能を有効にすることができます。

gateway_enable=YES          # Set to YES if this host will be a gateway

このオプションによって sysctl(8) の変数 net.inet.ip.forwarding が 1 になります。

ほとんどの場合、 ルータについての情報を同じネットワークの他の計算機等に知らせるために、 経路制御のためのプロセスを走らせる必要があるでしょう。 FreeBSD には BSD の標準経路制御デーモンである routed(8) が付属していますが、より複雑な状況に対処するためには GaTeD(http://www.gated.org/ から入手可能) を使用することもできます。 3_5Alpha7 において FreeBSD がサポートされています。

注意してほしいのは、FreeBSD をこのようにして使用している場合でも、 ルータに関するインターネット標準の必要条件を完全には満たしていない ということです。しかし、普通に使用する場合にはほとんど問題ありません。

通常、この質問が出てくる状況は自宅に二台の PC があり、一台では FreeBSD が、もう一台では Win95 が走っているような場合です。 ここでやろうとしていう事は FreeBSD の走っている計算機をインターネット に接続し、Win95 の走っているマシンからは FreeBSD の走っているマシンを経由して接続を行なう事です。 これは二つ前の質問の特別な場合に相当します。

…で、答えは「はい」です。 FreeBSD 3.x のユーザモード ppp には -nat オプションがあります。 ppp を -nat オプション付きで起動し、 /etc/rc.conf にある gateway_enable を YES に設定します。 そして Windows マシンを正しく設定すれば、 きちんと動作するでしょう。

設定に関するさらに詳しい情報は、 Steve Sims 氏による Pedantic PPP Primer にあります。

カーネルモード ppp を利用する場合や、 インターネットとのイーサネット接続が利用できる場合は、 natd を利用する必要があります。 この FAQ の natd のセクションを参照してください。

BIND の配布物と FreeBSD とでは cdefs.h というファイルの中でデータ型の矛盾があります。 compat/include/sys/cdefs.h を削除してください。

使えます。FreeBSD を用いて他のサイトに接続する場合には、 slattach(8)、sliplogin(8)、ppp(8) そして pppd(8) のマニュアルページをご覧ください。 ppp(8) と pppd(8) は、 PPP のサーバ、クライアント両方の機能を持っています。 その一方で、sliplogin(8) は SLIP のサーバ専用で、 slattach(8) は SLIP のクライアント専用です。

これらを使うためのさらなる情報については、ハンドブックの PPP と SLIP の章をご覧ください。

「シェルアカウント」を通じてのみインターネットへアクセス可能な場合、 slirp package みたいなものが欲しくなるかもしれませんね。 これを使えば、ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます。

ローカルなサブネット (一台以上のローカルマシン) を持っているが、 インターネットプロバイダから 1 つしか IP アドレスの割り当てを受けていない場合 (または IP アドレスを動的に割り当てられている場合でも)、 natd(8) プログラムを使いたくなるかもしれませんね。 natd を使えば、 1 つしか IP アドレスを持っていない場合でも、 サブネット全体をインターネットに接続させることができます。

ppp(8) も同様の機能を持っており、-nat スイッチで有効にすることができます。 どちらの場合も alias ライブラリ (libalias(3)) が使われます。

Berkeley UNIX におけるネットワークの構成において、 ネットワークのインタフェースはカーネルコードからのみ、 直接あつかうことができます。 より詳しく知りたい場合は、 /etc/rc.network というファイルや、 このファイルの中に書いてある、 さまざまなプログラムについてのマニュアルページを見てください。 それでもまだ分からない場合には、 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう。 ごく少しの例外をのぞいては、FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです。

ifconfig(8) のコマンドラインに netmask 0xffffffff を追加して、次のように書いてください。

# ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff

他のポートを使用したい場合には、 ifconfig(8) のコマンドラインにパラメータを追加しなければなりません。 デフォルトでは link0 が用いられるようになっています。 BNC のかわりに AUI ポートを使用したい場合には、 link2 というパラメータを追加してください。 これらのフラグは、 /etc/rc.conf (rc.conf(5) 参照) にある ifconfig_* の変数を使って指定されるはずです。

PC 用のネットワークカードによっては、 NFS のような、 ネットワークを酷使するアプリケーションにおいて問題を起こすものがあります。

この点に関しては FreeBSD ハンドブックの「NFS」を参照してください。

Linux の NFS のコードには、 許可されたポートからのリクエストしか受けつけないものがあります。 以下を試してみてください。

# mount -o -P linuxbox:/blah /mnt

SunOS 4.X が走っている Sun Workstation は、 許可されたポートからのマウント要求しか受けつけません。 以下を試してみてください。

# mount -o -P sunbox:/blah /mnt

最も良くある問題は、exports(5) のマニュアルページの以下の部分を正しく理解していないことです。

さて、ありがちな間違いをご覧になればはっきりするでしょう。 もし /usr 以下が単一のファイルシステムである (つまり /usr に何もマウントされない) 場合、 次の exports リストは正しくありません。

/usr/src   client
/usr/ports client

一つのファイルシステムに対して属性の指定が二行になっています。 /usr は同じホスト client にエクスポートされますから、 正しい書き方は次のようになります。

/usr/src /usr/ports  client

もう一度マニュアルページの文章を確認すると、 あるホストにエクスポートされる各ファイルシステムの属性は すべて一行に書かれていなければならない、となっています (ここでは、「アクセス可能なすべてのホスト」 も一つの独立したホストとして扱われることに注意してください)。 このことは、ファイルシステムをエクスポートするために 奇妙な書式を使わなければならない原因にもなっているのですが、 ほとんどの人にとって、これは問題にはならないでしょう。

次に示すのは、有効な exports リストの例です。 ここでは、/usr と /exports がローカルファイルシステムです。

# Export src and ports to client01 and client02, but only
# client01 has root privileges on it
/usr/src /usr/ports -maproot=0    client01
/usr/src /usr/ports               client02
# The "client" machines have root and can mount anywhere
# up /exports. The world can mount /exports/obj read-only
/exports -alldirs -maproot=0      client01 client02
/exports/obj -ro

/etc/rc.conf (rc.conf(5) 参照) の中で次の変数を NO にして、 TCP extension を無効にしてみてください。

tcp_extensions=NO

Xylogic の Annex も同様の問題がありますので、 Annex 経由で PPP を行なう場合にもこの変更を行ってください。

FreeBSD 2.0 かそれ以降では、 標準の状態で完全にマルチキャストに対応しています。 現在使用している計算機をマルチキャストのルータ (router) として使用するには、 MROUTING というオプションを定義したカーネルを作ったうえで、 mrouted を走らせる必要があります。2.2 かそれ以降の FreeBSD ならば、 /etc/rc.conf でフラグ mrouted_enable を YES にセットしておくことで、 起動時に mrouted を起動できます。

MBONE 用のツールは ports 内の専用のカテゴリー mbone にあります。 vic や vat といった会議用のツールを探している場合は、 この場所を見てください。

詳しい情報は Mbone Information Web にあります。

Glen Foster 氏による一覧に、 最近の製品を追加したものを以下に示します。

Vendor          Model
----------------------------------------------
ASUS            PCI-L101-TB
Accton          ENI1203
Cogent          EM960PCI
Compex          ENET32-PCI
D-Link          DE-530
Dayna           DP1203, DP2100
DEC             DE435, DE450
Danpex          EN-9400P3
JCIS            Condor JC1260
Linksys         EtherPCI
Mylex           LNP101
SMC             EtherPower 10/100 (Model 9332)
SMC             EtherPower (Model 8432)
TopWare         TE-3500P
Znyx            (2.2.X) ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
                (3.X) ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442,
                      ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)

実際にはそのホストは別のドメインにあるのではないですか。 たとえば、foo.bar.edu というドメインの中から、 bar.edu ドメインにある mumble というホストを指定したい場合には、 mumble だけではダメで、 mumble.bar.edu という FQDN (fully-qualified domain name) で指定しなければなりません。

伝統的に、BSD の BIND のリゾルバ (resolver) ではこのような事は可能でしたが、 FreeBSD に入っている bind (named(8) 参照) の現在のバージョンでは、 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません。 したがって mumble というホスト名は、 mumble.foo.bar.edu という名前か、もしくは root ドメイン内にある場合にしか適用されません。

これは、 mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチが行なわれていた 以前の振る舞いとは異なったものです。このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください。

/etc/resolv.conf ファイル (resolv.conf(5) 参照) の中で

domain foo.bar.edu

と書いてある行を、 search foo.bar.edu bar.edu のように書きかえることで、上のような事ができます。しかし、 RFC 1535 にあるように、 検索順序が「内部 (local) と外部 (public) の管理の境界」をまたがないようにしてください。

IPFIREWALL オプションを付けてカーネルをコンパイルした場合には、 2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として、 明示的に許可されていないすべてのパケットは落とされる設定 になっている事を覚えておいてください。

もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる ようにするには、root でログインして次のコマンドを実行してください。

# ipfw add 65534 allow all from any to any

/etc/rc.conf に firewall_type='open' を追加してもよいでしょう。

FreeBSD のファイアウォールの設定についての情報は FreeBSD ハンドブックの「ファイアウォール」にあります。

この答えは、 使っているルールセットとプロセッサのスピードによってほとんど決まります。 イーサネットに対して少しのルールセットだけを使っている場合には、 ほとんどその影響は無視できる程度です。 実際の測定値を見ないと満足できない方々のために、 実際の測定結果をお見せしましょう。

次の測定は 486-66 (訳注: Intel 社製 CPU i486、66MHz のこと) 上で 2.2.5-STABLE を使用して行なわれました。 IPFW は変更が加えられて、ip_fw_chk ルーチン内でかかる時間を 測定して 1000 パケット毎に結果をコンソールに表示するようになっています。

それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが行なわれました。 ひとつ目のルールセットは最悪のケースを見るために

ipfw add deny tcp from any to any 55555

というルールを繰り返したものです。

IPFW のパケットチェックルーチンは、 パケットが (ポート番号のせいで) このルールにマッチしないことがわかるまでに、 何度も実行されます。そのため、これは最悪のケースを示します。 このルールを 999 個繰り返し並べた後に

allow ip from any to any

が書かれています。

2つ目のルールセットは、なるべく早くチェックが終了するように書かれたものです。

ipfw add deny ip from 1.2.3.4 to 1.2.3.4

このルールでは、発信元の IP アドレスがマッチしないので、 チェックはすぐに終了します。上のルールセットとおなじように、 1000 個目のルールは

allow ip from any to any

です。

1 つ目のルールセットの場合、 パケットあたりのオーバヘッドはおよそ 2.703ms/packet、 これはだいたい 1 つのルールあたり 2.7 マイクロ秒かかっていることになります。 したがって、 このルールにおけるパケット処理時間の理論的な限界は、 毎秒約 370 パケットです。 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると、 バンド幅の利用効率は 55.5% が限界となることになります。

2 つ目のルールセットでは、それぞれのパケットがおよそ 1.172msで処理されていますので、 だいたい 1 つのルールあたり 1.2 マイクロ秒かかっていることになります。 パケット処理時間の理論的な限界は、 毎秒約 853 パケットとなりますので、 10Mbps Ethernet のバンド幅を使い切ることができます。

このテストでのルール数は多過ぎるため、 実際に使用する際の結果を反映している訳ではありません。 これらは上に示した数値を出すためだけに用いられたものです。 効率の良いルールセットを作るためには、 次のような事を考えておけばよいでしょう。

おそらく、あなたが期待している動作とは、 単なるパケット転送ではなくネットワークアドレス変換 (NAT) と呼ばれるものだからでしょう。 「fwd」 ルールは文字どおり、本当に転送しか行ないません。 パケットの中身については一切手を加えないのです。 そのため、次のようなルールを設定したとすると、

01000 fwd 10.0.0.1 from any to foo 21

宛先アドレスに foo と書かれたパケットが このルールを設定したマシンに到着した場合、そのパケットは 10.0.0.1 に転送されますが、宛先アドレスは foo のままになります。 つまり、パケットに宛先アドレスが 10.0.0.1 に書き換えられるということはありません。 自分宛でないパケットを受けとったマシンは、 おそらくほとんどの場合、そのパケットを破棄すると思います。 そのため 「fwd」 ルールは、 そのルールを書いたユーザが意図したようには動かないことが良くあります。 この動作はバグではなく、仕様なのです。

サービスの転送をきちんと動作させる方法については、 サービスのリダイレクトに関する FAQ や natd(8) のマニュアルページ、 Ports Collection にいくつか含まれているポート転送ユーティリティなどをご覧になると良いでしょう。

FTP などのサービスのリクエストは、「socket」 パッケージを利用してリダイレクトできます。 「socket」 パッケージは ports の sysutils カテゴリに含まれています。 (/etc/inet.confに書かれている) コマンド行を、次のように 「socket」 を呼ぶように変更してください。

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp

ここで ftp.foo.com はリダイレクト先のホスト名、 行の最後の ftp はポート名です。

FreeBSD 用のバンド幅管理ツールには、無料で手に入れられる ALTQ と、 Emerging Technologies から入手できる Bandwidth Manager という市販のものの 2 種類があります。

おそらく違います。FreeBSD 3.0 以降では、外向けの問合せに ランダムな大きな番号のポートを用いるバージョンの BIND を 用いています。ファイアウォールを通すため、またはあなたの 気分で、外向きの問合せを 53 番ポートから行いたいならば、 /etc/namedb/named.conf に次のように 設定してみてください。

options {
        query-source address * port 53;
};

更に限定したければ、* を単一の IP アドレスに置き換えることもできます。

それはともかく、おめでとうごさいます。 sockstat の出力を見て、おかしな現象に 注目するのはよい習慣です。

バークレーパケットフィルタ (bpf(4)) ドライバは、それを利用するプログラムを実行する前に有効にしておく必要があります。 カーネルコンフィグファイルに、次のように追加してカーネルの再構築をしてください。

pseudo-device bpfilter		# Berkeley Packet Filter

そして再起動してから、次にデバイスノードを作成する必要があります。 これは、次のように入力し、/dev を変更することで行ないます。

# sh MAKEDEV bpf0

デバイスノードの作成の詳細は、 FreeBSD ハンドブックの「デバイスノード」を参照してください。

Ports Collection に含まれる sharity light パッケージを使ってください、

これは、カーネル自身から「ICMP や TCP のリセット (RST) 応答を、妥当な数よりも多く送っている」ということを、 あなたに伝えるメッセージです。 ICMP 応答は良く、使われていない UDP ポートに接続しようとした結果として生成されます。 また、TCP リセットはオープンされていない TCP ポートに接続しようとした結果として生成されます。 その他、これらのメッセージが表示される原因となる状況として、 以下のようなものがあります。

メッセージ中の最初の数字は、 上限を設定しなかった場合にカーネルが送っていたであろうパケットの数を示し、 二番目の数字は、パケット数の上限値を示します。 この上限値は net.inet.icmp.icmplim という sysctl 変数を使うことで、以下のように変更可能です。 ここでは上限を 1 秒あたりのパケット数で 300 にしています。

# sysctl -w net.inet.icmp.icmplim=300

カーネルの応答制限を無効にせず、 ログファイル中のメッセージだけを抑制したい場合、 net.inet.icmp.icmplim_output sysctl 変数を次のようにすることで出力を止めることができます。

# sysctl -w net.inet.icmp.icmplim_output=0

最後に、もし応答制限を無効にしたい場合は、 net.inet.icmp.icmplim sysctl 変数に (上の例のようにして) 0 を設定することで実現できます。 ただし応答制限を無効化するのは、上記の理由からおすすめしません。

まず ppp(8) のマニュアルと、 FreeBSD ハンドブックの「PPP」を読んでみましょう。 次に、

set log Phase Chat Connect Carrier lcp ipcp ccp command

という命令を ppp のコマンドプロンプトに対して打ち込むか、 設定ファイル /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください。 その際、 /etc/syslog.conf (syslog.conf(5) 参照) に

!ppp
*.*              /var/log/ppp.log

と書かれた行が含まれているか、また、 /var/log/ppp.log が存在しているかどうか確かめておいてください。 さて、これで何が起きているのか突き止めるために、 ログファイルからたくさんの情報を得られるようになりました。 ログに訳の分らない部分があっても心配ご無用。 あなたが助けを求めた誰かにとっては、 その部分が意味をなす場合があるのです。

使用中の ppp のバージョンで 「set log」 命令を解釈しない場合は、最新版をダウンロードすべきです。 FreeBSD の 2.1.5 以降でビルドできます。

ホスト名の解決がうまくいっていないのでしょう。まず、 リゾルバ (resolver) が /etc/hostsを参照するように、 /etc/host.conf の最初の行に host と書き込んでください。 つぎに、/etc/hosts に使用しているマシンのエントリを書き加えます。 ローカルでネットワークを使用していない場合は、 localhost の行を以下のように変更してください。

127.0.0.1      foo.bar.com foo localhost

使用しているホストのエントリを追加してもかまいません。 詳細は関連するマンページを参照してください。

まず最初に、デフォルトルートが確立しているかどうかチェックしてください。 netstat -rn (netstat(1) 参照) を実行すると、以下のような情報が表示されるはずです。

Destination        Gateway            Flags     Refs     Use     Netif Expire
default            10.0.0.2           UGSc        0        0      tun0
10.0.0.2           10.0.0.1           UH          0        0      tun0

これはあなたがハンドブックやマニュアル、 ppp.conf.sample の中で出てくるアドレスを使用していると仮定した場合の例です。 デフォルトルートが確立していない場合、 ppp.conf の中の HISADDR が理解できない、 古いバージョンの ppp(8) が走っている可能性があります。 FreeBSD 2.2.5 より前のバージョンに付属していた ppp を使用している場合、

add 0 0 HISADDR

と書かれた行を以下のように修正してください。

add 0 0 10.0.0.2

netstat -rn でデフォルトルートの情報が表示されない場合、もう一つ、 /etc/rc.conf (rc.conf(5) 参照) (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトのルータを誤って設定し、 ppp.conf から

delete ALL

の行をうっかり消してしまった可能性があります。 この場合は、 FreeBSD ハンドブックの「システムの最終設定」の項を読み直してください。

このエラーは通常、 /etc/ppp/ppp.linkup に以下のようなセクションが無い場合に起こります。

MYADDR:
  delete ALL
  add 0 0 HISADDR

これは動的 IP アドレスを使用している場合、 またはゲートウェイのアドレスを知らない場合にのみ必要な設定です。 インタラクティブモードを使用している場合、 パケットモードに入った後で (プロンプトが PPP と大文字に変わったらパケットモードに入ったしるしです)、 以下の命令を入力してください。

delete ALL
add 0 0 HISADDR

詳しい情報については、 FreeBSD ハンドブックの「PPP と動的 IP 設定」の項を参照してください。

ppp のタイムアウトは デフォルトでは 3 分です。 これは

set timeout NNN

という命令によって調整することができます。 NNN には、 接続が切れるまでのアイドル時間が秒数で入ります。 NNN が 0 の場合、 タイムアウトによる切断は起こりません。 このコマンドは ppp.conf に入れることも、 インタラクティブモードでプロンプトから入力することも できます。 ソケットを用いる telnet(1) か pppctl(8) を使用し、 ppp サーバに接続することによって、 回線がアクティブな間に限定してタイムアウトの時間を調整することも可能です。

詳しい情報は ppp(8) のマニュアルページを参照してください。

Link Quality Reporting (LQR) の設定を行っている場合、 マシンと接続先の間で非常にたくさんの LQR パケットが失われている可能性があります。結果として ppp は回線の具合いが悪いと考え、 回線を切断するのです。2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています。 現在ではデフォルトの状態で無効です。 LQR は以下の命令で無効にすることができます。

disable lqr

ノイズの多い回線、あるいは待ち機能付きの回線では、 時々モデムが (誤って) キャリアを失ったと思い込み、 回線が切断されてしまうことがあります。

大多数のモデムでは、 一時的なキャリアの喪失をどれくらいの時間で検出するかを、 設定で決めることができます。 たとえば USR Sportster では、S10 レジスタ の値を 10 倍した秒数がその値になります。 この場合、モデムをもっとのんびり屋さんにするには、 dial 行に次のような文字列を加えると良いでしょう。

set dial "...... ATS10=10 OK ......"

詳しくはお使いのモデムのマニュアルをご覧ください。

たくさんの人が、原因不明のハングアップを経験しています。 検証のために必要なのは、まずどちら側のリンクでそれが起こっているか、 ということです。

外部接続型モデムを利用しているなら、 単に ping を使うことで、 データを送信するときに TD ランプが点灯するかどうかを確認することができます。 もし、TD ランプが点灯して、 RD ランプが点灯しなければ、 問題は回線の向こう側にあります。TD が点灯しなければ、 問題は回線のこちら側です。内蔵型モデムの場合、 ppp.conf ファイルに set server コマンドを入れる必要があるでしょう。 回線が切断されたとき、pppctl を使って ppp に接続してください。 そのとき、 ネットワーク接続が急に復旧 (診断ソケットへのアクセスで、 ppp が復活します) するか、 もしくは接続自体が全くできない (ただし、 ppp 起動時に set socket コマンドがちゃんと実行されているとします) としたら、 問題は回線のこちら側です。 もし、接続可能で、かつ状況が変化しなければ、 set log local async を使ってローカル非同期ログ (async logging) を有効にし、 ping を他のウィンドウかターミナルから使ってください。 非同期ログには、こちら側のリンクの送受信データが記録されます。 もし、データが送信されたにもかかわらず返って来ていなければ、 問題は回線の向こう側にあることになります。

問題が回線のどちら側かにあることが分かったら、 つぎの二つの可能性が考えられるでしょう。

これに対処できることはほとんどありません。大部分の ISP は、Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう。 ppp.conf ファイルの中に enable lqr を記述することで ppp が回線の向こう側で発生する切断を検出することができますが、 この検出は比較的遅いため、あまり役に立ちません。また、あなたは user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね。

まず最初に、こちら側の圧縮機能をすべて無効にしてみてください。 それには、設定ファイルをつぎのようにします。

disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
deny pred1 deflate deflate24 protocomp acfcomp shortseq vj

そして再接続し、変更前と同じように通信できることを確認します。 もしこれによって状況が改善されるか、完全に解決したら、 (上の設定のうち) どの設定で状況が変化したのかを、 色々な組合せで試してみてください。これは、ISP に問い合わせを行なうときの有効な情報となります (ただし、 あなたが Microsoft 社製品以外のものを利用していることも明らかにしてしまいますが)。

ISP に問い合わせを行なう前に、こちら側の非同期ログを有効にして、 接続がハングアップするまで待ってください。この作業は、 非常に多くのディスク空間を消費するかも知れません。 興味の対象となっているのは、通信ポートから最後に読み込まれたデータです。 それは通常 ASCII データで、 問題点の詳細 (「Memory fault, core dump」 など) が 記載されている可能性があります。

回線の向こう側で通信ログを監視することは可能なはずですので、 切断が発生した時、ISP の対応が好意的ならば どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません。 <brian@Awfulhak.org> まで詳細を送って頂くか、ISP に直接私に連絡するように伝えて下さっても構いません。

ベストな方法は、 CFLAGS+=-g と STRIP= を ppp の Makefile に追加して、 ppp を再構築し、 そして make clean && make && make install を行なうことです。 ppp がハングアップした時、 ps ajxww | fgrep ppp を使って ppp のプロセス ID を調べ、 gdb ppp PID を実行してください。 gdb のプロンプトから、 bt を使ってスタックをトレースすることができます。

スタックトレースの結果は、<brian@Awfulhak.org> まで送ってください。

2.2.5 より前のリリースの FreeBSD では、 ppp(8) はリンクが確立した後、接続先が Line Control Protocol (LCP) を発信するのを待ちます。しかし、多くの ISP ではネゴシエーションを自分からは起こさず、 クライアントが起こすのを待っています。 ppp に強制的に LCP を発信させるには、 次の命令を使います。

set openmode active

時折、接続直後のログに 「magic is the same」 というメッセージがあらわれることがあります。 このメッセージがあらわれても何も起きない場合もありますし、 どちらかの側が接続を切ってしまう場合もあります。 ppp の実装の多くはこの問題に対応できておらず、 その場合にはちゃんと link が上がっている状態であっても、 ppp が最終的にあきらめてしまい、 接続を切るまで設定のリクエストが繰り返し送られ、 設定が行われたという通知がログファイルに残ると思います。

これは通常、 ディスクアクセスの遅いサーバマシンのシリアルポートで getty が生きていて、 ppp がログインスクリプトか、 ログイン直後に起動されたプログラムから実行されている場合に起こります。 slirp を使用している場合に同様の症状が見られたという報告もあります。 原因は getty の終了されるまでと、 ppp が実行され、 クライアント側の ppp が Line Control Protocol (LCP) を送り始めるまでのタイミングにあります。 サーバ側のシリアルポートで ECHO が有効なままになっているので、 クライアント側の ppp にパケットが「反射」してしまうのです。

LCP ネゴシエーションの一部として、 リンクの両サイドで magic number を定めて、 「反射」が起きていないかどうか確かめる作業があります。 規約では、接続相手がこちらと同じ magic number を提示してきたら、 NAK を送って新しい magic number を選択しなければならないと定めています。 この作業の間、サーバのシリアルポートの ECHO がずっと有効になったままなので、 クライアント側の ppp は LCP パケットを送り、 パケットが反射して全く同じ magic number が送られてくるのを見つけ、 それに対して NAK を送るのです。一方 NAK 自体も (これは ppp が magic number を変更しなければいけないことを意味しています) 反射してくるので、 結果として magic number が数えきれないほど変更され、 そのすべてがサーバの tty バッファの中に積み重なることになるのです。 サーバでスタートした ppp は、すぐに magic number であふれかえってしまい、 LCP のネゴシエーションを十分に行ったものと判断して、 さっさと接続を切ってしまいます。 一方、 クライアント側は反射が帰ってこなくなったので満足しますが、 それもサーバが接続を切ったことを知るまでです。

この事態は、以下の行を ppp.conf の中に書いて、 相手がネゴシエーションを開始できるようにする事によって回避できます。

set openmode passive

これで ppp はサーバが LCP ネゴシエーションを起こすのを待つようになります。 しかし、 自分からは決してネゴジェーションを起こさないサーバもあるかもしれません。 もしこの状況に遭遇した場合には、次のようにしてください。

set openmode active 3

これによって ppp は 3 秒間 passive モードを続けた後で、 LCP リクエストを送り始めます。 この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します。

現在の ppp は、まだ LCP や CCP、 IPCP の返事が、 元のリクエストと連携してくれる機能がきちんと実装されていません。 その結果、ある ppp の実装が相手よりも 6 秒以上遅い場合には、 LCP 設定のリクエストをさらに 2 回送ります。 これは致命的な物です。

A と Bという 2 つの実装を考えてみましょう。 A が接続の直後に LCP リクエストを送り、 一方 B の方はスタートするのに 7 秒かかったとします。B がスタートする時には A は LCP リクエストを 3 回送ってしまっています。 前の節で述べた magic number の問題が起きないよう、 ECHO は off になっていると考えています。 B は REQ を送ります。 するとこれは A の REQ のうち、 最初の物に対する ACK となります。 結果として、A は OPENED の状態に入り、 B に対して (最初の) ACK を送ります。 そのうちに B は、B がスタートする前に A から送られたもう 2 つの REQ に対する ACK を送り返します。 B は A からの最初の ACK を受け取り OPENED の状態に入ります。 A は B からの 2 つ目の ACK を受け取りますので、 REQ-SENTの状態に戻り、 さらに、RFC のとおりに (4 つ目の) REQ を送ります。そして 3 つ目の ACK を受け取って OPENED 状態に入ります。 一方、B は A からの 4 つ目の REQ を受け取りますので、 ACK-SENT の状態に入り、2 つ目の REQ と 4 つ目の ACK を RFC のとおりに送ります。 Aは、 REQ を受けとると REQ-SENT の状態になり、さらに REQ を送ります。 そしてすぐに ACK を受け取って OPENED の状態に入ります。

これが、片方の ppp があきらめてしまうまで続きます。

これを回避する最も良い方法は、 片方を passive モードに設定する、 すなわち反対側がネゴシエーションを開始するまで待つようにする事です。 これは、

set openmode passive

というコマンドでできます。 このオプションは気を付けて使わないといけません。さらに

set stopped N

というコマンドを追加して、 ppp がネゴシエーションが開始するまで待つ 最大の時間を設定してください。もしくは、

set openmode active N

というコマンド (ここで、 N はネゴシエーションが始まるまで待つ時間) を使うこともできます。 詳しくはマニュアルページを参照してください。

2.2.5 より前のバージョンの FreeBSD では、ppp が Predictor1 圧縮のネゴシエーションを誤って解釈して、 接続直後にリンクを無効にしている可能性があります。 これは両サイドが異なる Compression Control Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します。 この問題は現在は解決していますが、あなたの走らせている ppp のバージョンが古い場合でも、次の命令で解決することができます。

disable pred1

shell あるいは ! コマンドを使用すると、 ppp はシェルを起動し (何か引数を渡した場合は、 ppp は引数も実行します)、 コマンドが終了するまで処理を中断します。 コマンドを実行中に ppp のリンクを使おうとすると、 リンクが固まっているように見えますが、 これは ppp がコマンドの終了を待っているからです。

このような場合は、代わりに !bg コマンドを使用してください。 与えられたコマンドがバックグラウンドで実行されるので、 ppp はリンクに関するサービスを継続することができます。

ヌルモデムケーブルを使用して直接接続している場合、 ppp は自動的には接続の終了を知ることができません。 これはヌルモデムシリアルケーブルの配線に起因しています。 この種の接続形態を用いる場合は、 以下の命令を用いて LQR を常に有効にする必要があります。

enable lqr

こうすると、接続先がネゴシエーションを行う場合、デフォルトで LQR の使用を受け入れるようになります。

ppp が思いもしないときにダイアルを始める場合、その原因を突き止め、 防止のためにダイヤルフィルタ (dfilters) をかけてやる 必要があります。

原因を突き止めるためには、以下の命令を使用してください。

set log +tcp/ip

これで接続を通過するすべてのトラフィックをログに残すことができるようになりました。 次に突然回線がつながったときのログのタイムスタンプをたどれば、 原因を突き止めることができるはずです。

原因がわかったら、次に、このような状況ではダイヤルが起こらないようにしましょう。 通常、この手の問題は、DNS で名前の解決をしようとしたために起こります。 DNS による名前の解決によって、 接続が行われるのを防止するには、 次のような手段を用います (これは ppp の既に確立した接続に関してパケットのフィルタリングをするものではありません)。

set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0

これはデマンドダイヤル機能に問題を生じさせるため、 常に適切であるとはかぎりません。 ほとんどのプログラムは他のネットワーク関連の処理を行なう前に DNS への問い合わせが必要になります。