訳:
内川 喜章 <yoshiaki@kt.rim.or.jp>
、
1997 年 11 月 10 日
3.1. | ハードディスクに不良ブロックがあります! |
SCSI ディスクの場合は自動的に再マップする機能があるはずです。 しかし、理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています…。
これを有効化するには、
最初のデバイスのモードページを変更する必要があります。
これは次のコマンドを実行することで、FreeBSD
上で行なうことができます
(
そして、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 を利用する上で、注意しなければならない点が一つあります。
それは、不良ブロックスペシャルファイルは、
ディスクの最終トラックに置かれるということです。
このファイルには、ディスクの先頭の付近、
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 によるフォーマットとパーティション確保を含みます)。 もし、不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら、 ドライブの交換を考えてください。不良ブロックは、時間とともに悪化するからです。 | |
3.2. | Bustek 742a EISA SCSI が認識されません。 |
この情報は 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 に合わせる必要があるでしょう。 | |
3.3. | HP Netserver 上のオンボード SCSI コントローラが認識されません。 |
基本的にこれは既知の問題です。HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが、「本当の」EISA スロットはすべてそれよりも前のアドレスに配置されているのです。 残念ながら、 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間と衝突し、FreeBSD の自動コンフィグレーションは、 現状ではうまくこの状況を処理できていないのです。
ですから現時点での最良の方法は、カーネルオプションの
もちろん、これはこのようなマシンにインストールする際に 「卵が先か、 鶏が先か」といった問題を生み出すことになります。 この問題を回避するために、 ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています。 このとき 「visual」 インタフェースは使用せず、 コマンドラインインタフェースを使用してください。単純に eisa 12 quit とプロンプト上から打ち込み、 後は普通にインストールを行なってください。 とにかくカスタムカーネルのコンパイルとインストールを行なうことを おすすめします。 うまくいけば、将来のバージョンではこの問題が解決していることでしょう。 注記:HP Netserver
では | |
3.4. | この CMD640 IDE コントローラはどこかおかしいようです。 |
それは壊れているのです。両方のチャンネルを同時に制御できないのです。 現在、このチップを使っているシステムを自動的に検出して、 うまく動かすためのしくみが使えるようになっています。 くわしくは wd(4) のマニュアルページを参照してください。
CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1
あるいは 2.2.2 を使い、
かつセカンダリのチャネルを使いたいのであれば、
| |
3.5. |
|
たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ
を使用しているなど)。FreeBSD 2.0.5R
以前はこれに関して寛大で、
IRQ の衝突があってもネットワークドライバは機能していました。
しかし 2.0.5R 以降はもはや、IRQ の衝突に寛大ではありません。
ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプのインタフェース) を使っている場合、 デバイスのタイムアウトはターミネーションの不良によっても起きます。 これをチェックするにはケーブルを外してターミネータを直接 NIC に接続します。そしてエラーメッセージが消えるかどうか 確認します。 NE2000 コンパチブルカードのなかには、 UTP ポートのリンクがなかったりケーブルが接続されていない場合に このエラーを出すものがあります。 | |
3.6. | CDROM をマウントしようとすると
|
mount(8)
にマウントしたいデバイスのタイプを指定する必要があります。
デフォルトでは mount(8)
はファイルシステムを
CDROM のデバイス
デバイスの名前はインタフェースによっては別の名前になっている
かもしれないので注意してください
(
| |
3.7. | CDROM をマウントしようとすると
|
これは 一般的に CDROM ドライブの中に CDROM が入っていないか、 ドライブがバス上に見えないことを意味します。ドライブに CDROM を入れるか、IDE (ATAPI) であれば master/slave の状態をチェックしてください。 また、CDROM ドライブに CDROM を入れてから認識するまでには数秒かかりますので、 少し待ってみてください。 SCSI CDROM ではバスリセットへの応答時間が遅いために、 失敗することがあるかもしれません。 SCSI CDROM を持っている場合は、 カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください。 options "SCSI_DELAY=15" 訳注:
現在の GENERIC カーネルでは上の設定はデフォルトになっています。
問題がある場合は | |
3.8. | CDROM をマウントすると、ファイル名中の英数字以外の 文字が、「?」 と表示されてしまいます。 |
もっともありそうなのは、その CDROM が 「Joliet」 拡張を利用してファイルおよび ディレクトリに関する情報を保存しているということです。この拡張は、 すべてのファイル名を Unicode の 2 バイト文字で保存するように 規定しています。現在、FreeBSD カーネルに汎用的な Unicode インタフェースを導入する作業が行われていますが、 まだ完了していません。したがって、CD9660 ドライバはファイル名の文字を解読できません。 一時的な解決策として、FreeBSD 4.3R 以降では、CD9660
ドライバに特別な仕掛けを施して、ユーザーがその場で適切な
変換表を読み込めるようにしました。一般的なエンコーディングに
対応したいくつかのモジュールが
訳注:この記述は古くなっています。 英語版の記述をご覧ください。 | |
3.9. | 私のプリンタはとてつもなく遅いのです。 どうしたらよいのでしょう? |
パラレルインタフェースで、問題はとんでもなく遅いだけであるなら、 プリンタボートを 「polled」 モードに設定してみてください。
HP の新しいプリンタには、 割り込みモードで使えないものがあるようです (完全にわかったわけではありませんが)。 タイミングの問題のように思われます。 | |
3.10. | わたしのプログラムは時々
|
Signal 11 エラーはオペレーティングシステムが 許可を与えていないメモリにアクセスしようとしたときに発生します。 このようなことがランダムな間隔で起っているようなら、 注意深く調査していった方が良いです。 この手の問題はたいていの場合、以下のどちらかです。
それが FreeBSD のバグでは「ない」という決定的なケースとして、 その問題の発生がプログラムをコンパイルしているときであり、 コンパイル毎に毎回、コンパイラの挙動が変るというものがあります。 たとえば、あなたが 「make buildworld」 を実行していて、 コンパイラが ls.c から ls.o をコンパイルしようとしたときに コンパイルに失敗したとします。もう一度 「make buildworld」 を実行したときに、まったく同じ場所でコンパイルが失敗したのなら、 それは build が壊れている (訳注: つまりソースにバグがある) と言うことです -- ソースを更新してやりなおしてみてください。 もしコンパイルが別の場所でしくじっていたら、 それはハードウェアの問題です。 あなたのやるべき事は: 前者の場合は、 そのプログラムの間違ったアドレスへアクセスしようとしている部分を、 gdb 等のデバッガで見つけて修正します。 後者の場合は、 ハードウェアに問題がないことを確かめる必要があります。 その一般的な原因として :
SIG11 FAQ (下に示します) にはこれらの問題のすべてが 詳しく説明されています。Linux の視点に基づくものですが、 これも読んでおいた方がいいでしょう。そこではまた、 メモリのテストを行うソフトウェアや、 ハードウェアがなぜ問題のあるメモリを見逃してしまうかについても 議論されています。 最後に、これらがどれも助けにならなかったら、 FreeBSD のバグを発見した可能性があります。 以下の説明を読んで障害報告を送ってください。 詳細な FAQ は、 the SIG11 problem FAQ にあります。 | |
3.11. | 起動の時に画面が真っ暗になって同期も取れません。 |
これは ATI Mach 64 ビデオカードの既知の問題です。
この問題はカードがアドレス バグが修正されるまでは、次のようにして対処してください。
もしシリアルポートを有効にしたいのであれば以下の変更を行なって
新しいカーネルを作る必要があります。
この対処を行なった後でもまだ X ウィンドウシステムはうまく動かないかもしれません。 その場合は、 使用している XFree86 がすくなくとも XFree86 3.3.3 以降であることを確かめてください。 それ以降のバージョンでは、 Mach64 カードやそれらのカードのためにつくられた X サーバ の組込みをサポートします。 | |
3.12. | 128MB の RAM があるのですが、64MB しか認識しません。 |
FreeBSD がメモリのサイズを BIOS から取得する方法の制限により、 KB 単位で 16 ビット分までしか検出できません (すなわち最大 65535KB=64MB です。これより少ない場合もあります。 ある BIOS の場合はメモリサイズが 16MB に制限されます)。 64MB 以上のメモリを積んでいる場合、 FreeBSD はそれを検出しようとします。 しかしその試みは失敗するかもしれません。 この問題を回避するには、 以下に示すカーネルオプションを使用する必要があります。 完全なメモリ情報を BIOS から取得する方法もありますが、 起動ブロックに空きが無いため実装できません。 起動ブロックの問題が解決されれば、 いつか拡張 BIOS 機能を使用して完全なメモリ情報を取得できるようになるでしょう。 とりあえず現在は、カーネルオプションを使ってください。
| |
3.13. | FreeBSD 2.0 が
|
注記:メッセージは、 このパニックは、ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します。 以下のオプションをカーネルコンフィグファイルに追加して mbuf クラスタに使用できる仮想メモリの量を増やしてください。
| |
3.14. | 新しいカーネルで再起動すると
|
ファイル これが起こったなら、シングルユーザで再起動した後に、 以下のコマンドを実行してください。
| |
3.15. |
|
これは Ultrastor SCSI Host Adapter と衝突しています。
起動時に kernel configuration メニューに入り、
問題を起こしている
| |
3.16. | sendmail が |
この事は、sendmail FAQ に次のように書いてあります。 * "Local configuration error" というメッセージが出ます。たとえば:
もはや現在の
sendmail FAQ
は sendmail release とは一緒には保守されていません。
しかし次のネットニュースに定期的に投稿されてます。
comp.mail.sendmail、
comp.mail.misc、
comp.mail.smail、
comp.answers、
news.answers。
また、メール経由でコピーを入手する場合は
mail-server@rtfm.mit.edu
宛まで本文に | |
3.17. | リモートマシン上のフルスクリーンアプリケーションがうまく動かない |
リモートマシンのターミナルタイプが FreeBSD
のコンソールで必要とされている この問題を解決しうる方法はいろいろあります:
| |
3.18. | 私のマシンで |
これは、割り込みに関連するさまざまな不具合によって発生します。 あるいは、あるデバイスが元々持っているバグが表面化したのかも知れません。 この症状を再現させる一つの方法として、パラレルポート上で、 TCP/IP を 大きな MTU で走らせるというものがあります。 グラフィックアクセラレータがこの症状を起こすことがありますが、 その場合はまず、カードの割り込み設定を確認してください。 この問題の副作用として、 プロセスが 「SIGXCPU exceeded cpu time limit」 というメッセージとともに終了してしまう、というものがあります。 1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で この問題が解決しないなら、次の sysctl 変数をセットしてください。
これは、パフォーマンスへ強い影響を与えますが、
問題の発生に比べればおそらく気にならない程度でしょう。
もし、これでもまだ問題が残るようなら、
カーネルオプションの | |
3.19. |
|
これは FreeBSD 3.x で PCI のサウンドカードを使っているときに
発生します。 注記:この警告を、単にカーネルコンフィグファイルの当該行を
PCI のサウンドカードを持っているのならば、以下のようにして
この状況は FreeBSD 4.x では生じません。多くの努力の結果より
PnP 中心に作り替えられ、
現在、 | |
3.20. | プラグアンドプレイのカードが認識されなくなりました
(または、 |
現在の 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) の出力は、 以下のようになります。
[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 です。
この情報はファイル まず失敗したときに備えて 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 の時と同じように
| |
3.21. |
|
このエラーは、 実行しようとしたアプリケーションが あるカーネルシンボルを検索した結果、 何らかの理由でその検索に失敗した、ということを意味しています。 これは、以下に示すいずれかの理由によるものです。
| |
3.22. | |
症状: TCP コネクションが確立してから、 クライアントソフトウェアがパスワードを尋ねてくるまで (telnet(1) の場合は、ログインプロンプトが表示されるまで) に長い時間がかかる、というもの。 問題: おそらく、サーバソフトウェアがクライアントの IP アドレスからホスト名を解決しようとして、遅れが生じている のでしょう。FreeBSD に付属する SSH や Telnet を含む多くの サーバソフトウェアは、この名前解決をおこないます。これは、 管理者が後日参照するログファイルに、その他の情報と一緒に ホスト名を記録できるようにするのが目的です。 対処法: もし、あなたのコンピュータ (クライアント) からどのサーバに接続する場合にも問題が起こるのであれば、 クライアントに問題があります。そして、誰かがあなたの コンピュータ (サーバ) に接続するときだけ問題が起こるのであれば、 そのサーバの問題です。 問題がクライアントにある場合、唯一の対処法は サーバがそのクライアントの名前を解決できるように DNS を修正することです。 症状がローカルネットワークで発生しているなら、サーバの設定に 原因がありますので、このまま続きを読みましょう。 そうではなく、グローバルなインターネット環境で発生しているなら、 ISP に連絡して問題の修正をお願いしなければならない可能性が高いでしょう。 問題がサーバにあって、症状がローカルネットワークで
発生しているなら、ローカルのアドレス範囲にあるアドレスを、
それに対応するホスト名に解決する問合せを処理できるように、
サーバを設定する必要があります。
詳しくは、hosts(5) および named(8)
のマニュアルをご覧ください。グローバルなインターネット環境の場合は、
サーバのリゾルバが正しく動作していないのが原因かもしれません。
確認するには、他のホスト (たとえば
| |
3.23. | file: table is full という メッセージが繰り返し dmesg にあらわれます。 |
このエラーは、システムのファイル記述子を使い果たして しまった時に発生します。メモリ中のファイルテーブルが一杯に なっているのです。 解決法:
手動で sysctl 変数
カーネルに設定されたデフォルトのファイル記述子の 数を決定するのは、次の maxusers 32 カーネル設定ファイルの 現在設定されている
| |
3.24. | laptop の時間が狂って、大きく進んだり遅れたりします。 |
laptop には二つ以上の時計が内蔵されていますが、FreeBSD が間違った方を選択して使用しています。 dmesg(8) を実行して
sysctl(3) 変数
バッテリ駆動している時に、BIOS が CPU の速度を変えるために TSC クロックを変更したり、電力節約モードに入ることがあります。 しかし、FreeBSD はそういった調整を関知しないので、 時間が早まったり遅れたりするようです。 上記の例では、
これで、laptop はより正確な時間を刻むでしょう。 この変更を起動時に自動で行うには、次の行を
kern.timecounter.hardware=i8254 | |
3.25. | BIOS 画面が出た後、FreeBSD のブートローダが Read error と表示して止まって しまいます。 |
FreeBSD のブートローダがハードディスクのジオメトリを正しく 認識していないようです。FreeBSD のスライスを fdisk によって手動で作成したり変更したりする際に、 ジオメトリを誤って指定してしまったのでしょう。 ハードディスクのジオメトリの正しい値は、マシンの BIOS から 得られます。そのハードディスクのシリンダ、ヘッド、セクタの 数を探してください。 sysinstall(8) の fdisk において、 G を入力してハードディスクのジオメトリを 設定してください。 シリンダ、ヘッド、セクタの数を入力するダイアログが出てきます。 BIOS から得た値を斜線 (/) で区切って入力してください。 5000 シリンダ、250 ヘッド、60 セクタなら、
リターンキーを押して値を設定してください。それから W を入力してハードディスクに新しいパーティ ションテーブルを書き込んでください。 | |
3.26. | 別のオペレーティングシステムが、ブートマネージャを 壊してしまいました。どうすれば復旧できるでしょうか。 |
sysinstall(8) を立ち上げて Configure (設定)、Fdisk の順に選択してください。ブートマネージャが置かれていた ディスクを選択して、スペースキーを 押してください。W を押して変更を ディスクに書き込んでください。どのブートローダを インストールするか尋ねられます。ここで選択すれば戻せます。 |
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、
ドキュメント を読んだ上で
<questions@FreeBSD.org> まで (英語で) 連絡してください。
本文書に関する質問については、
<doc@FreeBSD.org> まで電子メールを (英語で) 送ってください。