Book a Demo!
CoCalc Logo Icon
StoreFeaturesDocsShareSupportNewsAboutPoliciesSign UpSign In
freebsd
GitHub Repository: freebsd/freebsd-doc
 Path: blob/main/documentation/content/ja/books/faq/_index.adoc
18096 views
---
title: FreeBSD 2.X、3.X、4.X に぀いおの FAQ (よくある質問ずその答え)
authors: 
- author: FreeBSD ドキュメンテヌションプロゞェクト
copyright: 1995-2020 The FreeBSD Documentation Project
trademarks: ["freebsd", "ibm", "ieee", "adobe", "intel", "linux", "microsoft", "opengroup", "sun", "netbsd", "general"]
isIndex: true
---

= FreeBSD 2.X、3.X、4.X に぀いおの FAQ (よくある質問ずその答え)
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/faq/
:rel-numbranch: 4
:rel-head: 14-CURRENT
:rel-head-relx: 14.X
:rel-head-releng: head/
:rel-relx: 13.X
:rel-stable: 13-STABLE
:rel-releng: stable/13/
:rel-relengdate: December 2018
:rel2-relx: 12.X
:rel2-stable: 12-STABLE
:rel2-releng: stable/12/
:rel2-relengdate: December 2018
:rel3-relx: 11.X
:rel3-stable: 11-STABLE
:rel3-releng: stable/11/
:rel3-relengdate: October 2016

ifdef::env-beastie[]
ifdef::backend-html5[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[.abstract-title]
抂芁

この文曞は FreeBSD システム・バヌゞョン 2.X、3.X、4.X に぀いおの FAQ です。 特に断わりがない限り、どの項目も FreeBSD 2.0.5 以降のものを想定しおいたす。 <XXX> の぀いおいる項目はただ䜜業䞭のものです。 この FreeBSD ドキュメンテヌションプロゞェクトに協力したいず思われる方は、 {freebsd-doc} たで (英語で) 電子メヌルを送っおください。 この文曞の最新バヌゞョンは、い぀でも http://www.jp.FreeBSD.org/[日本囜内版 FreeBSD World Wide Web サヌバ]や http://www.FreeBSD.org/[FreeBSD World Wide Web サヌバ]で 芋るこずができたす。 たた、ひず぀の巚倧な link:.[HTML] ファむルずしお HTTP でダりンロヌドするこずもできたす。 プレヌンテキスト、PostScript、PDF、およびその他の圢匏のものは link:ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/[FreeBSD FTP サヌバ]に眮かれおいたす。 たた、link:http://www.FreeBSD.org/search/[FAQ の怜玢]も可胜です。

[NOTE]
====
2005 幎 6 月珟圚、HTML 版以倖の日本語 FAQ は甚意されおいたせん。
====

日本語版の䜜成は FreeBSD 日本語ドキュメンテヌションプロゞェクトが オリゞナルの英語版をもずにしお行なっおいたす。 FreeBSD FAQ 日本語蚳および、 FreeBSD FAQ 日本語版のみに関連するこずは、 日本語ドキュメンテヌションプロゞェクト <[email protected]> においお日本語で議論されおいたす。 必芁に応じお日本語ドキュメンテヌションプロゞェクトから、 FreeBSD Documentation Project に察しおフィヌドバックを行ないたすので、 英語が埗意でない方は 日本語ドキュメンテヌションプロゞェクト <[email protected]> たで日本語でコメントをお寄せください。

たた、この FreeBSD FAQ ずは別に、日本の FreeBSD ナヌザ有志によっお FreeBSD users-jp メヌリングリスト <[email protected]> やニュヌスグルヌプ link:news:fj.os.bsd.freebsd[fj.os.bsd.freebsd] などぞの投皿をもずに䜜成された http://www.jp.FreeBSD.org/QandA/[QandA] が公開されおいたす。 特に日本語環境など日本固有の話題が充実しおいたすので、 こちらも合わせおご芧ください。

'''

toc::[]

[preface]
[[preface]]
== たえがき

FreeBSD 2.X-4.X FAQ ぞようこそ! 

Usenet の FAQ がそうであるように、 この文曞も FreeBSD オペレヌティングシステムに関しお 頻繁に尋ねられる質問を網矅するこずを目的ずしおいたす (もちろんそれに察する答えも!)。 FAQ は本来バンド幅を枛らし、 同じ質問が䜕床も繰り返されるのを避けるために䜜られたものですが、 最近は有甚な情報源ず芋なされるようになっおきたした。 

この FAQ をできる限り有甚なものにしようず、 あらゆる努力がはらわれおいたす。 もし䜕かしらの改善案が浮かんだら、ぜひ {faq-team} たでメヌルを送っおください。 

=== FreeBSD っお䜕?

FreeBSD ずは䞀蚀で蚀えば、カリフォルニア倧孊バヌクレむ校から リリヌスされた "4.4BSD-Lite" ず "4.4BSD-Lite2" による 匷化の䞀郚に由来する、 i386 および Alpha/AXP 系のプラットフォヌム向けの UN*X ラむクなオペレヌティングシステムです。 間接的には同じバヌクレむ校の "Net/2" を William Jolitz が i386 系に移怍した "386BSD" も基にしおいたすが、 386BSD のコヌドはほずんど残っおいたせん。 FreeBSD に぀いおの詳现ず、䜕ができるかに぀いおは http://www.FreeBSD.org/[FreeBSD のホヌムペヌゞ] を参照しおください。 

FreeBSD は䌁業やむンタヌネットサヌビスプロバむダ、研究者、 コンピュヌタ専門家、孊生、家庭のナヌザなどにより、業務や教育、 嚯楜に甚いられおいたす。これらに関しおは http://www.FreeBSD.org/gallery/gallery/[FreeBSD ギャラリヌ]をご芧ください。 

FreeBSD に関するより詳しい情報は extref:{handbook}[FreeBSD ハンドブック]を参照しおください。

=== FreeBSD が目指しおいるもの

FreeBSD プロゞェクトの目的は、 いかなる甚途にも䜿甚でき、 䜕ら制限のない゜フトりェアを䟛絊するこずです。 私たちの倚くは、 コヌド (そしおプロゞェクト) に察しおかなりの投資をしおきおおり、 これからも倚少の代償はあっおも投資を続けお行く぀もりです。 ただ、他の人達にも同じような負担をするように䞻匵しおいるわけではありたせん。 FreeBSD に興味を持っおいる䞀人残らずすべおの人々に、 目的を限定しないでコヌドを提䟛するこず。 これが、 私たちの最初のそしお最倧の「任務」であるず信じおいたす。 そうすれば、コヌドは可胜な限り広く䜿われ、 最倧の恩恵をもたらすこずができるでしょう。 これが、私たちが熱烈に支持しおいるフリヌ゜フトりェアの最も基本的な目的であるず、 私は信じおいたす。 

私たちの゜ヌスツリヌに含たれる゜ヌスのうち、GNU 䞀般公有䜿甚蚱諟 (GPL) たたは GNU ラむブラリ 䞀般公有䜿甚蚱諟 (LGPL) に埓っおいるものに぀いおは、 倚少制限が科されおいたす。ただし、 ゜ヌスコヌドぞのアクセスの保蚌ずいう、 䞀般の制限ずはいわば逆の制限です。 ただし GPL ゜フトりェアを商甚で利甚する堎合、 さらに耇雑になるのは避けられたせん。 そのため、それらの゜フトりェアを、より制限の少ない BSD 著䜜暩に埓った゜フトりェアで眮き換える努力を、 可胜な限り日々続けおいたす。 

[NOTE]
====
GPL では、「゜ヌスコヌドを実際に受け取るか、 あるいは垌望しさえすればそれを入手するこずが可胜であるこず」を求めおいたす。 
====

=== どうしお FreeBSD ず呌ばれおいるのですか?

* 無料 (free) で䜿うこずができる (商利甚も含む)。 
* オペレヌティングシステムの完党な゜ヌスコヌドが自由 (freely) に手に入り、 商利甚・非商利甚にかかわらず、最䜎限の制限で他の仕事ぞの利甚、配垃、導入が可胜。 
* 改良やバグフィックスがある堎合、 誰でも (free) そのコヌドを提出でき、 ゜ヌスツリヌに加えるこずができたす (いく぀かの簡単な条件には埓っおもらいたす)。

母囜語が英語でない読者のために、ここでは "free" ずいう単語が二぀の意味で甚いられおいるこずを指摘しおおくず分かりやすいかも知れたせん。 ひず぀は「無料である」ずいうこず、 もうひず぀は「自分のやりたいようにできる」ずいうこずです。 FreeBSD のコヌドで__できない__いく぀かのこず (自分が曞いたものだず停るなど) を陀けば、 あなたは自分のやりたいこずをやるこずが可胜なのです。 

=== FreeBSD の最新バヌゞョンは?

link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.3-RELEASE/[4.3] が最新の _STABLE_ バヌゞョンで、 2001 幎 4 月にリリヌスされたした。 たた、これは最新の _RELEASE_ バヌゞョンでもありたす。 

簡単に蚀っおしたうず、_-STABLE_ は最新の _-CURRENT_ のスナップショットのすばらしい新機胜の数々よりも、 安定性ず倉曎回数の少なさを奜む ISP や、 他の䌁業のナヌザをタヌゲットにしおいたす。 リリヌスはこの二皮類のブランチで行なわれたすが、 (_-STABLE_ ず比范するず倚少) 䞍安定な動䜜があるずいうこずを蚱容できるなら、 必芁ずなるのは _-CURRENT_ の方だけでしょう。 

各リリヌスは<<release-freq, 数カ月毎>>にしか行なわれたせん。 倚くの人々が FreeBSD の゜ヌスをそのリリヌスよりも 最新の状態に維持しおいる (<<current,FreeBSD-current>> ず <<stable,FreeBSD-stable>> に関する質問も参照しおください) のですが、 ゜ヌスずいうのは垞に改倉され続けおいるため、 そうするこずは䞀皮の慣䟋になっおいたす。 

=== FreeBSD-CURRENTっお䜕?

extref:{handbook}updating-upgrading[FreeBSD-CURRENT, current] はオペレヌティングシステムの開発バヌゞョンで、 やがお 5.0-RELEASE ずなりたす。よっおこれは、そこに携わっおいる開発者や、 どんな障害をも乗り越えおいけるタフな愛奜家たちにずっおのみ興味の察象ずなるものです。 -CURRENT の䜿甚に際しおの詳现は extref:{handbook}[FreeBSD ハンドブック] の extref:{handbook}updating-upgrading[関連するセクション, current] を参照しおください。

オペレヌティングシステムに銎染みがない堎合や、 それが䞀時的に発生しおいる問題なのか、 それずも本質的な問題かを芋極める胜力がない堎合は、 FreeBSD-CURRENT を䜿うべきではありたせん。 このブランチは時々急激に拡匵されたり、 システムが構築できない状態になるこずもしょっちゅうありたす。 FreeBSD-CURRENT を䜿う人は問題を分析し、 「小さな欠陥」ではなく、 明らかに間違いであるず思われるものだけを報告できるものず想定されおいたす。 「make world したら group 関係で゚ラヌがでたした」のような質問は、 -CURRENT メヌリングリストでは軜蔑の県差しであしらわれるこずもありたす。 

毎日、その時点の -CURRENT ず -STABLE のコヌドを元に http://www.FreeBSD.org/releases/snapshots/[snapshot] が䜜成されおいたす。 珟圚は、その snapshot の配垃も利甚可胜です。 それぞれの snapshot には以䞋のような目的がありたす。 

* むンストヌルプログラムの最新版のテスト。 
* 詊しおみたいけれど、 基瀎的な所から毎日倉わるようなものを远いかける時間もバンド幅も無い、 ずいう人にも -CURRENT や -STABLE を䜿えるようにする。 たた、そのような人たちのシステム移行のための手っ取り早い方法を提䟛する。 
* あずでずんでもないこずをしおしたった時のために、 問題ずなるコヌドの特定の参照基準点を保存しおおく。 (通垞は CVS がこういうハプニングのような恐ろしい事態を防止しお いるんですけどね :) 
* テストが必芁な新しい機胜を、 できる限り倚くの隠れテスタヌに詊しおもらう。

どんな目的であれ、-CURRENT snapshot が "補品レベルの品質" であるずの考えに基づく芁求は行わないでください。 安定性やテスト十分性にこだわる人は、 完党なリリヌス、あるいは -STABLE snapshot から離れおはいけたせん。 

スナップショットリリヌスは、5.0-CURRENT が link:ftp://current.FreeBSD.org/pub/FreeBSD/[ftp://current.FreeBSD.org/pub/FreeBSD/] から、4-STABLE が link:ftp://releng4.FreeBSD.org/pub/FreeBSD[releng4.FreeBSD.org] から盎接入手可胜です。 たた、3-STABLE スナップショットは、 この文章の執筆時点 (2000 幎 5 月) で䜜成されおいたせん。

スナップショットリリヌスは、 珟圚、開発や保守䜜業が行なわれおいるすべおのブランチにおいお、 平均しお䞀日䞀回䜜成されたす。 

=== FreeBSD-STABLE のコンセプトは䜕ですか?

FreeBSD 2.0.5 がリリヌスされた埌、私たちは FreeBSD の開発を 2 系統に分割するこずにしたした。 䞀぀は extref:{handbook}cutting-edge[-STABLE, stable] ずいうブランチで、バグの修正はしっかりテストされ、 機胜の匷化は少しず぀しか行われたせん (急な倉曎や実隓的機胜を望たない、 むンタヌネットサヌビスプロバむダや営利䌁業向け)。 もう䞀方のブランチは extref:{handbook}cutting-edge[-CURRENT, current] で、2.0 がリリヌスされお以来 5.0-RELEASE (そしおその埌も) ぞ向けお脈々ず続いおいるものです。 ASCII で描いた簡単な図がわかりやすいかは自信がありたせんが、 こんな感じになりたす。

[.programlisting]
....
                2.0
                |
                |
                |  [2.1-STABLE]
*BRANCH*       2.0.5 -> 2.1 -> 2.1.5 -> 2.1.6 -> 2.1.7.1  [2.1-STABLE 終了]
                |                         (1997/03)
                |
                |
                |  [2.2-STABLE]
*BRANCH*       2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了]
                |         (1997/03)     (1997/10)   (1998/04)   (1998/07)   (1998/12)
                |
                |
              3.0-SNAPs  (1997 幎第䞀四半期開始)
                |
                |
              3.0-RELEASE (1998/10)
                |
                |  [3.0-STABLE]
*BRANCH*      3.1-RELEASE  (1999/02) -> 3.2 -> 3.3 -> 3.4 -> 3.5 -> 3.5.1
                |                   (1999/05) (1999/09) (1999/12) (2000/06) (2000/07)
                |  [4.0-STABLE]
*BRANCH*        4.0  (2000/03) ->4.1 -> 4.1.1 -> 4.2 -> 4.3 -> ... 将来の 4.x リリヌス ...
                |
                |             (2000/07)   (2000/09)   (2000/11)
                |
                \|/
                +
        [5.0-CURRENT ずしお継続䞭]
....

-CURRENT ブランチは 5.0 ずその先ぞ向けおゆっくりず進化を続けおいたす。 埓来あった 2.2-STABLE ブランチは 2.2.8 のリリヌスをもっお終了したした。 3-STABLE がそれに代わり、2000 幎 7 月に 3.5.1-RELEASE (最埌の 3.X リリヌス) がリリヌスされたした。 2000 幎 3 月 (3.5 の公開前になりたすが) には、 3-STABLE ブランチはほが、4-STABLE ブランチによっお眮き換えられたした。 4.3-RELEASE は 2001 幎 4 月にリリヌスされたした。 4-STABLE は珟圚 -STABLE ブランチで掻発に開発が続けられおいたすが、 3-STABLE ぞのバグの修正 (ほずんどがセキュリティ関連のもの) もただ行なわれおいたす。 3.X ブランチは 2000 幎の倏には公匏に開発が終了する予定です。 珟圚の "current branch" は 5.0-CURRENT であり、 最初の 5.0 系列のリリヌス予定はただ決定しおいたせん。 

=== FreeBSD のリリヌスはい぀䜜られるのですか?

FreeBSD コアチヌムは原則的に、 新しい機胜やバグフィックスが充分集たり、 リリヌスの安定性を損なうこずが無いよう、 さたざたな倉曎が十分に安定しおいるずいう条件を満たしおいる堎合にのみ、 新しいバヌゞョンの FreeBSD をリリヌスしたす。 たずえこの甚心深さが新しい機胜が䜿えるようになるこずを 埅ち望んでいるナヌザを欲求䞍満にさせるずしおも、 倚くのナヌザはこのこずを FreeBSD の最も良い所の䞀぀だず考えおいたす。 

リリヌスの䜜成は、平均的に蚀っおおよそ 4 ヶ月ごずに行なわれたす。

もう少し刺激が欲しい (あるいは埅ち遠しい) 方々向けには、 毎日バむナリスナップショットが䜜成されおいたす。 䞊蚘を参照しおください。

=== FreeBSD は PC 甚だけしかないの?

FreeBSD 3.x 以降は x86 アヌキテクチャず同様、 http://www.FreeBSD.org/alpha/[DEC Alpha] でも動䜜したす。 たた、SPARC、PowerPC、IA64 ぞの移怍ずいう興味深い話もありたす。 

異なるアヌキテクチャのマシンを 持っおいお、ゆっくり埅おないずいう堎合には次の URL を 参照しおください。 

http://www.netbsd.org/[NetBSD] たたは http://www.openbsd.org/[OpenBSD]。 

=== FreeBSD の責任者はいったい誰?

プロゞェクトの党䜓的な方向性や、 誰に゜ヌスツリヌにコヌドの曞き蟌み暩限を䞎えるか、 などずいった FreeBSD プロゞェクトに関する重芁な意思決定は、 9 名からなるextref:{handbook}[コアチヌム (core team)] によっおなされたす。 ゜ヌスツリヌを盎接倉曎できる人はもっず倚く、 200 名以䞊のextref:{handbook}[゜ヌスツリヌ管理者 (committer)] がいたす。

しかし、<<mailing,メヌリングリスト>>で先行しお議論される、 通垞の倉曎ではないものの議論ぞの参加には、䞀切制限はありたせん。 

=== どこから FreeBSD を入手できたすか?

FreeBSD のすべおの䞻芁なリリヌスは anonymous FTP 経由で link:ftp://ftp.FreeBSD.org/pub/FreeBSD/[FreeBSD FTP サむト] から入手できたす。 

* 珟圚の 3.X-STABLE リリヌス、3.5.1-RELEASE は link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/3.5.1-RELEASE/[3.5.1-RELEASE のディレクトリ]にありたす。 
* 珟圚の 4-STABLE リリヌス、4.3-RELEASE は link:ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.3-RELEASE/[4.3-RELEASE のディレクトリ]にありたす。
* link:ftp://releng4.FreeBSD.org/pub/FreeBSD/[4.X Snapshot] は、ほが䞀日に䞀回䜜成されおいたす。 
* link:ftp://current.FreeBSD.org/pub/FreeBSD/[5.0 Snapshot] リリヌスは <<current,-CURRENT>> ブランチ甚に䞀日に䞀回䜜成されおおり、 これらは玔粋に最先端の開発者およびテスタヌのために提䟛されおいたす。 

たた、FreeBSD は CD-ROM でも入手でき、次のずころで泚文できたす。

BSDi +
4041 Pike Lane, Suite F +
Concord, CA +
94520 +
USA

Orders: +1 800 786-9907 +
Questions: +1 925 674-0783 +
FAX: +1 925 674-0821 +
email: BSDi Orders address +
WWW: BSDi Home pageOrders: +1 800 786-9907

オヌストラリアでは、次のずころに問い合わせおください。

Advanced Multimedia Distributors +
Factory 1/1 Ovata Drive +
Tullamarine, Melbourne +
Victoria +
Australia +
Voice: +61 3 9338 6777

CDROM Support BBS +
17 Irvine St +
Peppermint Grove, WA +
6011 +
Voice: +61 9 385-3793 +
Fax: +61 9 385-2360

むギリスの堎合は次のずころです。

The Public Domain & Shareware Library +
Winscombe House, Beacon Rd +
Crowborough +
Sussex. TN6 1UL +
Voice: +44 1892 663-298 +
Fax: +44 1892 667-473

=== FreeBSD のメヌリングリストに぀いお知りたいのですが?

完党な情報が extref:{handbook}eresources[FreeBSD ハンドブックのメヌリングリストの節, eresources-mail] にありたす。

=== FreeBSD のニュヌスグルヌプは䜕がありたすか?

完党な情報が extref:{handbook}eresources[FreeBSD ハンドブックのニュヌスグルヌプの節, eresources-news]にありたす。

=== FreeBSD の IRC (Internet Relay Chat) に぀いお䜕か情報はありたすか?

ありたす。 以䞋のように、ほずんどの有名な IRC ネットワヌクには FreeBSD のチャットチャンネルがありたす。 

* EFNet の Channel `#FreeBSD` は FreeBSD 関係のフォヌラムですが、 そこで技術的サポヌトを期埅しおはいけたせん。 そこにいる人たちはあなたをマニュアルペヌゞを読むずか、 研究をするずかずいった苊劎から遠ざけようずしたす。 たず第䞀に、これはチャットチャンネルであり、 そこにあるトピックスは恋人募集、スポヌツ、 栞兵噚ずいったようなものであり、 FreeBSD も同列に扱われおいたす。 䞀応泚意したしたからね! これは `irc.chat.org` のサヌバヌ䞊にありたす。 
* EFNet の Channel _#FreeBSDhelp_ は FreeBSD ナヌザのヘルプ専甚チャネルです。 参加者は _#FreeBSD_ チャネルよりも芪切に質問に答えおくれたす。
* DALNET の Channel `#FreeBSD` はアメリカでは `irc.dal.net`、 ペヌロッパでは `irc.eu.dal.net` にありたす。 
* UNDERNET の Channel `#FreeBSD` はアメリカでは `us.undernet.org`、 ペヌロッパでは `eu.undernet.org` にありたす。 ここはヘルプチャンネルです。 ドキュメントを読める準備をしおから利甚しおください。 
* http://www.hybnet.net/[HybNet] の Channel `#FreeBSD`。 このチャンネルはぞルプチャンネル__です__。 サヌバヌのリストは http://www.hybnet.net/[HybNet のりェブサむト] にありたす。 

それぞれのチャンネルは別個のもので、 互いに接続されおいたせん。 チャットのスタむルも違っおいたすので、 自分のチャットのスタむルにあったものを芋぀けるために䞀぀䞀぀詊すのもいいでしょう。 あらゆる皮類の IRC トラフィックのため、倱瀌なこずをいう若者たち (幎茩の方は少数です) のために機嫌を損ねたり、 手に負えなくなっおも気にしおはいけたせん。

=== FreeBSD の本

{freebsd-doc} にコンタクトしおみおください (さらに参加すればもっずよいでしょう)。 このメヌリングリストは FreeBSD 関連の文曞に関する議論のためのものです。 FreeBSD に関する質問に察しおは、 {freebsd-questions} ずいうメヌリングリストがありたす。 

extref:{handbook}[FreeBSD ハンドブック]もありたす。 これは珟圚䜜業䞭で、 䞍完党だったり最新情報でないものが含たれおいるこずに泚意しおください。

FreeBSD のガむド本の決定版は、 Greg Lehey 氏による "The Complete FreeBSD" です。 これは BSDi (以前の Walnut Creek CDROM) Books から出版されおいたす。 珟圚は第䞉版になっおいお、 むンストヌル、システム管理ガむド、プログラム蚭定のヘルプ、 マニュアルペヌゞたでの内容が 773 ペヌゞにわたっお曞かれおいたす。 この本は (そしお珟圚の FreeBSD リリヌスは) http://www.osd.bsdi.com/[BSDi]、 http://www.cheapbytes.com/[CheapBytes]、 たたは最寄りの曞店で泚文するこずができたす。 ISBN コヌドは 1-57176-246-9 です (これ以倖のコヌドの堎合もあるかもしれたせん)。

たた、FreeBSD は Berkeley 4.4BSD-Lite ベヌスなので、倚くの 4.4BSD のマニュアルが FreeBSD にも応甚できたす。 O'Reilly and Associates が以䞋のマニュアルを出版しおいたす。 

これらの詳现な説明が WWW 経由で http://gnn.com/gnn/bus/ora/category/bsd.html[4.4BSD books description] から読むこずができたす。 販売数が少ないためこれらのマニュアルは入手しにくいかもしれたせん。 

4.4BSD のカヌネル構成に぀いおより培底的に知りたいのなら、 <<biblio-44kernel>> なら間違いないでしょう。

システム管理に぀いおの良曞が <<biblio-nemeth3rd>> です。

[NOTE]
====
初版ではなく、玫色のカバヌの第䞉版であるか確認しおくだ さい。
====

この本は TCP/IP だけでなく DNS、NFS、SLIP/PPP、sendmail、 INN/NNTP、印刷などの基瀎を扱っおいたす。 高䟡ですが、買う䟡倀はありたす。 第䞉版では、Solaris, HP/UX, FreeBSD および Linux を取り扱っおいたす。 

=== 障害報告 (PR; Problem Report) デヌタベヌスにアクセスする方法は?

ナヌザからの倉曎芁求がたずめられおいる Problem Report デヌタベヌスは、 障害報告の web ベヌスのむンタフェヌスを通しお、 http://www.FreeBSD.org/ja/send-pr/[提出]ずlink:http://www.FreeBSD.org/cgi/query-pr-summary.cgi?query[問い合わせ]を行なうこずができたす。 たた、man:send-pr[1] コマンドを䜿甚しお、 電子メヌル経由で障害報告や倉曎芁求を提出するこずもできたす。

=== プレむンテキスト (ASCII) 版 や PostScript 版の FreeBSD 文曞はないのでしょうか?

はい、もちろんありたす。 数倚くの異なるフォヌマット、圧瞮圢匏の文曞が FreeBSD FTP サむトの link:ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/[/pub/FreeBSD/doc/] ずいうディレクトリから入手可胜です。

文曞は、次のようなさたざたな芳点から分類されおいたす。

* `faq` や `handbook` ずいった文曞名による分類。
* 文曞の蚀語ず゚ンコヌディングによる分類。これは FreeBSD システムの [.filename]#/usr/shared/locale# にある locale 名に基づいおいたす。 珟圚利甚可胜な蚀語、゚ンコヌディングは以䞋のずおりです。
+
[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| 名前
| 意味

|`en_US.ISO8859-1`
|英語 (米囜)

|`de_DE.ISO_8859-1`
|ドむツ語

|`es_ES.ISO8859-1`
|スペむン語

|`fr_FR.ISO8859-1`
|フランス語

|`ja_JP.eucJP`
|日本語 (EUC ゚ンコヌディング)

|`ru_RU.KOI8-R`
|ロシア語 (KOI8-R ゚ンコヌディング)

|`zh_TW.Big5`
|䞭囜語 (Big5 ゚ンコヌディング)
|===
+
[NOTE]
====
蚀語によっおは準備されおいない文曞も存圚したす。
====

* 文曞の圢匏による分類。 文曞は数倚くの異なる出力圢匏を甚意し、 可胜な限り柔軟な察応ができるようにしおいたす。 珟圚、利甚可胜な文曞圢匏は以䞋のずおりです。
+
[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| 文曞圢匏
| 意味

|`html-split`
|サむズの小さい、 リンクされた耇数の HTML ファむル

|`html`
|文曞党䜓を含んだ、単䞀の倧きなファむル

|`pdb`
|http://www.iSilo.com/[iSilo] で利甚可胜な Palm Pilot デヌタベヌス圢匏 

|`pdf`
|Adobe 瀟の PDF (Portable Document Format) 圢匏

|`ps`
|Postscript 圢匏

|`rtf`
|Microsoft 瀟のリッチテキスト圢匏

|`txt`
|プレむンテキスト圢匏
|===
* 圧瞮ず package 圢匏による分類。 珟圚利甚されおいるのは次の 3 皮類です。
.. `html-split` 圢匏の堎合、 ファむルはたず、man:tar[1] を䜿っおたずめられ、 たずめられた [.filename]#.tar# ファむルは次に解説する方匏で圧瞮されたす。
.. その他の圢匏の堎合、ファむルは [.filename]#book.format# (たずえば [.filename]#book.pdb#、 [.filename]#book.html# など) ずいう単䞀のファむルです。
+ 
䞊にあげたファむルは 3 皮類の方匏のいずれかで圧瞮されたす。
+
[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| 方匏
| 説明

|`zip`
|Zip 圢匏。 FreeBSD で圧瞮を元に戻すには、たず [.filename]#archivers/unzip# の port をむンストヌルする必芁がありたす。

|`gz`
|GNU Zip 圢匏。圧瞮を元に戻すには、 FreeBSD に含たれる man:gunzip[1] を䜿いたす。

|`bz2`
|BZip2 圢匏。 他の圢匏に比べお普及しおいたせんが、 䞀般的にファむルサむズが小さくなりたす。 圧瞮を元に戻すには、 [.filename]#archivers/bzip2# port をむンストヌルしおください。
|===
+ 
Postscript 版のハンドブックが BZip2 圢匏で圧瞮されおいる堎合、ファむル名は [.filename]#handbook/# ディレクトリの䞭の [.filename]#book.xml.bz2# になりたす。
.. さたざたな圢匏に敎圢された文曞は、以䞋に述べるように FreeBSD の package ずしおも提䟛されおいたす。

ダりンロヌドする文曞ず圧瞮圢匏を遞択したら、 文曞を FreeBSD _package_ ずしおダりンロヌドするかどうか決めなければなりたせん。

package ずしおダりンロヌドしおむンストヌルする堎合には、 文曞を man:pkg_add[1] や man:pkg_delete[1] ずいった、普通の FreeBSD package 管理システムを甚いた管理が可胜であるずいう利点がありたす。

文曞の package をダりンロヌドしおむンストヌルするこずに決めたら、 たずはダりンロヌドするファむル名を知る必芁がありたす。 文曞の package は、[.filename]#packages# ずいうディレクトリに眮かれおいたす。 そしおそれぞれの package ファむルは、 [.filename]#文曞名.蚀語.゚ンコヌディング.圢匏.tgz# ずいうような名前になっおいたす。

たずえば、FAQ の英語版で PDF 圢匏のものは、 [.filename]#faq.en_US.ISO8859-1.pdf.tgz# ずいうファむル名です。

ファむル名がわかったら、 次のようなコマンドで英語版の PDF 圢匏 FAQ の package をむンストヌルするこずができたす。

[source,shell]
....
# pkg_add ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/faq.en_US.ISO8859-1.pdf.tgz
....

むンストヌルの終了埌は man:pkg_info[1] を䜿い、 ファむルがどこにむンストヌルされたかを調べるこずができたす。

[source,shell]
....
# pkg_info -f faq.en_US.ISO8859-1.pdf
Information for faq.en_US.ISO8859-1.pdf:

Packing list:
        Package name: faq.en_US.ISO8859-1.pdf
        CWD to /usr/shared/doc/en_US.ISO8859-1/books/faq
File: book.pdf
        CWD to .
File: +COMMENT (ignored)
File: +DESC (ignored)
....

ご芧になるずわかるずおり、[.filename]#book.pdf# は [.filename]#/usr/shared/doc/en_US.ISO8859-1/books/faq# にむンストヌルされたす。

package を利甚しない堎合は、 自分で圧瞮されたファむルをダりンロヌドしお元に戻し、 適切な堎所にそれをコピヌする必芁がありたす。 

たずえば、分割された HTML 版の FAQ で、 man:gzip[1] で圧瞮されおいるものは [.filename]#en_US.ISO8859-1/books/faq/book.html-split.tar.gz# ずいうファむルです。 これをダりンロヌドしお圧瞮を元に戻すには、次のようにする必芁があるでしょう。

[source,shell]
....
# fetch ftp://ftp.freebsd.org/pub/FreeBSD/doc/en_US.ISO8859-1/books/faq/book.html-split.tar.gz
# gzip -d book.html-split.tar.gz
# tar xvf book.html-split.tar
....

こうするず、耇数の [.filename]#.html# ファむルが䜜成されたす。 䞭心ずなっおいるのは [.filename]#index.html# ずいう名前のファむルで、 目次や前曞き、文曞の他の郚分ぞのリンクが含たれおいたす。 これらのファむルは、必芁に応じお他の堎所にコピヌしおも構いたせん。

=== FreeBSD のりェブサむトのミラヌサむトになりたいです!

承知したした! りェブペヌゞをミラヌするにはいく぀かの手段がありたす。

* CVSup を䜿いたす。 CVSup を䜿っお CVSup サヌバに接続するこずで、 敎圢されたファむルを取っおくるこずができたす。
+ 
りェブペヌゞを取埗する堎合は、 [.filename]#/usr/shared/examples/cvsup/www-supfile# にある supfile の䟋を参考にしおください。
* FTP を䜿っおミラヌリングしたす。 あなたの奜きな FTP ミラヌリングツヌルを䜿っお、 FTP サヌバに眮いおある web サむトのコピヌをダりンロヌドするこずができたす。 タりンロヌドは単玔に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-CURRENT/www から始めおください。

=== この文曞を他の蚀語に翻蚳したいのですが?

報酬は支払えたせんが、 文曞の翻蚳を提出しおくださる方には、 フリヌの CD、T シャツの手配や、 ハンドブックにある貢献者䞀芧ぞの登録を行ないたいず思いたす。 翻蚳䜜業をはじめる前に、 {freebsd-doc} ぞ連絡するようにお願いしたす。 翻蚳䜜業を手䌝うずいう人が珟われるかも知れたせんし。 既に翻蚳チヌムがあっお、あなたの参加を歓迎しおくれるかも知れたせん。 

=== その他の情報

以䞋のニュヌスグルヌプには FreeBSD ナヌザに盎接関係のある議論が行われおたす。 

* link:news:comp.unix.bsd.freebsd.announce[comp.unix.bsd.freebsd.announce] (moderated)
* link:news:comp.unix.bsd.freebsd.misc[comp.unix.bsd.freebsd.misc]
* link:news:comp.unix.bsd.misc[comp.unix.bsd.misc]

Web 䞊のリ゜ヌス:

* http://www.FreeBSD.org/[FreeBSD のホヌムペヌゞ]
* [[pao]] ラップトップ PC を持っおいる方は、 迷うこずなく日本のlink:http://www.jp.FreeBSD.org/PAO/[现川 達己氏の Mobile Computing のペヌゞ] を芋たしょう。 
* [[smp]] SMP (Symmetric MultiProcessing) に関する情報は、 http://people.FreeBSD.org/~fsmp/SMP/SMP.html[SMP サポヌトペヌゞ]をご芧ください。 
* [[multimedia]] FreeBSD のマルチメディアアプリケヌションに関する情報は、 http://people.FreeBSD.org/~faulkner/multimedia/mm.html[マルチメディア]のペヌゞをご芧ください。 特に http://people.FreeBSD.org/~ahasty/Bt848.html[Bt848] ビデオキャプチャチップに興味のある方は、 リンクをたどっおみおください。 

FreeBSD ハンドブックには、 実に完成されたextref:{handbook}bibliography[参考図曞, bibliography]の䞀芧があり、 買うべき本をさがしおいる方は読む䟡倀がありたす。

== むンストヌル

=== FreeBSD を入手するには、どのファむルをダりンロヌドすれば良いのでしょうか?

FreeBSD 3.1-RELEASE 以前では、 むンストヌルの際に必芁なのは [.filename]#floppies/boot.flp# ず名前の぀いた 䞀぀のフロッピヌディスクむメヌゞだけでした。 しかし FreeBSD 3.1-RELEASE 以降、 幅広い皮類のハヌドりェアサポヌトが基本システムに远加され、 そのサポヌトが必芁ずする容量を補うため、 3.X ず 4.X の系列では新たに、 [.filename]#floppies/kernel.flp# および [.filename]#floppies/mfsroot.flp# ずいう、二぀のフロッピヌディスクむメヌゞを䜿うようになりたした。 これらのむメヌゞをフロッピヌディスクに曞き蟌むには、 `fdimage` や man:dd[1] ずいったツヌルが必芁ずなりたす。 

(DOS ファむルシステムからのむンストヌルなどで) あなた自身が手動で配垃ファむルをダりンロヌドする堎合には、 以䞋の配垃ファむルをダりンロヌドするこずをおすすめしたす。 

* [.filename]#bin/#
* [.filename]#manpages/#
* [.filename]#compat*/#
* [.filename]#doc/#
* [.filename]#src/ssys.*#

この手順の完党な説明ず、䞀般的なむンストヌル時の問題に぀いおは extref:{handbook}install[FreeBSD ハンドブックのむンストヌルの節, install] を参照しおください。

=== ブヌトフロッピヌむメヌゞが䞀枚のフロッピヌディスクに玍たらないみたい!

3.5 むンチ (1.44MB) のフロッピヌディスクには、 1474560 バむトのデヌタを栌玍できたす。 ブヌトむメヌゞはちょうど 1474560 バむトの倧きさです。 

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

* FTP によっおフロッピヌむメヌゞをダりンロヌドする際に、 _バむナリ (binary)_ モヌドにしおいなかった。 
+ 
FTP クラむアントの䞭には、 転送モヌドのデフォルトを__アスキヌ (ascii)__ モヌドにしお、 クラむアント偎システムの慣習にあうよう、 すべおの行末の文字を倉曎するものがありたす。 この堎合は垞に、ブヌトむメヌゞが壊れたものになりたす。 ダりンロヌドしたブヌトむメヌゞのサむズをチェックしおください。 サヌバ䞊のものず__正確に__䞀臎しなければ、 ダりンロヌドの凊理を疑いたしょう。 
+ 
これを回避するには、 サヌバに接続しおむメヌゞのダりンロヌドを開始する前に FTP のコマンドプロンプトで `binary` ずタむプしたす。 
* ブヌトむメヌゞを DOS の `copy` コマンド (たたは GUI の同等のツヌル) でフロッピヌディスクぞ転送した。 
+ 
`copy` のようなプログラムは、 盎接起動するように䜜成されたブヌトむメヌゞをうたく凊理できたせん。 むメヌゞにはフロッピヌディスクの完党な䞭身がトラック単䜍で栌玍されおおり、 フロッピヌディスク䞊に通垞のファむルずしお 栌玍されるように想定されおいるわけではありたせん。 extref:{handbook}install[FreeBSD のむンストヌル, install]に蚘述されおいるように、 䜎レベルのツヌル (たずえば `fdimage` や `rawrite`) を䜿甚しお "そのたたの (raw)" の状態でフロッピヌディスクに 転送する必芁がありたす。

=== FreeBSD のむンストヌルに぀いおの説明曞はどこにありたすか?

むンストヌルの説明曞はextref:{handbook}install[FreeBSD ハンドブックのむンストヌルの章, install]にありたす。

=== FreeBSD を動䜜させるには䜕が必芁ですか?

386 以䞊の PC、5MB 以䞊の RAM、 そしお最䜎 60MB のハヌドディスク容量が必芁ずなりたす。 ロヌ゚ンドの MDA カヌドでも動䜜したすが、 X11R6 を䜿うには VGA かそれ以䞊のビデオカヌドが必芁ずなりたす。 

<<hardware>> もご芧ください。 

=== 4MB しかメモリがないのですが、むンストヌルできたすか?

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 環境を぀くるには、 <<custrel,ここの指瀺>>にしたがっおください。 

=== 同じマシンで Windows 95/98 ず共存できたすか?

たず Windows 95/98 をむンストヌルしおから、そのあずで FreeBSD をむンストヌルしおください。FreeBSD のブヌトマネヌゞャが Win95 ず FreeBSD のブヌト管理をしおくれるようになりたす。 Windows 95/98 を埌にむンストヌルした堎合はひどいこずに、 問い合わせるこずもなくブヌトマネヌゞャを䞊曞きしおしたいたす。 そうなっおしたった堎合は次の節をご芧ください。 

=== Windows 95/98 がブヌトマネヌゞャを朰しちゃった! どうやっお戻すの?

ブヌトマネヌゞャの再むンストヌルの方法ずしお、 FreeBSD では以䞋に瀺す䞉通りの方法が甚意されおいたす。

* DOS を起動し、FreeBSD の配垃物の䞭にある [.filename]#tools/# ディレクトリぞ移動し、 [.filename]#bootinst.exe# を探しおください。 そしお次のように実行したす。 
+
[source,shell]
....
...\TOOLS> bootinst.exe boot.bin
....
+ 
こうするこずで、 ブヌトマネヌゞャが再むンストヌルされたす。 
* FreeBSD のブヌトフロッピヌディスクから起動し、 「カスタム」むンストヌルメニュヌを遞択し、 続いお「パヌティション」を遞択したす。 ブヌトマネヌゞャがむンストヌルされおいたドラむブ (倚分最初のもの) を遞択し、 パヌティション゚ディタにたどり着いたら、 (䜕も倉曎せず) そのたた (W)rite を指定したす。 確認のメッセヌゞが出たすので「はい(Y)」ず答え、 ブヌトマネヌゞャ遞択の画面で確実に "Boot Manager" を遞択したす。 これでブヌトマネヌゞャがディスクに再び曞き蟌たれたす。 むンストヌルメニュヌから抜けお再起動するず、 ハヌドディスクは元通りになりたす。 
* FreeBSD 起動フロッピヌ (もしくは CD-ROM) から起動し、 "Fixit" メニュヌを遞択したす。 Fixit フロッピヌか CD-ROM #2 ("live" ファむルシステムオプション) の奜きな方を遞択しお fixit シェルに入りたす。 そしお、次のコマンドを実行しおください。
+
[source,shell]
....
Fixit# fdisk -B -b /boot/boot0 起動デバむス
....
+ 
_起動デバむス_ の郚分は、たずえば [.filename]#ad0# (䞀番目の IDE ディスク)、 [.filename]#ad4# (セカンダリ IDE コントロヌラの䞀番目の IDE ディスク)、 [.filename]#da0# (䞀番目の SCSI ディスク) などずいった、実際の起動デバむスを衚しおいたす。

===  IBM Thinkpad の A、T、X シリヌズのいずれかを持っおいたす。 FreeBSD をむンストヌルしたら起動しなくなっおしたいたした。 どうすればいいですか? 

これらのマシンに䜿われおいる初期のリビゞョンの IBM BIOS にはバグがあり、FreeBSD のパヌティションをディスクサスペンド甚の FAT 領域だず誀認したす。 そのため、BIOS が FreeBSD のパヌティションを 怜出したずころでシステムがハング (停止) しおしたいたす。 

IBM  によれば、以䞋のモデル/BIOS リリヌス番号には修正が含たれおいたす。 

[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| モデル
| BIOS リビゞョン番号

|T20
|IYET49WW 以降

|T21
|KZET22WW 以降

|A20p
|IVET62WW 以降

|A20m
|IWET54WW 以降

|A21p
|KYET27WW 以降

|A21m
|KXET24WW 以降

|A21e
|KUET30WW
|===

それより新しいリビゞョンの BIOS にたたバグが入り蟌んだか もしれないずいう報告がありたした。Jacques Vidrine は mailto:[email protected][[email protected]] メヌリングリストにあおた http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=200565+208320+/usr/local/www/db/text/2001/freebsd-mobile/20010429.freebsd-mobile[メッセヌゞ] で、これ以降の IBM の laptop で FreeBSD が正垞に起動しない 堎合におそらくうたく行く、BIOS をアップグレヌドたたは ダりングレヌドできる手順を説明しおいたす。

もし問題のある BIOS を䜿っおいおアップグレヌドが遞べない堎合、 FreeBSD をむンストヌルしおから FreeBSD が䜿っおいるパヌティション ID を倉曎し、 倉曎されたパヌティション ID を正しく扱うこずのできる 新しい起動ブロックをむンストヌルするこずで解決するこずができたす。 

それにはたず、 セルフテスト画面を通過する状態にたでマシンを回埩させる必芁がありたす。 そのためには、マシンがプラむマリディスクから FreeBSD パヌティションを芋぀けないようにしお起動しなければなりたせん。 たずえば、䞀床ハヌドディスクを倖しおしたっお、そのディスクを叀い ThinkPad (ThinkPad 600 など) やデスクトップ PC に適切な倉換ケヌブルで接続したす。 その埌 FreeBSD のパヌティションを削陀し、 ハヌドディスクを元の ThinkPad に戻したす。 こうするこずで ThinkPad は起動可胜な状態に戻るはずです。 

マシンがちゃんず動くようになったら、 以䞋の埩旧手順に埓っお FreeBSD をむンストヌルするこずができたす。 

[.procedure]
====
. http://people.freebsd.org/\~bmah/ThinkPad/[http://people.freebsd.org/~bmah/ThinkPad/] から [.filename]#boot1# ず [.filename]#boot2# をダりンロヌドしたす。 これらのファむルは、 あずで必芁になった時、取り出せる堎所に眮いおおきたす。 
. ThinkPad に普通に FreeBSD をむンストヌルしたす。 ただし、`Dangerously Dedicated` モヌドを䜿っおは__いけたせん__。 たた、むンストヌルが終わっおも再起動しおは__いけたせん__。
. "緊急ホログラフィックシェル (Emergency Holographic Shell)" (kbd:[ALT+F4]) に切り替えるか、"fixit" シェルを起動したす。 
. man:fdisk[8] を䜿っお FreeBSD のパヌティション ID を `165` から `166` に 倉曎したす (これは OpenBSD で䜿われおいるものです)。 
. [.filename]#boot1# ず [.filename]#boot2# のファむルをロヌカルファむルシステムに持っお来たす。 
. man:disklabel[8] を䜿っお [.filename]#boot1# ず [.filename]#boot2# を FreeBSD のスラむスに曞き蟌みたす。 
+
[source,shell]
....
# disklabel -B -b boot1 -s boot2 ad0sn
....
+ 
_n_ は、 あなたが FreeBSD をむンストヌルしたスラむスの番号です。 
. 再起動したす。起動プロンプトは `OpenBSD` ず瀺したすが、実際には、それで FreeBSD が起動したす。 
====

この方法で FreeBSD ず OpenBSD をデュアルブヌトする方法は、読者ぞの緎習問題ずしたしょう。 

=== 䞍良ブロックのあるディスクにむンストヌルできたすか?

FreeBSD 3.0 以前のシステムでは、 䞍良ブロックを自動的に再マッピングする `bad144` ずいうナヌティリティが含たれおいたしたが、 珟圚の IDE ドラむブはドラむブ自身がこの機胜を備えおいるため、 `bad144` は FreeBSD ゜ヌスツリヌから削陀されたした。 FreeBSD 3.0 かそれ以降をむンストヌルしたいず思っおいるなら、 比范的新しいディスクドラむブを賌入するこずを匷くおすすめしたす。 新しいドラむブを賌入する気がなければ、FreeBSD 2.x を利甚するべきです。

珟圚の IDE ドラむブで䞍良ブロックによる゚ラヌが発生した堎合、 たもなくドラむブが故障する可胜性がありたす (それはそのドラむブ内蔵の再マッピング機胜では 䞍良ブロックが修正できなくなったずいうこずであり、 ディスクがひどく壊れおいるこずを意味したす)。 新しいハヌドディスクドラむブに亀換したしょう。

䞍良ブロックのある SCSI ドラむブの堎合は、 <<awre,この回答>>を参照しおください。 

=== むンストヌラから起動したら倉なこずになりたした!

むンストヌラから起動しようずしたずきに、マシンが固たっおし たうずか自然ず再起動しおしたうずいった珟象であれば、 次の䞉぀の項目を確認しおください。 

. 新品の、フォヌマットしたおの、 ゚ラヌのないフロッピヌディスクを䜿っおいたすか? (䞉幎間もベッドの䞋に攟眮されおいた雑誌の付録みたいなや぀ではなくお、 買っおきたばかりの新品を䜿っおください) 
. フロッピヌむメヌゞをバむナリモヌドでダりンロヌドしたしたか? (困った顔をしないでください。私たちの䞭で䞀番優秀な人でさえ、 少なくずも䞀回はバむナリファむルを ASCII モヌドで思いがけずダりンロヌドしたこずがあるのです!) 
. Windows95 あるいは Windows98 を䜿甚しおいるなら、 ありのたたの本物の DOS で `fdimage` か `rawrite` を実行したしたか? これらの OS はディスク䜜成プログラムのような、 ハヌドりェアに盎接曞き蟌みを行なうプログラムに干枉する可胜性がありたす。 GUI の䞭の DOS シェル内郚で動䜜しおいる堎合でも、 この問題は発生したす。

たた、Netscape でブヌトむメヌゞをダりンロヌドする堎合も問題があるこずが報告されおいたすので、 できれば別の FTP クラむアントを䜿うのがよいでしょう。 

=== ATAPI CD-ROM から起動したのですが、 むンストヌルプログラムは CD-ROM が芋぀かりたせんず蚀っおきたす。 CD-ROM はどこに行っおしたったのでしょうか?

この問題は通垞、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 をむンストヌルするこずはできたせん。 もしこうしたテヌプを䜿うず、 レコヌドサむズが倧きすぎるずいう゚ラヌが起きるこずになりたす。 

=== PLIP 経由で二぀ FreeBSD box を接続したいのですが

Laplink パラレルケヌブルを甚意しお、 䞡方の PC のカヌネルに [.filename]#lpt# ドラむバが組み蟌たれおいるこずを確認しおください。 

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

パラレルむンタフェヌスに Laplink パラレルケヌブルを接続したす。 

`root` になっお、䞡方で [.filename]#lp0# のネットワヌクむンタフェヌスパラメヌタを蚭定したす。 たずえば、ホスト `max` ず `moritz` を接続したい堎合、 

[.programlisting]
....
              max <-----> moritz
IP Address      10.0.0.1        10.0.0.2
....

max 偎で次のようにしお、

[source,shell]
....
# ifconfig lp0 10.0.0.1 10.0.0.2
....

moritz 偎で同様に次のようにしたす。

[source,shell]
....
# ifconfig lp0 10.0.0.2 10.0.0.1
....

以䞊です! man:lp[4] ず man:lpt[4] のマニュアルペヌゞも参照しおください。 

たた、 [.filename]#/etc/hosts# にホストの远加もしたしょう。 

[.programlisting]
....
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` 偎:

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

[source,shell]
....
% netstat -r
Routing tables

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

[source,shell]
....
% 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
....

=== ラップトップ PC に PLIP 経由でむンストヌルできたすか?

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

.ネットワヌク接続甚のパラレルケヌブルの結線
[cols="1*l,1*l,1*l,1,1*l", options="header"]
|===
| A-name
| A 偎
| B 偎
| 説明
| ポヌト / ビット

|

....
DATA0
-ERROR
....
|

....
2
15
....
|

....
15
2
....
|Data
|

....
0/0x01
1/0x08
....

|

....
DATA1
+SLCT
....
|

....
3
13
....
|

....
13
3
....
|Data
|

....
0/0x02
1/0x10
....

|

....
DATA2
+PE
....
|

....
4
12
....
|

....
12
4
....
|Data
|

....
0/0x04
1/0x20
....

|

....
DATA3
-ACK
....
|

....
5
10
....
|

....
10
5
....
|Strobe
|

....
0/0x08
1/0x40
....

|

....
DATA4
BUSY
....
|

....
6
11
....
|

....
11
6
....
|Data
|

....
0/0x10
1/0x80
....

|GND
|18-25
|18-25
|GND
|-
|===

たた、 <<pao,Mobile Computing に぀いおのペヌゞ>>もご芧ください。 

=== ハヌドディスクドラむブには、 どのゞオメトリを䜿うべきでしょうか?

[NOTE]
====
ここでディスクの「ゞオメトリ」ずは、ディスクのシリンダ、ヘッダ、 トラック圓りのセクタの数を意味しおいたす - 䟿宜䞊、 C/H/S ずするこずにしたす。これはディスクのどの領域で読み曞きを 行なうかを PC の BIOS が決定する手段ずなりたす。
====

これに぀いおはある理由のために、誀解されおいる点が倚いようです。 たず最初に、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 ず䞀緒に配垃されおいるフリヌで䜿えるナヌティリティに [.filename]#pfdisk.exe# (FreeBSD CD-ROM の [.filename]#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 の起動時に Missing Operating System ず衚瀺されたす

これは FreeBSD や DOS、 そのほかの OS がディスク領域<<geometry,ゞオメトリ>> のずらえ方で衝突しあっおいるこずから起こる兞型的な䟋です。 こうなったら FreeBSD をむンストヌルし盎す以倖にはありたせんが、 他のずころで説明した手順にしたがっおやれば、 ほが間違いなくうたくいくはずです。 

=== ブヌトマネヌゞャの F? プロンプトが衚瀺されたせん。

これはすでに前に質問されおいる問題のもう䞀぀の症状です。 BIOS のゞオメトリず FreeBSD のゞオメトリ蚭定が䞀臎しおいないのです! コントロヌラや BIOS がシリンダの倉換 (``>1GB ドラむブの サポヌト``ずも呌ばれたす) をサポヌトしおいたら、 その蚭定を無効化しお FreeBSD をむンストヌルし盎しおみおください。 

=== ゜ヌスを党郚むンストヌルする必芁はありたすか?

䞀般的には「いいえ」です。 しかし最䜎でも、`base` ゜ヌスキット (これにはこの FAQ で述べられおいるファむルのいく぀かが含たれおいたす) ず、 `sys` (kernel) ゜ヌスキット (これにはカヌネルの゜ヌスが含たれおいたす) をむンストヌルする事を匷くおすすめしたす。 通垞、䜕かの実行に゜ヌスが必芁になる事はありたせん。 しかし、カヌネルをコンフィグレヌションするためのプログラム man:config[8] を実行する時は䟋倖です。 カヌネルの゜ヌスをむンストヌルしなくおもよい䟋ずしお、 どこか別の堎所からカヌネルの゜ヌスを読み蟌み専甚で NFS マりントするこずができたす。たた、 そこから新しいバむナリを䜜成できるようにもなっおいたす (カヌネル゜ヌスの制限があるので、盎接 [.filename]#/usr/src# をマりントする事はおすすめできたせん。 それよりもどこか別のディレクトリにマりントしお、 ゜ヌスツリヌの耇補ができるように適切にシンボリックリンクを匵っおください)。 

゜ヌスをネットワヌク䞊に持ち、 そこからシステムをビルドするようにしおおけば、 FreeBSD の将来のリリヌスぞのアップグレヌドがずっず簡単になりたす。 

実際に゜ヌスのサブセットを遞択するには、 システムむンストヌルツヌルの「配垃ファむル」メニュヌにある、 「カスタム」メニュヌを䜿甚したす。 

=== カヌネルは必ず䜜り盎さなくちゃならないんですか?

カヌネルを新しく䜜り盎すのは元々、 FreeBSD のむンストヌル時に必須の䜜業でした。 でも最近のリリヌスでは、 ずおもナヌザフレンドリなカヌネル蚭定ツヌルの恩恵を受けおいたす。 FreeBSD の起動プロンプト (boot:) で `-c` ずタむプすればビゞュアルな蚭定画面になり、 ほずんどの䞀般的な ISA カヌドに぀いおのカヌネルの蚭定をするこずができるのです。 

今でも、 必芁なデバむスドラむバだけを組み蟌んだカヌネルを䜜るこずはよい事ずされおいたす。 ほんのちょっずだけメモリを節玄できたすからね。 でもほずんどのシステムでは、 もはやどうしおもやらなくちゃならないこずではないのです。 

=== DES ず MD5、どちらのパスワヌドを䜿うべきなのでしょうか? たた、ナヌザがどちらを䜿うこずになるか指定する方法はありたすか?

FreeBSD の暙準のパスワヌドフォヌマットは _MD5_ を䜿ったものです。 これは _DES_ アルゎリズムに基づいた手法を甚いる UNIX の䌝統的なパスワヌドフォヌマットより安党 (secure) だず 信じられおいるものです。 DES パスワヌドは あなたが FreeBSD のパスワヌドファむルを、 安党性に劣るパスワヌドフォヌマットを利甚しおいる叀い OS ず共有しなければならなくなったずきのために 利甚可胜になっおいたす (これは利甚するためには、 sysinstall から "crypto" 配垃物のむンストヌル 遞ぶか、゜ヌスから build しおいるなら、 crypto の゜ヌスがむンストヌルされおいる必芁がありたす)。 新しいパスワヌドにどちらのパスワヌドフォヌマットを䜿うかは [.filename]#/etc/login.conf# の䞭の "passwd_format" ずいう login ケヌパビリティで制埡されたす。このケヌパビリティは "des" (利甚できるなら) か "md5" のどちらかの倀を取りたす。 login ケヌパビリティの詳现に぀いおは man:login.conf[5] を 参照しおください。

=== ブヌトフロッピヌで起動するず、 Probing Devices... の画面でハングアップしたす。

IDE Zip か Jaz ドラむブが接続されおいたら、 それを取り倖しおもう䞀床詊しおみたしょう。 ブヌトフロッピヌはこの皮のドラむブを誀認しおしたうのです。 システムがむンストヌルされた埌は、そのドラむブを再床接続するこずができたす。 うたくいけばこの問題は将来のリリヌスで解決されるでしょう。 

=== むンストヌル終了埌にシステムを再起動するず、 panic: cant mount root の゚ラヌずなりたす。

この゚ラヌはディスクデバむスに぀いお、 起動ブロックずカヌネルの認識が混乱しおいるために起こりたす。 この゚ラヌは通垞、 2 台の IDE ディスクがそれぞれ別の IDE コントロヌラのマスタヌに䞀぀ず぀接続されおいるシステムにおいお、 FreeBSD がセカンダリ IDE コントロヌラに接続されたディスクにむンストヌルされおいる堎合に発生したす。 起動ブロックは FreeBSD が wd1 (2 台目の BIOS ディスク) にむンストヌル されおいるず認識するのに察し、 カヌネルはセカンダリ IDE の 1 台目のハヌドディスクである wd2 にむンストヌルされおいるず認識するのです。 デバむス怜出埌で、 カヌネルは起動ブロックが起動ディスクだず認識したディスクである wd1 をマりントしようずしたす。 しかし、実際には起動ディスクは wd2 なので倱敗しおしたうのです。 

この問題を解決するには、以䞋のどれか䞀぀を行っおください。 

. FreeBSD 3.3 以降を利甚しおいる堎合には、 システムを再起動しお、`Booting kernel in 10 seconds; hit [Enter] to interrupt` が衚瀺されおいる間に `Enter` キヌを抌したす。 するず、ブヌトロヌダに移行したす。 
+ 
そうしたら、`set root_disk_unit="disk_number"` ず入力したす。 FreeBSD が最初の IDE コントロヌラのマスタヌに接続されたドラむブにむンストヌルされおいれば、 _disk_number_ は `0` です。 たた、 最初の IDE コントロヌラのスレヌブなら `1`、 二番目の IDE コントロヌラのマスタヌなら `2`、 二番目の IDE コントロヌラのスレヌブなら `3` になりたす。 
+ 
その埌、`boot` ず入力したす。 システムはきちんず再起動するはずです。
+ 
この倉曎を恒久的なものにする (぀たり、 再起動や電源を入れる床にこの操䜜をする必芁がないようにする) には、 [.filename]#/boot/loader.conf.local# に `root_disk_unit="disk_number"` ずいう行を远加しおください。
. FreeBSD 3.2 以前を利甚しおいる堎合は、 Boot: プロンプトで `1:wd(2,a)kernel` ず入力しお゚ンタヌキヌを抌したす。 システムが起動したら、 `echo "1:wd(2,a)kernel" > /boot.config` ずいうコマンドを実行しおこれをデフォルトのブヌト文字列ずしたす。 
. FreeBSD のディスクをプラむマリ IDE コントロヌラに接続しお、 ハヌドディスクが連続したドラむブ番号で認識されるようにしたす。 
. カヌネルのコンフィグレヌションファむルで wd の行を以䞋のように倉曎し、 extref:{handbook}kernelconfig[カヌネルの再構築, kernelconfig]を行っお、 新しいカヌネルをむンストヌルしたす。
+
[.programlisting]
....
controller      wdc0    at isa? port "IO_WD1" bio irq 14 vector wdintr
disk            wd0     at wdc0 drive 0
# disk            wd1     at wdc0 drive 1 # この行をコメントアりト

controller      wdc1    at isa? port "IO_WD2" bio irq 15 vector wdintr
disk            wd1     at wdc1 drive 0 # wd2 から wd1 ぞ倉曎
disk            wd2     at wdc1 drive 1 # wd3 から wd2 ぞ倉曎
....
+ 
ディスクの接続を倉曎しお元の蚭定に戻したい堎合は、ディスクを お望みの蚭定の通りの接続に戻しおから再起動したす。 システムは正垞に起動するはずです。

=== メモリの倧きさの制限は?

認識できるメモリの䞊限は、4GB です。 この構成は詊隓枈みで、 詳现は link:ftp://ftp.cdrom.com/archive-info/configuration[wcarchive's configuration] をご芧ください。 このようにたくさんのメモリをマシンに導入しようずいう堎合には、 泚意が必芁です。ECC 機胜をサポヌトし、なおか぀ 容量性負荷 (蚳泚: 倚くのメモリ玠子は容量性負荷ずしお働きたすが、 メモリバス䞊に容量性負荷が増えるず信号の䌝達が遅れ、誀動䜜の原因ずなりたす) を 䜎枛させるため、18 チップ構成のメモリモゞュヌルより 9 チップ構成のメモリモゞュヌルを遞択するこずが、おそらく望たしいでしょう。 

=== ffs ファむルシステムの倧きさの制限は?

ffs ファむルシステムの堎合、 論理的な最倧の䞊限は 8 TB (2G ブロック)、 デフォルトのブロックサむズを 8K ずするず 16 TBずなりたす。 実際問題ずしお、1 TB の゜フトりェアの限界がありたすが、 修正すれば 4 TB のファむルシステムが可胜です (実際に存圚したす)。 

䞀぀の ffs のファむルの最倧のサむズは、ブロックサむズが 4K の堎合で 箄 1G ブロック (4 TB)です。

.最倧ファむルサむズ
[cols="1,1,1,1,1", options="header"]
|===
| fs ブロックサむズ
| 2.2.7-stable
| 3.0-current
| 動䜜確認枈みのサむズ
| 動䜜するはずのサむズ

|4K
|4T-1
|4T-1
|4T-1
|>4T

|8K
|>32G
|8T-1
|>32G
|32T-1

|16K
|>128G
|16T-1
|>128G
|32T-1

|32K
|>512G
|32T-1
|>512G
|64T-1

|64K
|>2048G
|64T-1
|>2048G
|128T-1
|===

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 のファむルを栌玍するには?

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

以䞋の䟋は、32K のディスク容量 (3 ぀の間接ブロックず 1 ぀のデヌタブロック) を䜿っお、 小さなルヌトパヌティションに 8T-1 の倧きさのファむルを䜜成したす。 ここでの dd コマンドは倧きなファむルが扱えるものが必芁です。 

[source,shell]
....
% 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%    /
....

=== 新しいカヌネルをコンパむルしたら、起動時に archsw.readin.failed ずいう゚ラヌメッセヌゞが衚瀺されるようになっおしたいたした。

ロヌダがスタヌトする前の | が衚瀺されおいるずきに䜕かキヌを抌すこずで、 起動のセカンドステヌゞから盎接、起動するカヌネルを指定しお起動するこずができたす。 特に、カヌネルの゜ヌスを曎新し、__make world しないで__新しいカヌネルだけむンストヌルした堎合にこの症状が珟われたす。 こういう操䜜は動䜜が保蚌されたせん。きちんず make world しおください。 

=== 3.X から 4.X にアップグレヌドするにはどうしたら良いのですか?

アップグレヌドには、 バむナリスナップショットを䜿うこずを__匷く__おすすめしたす。 4-STABLE スナップショットは link:ftp://releng4.FreeBSD.org/[releng4.FreeBSD.org] から入手可胜です。

゜ヌスを䜿っおアップグレヌドする堎合は、詳现に぀いお extref:{handbook}updating-upgrading[FreeBSD ハンドブック, cutting-edge]を参照するようにしおください。

[CAUTION]
====

゜ヌスを䜿ったアップグレヌドは、 慣れおいないナヌザにはたったくおすすめできたせん。 3.X から 4.X ぞの堎合は特にそうです。 ゜ヌスを䜿ったアップグレヌドを詊す前に、 手順を泚意深く読むように心がけおください。
====

=== セキュリティプロファむル (security profiles) ずは䜕ですか?

"セキュリティプロファむル"ずは、特定の プログラムやその他の蚭定を有効にしたり無効にするこずで、求める 比率で安党ず䟿利さを実珟しようずする構成の遞択肢の集たりの こずです。セキュリティプロファむルが厳しいほど、デフォルトで 有効になるプログラムが枛りたす。これは、動かさなければならない もの以倖は、䜕も動かしおはいけないずいうセキュリティの 基本的原則の䞀぀です。

セキュリティプロファむルは、単にデフォルトの蚭定である ずいうこずに気を぀けおください。FreeBSD をむンストヌルした あずに [.filename]#/etc/rc.conf# に適切な行を線集したり 远加すれば、どのプログラムでも有効にしたり無効にしたりできたす。 埌者に぀いお詳しいこずは man:rc.conf[5] のマニュアルを ご芧ください。

以䞋に、各セキュリティプロファむルが䜕を行うかを説明した 衚を掲茉したす。列はセキュリティプロファむルの遞択肢で、行は 有効たたは無効になるプログラムや機胜です。

.指定できるセキュリティプロファむル
[cols="1,1,1,1,1", options="header"]
|===
| 
| Extreme
| High
| Moderate
| Low

|man:inetd[8]
|NO
|NO
|YES
|YES

|man:sendmail[8]
|NO
|YES
|YES
|YES

|man:sshd[8]
|NO
|YES
|YES
|YES

|man:portmap[8]
|NO
|NO
|おそらく (むンストヌル時に、すでにマシンを NFS クラむアントたたはサヌバずしお蚭定しおいるず、 ポヌトマッパが有効になりたす。) 
|YES

|NFS server
|NO
|NO
|YES
|YES

|man:securelevel[8]
|YES (2) (securelevel を蚭定するセキュリティプロファむル (Extreme たたは High) を遞択する堎合、その圱響を 承知しおいなければなりたせん。man:init[8] のマニュアルを 読み、セキュリティレベルの意味に぀いお特に泚意を 払っおください。そうしないず、埌で深刻な問題が 起きるかもしれたせん。) 
|YES (1)
|NO
|NO
|===

[WARNING]
====

セキュリティプロファむルは魔法の薬ではありたせん。 High に蚭定したら、適圓な extref:{handbook}eresources[ メヌリングリスト, eresources-mail]を読んだり、良質なパスワヌドや パスフレヌズを甚いたり、セキュリティに぀いおのよい習慣を 守ったりしなくおいいわけではありたせん。求めるセキュリティず 䟿利さの比率を手軜に蚭定しおくれるだけです。
====

[NOTE]
====
セキュリティプロファむルの機構は、FreeBSD を最初に むンストヌルする時に䜿うこずを想定しおいたす。すでに FreeBSD がむンストヌルされおいるなら、単に求める機胜を 有効にしたり無効にしたりする方が、おそらく効率が よいでしょう。もし、本圓にセキュリティプロファむルを 䜿いたいのであれば、man:sysinstall[8] を再実行すれば 蚭定できたす。
====

[[hardware]]
== ハヌドりェアコンパチビリティ

=== FreeBSD は、 どんなハヌドディスクドラむブをサポヌトしおいるのですか?

FreeBSD は、EIDE ず SCSI ハヌドディスクドラむブをサポヌトしおいたす (互換コントロヌラも含みたす。 次の節参照)。 たた独自の "Western Digital" むンタフェヌスを䜿甚しおいるすべおのドラむブ (MFM、 RLL、ESDI、もちろん IDE) もサポヌトしおいたす。 独自仕様のむンタフェヌスを䜿甚する ESDI コントロヌラでは動䜜しないものがあり、 WD1002/3/6/7 ずその互換むンタフェヌスず衝突したす。 

=== どの SCSI コントロヌラをサポヌトしおいるのですか?

extref:{handbook}[FreeBSD ハンドブック]に蚘されおいる完党なリストを参照しおください。

=== どんな CD-ROM ドラむブをサポヌトしおいるのですか?

サポヌトされおいる SCSI コントロヌラに接続できる SCSI ドラむブは、すべおサポヌトされおいたす。 

たた、以䞋の専甚 CD-ROM むンタフェヌスもサポヌトしおいたす。 

* ミツミ LU002 (8bit)、LU005 (16bit) および FX001D (16bit 2倍速)。
* ゜ニヌ CDU 31/33A
* Sound Blaster 非 SCSI タむプの CD-ROM
* 束䞋/Panasonic CD-ROM
* ATAPI 互換の IDE CD-ROM

SCSI でないカヌドはすべお、SCSI ドラむブよりも極めお動䜜速床が 遅いこずが知られおおり、ATAPI CD-ROM には動䜜しないものもあるようです。 

BSDi の FreeBSD 2.2 CD-ROM からは CD からの盎接起動が サポヌトされおいたす。 

=== FreeBSD は、どの CD-RW ドラむブに察応しおいたすか?

FreeBSD は ATAPI 互換の IDE CD-R たたは CD-RW ドラむブで あれば察応しおいたす。FreeBSD バヌゞョン 4.0 以降に぀いおは、 man:burncd[8] のマニュアルをご芧ください。それ以前の バヌゞョンの FreeBSD では、 [.filename]#/usr/shared/examples/atapi# にある䟋を ご芧ください。

たた、FreeBSD は SCSI の CD-R たたは CD-RW ドラむブにも 察応しおいたす。ports たたは packages から `cdrecord` コマンドをむンストヌルしお、 カヌネルに [.filename]#pass# デバむスが組み蟌たれお いるこずを確認しおください。

=== ZIP ドラむブをサポヌトしおいたすか?

もちろん、 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 をお䜿いでしたら、 カヌネルコンフィグレヌションファむルに [.filename]#scbus0#、 [.filename]#da0#、 [.filename]#ppbus0#、 [.filename]#vp0# の各ドラむバが蚘述されおいるこずを確認しおください。 (GENERIC カヌネルには [.filename]#vp0# を陀くすべおのドラむバが含たれおいたす)。 これらすべおのドラむバがあれば、 パラレルポヌトのドラむブは [.filename]#/dev/da0s4# ずなりたす。 ディスクは `mount /dev/da0s4 /mnt` ずするか `mount_msdos /dev/da0s4 /mnt` (DOS ディスクの堎合) ずするこずでマりントできたす。 

それから<<jaz,リムヌバブルドラむブに関する泚意>>および、 <<disklabel,「フォヌマット」に関する泚意>>に぀いおも 確認しおおいおください。 

=== では、JAZ や EZ、 それからその他のリムヌバブルドラむブはサポヌトしおいたすか?

FreeBSD では、IDE バヌゞョンの EZ ドラむブを陀くすべおの SCSI デバむスは、 SCSI のディスクず同等に扱われたす。 たた IDE EZ は IDE ドラむブず同等ずなりたす。 

[[jaz]] システム皌働䞭のメディア亀換に぀いお FreeBSD がどれほどうたく動くか定かではありたせん。 もちろんメディアを入れ替える前にそのドラむブのマりントを解陀しなければいけないでしょうし、 FreeBSD がそれらを認識するには、 起動時に倖郚ナニットにも電源が投入されおいるこずを確認しなければいけないでしょう。 

<<disklabel,「フォヌマット」に関する泚意>>も参照のこず。

=== どのマルチポヌトシリアルカヌドをサポヌトしおいたすか?

䞀芧は extref:{handbook}[その他のデバむス]の節にありたす。

無名のカヌドにもうたく動くものがあり、 特に AST 互換ずいわれおいるものに倚く芋られたす。 

カヌド蚭定の詳现な情報は、man:sio[4] のマニュアルペヌゞを参照しおください。 

=== USB キヌボヌドを持っおいるのですが、FreeBSD で䜿えたすか?

USB デバむスは FreeBSD 3.1 からサポヌトされたしたが、 実装は FreeBSD 3.2 であっおもただ完党ではないため、 必ずしも安定しお動䜜するずは限りたせん。 もし、それでも USB キヌボヌドを䜿っおみたいずいう人は、 以䞋の手順を詊しおみおください。 

[.procedure]
====
. FreeBSD 3.2 か、それ以降を䜿いたす。
. カヌネルコンフィグレヌションファむルに以䞋の行を远加し、 カヌネルを再構築したす。 
+
[.programlisting]
....
device  uhci
device  ohci
device  usb
device  ukbd
options KBD_INSTALL_CDEV
....
+ 
FreeBSD 4.0 より前のバヌゞョンでは、 代わりに次のようにしたす。
+
[.programlisting]
....
controller      uhci0
controller      ohci0
controller      usb0
controller      ukbd0
options         KBD_INSTALL_CDEV
....
+
. [.filename]#/dev# ディレクトリに移動し、 次のようにしおデバむスノヌドを䜜成したす。
+
[source,shell]
....
# cd /dev
# ./MAKEDEV kbd0 kbd1
....
+
. [.filename]#/etc/rc.conf# を線集し、 以䞋の行を远加したす。
+
[.programlisting]
....
usbd_enable="YES"
usbd_flags=""
....
====

システムを再起動させた埌、 AT、USB 䞡方のキヌボヌドが接続されおいれば、 AT キヌボヌドは [.filename]##/dev/kbd0## に、 USB キヌボヌドは [.filename]##/dev/kbd1##になりたす。 䞀方、USB キヌボヌドだけが接続されおいるなら、 [.filename]##/dev/ukbd0## ずなりたす。 

USB キヌボヌドをコン゜ヌルで利甚するには、 それをコン゜ヌルドラむバに察しお明瀺的に指定する必芁がありたす。 システムの初期化の際に、次に瀺すようなコマンドを実行しおください。 

[source,shell]
....
# kbdcontrol -k /dev/kbd1 < /dev/ttyv0 > /dev/null
....

ただし、USB キヌボヌドしか接続されおいない堎合、それは [.filename]#/dev/kbd0# ずしおアクセスされたすので、 コマンドは次のようにしなければなりたせん。ご泚意ください。 

[source,shell]
....
# kbdcontrol -k /dev/kbd0 < /dev/ttyv0 > /dev/null
....

䞊のコマンドは、[.filename]#/etc/rc.i386# に远加するず良いでしょう。 

この蚭定を䞀床行なっおいれば、 X 環境でも特に他の蚭定なしに USB キヌボヌドが利甚できたす。 

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

詳现に぀いおは、man:ukbd:[4] のマニュアルペヌゞを参照しおください。 

=== 珍しいバスマりスを持っおいるのですが、どのように蚭定すればいいのですか?

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

それは FreeBSD 3.0 を含む、それ以前のリリヌスの堎合は次のずおり、

[.programlisting]
....
device mse0 at isa? port 0x23c tty irq5 vector mseintr
....

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

[.programlisting]
....
device mse0 at isa? port 0x23c tty irq5
....

そしお FreeBSD 4.X ずそれ以降では、次のようになりたす。

[.programlisting]
....
device mse0 at isa? port 0x23c irq5
....

通垞バスマりスには専甚のむンタフェヌスカヌドが附属しおいたす。 むンタフェヌスカヌドによっおはポヌトアドレスや割り蟌み番号を䞊蚘の 蚭定以倖に倉曎できるかもしれたせん。詳しくはバスマりスのマニュアルず man:mse[4] のマニュアルペヌゞを参照しおください。 

=== PS/2 マりス (「マりスポヌトマりス」、「キヌボヌドマりス」) を 䜿うにはどのように蚭定すればいいのですか?

あなたが 2.2.5 以降のバヌゞョン FreeBSD を䜿っおいるのなら、 必芁なドラむバ [.filename]#psm# はカヌネルに含たれおいお有効になっおいたす。 カヌネルは起動時に PS/2 マりスを怜出するでしょう。 

あなたの䜿っおいる FreeBSD が比范的新しいけれど前のバヌゞョン (2.1.x 以降) のものなら、 むンストヌルの時に、単にカヌネルのコンフィグレヌションのメニュヌ䞊で PS/2 マりスを有効化するだけです、あるいは埌で `boot:` プロンプト䞊で `-c` を指定するこずでもメニュヌは珟れたす。 デフォルトでは無効に蚭定されおいたすので、 明瀺的に有効化しおあげないずいけたせん。 

あなたの䜿っおいる FreeBSD が比范的叀いものなら、 カヌネルコンフィグレヌションファむルに以䞋の行を加えお カヌネルを再コンパむルする必芁がありたす。 

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

[.programlisting]
....
device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr
....

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

[.programlisting]
....
device psm0 at isa? tty irq 12
....

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

[.programlisting]
....
device psm0 at atkbdc? irq 12
....

カヌネルの再構築に぀いおよく知らないのであれば、 extref:{handbook}kernelconfig[カヌネルのコンフィグレヌション, kernelconfig]を参照しおください。

起動時にカヌネルが [.filename]#psm0# を怜出したら、 [.filename]#psm0# の゚ントリが [.filename]#/dev# の䞭にあるこずを確認しおください。それには、以䞋のようにしたす。 

[source,shell]
....
# cd /dev; sh MAKEDEV psm0
....
これは `root` でログむンしおいるずきに行なっおください。 

[[moused]]
=== X Window System 以倖の環境でマりスを䜿うこずは可胜ですか?

もしデフォルトのコン゜ヌルドラむバである syscons を䜿っおいるのであれば、 テキストコン゜ヌル䞊でマりスを䜿っお、 テキストのカットアンドペヌストができたす。 マりスデヌモンである moused を起動し、 仮想コン゜ヌルでマりスポむンタを有効にしおください。 

[source,shell]
....
# moused -p /dev/xxxx -t yyyy
# vidcontrol -m on
....

ここで _xxxx_ はマりスのデバむス名、 _yyyy_ はマりスのプロトコルタむプです。 サポヌトされおいるプロトコルタむプに぀いおは man:moused[8] のマニュアルペヌゞを参照しおください。 

システムを起動する時に自動的に moused を起動したい堎合には、次のようにしたす。 FreeBSD 2.2.1 では以䞋の倉数を [.filename]#/etc/sysconfig# で蚭定しおください。

[.programlisting]
....
mousedtype="yyyy"
mousedport="xxxx"
mousedflags=""
....

FreeBSD 2.2.2 以降のバヌゞョンでは [.filename]#/etc/rc.conf# で以䞋のように蚭定したす。

[.programlisting]
....
moused_type="yyyy"
moused_port="xxxx"
moused_flags=""
....

FreeBSD 3.1 ずそれ以降で PS/2 マりスを利甚する堎合は、 `moused_enable="YES"` を [.filename]#/etc/rc.conf# に曞き加えるだけです。

たた、起動時にすべおの仮想端末で、 暙準のコン゜ヌルに加えマりスデヌモンも䜿えるようにしたい、 ずいう堎合には、以䞋の行を [.filename]#/etc/rc.conf# に加えたす。 

[.programlisting]
....
allscreens_flags="-m on"
....

FreeBSD 2.2.6 以降の堎合で 比范的新しいシリアルマりスを䜿っおいるならば、 マりスデヌモンはマりスのプロトコルタむプを自動刀別できたす。 自動刀別を詊みるには、プロトコルタむプずしお `auto` を指定したす。 

マりスデヌモンを実行䞭は、マりスデヌモンず他のプログラム (たずえば X Window System) の間でマりスぞのアクセスを調敎しなければなりたせん。 この問題に぀いおは <<x-and-moused,X ずマりス>>をご芧ください。 

=== マりスを䜿っお、 テキストコン゜ヌルでカットアンドペヌストするにはどうしたらよいのですか?

マりスデヌモンを起動 (<<moused,前の質問に察する答え>>を参照しおください) したあず、 ボタン 1 (巊ボタン) を抌しながらマりスを動かしお範囲を指定したす。 ボタン 2 (䞭ボタン) たたはボタン 3 (右ボタン) をクリックするずテキスト カヌ゜ルの䜍眮に遞択した範囲のテキストがペヌストされたす。 

FreeBSD 2.2.6 以降では、ボタン 2 をクリックするずペヌストされ、ボタン 3 をクリックした堎合に既存の遞択範囲が珟圚のマりスポむンタの䜍眮たで 「延長たたは短瞮」されたす。もしマりスに䞭ボタンがないなら、 moused のオプションを䜿っお䞭ボタンの゚ミュレヌションをするか、 他のボタンを䞭ボタンずしお䜿う事ができたす。 詳しくは man:moused[8] のマニュアルペヌゞを参照しおください。 

=== USB マりスを持っおいるのですが、FreeBSD で䜿えたすか?

USB デバむスは FreeBSD 3.1 からサポヌトされたしたが、 実装は FreeBSD 3.2 であっおもただ完党ではないため、 必ずしも安定しお動䜜するずは限りたせん。 もし、それでも USB マりスを䜿っおみたいずいう人は、 以䞋の手順を詊しおみおください。 

[.procedure]
====
. FreeBSD 3.2 か、それ以降を䜿いたす。
. カヌネルコンフィグレヌションファむルに以䞋の行を远加し、 カヌネルを再構築したす。 
+
[.programlisting]
....
device  uhci
device  ohci
device  usb
device  ums
....
+ 
FreeBSD 4.0 より前のバヌゞョンでは、 代わりに次のようにしたす。
+
[.programlisting]
....
controller      uhci0
controller      ohci0
controller      usb0
device          ums0
....
+
. [.filename]#/dev# ディレクトリに移動し、 次のようにしおデバむスノヌドを䜜成したす。
+
[source,shell]
....
# cd /dev
# ./MAKEDEV ums0
....
+
. [.filename]#/etc/rc.conf# を線集し、 以䞋の行を远加したす。
+
[.programlisting]
....
moused_enable="YES"
moused_type="auto"
moused_port="/dev/ums0"
moused_flags=""
usbd_enable="YES"
usbd_flags=""
....
+ 
moused の蚭定の詳现に぀いおは、 <<moused,前項>>も参照しおください。 
. X のセッションで USB マりスを䜿うには、 [.filename]#XF86Config# を線集する必芁がありたす。 XFree86 3.3.2、もしくはそれ以降を利甚しおいる堎合は、 _Pointer_ セクションが次のようになっおいるこずを確認しおください。 
+
[.programlisting]
....
Device          "/dev/sysmouse"
Protocol        "Auto"
....
+ 
それより前のバヌゞョンの XFree86 を利甚しおいる堎合は、 _Pointer_ セクションが次のようになっおいるこずを確認しおください。 
+
[.programlisting]
....
Device          "/dev/sysmouse"
Protocol        "SysMouse"
....
====

X 環境でのマりスの利甚に぀いおは、 <<x-and-moused,他の項>>も参照しおください。 

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

=== わたしのマりスにはホむヌル機胜や䟿利なボタンが぀いおいるのですが、 これは FreeBSD でも䜿えるのですか?

答えは残念ながら「堎合によりたす」です。 こうしたマりスの付加的な機胜は倧抵の堎合、特殊なドラむバを必芁ずしたす。 マりスのデバむスドラむバやナヌザのプログラムが そのマりスに察する固有のサポヌトをしおいない堎合には、 暙準的な 2 ボタン/3 ボタンマりスのように振舞いたす。 

X りィンドりシステムの環境でのホむヌルの䜿い方に぀いおは、 <<x-and-wheel,X ずホむヌル>>の項をご芧ください。 

===  わたしのマりスはきちんず動いおくれないようです。 マりスカヌ゜ルが画面䞭をずびたわりたす。 このマりスにはホむヌルが぀いおいお、 接続は PS/2 ポヌトです。

FreeBSD 3.2 およびそれ以前の PS/2 マりスドラむバ psm には、 Logitech モデル M-S48 ずその OEM のホむヌルマりスで䞍具合が発生したす。 以䞋のパッチを [.filename]#/sys/i386/isa/psm.c# に適甚しお、カヌネルを再構築しおください。 

[.programlisting]
....
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 より新しいリリヌスではきちんず動䜜するはずです。 

=== ラップトップ PC のマりス/トラックボヌル/タッチパッドは䜿えたすか?

<<ps2mouse,前の質問に察する答え>>ず、 <<pao,モバむルコンピュヌティングのペヌゞ>>をご芧ください。 

=== どんなテヌプドラむブをサポヌトしおいたすか?

FreeBSD は SCSI ず QIC-36 (QIC-02 むンタフェヌス付き) をサポヌトしおいたす。 これらには 8-mm (Exabyte ず呌ばれおいたす) や DAT ドラむブも含たれおいたす。 

初期の 8-mm ドラむブの䞭には SCSI-2 ずたったく互換性を持たないものがありたす。 これらは FreeBSD 䞊では動䜜したせん。 

=== どんなテヌプチェンゞャヌをサポヌトしおいたすか?

FreeBSD 2.2 は man:ch[4] デバむスず man:chio[1] コマンドを䜿甚した SCSI チェンゞャヌをサポヌトしおいたす。 実際のチェンゞャヌの制埡方法の詳现は、man:chio[1] のマニュアルペヌゞを参照しおください。 

䜿甚しおいる補品が AMANDA のようにチェンゞャヌに察応枈みのものでない堎合は、 次のこずに぀いお留意しおください。 それらの補品は任意のポむント間のテヌプの移動を制埡するだけなので、 テヌプがどのスロットに入っおいるか、珟圚ドラむブにあるテヌプが どのスロットに戻るべきかを把握しおおく必芁がありたす。 

=== どんなサりンドカヌドをサポヌトしおいたすか?

FreeBSD は SoundBlaster、SoundBlaster Pro、SoundBlaster 16、 Pro Audio Spectrum 16、AdLib それから Gravis UltraSound サりンドカヌドを サポヌトしおいたす。MPU-401 やその互換カヌドも機胜に制限はあるものの サポヌトされおいたす。マむクロ゜フトサりンドシステムのスペックに準拠 したカヌドも、[.filename]#pcm# ドラむバでサポヌトされおいたす。 

[NOTE]
====
これらはサりンドに぀いおのみの話です! これらのドラむバは CD-ROM、SCSI、カヌド䞊にあるゞョむスティックをサポヌトしおいたせん (SoundBlaster は䟋倖です)。SoundBlaster SCSI むンタフェヌスず非 SCSI CD-ROM はサポヌトしおいたすが、そのデバむスからは起動できたせん。 
====

=== pcm ドラむバで es1370 から音が出ないのはどうにかなりたせんか?

マシンを起動するごずに以䞋のコマンドを実行しおください。

[source,shell]
....
# mixer pcm 100 vol 100 cd 100
....

=== どんなネットワヌクカヌドをサポヌトしおいたすか?

より完党な䞀芧に぀いおはextref:{handbook}[むヌサネットカヌド]の節を参照しおください。

=== 数倀挔算コプロセッサを持っおいたせんが、䜕かたずいでしょうか?

[NOTE]
====
これらは 386/486SX/486SLC を持っおいる堎合に圱響したす - ほかのマシンでは CPU に内蔵されおいたす。 
====

䞀般にこれらは問題ずはなりたせん。 しかし、数倀挔算゚ミュレヌションコヌドのパフォヌマンスか、 正確さのいずれかを遞択する状況がありたす (詳しくは <<emul,FP ゚ミュレヌション>> に぀いおの節をご芧ください)。 ずくに、X 䞊で匧を描く際にずおも遅くなるこずでしょう。 数倀挔算コプロセッサを賌入されるこずを匷くおすすめしたす。 ずおも圹立぀こずでしょう。 

[NOTE]
====
他の数倀挔算コプロセッサよりも優れたコプロセッサもありたす。 これは蚀いにくいこずなのですが、Intel を買うために躍起になる人もいないでしょう。 それが FreeBSD 䞊で動くずいう確信がないのなら、クロヌンにご甚心を。 
====

=== FreeBSD がサポヌトするデバむスは他にもあるんでしょうか?

extref:{handbook}[FreeBSD ハンドブック]に蚘されおいる、 サポヌトされおいる他のデバむスの䞀芧を参照しおください。

=== パワヌマネヌゞメント機胜付きのラップトップ PC を持っおいるのですが 。

FreeBSD は䞀郚のマシンの APM をサポヌトしおいたす。 [.filename]#LINT# カヌネルコンフィグファむル の APM の郚分をご芧ください。 さらに詳しいこずは man:apm[4] に茉っおいたす。 

=== Micron システムが起動時に固たっおしたいたす。

特定の Micron 補のマザヌボヌドの䞭には、PCI BIOS が芏栌通りに 実装されおいないために FreeBSD の起動に倱敗するものがありたす。 その BIOS は、PCI デバむスをあるアドレスで蚭定したず報告するにも 関わらず、実際にはそうしおいないのです。 

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

=== 新しい Adaptec コントロヌラを持っおいるのですが、 FreeBSD が怜出できないようです。

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

=== 内蔵の Plug & Play モデムを持っおいるのですが、FreeBSD が怜出できないようです。

モデムの PnP ID を シリアルドラむバの PnP ID リストに远加する必芁があるでしょう。 Plug & Play サポヌトを有効にするには、 `controller pnp0` をコンフィグレヌション ファむルに付け加え、 新しいカヌネルをコンパむルしおシステムを再起動しおください。 カヌネルは、怜出したすべおのデバむスの PnP ID を衚瀺したす。 モデムの欄にある PnP ID を [.filename]#/sys/i386/isa/sio.c# の 2777 行目くらいにあるテヌブルに曞き入れおください。 テヌブルを芋぀けるには、構造䜓 `siopnp_ids[]` の文字列 `SUP1310` を探したす。 カヌネルを䜜り盎したらむンストヌルし、システムを再起動しおください。 そうすれば、モデムが怜出されるはずです。 

起動時のコンフィグレヌションの際に、`pnp` コマンドを䜿甚しお PnP の蚭定をマニュアルで行なわなければならないかもしれたせん。 その堎合、モデムを怜出させるためのコマンドは

[.programlisting]
....
pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8
....

のようになりたす。 

=== シリアルコン゜ヌルで boot: プロンプトを衚瀺するにはどうすればいい?

. `options COMCONSOLE` を指定しおカヌネルを構築しおください。 
. そしお [.filename]#/boot.config# を䜜成しお `-P` ずだけ曞き入れおください。 
. その埌、キヌボヌドをシステムから抜きたす。

[.filename]#/usr/src/sys/i386/boot/biosboot/README.serial# に、 これに関する情報が曞かれおいたす。 

=== なぜ Micron コンピュヌタで 3Com PCI ネットワヌクカヌドが動かないのでしょう?

特定の Micron 補のマザヌボヌドの䞭には、PCI BIOS が芏栌通りに 実装されおいないために FreeBSD の起動に倱敗するものがありたす。 その BIOS は、PCI デバむスをあるアドレスで蚭定したず報告するにも 関わらず、実際にはそうしおいないのです。 

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

=== 察称型マルチプロセシング (SMP) をサポヌトしおいたすか?

SMP は、3.0-STABLE ずそれ以降のリリヌスでのみサポヌトされおいたす。 _GENERIC_ カヌネルでは SMP は有効化されおいたせんので、 SMP を有効化するにはカヌネルを再構築する必芁がありたす。 [.filename]#/sys/i386/conf/LINT# を芋お、 カヌネルコンフィグファむルにどのオプションを远加すれば良いのか確かめおください。

=== ASUS K7V マザヌボヌドのシステムでブヌトフロッピヌを䜿うず、 システムがハングアップしたす。 察応策はありたせんか? 

BIOS セットアップで "起動時のりィルス保護機胜" を無効化しおください。

== トラブルシュヌティング

=== ハヌドディスクに䞍良ブロックがありたす!

SCSI ディスクの堎合は自動的に再マップする機胜があるはずです。 しかし、理解し難い理由から倚くのドラむブがこの機胜が無効化 されお出荷されおいたす...。 

これを有効化するには、 最初のデバむスのモヌドペヌゞを倉曎する必芁がありたす。 これは次のコマンドを実行するこずで、FreeBSD 䞊で行なうこずができたす (`root` 暩限で行ないたす)。 

[source,shell]
....
# scsi -f /dev/rsd0c -m 1 -e -P 3
....

そしお、AWRE ず ARRE の倀を 0 から 1 ぞ倉曎したす 

[source,shell]
....
AWRE (Auto Write Reallocation Enbld):  1
ARRE (Auto Read Reallocation Enbld):  1
....

以䞋は、link:mailto:[email protected][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 を利甚する䞊で、泚意しなければならない点が䞀぀ありたす。 それは、䞍良ブロックスペシャルファむルは、 ディスクの最終トラックに眮かれるずいうこずです。 このファむルには、ディスクの先頭の付近、 [.filename]#/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 によるフォヌマットずパヌティション確保を含みたす)。 

もし、䞍良ブロックの再マッピングを有効にしおいお䞍良ブロックが芋付かったら、 ドラむブの亀換を考えおください。䞍良ブロックは、時間ずずもに悪化するからです。 

=== 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 に合わせる必芁があるでしょう。 

=== HP Netserver 䞊のオンボヌド SCSI コントロヌラが認識されたせん。

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

ですから珟時点での最良の方法は、カヌネルオプションの `EISA_SLOTS` を 12 に倉え、 アドレス空間の衝突がないかの ようなふりをさせるこずです :) extref:{handbook}kernelconfig[カヌネルの再構築, kernelconfig]に蚘述されおいるようにしおカヌネルを再構築しおください。

もちろん、これはこのようなマシンにむンストヌルする際に 「卵が先か、 鶏が先か」ずいった問題を生み出すこずになりたす。 この問題を回避するために、 _ナヌザコンフィグ (UserConfig)_ の䞭には特別な仕組みが組み蟌たれおいたす。 このずき "visual" むンタフェヌスは䜿甚せず、 コマンドラむンむンタフェヌスを䜿甚しおください。単玔に 

[.programlisting]
....
eisa 12
quit
....

ずプロンプト䞊から打ち蟌み、 埌は普通にむンストヌルを行なっおください。 ずにかくカスタムカヌネルのコンパむルずむンストヌルを行なうこずを おすすめしたす。 

うたくいけば、将来のバヌゞョンではこの問題が解決しおいるこずでしょう。 

[NOTE]
====
HP Netserver では``危険芚悟の専甚ディスク``は䜿甚できたせん。 詳现に぀いおは <<dedicate,この泚意事項>>をご芧ください。 
====

=== この CMD640 IDE コントロヌラはどこかおかしいようです。

それは壊れおいるのです。䞡方のチャンネルを同時に制埡できないのです。 

珟圚、このチップを䜿っおいるシステムを自動的に怜出しお、 うたく動かすためのしくみが䜿えるようになっおいたす。 くわしくは wd(4) のマニュアルペヌゞを参照しおください。 

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

=== ed1: timeout のようなメッセヌゞがい぀も出たす。

たぶん IRQ の衝突が原因でしょう (二぀のボヌドが同じ IRQ を䜿甚しおいるなど)。FreeBSD 2.0.5R 以前はこれに関しお寛倧で、 IRQ の衝突があっおもネットワヌクドラむバは機胜しおいたした。 しかし 2.0.5R 以降はもはや、IRQ の衝突に寛倧ではありたせん。 `-c` オプションを぀けお起動し、 ed0/de0/... の゚ントリをボヌドの蚭定に合わせおください。 

ネットワヌクカヌドの BNC コネクタ (蚳泚: 10BASE-2 タむプのむンタフェヌス) を䜿っおいる堎合、 デバむスのタむムアりトはタヌミネヌションの䞍良によっおも起きたす。 これをチェックするにはケヌブルを倖しおタヌミネヌタを盎接 NIC に接続したす。そしお゚ラヌメッセヌゞが消えるかどうか 確認したす。 

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

=== CDROM をマりントしようずするず Incorrect super block ず蚀われたす。

man:mount[8] にマりントしたいデバむスのタむプを指定する必芁がありたす。 デフォルトでは man:mount[8] はファむルシステムを `ufs` ずみなしたす。CDROM のファむルシステムを マりントしたいのであれば `-t cd9660` ず man:mount[8] にオプションを぀けお明瀺する必芁がありたす。 これはもちろん CDROM が ISO 9660 ファむルシステムである堎合です。ほずんどの CDROM はこの圢匏です。1.1R の FreeBSD では (蚳泚: 2.1.5R、 2.2R でも同様です) 自動的に Rock Ridge 拡匵 (長いファむル名ぞの察応) をうたく解釈したす。 

CDROM のデバむス [.filename]#/dev/cd0c# を [.filename]#/mnt# にマりントしたい堎合の䟋では、次のようにしたす。 

[source,shell]
....
# mount -t cd9660 /dev/cd0c /mnt
....

デバむスの名前はむンタフェヌスによっおは別の名前になっおいる かもしれないので泚意しおください ([.filename]#/dev/cd0c# はこの堎合の䟋です)。 オプション `-t cd9660` によっお `mount_cd9660` コマンドが実行されるこずに泚意しおください。 このため䟋は次のようにするこずもできたす。 

[source,shell]
....
# mount_cd9660 /dev/cd0c /mnt
....

=== CDROM をマりントしようずするず Device not configured ず蚀われたす。

これは 䞀般的に CDROM ドラむブの䞭に CDROM が入っおいないか、 ドラむブがバス䞊に芋えないこずを意味したす。ドラむブに CDROM を入れるか、IDE (ATAPI) であれば master/slave の状態をチェックしおください。 たた、CDROM ドラむブに CDROM を入れおから認識するたでには数秒かかりたすので、 少し埅っおみおください。 

SCSI CDROM ではバスリセットぞの応答時間が遅いために、 倱敗するこずがあるかもしれたせん。 SCSI CDROM を持っおいる堎合は、 カヌネルコンフィグレヌションファむルに以䞋の行を加えお 再コンパむルしお詊しおみおください。 

[.programlisting]
....
options "SCSI_DELAY=15"
....

[NOTE]
====
珟圚の GENERIC カヌネルでは䞊の蚭定はデフォルトになっおいたす。 問題がある堎合は `SCSI_DELAY` の数倀を増やしおみおください。 
====

=== CDROM をマりントするず、ファむル名䞭の英数字以倖の 文字が、? ず衚瀺されおしたいたす。

もっずもありそうなのは、その CDROM が "Joliet" 拡匵を利甚しおファむルおよび ディレクトリに関する情報を保存しおいるずいうこずです。この拡匵は、 すべおのファむル名を Unicode の 2 バむト文字で保存するように 芏定しおいたす。珟圚、FreeBSD カヌネルに汎甚的な Unicode むンタフェヌスを導入する䜜業が行われおいたすが、 ただ完了しおいたせん。したがっお、CD9660 ドラむバはファむル名の文字を解読できたせん。

䞀時的な解決策ずしお、FreeBSD 4.3R 以降では、CD9660 ドラむバに特別な仕掛けを斜しお、ナヌザヌがその堎で適切な 倉換衚を読み蟌めるようにしたした。䞀般的な゚ンコヌディングに 察応したいく぀かのモゞュヌルが [.filename]#sysutils/cd9660_unicode# port で提䟛されおいたす。

[NOTE]
====
この蚘述は叀くなっおいたす。<<CDROM-UNICODE-FILENAMES,英語版の蚘述>>をご芧ください。
====

=== 私のプリンタはずお぀もなく遅いのです。 どうしたらよいのでしょう?

パラレルむンタフェヌスで、問題はずんでもなく遅いだけであるなら、 プリンタボヌトを "polled" モヌドに蚭定しおみおください。

[source,shell]
....
# lptcontrol -p
....

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

=== わたしのプログラムは時々 Signal 11 の゚ラヌで止たっおしたいたす。

Signal 11 ゚ラヌはオペレヌティングシステムが 蚱可を䞎えおいないメモリにアクセスしようずしたずきに発生したす。 このようなこずがランダムな間隔で起っおいるようなら、 泚意深く調査しおいった方が良いです。

この手の問題はたいおいの堎合、以䞋のどちらかです。

. その問題が特定の、 あなたが自分で開発したアプリケヌションでのみ起っおいるなら、 あなたのコヌドにバグがあるのでしょう。
. それが FreeBSD のベヌスシステムの䞀郚ず関連する問題なら、 コヌドにバグがあるずいうこずになりたす。 しかしほずんどの堎合、 普通の FAQ の読者がそのようなコヌドを䜿うようになるずっず前に、 そういった問題は発芋され、修正されおいるはずです (それが -current の圹目なのですから)。

それが FreeBSD のバグでは「ない」ずいう決定的なケヌスずしお、 その問題の発生がプログラムをコンパむルしおいるずきであり、 コンパむル毎に毎回、コンパむラの挙動が倉るずいうものがありたす。

たずえば、あなたが "make buildworld" を実行しおいお、 コンパむラが ls.c から ls.o をコンパむルしようずしたずきに コンパむルに倱敗したずしたす。もう䞀床 "make buildworld" を実行したずきに、たったく同じ堎所でコンパむルが倱敗したのなら、 それは build が壊れおいる (蚳泚: ぀たり゜ヌスにバグがある) ず蚀うこずです -- ゜ヌスを曎新しおやりなおしおみおください。 もしコンパむルが別の堎所でしくじっおいたら、 それはハヌドりェアの問題です。

あなたのやるべき事は:

前者の堎合は、 そのプログラムの間違ったアドレスぞアクセスしようずしおいる郚分を、 gdb 等のデバッガで芋぀けお修正したす。

埌者の堎合は、 ハヌドりェアに問題がないこずを確かめる必芁がありたす。

その䞀般的な原因ずしお :

. ハヌドディスクが熱を持ちすぎおいるかも知れたせん: ケヌスのファンがちゃんず動いおいおディスクを冷やしおいるか 確かめおください (たぶん、他の郚品も過熱しおいたす)。
. CPU がオヌバヌヒヌトしおいたす: CPU をオヌバヌクロックしおいたせんか? さもなければ CPU ファンが死んでいるのかもしれたせん。 いずれにせよ、少なくずも問題解決の間では ハヌドりェアが動くべく指定された条件で動かしおください。 クロックはデフォルトの蚭定に戻しおください。
+ 
もしあなたがクロックアップをしおいるのなら、 遅いシステムでも、システムが焌き付いお 買い換えなければならなくなるよりずっずマシだずいうこずを 芚えおおいた方が良いでしょう。 倧きいコミュニティでは特に、 あなたがそれが安党だず思っおいるかどうかは関係なく、 オヌバヌクロックしたシステムに発生した問題には同情的ではありたせん。
. 怪しいメモリ: もし耇数の SIMM や DIMM を䜿っおいるならそれを党郚抜いおから 各 SIMM や DIMM を別個に組み蟌んだシステムを立ち䞊げおるこずで どの DIMM/SIMM が怪しいのか、それずも組合わせが悪いのか ず問題の幅が狭たりたす。
. 楜芳的すぎるマザヌボヌドの蚭定: ほずんどの堎合に暙準蚭定で十分なタむミングを、 BIOS の蚭定やマザヌボヌド䞊のゞャンパピンを倉えるこずで、 さたざたに倉曎するこずができたす。しかし時には RAM の アクセスりェむトを䜎くしすぎたり "RAM Speed: Turbo" や その手の BIOS の蚭定でおかしな挙動が起こるこずがありたす。 BIOS を暙準の蚭定に戻すずいうのはいいアむディアですが、 その前にあなたの蚭定を曞き留めおおいた方がいいでしょう。
. マザヌボヌドぞの電源が安定しおいない。 もし䜿っおいない I/O ボヌドやハヌドディスク、 CDROM 等があるなら、䞀旊それらから電源ケヌブルを抜き、 電源が小さな負荷ならなんずか動䜜するか確認したしょう。 あるいは別の電源を詊しおみたしょう。 その時はなるべく、少し容量の倧きいもので詊したしょう (たずえば、今の電源容量が 250W だったら 300W のものを詊したす)。

SIG11 FAQ (䞋に瀺したす) にはこれらの問題のすべおが 詳しく説明されおいたす。Linux の芖点に基づくものですが、 これも読んでおいた方がいいでしょう。そこではたた、 メモリのテストを行う゜フトりェアや、 ハヌドりェアがなぜ問題のあるメモリを芋逃しおしたうかに぀いおも 議論されおいたす。

最埌に、これらがどれも助けにならなかったら、 FreeBSD のバグを発芋した可胜性がありたす。 以䞋の説明を読んで障害報告を送っおください。

詳现な FAQ は、link:http://www.bitwizard.nl/sig11/[the SIG11 problem FAQ] にありたす。

=== 起動の時に画面が真っ暗になっお同期も取れたせん。

これは ATI Mach 64 ビデオカヌドの既知の問題です。 この問題はカヌドがアドレス `2e8` を䜿い、 4 番目のシリアルポヌトもここを䜿うずいうこずにありたす。 man:sio[4] ドラむバのバグ (仕様?) のため、 4 番目のシリアルポヌトがなくおも、 通垞このアドレスを䜿う sio3 (4 番目のポヌトにあたりたす) を無効にしおも、ドラむバはこのアドレスをさわりたす。 

バグが修正されるたでは、次のようにしお察凊しおください。 

. 起動プロンプトが出たら `-c` ず入力したす (これによりカヌネルはコンフィグレヌションモヌドに入りたす)。 
. [.filename]#sio0#, [.filename]#sio1#, [.filename]#sio2#, [.filename]#sio3# (これらすべお) を無効にしたす。 これによっお man:sio[4] ドラむバは動䜜しなくなりたすが、問題はありたせん。 
. exit ず入力しお起動を続行したす。

もしシリアルポヌトを有効にしたいのであれば以䞋の倉曎を行なっお 新しいカヌネルを䜜る必芁がありたす。 [.filename]#/usr/src/sys/i386/isa/sio.c# の䞭で 1 ヵ所ある `0x2e8` ずいう文字列を探し、 この文字列ずその手前にあるコンマを削陀したす (埌ろのコンマは残したす)。 埌は通垞の手続きにしたがっお新しいカヌネルを䜜りたす。 

この察凊を行なった埌でもただ X りィンドりシステムはうたく動かないかもしれたせん。 その堎合は、 䜿甚しおいる XFree86 がすくなくずも XFree86 3.3.3 以降であるこずを確かめおください。 それ以降のバヌゞョンでは、 Mach64 カヌドやそれらのカヌドのために぀くられた X サヌバ の組蟌みをサポヌトしたす。 

=== 128MB の RAM があるのですが、64MB しか認識したせん。

FreeBSD がメモリのサむズを BIOS から取埗する方法の制限により、 KB 単䜍で 16 ビット分たでしか怜出できたせん (すなわち最倧 65535KB=64MB です。これより少ない堎合もありたす。 ある BIOS の堎合はメモリサむズが 16MB に制限されたす)。 64MB 以䞊のメモリを積んでいる堎合、 FreeBSD はそれを怜出しようずしたす。 しかしその詊みは倱敗するかもしれたせん。 

この問題を回避するには、 以䞋に瀺すカヌネルオプションを䜿甚する必芁がありたす。 完党なメモリ情報を BIOS から取埗する方法もありたすが、 起動ブロックに空きが無いため実装できたせん。 起動ブロックの問題が解決されれば、 い぀か拡匵 BIOS 機胜を䜿甚しお完党なメモリ情報を取埗できるようになるでしょう。 ずりあえず珟圚は、カヌネルオプションを䜿っおください。 

`options "MAXMEM=n"`

_n_ には、 キロバむト単䜍でメモリの量を指定したす。128MB の堎合は、`131072` ずなりたす。 

=== FreeBSD 2.0 が kmem_map too small! ず蚀っおパニックしたす。

[NOTE]
====
メッセヌゞは、`mb_map too small!` の堎合もありたす。 
====

このパニックは、ネットワヌクバッファ (特に mbuf クラスタ) の仮想メモリが無くなったこずを瀺したす。 以䞋のオプションをカヌネルコンフィグファむルに远加しお mbuf クラスタに䜿甚できる仮想メモリの量を増やしおください。 

`options "NMBCLUSTERS=n"`

_n_ には、 同時に䜿甚したい TCP コネクションの数に応じお 512 から 4096 たでの数倀を指定できたす。 ずりあえず 2048 を詊しおみるのをおすすめしたす。 これでパニックは完党の予防できるはずです。 mbuf クラスタの割り圓お、䜿甚状況に぀いおは、 `netstat -m` で知るこずができたす (man:netstat[1] をご芧ください)。 `NMBCLUSTERS` のデフォルト倀は `512 + MAXUSERS * 16` です。 

=== 新しいカヌネルで再起動するず CMAP busy panic ずなっおパニックを起こしおしたいたす。 

ファむル [.filename]#/var/db/kvm_*.db# においお範囲倖のデヌタを怜出するためのロゞックは倱敗するこずがあり、 こうした矛盟のあるファむルを䜿甚するこずでパニックを匕き起こすこずがありたす。 

これが起こったなら、シングルナヌザで再起動した埌に、 以䞋のコマンドを実行しおください。 

[source,shell]
....
# rm /var/db/kvm_*.db
....

=== ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 ずいう゚ラヌが出たす

これは Ultrastor SCSI Host Adapter ず衝突しおいたす。 

起動時に kernel configuration メニュヌに入り、 問題を起こしおいる [.filename]#uha0# を disable にしたしょう。 

=== sendmail が mail loops back to myself ずいうメッセヌゞを出すのですが。

この事は、sendmail FAQ に次のように曞いおありたす。 

....
      * "Local configuration error" ずいうメッセヌゞが出たす。たずえば:

      553 relay.domain.net config error: mail loops back to myself
      554 <[email protected]>... Local configuration error

      のような物ですが、どのようにしたらこの問題を解決できたすか?

      これは、たずえば domain.net のようなドメむン宛おのメヌルを MX record で
      特定のホスト (ここでは relay.domain.net) に送ろうずしたのに、
      そのホストでは domain.net 宛おのメヌルを受け取れるような蚭定に
      なっおいない堎合です。蚭定の際に FEATURE(use_cw_file) を
      指定しおある堎合には /etc/sendmail.cw の䞭に domain.net を
      远加しおください。もしくは、/etc/sendmail.cf の䞭に
      "Cw domain.net" を远加しおください。
....

もはや珟圚の link:ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/sendmail-faq[sendmail FAQ] は sendmail release ずは䞀緒には保守されおいたせん。 しかし次のネットニュヌスに定期的に投皿されおたす。 link:news:comp.mail.sendmail[comp.mail.sendmail]、 link:news:comp.mail.misc[comp.mail.misc]、 link:news:comp.mail.smail[comp.mail.smail]、 link:news:comp.answers[comp.answers]、 link:news:news.answers[news.answers]。 たた、メヌル経由でコピヌを入手する堎合は link:mailto:[email protected][[email protected]] 宛たで本文に `send usenet/news.answers/mail/sendmail-faq` ず曞いお送りたす。 

=== リモヌトマシン䞊のフルスクリヌンアプリケヌションがうたく動かない

リモヌトマシンのタヌミナルタむプが FreeBSD のコン゜ヌルで必芁ずされおいる `cons25` 以倖のものです。 

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

* リモヌトマシンにログむンした埌、 そのリモヌトマシンが `ansi` か `sco` のタヌミナルタむプを知っおいるなら、 shell 倉数の TERM にそれらのいずれかを蚭定したす。 
* FreeBSD のコン゜ヌル偎で screen のような VT100 ゚ミュレヌタを䜿甚したす。 screen は䞀぀のタヌミナルの䞭で耇数のセッションを䞊列動䜜させるこずができたすし、 本来の機胜も優れおいたす。 各々の screen のりィンドりは VT100 タヌミナルのように振る舞うので、 リモヌト偎で蚭定されるべき TERM 倉数は `vt100` ずなりたす。 
* リモヌトマシンのタヌミナルデヌタベヌスに `cons25` の゚ントリをむンストヌルしたす。 このむンストヌル方法はリモヌトマシンのオペレヌティングシステムに䟝存したす。 リモヌトのシステムのシステム管理マニュアルが圹に立぀こずでしょう。 
* FreeBSD 偎で X サヌバを起動しお、 リモヌトマシンに `xterm` や `rxvt` のような X ベヌスのタヌミナル゚ミュレヌタを䜿っおログむンしたす。 (蚳泚: 日本語が必芁な堎合は `kterm` 等を 利甚したす) リモヌトホストの TERM 倉数は `xterm` もしくは `vt100` (蚳泚: もしくは `kterm`) に蚭定したす。 

=== 私のマシンで calcru: negative time... ず衚瀺されるのですが

これは、割り蟌みに関連するさたざたな䞍具合によっお発生したす。 あるいは、あるデバむスが元々持っおいるバグが衚面化したのかも知れたせん。 この症状を再珟させる䞀぀の方法ずしお、パラレルポヌト䞊で、 TCP/IP を 倧きな MTU で走らせるずいうものがありたす。 グラフィックアクセラレヌタがこの症状を起こすこずがありたすが、 その堎合はたず、カヌドの割り蟌み蚭定を確認しおください。 

この問題の副䜜甚ずしお、 プロセスが "SIGXCPU exceeded cpu time limit" ずいうメッセヌゞずずもに終了しおしたう、ずいうものがありたす。

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

[source,shell]
....
# sysctl -w kern.timecounter.method=1
....

これは、パフォヌマンスぞ匷い圱響を䞎えたすが、 問題の発生に比べればおそらく気にならない皋床でしょう。 もし、これでもただ問題が残るようなら、 カヌネルオプションの `NTIMECOUNTER` を倧きな倀に増やしおください。 `NTIMECOUNTER=20` にたで増やしおも解決しない堎合は、 蚈時凊理の信頌性が保おない皋の割り蟌みが、 そのマシン䞊で起こっおいるこずを意味したす。 

=== pcm0 not found ずいう衚瀺を芋たり カヌネルコンフィグレヌションファむルには device pcm0 ず 曞いおあるのにサりンドカヌドが pcm1 ずしお 発芋されたりしたす。

これは FreeBSD 3.x で PCI のサりンドカヌドを䜿っおいるずきに 発生したす。`pcm0` デバむスは ISA のカヌド専甚に予玄されおいるものです。このため、 あなたが PCI カヌドを持っおいるずきはこの゚ラヌが衚瀺され、 カヌドは `pcm1` ずしお怜出されたす。 

[NOTE]
====
この譊告を、単にカヌネルコンフィグファむルの圓該行を `device pcm1` に倉曎するこずで 抑制するこずはできたせん。その時は `pcm1` が ISA カヌドのために予玄され、PCI のカヌドは `pcm2` ずしお (`pcm1 not found` の譊告ずずもに) 怜出されたす。
====

PCI のサりンドカヌドを持っおいるのならば、以䞋のようにしお `snd0` デバむスのかわりに `snd1` を䜜る必芁がありたす。

[source,shell]
....
# cd /dev
# ./MAKEDEV snd1
....

この状況は FreeBSD 4.x では生じたせん。倚くの努力の結果より __PnP 䞭心__に䜜り替えられ、 珟圚、`pcm0` デバむスは ISA カヌド専甚に予玄されたものではなくなりたした。

=== プラグアンドプレむのカヌドが認識されなくなりたした (たたは、unknown ず認識されるようになりたした)。

珟圚の FreeBSD 4.x はより __PnP 䞭心__に なっおいたす。その副䜜甚の圱響で、FreeBSD 3.x で動いおいた PnP デバむス (たずえばサりンドカヌドや内蔵モデム) の䞭には、 動かなくなっおしたったものもありたす。

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

PnP BIOS はあらかじめ、[モデムを] ポヌト空間に存圚しおいるかのように蚭定したす。 そのため [3.x では] 埓来の手法に基づく ISA デバむスの怜玢により、モデムの存圚を「発芋」できたす。 

4.0 の ISA コヌドは、より PnP 䞭心になっおいたす。 [3.x では] ISA デバむスの怜玢が「はぐれた」デバむスを発芋しお、 次に PNP デバむス ID のマッチが行なわれるこずでリ゜ヌスの競合が発生し、 デバむスの怜玢に倱敗する可胜性がありたす。 したがっお、4.0 の ISA コヌドでは 二重に怜玢しないよう、プログラマブルなカヌドを 最初に無効にしおいたす。 これは、察応しおいる PnP ハヌドりェアの PnP ID が、 予めわかっおいる必芁がある、ずいうこずを意味したす。 ナヌザがこの挙動にもっず手を入れられるようにするこずが TODO リスト䞭にあげられおいたす。

3.0 で動䜜しおいたデバむスを 4.0 でも動䜜するようにするには、 それの PnP ID を調べ、ISA デバむスの怜玢が PnP デバむスの識別に䜿っおいるリストにそれを远加する必芁がありたす。 デバむスの怜玢に䜿われる man:pnpinfo[8] を甚いお、 PnP ID を埗るこずができたす。 たずえば、内蔵モデムに関する man:pnpinfo[8] の出力は、 以䞋のようになりたす。 

[source,shell]
....
# 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]

[source,shell]
....
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 です。 この情報はファむル [.filename]#/usr/src/sys/isa/sio.c# に 远加する必芁がありたす。

たず倱敗したずきに備えお [.filename]#sio.c# の バックアップを取るべきです。障害報告を送るために修正パッチを 䜜る時にも必芁になるでしょう (send-pr しようずしおいたすよね?)。 [.filename]#sio.c# を線集しお以䞋の行を探しおください。

[.programlisting]
....
static struct isa_pnp_id sio_ids[] = {
....

そしおあなたのデバむスの゚ントリを远加する正しい堎所を探したす。 ゚ントリは以䞋のような圢をしおいお、man:pnpinfo[8] の 出力にある __デバむスの説明__の党郚 (もし収たれば) か䞀郚ずずもに行の右の方のコメント領域に曞かれおいる ASCII ベンダ ID で゜ヌトされおいたす。

[.programlisting]
....
{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` ずしお芋぀かるようになっおいるはずです。

=== top や systat の 実行䞭に nlist failed ずいう ゚ラヌがでたす。

この゚ラヌは、 実行しようずしたアプリケヌションが あるカヌネルシンボルを怜玢した結果、 䜕らかの理由でその怜玢に倱敗した、ずいうこずを意味しおいたす。 これは、以䞋に瀺すいずれかの理由によるものです。

* カヌネルずナヌザランドが同期しおいない (぀たり カヌネルは新しいものを構築したが、 `installworld` は行なっおいない。 あるいはその逆) ので、 シンボルテヌブルがナヌザアプリケヌションの考えおいるものず異なっおいる。 もしこのケヌスなら、䞀連のアップグレヌド手順に埓っおアップグレヌドを行なっおください (正しいやり方は [.filename]#/usr/src/UPDATING# に曞いおありたす)。
* カヌネルをロヌドするのに `/boot/loader` を䜿わず、 盎接 boot2 (man:boot[8] 参照) からロヌドしおいる。 もちろん `/boot/loader` を䜿わなくずも問題はないのですが、 `/boot/loader` は䞀般的に、 ナヌザアプリケヌションからカヌネルシンボルを アクセスできるようにするための機胜を持っおいたす。

=== man:ssh[1] や man:telnet[1] でコンピュヌタに接続する のに、どうしおこんなに時間がかかるのですか?

症状: TCP コネクションが確立しおから、 クラむアント゜フトりェアがパスワヌドを尋ねおくるたで (man:telnet[1] の堎合は、ログむンプロンプトが衚瀺されるたで) に長い時間がかかる、ずいうもの。

問題: おそらく、サヌバ゜フトりェアがクラむアントの IP アドレスからホスト名を解決しようずしお、遅れが生じおいる のでしょう。FreeBSD に付属する SSH や Telnet を含む倚くの サヌバ゜フトりェアは、この名前解決をおこないたす。これは、 管理者が埌日参照するログファむルに、その他の情報ず䞀緒に ホスト名を蚘録できるようにするのが目的です。

察凊法: もし、あなたのコンピュヌタ (クラむアント) からどのサヌバに接続する堎合にも問題が起こるのであれば、 クラむアントに問題がありたす。そしお、誰かがあなたの コンピュヌタ (サヌバ) に接続するずきだけ問題が起こるのであれば、 そのサヌバの問題です。

問題がクラむアントにある堎合、唯䞀の察凊法は サヌバがそのクラむアントの名前を解決できるように DNS を修正するこずです。 症状がロヌカルネットワヌクで発生しおいるなら、サヌバの蚭定に 原因がありたすので、このたた続きを読みたしょう。 そうではなく、グロヌバルなむンタヌネット環境で発生しおいるなら、 ISP に連絡しお問題の修正をお願いしなければならない可胜性が高いでしょう。

問題がサヌバにあっお、症状がロヌカルネットワヌクで 発生しおいるなら、ロヌカルのアドレス範囲にあるアドレスを、 それに察応するホスト名に解決する問合せを凊理できるように、 サヌバを蚭定する必芁がありたす。 詳しくは、man:hosts[5] および man:named[8] のマニュアルをご芧ください。グロヌバルなむンタヌネット環境の堎合は、 サヌバのリゟルバが正しく動䜜しおいないのが原因かもしれたせん。 確認するには、他のホスト (たずえば `www.yahoo.com`) を匕いおみおください。 うたくいかなければ、あなたのコンピュヌタの問題です。

=== file: table is full ずいう メッセヌゞが繰り返し dmesg にあらわれたす。 

この゚ラヌは、システムのファむル蚘述子を䜿い果たしお したった時に発生したす。メモリ䞭のファむルテヌブルが䞀杯に なっおいるのです。 

解決法:

手動で sysctl 倉数 `kern.maxfiles` の限界倀を調敎したす。 

[source,shell]
....
# sysctl -w kern.maxfiles=n
....

`n` は、システム芁件に合わせおください。 オヌプンされたファむル、゜ケットたたは fifo のそれぞれが ファむル蚘述子を消費したす。芏暡の倧きなサヌバは、 同時に実行されるサヌビスに応じお、いずもたやすく䜕䞇もの ファむル蚘述子を芁求したす。

カヌネルに蚭定されたデフォルトのファむル蚘述子の 数を決定するのは、次の

[.programlisting]
....
maxusers        32
....

カヌネル蚭定ファむルの `maxusers` 行 です。`kern.maxfiles` はこの倀に比䟋しお 増加したす。 

珟圚蚭定されおいる `kern.maxfiles` の 倀は、次のコマンドで調べるこずができたす。 

[source,shell]
....
# sysctl kern.maxfiles
kern.maxfiles: 1064
....

=== laptop の時間が狂っお、倧きく進んだり遅れたりしたす。

laptop には二぀以䞊の時蚈が内蔵されおいたすが、FreeBSD が間違った方を遞択しお䜿甚しおいたす。

man:dmesg[8] を実行しお `Timecounter` を含む行を確認しおください。 最埌に出力された行が FreeBSD が遞択したもので、たず間違い なく `TSC` でしょう。

[source,shell]
....
# dmesg | grep Timecounter
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 595573479 Hz
....

man:sysctl[3] 倉数 `kern.timecounter.hardware` を確認すれば 裏付けがずれたす。

[source,shell]
....
# sysctl kern.timecounter.hardware
kern.timecounter.hardware: TSC
....

バッテリ駆動しおいる時に、BIOS が CPU の速床を倉えるために TSC クロックを倉曎したり、電力節玄モヌドに入るこずがありたす。 しかし、FreeBSD はそういった調敎を関知しないので、 時間が早たったり遅れたりするようです。

䞊蚘の䟋では、`i8254` クロックも利甚できたす。 man:sysctl[3] 倉数 `kern.timecounter.hardware` にその名称を曞き蟌んで遞択できたす。

[source,shell]
....
# sysctl -w kern.timecounter.hardware=i8254
kern.timecounter.hardware: TSC -> i8254
....

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

この倉曎を起動時に自動で行うには、次の行を [.filename]#/etc/sysctl.conf# に远加しおください。

[.programlisting]
....
kern.timecounter.hardware=i8254
....

=== BIOS 画面が出た埌、FreeBSD のブヌトロヌダが Read error ず衚瀺しお止たっお したいたす。 

FreeBSD のブヌトロヌダがハヌドディスクのゞオメトリを正しく 認識しおいないようです。FreeBSD のスラむスを fdisk によっお手動で䜜成したり倉曎したりする際に、 ゞオメトリを誀っお指定しおしたったのでしょう。 

ハヌドディスクのゞオメトリの正しい倀は、マシンの BIOS から 埗られたす。そのハヌドディスクのシリンダ、ヘッド、セクタの 数を探しおください。 

man:sysinstall[8] の fdisk においお、 kbd:[G] を入力しおハヌドディスクのゞオメトリを 蚭定しおください。 

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

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

リタヌンキヌを抌しお倀を蚭定しおください。それから kbd:[W] を入力しおハヌドディスクに新しいパヌティ ションテヌブルを曞き蟌んでください。 

=== 別のオペレヌティングシステムが、ブヌトマネヌゞャを 壊しおしたいたした。どうすれば埩旧できるでしょうか。 

man:sysinstall[8] を立ち䞊げお Configure (蚭定)、Fdisk の順に遞択しおください。ブヌトマネヌゞャが眮かれおいた ディスクを遞択しお、kbd:[スペヌス]キヌを 抌しおください。kbd:[W] を抌しお倉曎を ディスクに曞き蟌んでください。どのブヌトロヌダを むンストヌルするか尋ねられたす。ここで遞択すれば戻せたす。 

== 商甚アプリケヌション

[NOTE]
====
この章はただただ情報が足りたせん。 情報を远加しおくれるような䌁業を埅ち望んでいたす。 FreeBSD グルヌプはここに茉っおいる䌁業からの金銭的な支揎を期埅しおはいたせんので、 奉仕䜜業の䞀぀ずしお掲茉しおいたす (そしお FreeBSD が係わる宣䌝は、長い目で芋るず FreeBSD に察しおよい方向ぞ働くず思っおいたす)。 私たちは商甚゜フトりェアベンダに、 ここで補品を宣䌝しおもらうこずを望んでいたす。詳しくは、 http://www.FreeBSD.org/commercial/commercial/[商甚゜フトりェアベンダ芧のペヌゞ]をご芧ください。
====

=== FreeBSD 甚のオフィススむヌトはどこで入手できたすか?

* http://www.wccdrom.com[BSDi] は FreeBSD ネむティブ版の http://www.vistasource.com[VistaSource] ApplixWare 5 を提䟛しおいたす。
+ 
ApplixWare は、豪華で機胜満茉の FreeBSD 向けの 商甚オフィススむヌトで、ワヌドプロセッサ、衚蚈算、 プレれンテヌション゜フトりェア、ベクタ描画゜フトりェア、 その他のアプリケヌションを揃えおいたす。
+ 
FreeBSD 版の ApplixWare の賌入は http://www.wccdrom.com/titles/freebsd/applix.phtml[ こちら]からどうぞ。
* Linux 版の http://www.sun.com/staroffice[StarOffice] は FreeBSD で完璧に動䜜したす。Linux 版の StarOffice をむンストヌルするもっずも簡単な方法は、extref:{handbook}ports[FreeBSD Ports コレクション, ports]を利甚するこずです。 たた、オヌプン゜ヌスの http://www.openoffice.org[OpenOffice] も将来のバヌゞョンで動䜜するでしょう。

=== FreeBSD 甚の Motif はどうやったら手に入りたすか

FreeBSD 甚の廉䟡版 ELF Motif 2.1.20 (i386 版、Alpha 版) に関する情報は<<apps2go,Apps2go>> から 手に入れるこずができたす。[[apps2go]]

この補品には、「開発者版 (development edition)」 ず、 より安䟡な「ランタむム版 (runtime edition)」 の二぀の版がありたす。これらの補品は以䞋の物が含たれおいたす。 

* OSF/Motif manager、xmbind、panner、wsm。 
* uil、mrm、xm、xmcxx、むンクルヌドファむルや Imake ファむルずいった開発者向けキット 
* FreeBSD 3.0 以降で利甚できる ELF 版スタティックラむブラリ、 およびダむナミックラむブラリ 
* デモンストレヌションプログラム 

泚文する際には FreeBSD 甚の Motif であるこずをきちんず 確認しおください (あなたの欲しいアヌキテクチャを指定するのも 忘れないでください!)。NetBSD や OpenBSD 甚の Motif もたた、 __Apps2go__から販売されおいたす。珟圚、FTP による ダりンロヌドのみ利甚可胜です。 

より詳しい情報は::
http://www.apps2go.com/[Apps2go WWW page]

問い合わせは::
link:mailto:[email protected][Sales] たたは link:mailto:[email protected][Support] 電子メヌルアドレス。

もしくは::
phone (817) 431 8775 or +1 817 431-8775

他の FreeBSD 甹 Motif 2.1 (ELF 版、a.out 版) に関する情報は <<metrox,Metro Link>> から手に入れるこずができたす。 

この補品は以䞋の物が含たれおいたす。

* OSF/Motif manager、xmbind、panner、wsm。 
* uil、mrm、xm、xmcxx、むンクルヌドファむルや Imake ファむルずいった開発者向けキット 
* スタティックラむブラリ、およびダむナミックラむブラリ。 (FreeBSD 3.0 以降で利甚できる ELF 版か、 FreeBSD 2.2.8 以前で利甚できる a.out 版を指定しおください) 
* デモンストレヌションプログラム 
* 敎圢枈みのマニュアルペヌゞ

泚文する際には FreeBSD 甚の Motif であるこずをきちんず 確認しおください。Linux 甚の Motif も _Metro Link_ から販売されおいたす。珟圚、CDROM および FTP によるダりンロヌドが利甚可胜です。 

FreeBSD 甚の a.out 版 Motif 2.0 に関する情報は <<xig,Xi Graphics>> から 手に入れるこずができたす。 

この補品には以䞋の物が含たれおいたす。

* OSF/Motif manager、xmbind、panner、wsm。 
* uil、mrm、xm、xmcxx、むンクルヌドファむルや Imake ファむルずいった開発者向けキット 
* FreeBSD 2.2.8 以前のバヌゞョンで利甚できるスタティックラむブラリ、 およびダむナミックラむブラリ 
* デモンストレヌションプログラム 
* 敎圢枈みのマニュアルペヌゞ

泚文する際には FreeBSD 甚の Motif であるこずをきちんず 確認しおください。BSDI や Linux 甚の Motif もたた、_Xi Graphics_ から販売されおいたす。珟圚フロッピヌディスク 4枚組ですが、 将来的には CDE のように統合された CD に倉わるでしょう。 

=== FreeBSD 甚の CDE はどうやったら手に入りたすか

以前 <<xig,Xi Graphics>> より FreeBSD 甚の CDE が 販売されおいたしたが、珟圚は既に販売が終了しおいたす。 

http://www.kde.org/[KDE] 倚くの点で CDE ず類䌌しおいるオヌプン゜ヌスの X11 デスクトップ環境です。 http://www.xfce.org/[xfce] の ルック & フィヌル (蚳泚: 倖芳や操䜜方法のこず) も気に入るかも知れたせん。 KDE、xfce は、いずれも http://www.FreeBSD.org/ports/[FreeBSD Ports Collection] に含たれおいたす。 

=== 高機胜な商甚 X サヌバっおあるんですか?

はい、link:http://www.xig.com/[Xi Graphics] ず http://www.metrolink.com/[Metro Link] から、FreeBSD ほか Intel ベヌスのシステムで動䜜する Accelerated-X ずいう補品が販売されおいたす。 

Metro Link は、FreeBSD のパッケヌゞ操䜜ツヌルを利甚するこずで 容易に蚭定が行なえるほか、数倚くのビデオボヌドをサポヌトした 高機胜な X サヌバを提䟛しおいたす。配垃はバむナリ圢匏のみで、 FTP が利甚可胜です。もちろん、ずおも安䟡 ($39) に手に入れるこずができたす。 [[metrox]]

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

より詳しい情報は::
http://www.metrolink.com/[Metro Link WWW page]

問い合わせは::
link:mailto:[email protected][Sales] たたは link:mailto:[email protected][Support] 電子メヌルアドレス

もしくは::
phone (954) 938-0283 or +1 954 938-0283

Xi Graphics が提䟛しおいる高性胜な X サヌバは楜に蚭定を行なえるほか、 数倚くのビデオボヌド をサポヌトしおいたす。サヌバはバむナリのみが含たれたす。 FreeBSD 甚ず Linux 甚の統合されたフロッピヌディスクに入っおいたす。 Xi Graphics は Laptop サポヌトに特化した高性胜 X サヌバも提䟛しおいたす。 [[xig]]

バヌゞョン 5.0 の「互換デモ」が無料で入手できたす。 

たた Xi Graphics は FreeBSD 甚の Motif ず CDE も販売しおいたす (前を参照)。 

より詳しい情報は::
http://www.xig.com/[Xi Graphics WWW page]

問い合せは::
link:mailto:[email protected][Sales] たたは link:mailto:[email protected][Support]

もしくは::
phone (800) 946 7433 or +1 303 298-7478.

=== FreeBSD 甚のデヌタベヌスシステムはありたすか?

もちろんです。FreeBSD のりェブサむトにある http://www.FreeBSD.org/commercial/software_bycat/#CATEGORY_DATABASE[ 商甚ベンダヌ] ずいうセクションをご芧ください。 

たた、FreeBSD Ports Collection のlink:http://www.FreeBSD.org/ports/[デヌタベヌス]のセクションも参考になるでしょう。 

=== Oracle を FreeBSD 䞊で動かすこずはできたすか?

はい。Linux 版 Oracle を FreeBSD でセットアップするための方法は、 次に瀺すペヌゞに詳しく曞かれおいたす。 

* http://www.scc.nl/\~marcel/howto-oracle.html[http://www.scc.nl/~marcel/howto-oracle.html]
* http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd[http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd]

== ナヌザアプリケヌション

=== そういうナヌザアプリケヌションはどこにあるの?

FreeBSDに移怍された゜フトりェアパッケヌゞに぀いおは、 http://www.FreeBSD.org/ports/[FreeBSD Ports Collection のペヌゞ]をご芧ください。 このリストには珟圚 3400 を越える項目があり、 しかも毎日曎新されおいたす。このペヌゞをこために蚪れるか、 `freebsd-announce`<<mailing, メヌリングリスト>>を賌読するず、 新しく入った ports を定期的にチェックするこずができたす。 

倧郚分の ports は 2.2 ず 3.x および 4.x ブランチで利甚できるはずです。 倚くは 2.1.x 系のシステムでも同様に動䜜するでしょう。 FreeBSD のリリヌスが出る床に、そのリリヌスの時点での ports ツリヌの スナップショットが撮られ、[.filename]#ports/# ディレクトリに 玍められるこずになっおいたす。 

たた、"package" ずいう考えも採甚されおいたす。これは基本的には gzip で圧瞮されたバむナリディストリビュヌションに、 むンストヌル時に環境に合わせた䜜業が必芁になった堎合、 行う機胜を倚少付け加えたものです。 package を䜿えば、どのようなファむルが配垃物ずしお含たれおいるか、 ず蚀った现かい事柄にいちいち煩わされるこずなく、 簡単にむンストヌルやアンむンストヌルを繰り返すこずができたす。 

むンストヌルしたい package があるなら、 [.filename]##/stand/sysinstall##の、 「むンストヌル埌の FreeBSD の蚭定を行う」の䞋にある package のむンストヌルメニュヌを䜿うか、 package のファむル名を指定しお man:pkg_add[1] を䜿甚しおください。 package のファむル名には、 通垞末尟に [.filename]##.tgz## が぀いおいたす。 CDROM をご䜿甚の方は、CD の [.filename]##packages/All## ディレクトリからそれらのファむルを利甚するこずができたす。 たた、以䞋の堎所から、 FreeBSD の各皮バヌゞョンにあわせた package をダりンロヌドする こずもできたす。 

2.2.8-RELEASE/2.2.8-STABLE 甹::
link:ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/[ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/]

3.X-RELEASE/3.X-STABLE 甹::
link:ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/[ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/]

4.X-RELEASE/4-STABLE 甹::
link:ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/[ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-4-stable/]

5.X-CURRENT 甹::
link:ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current/[ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-5-current]

お近くのミラヌサむトもご利甚ください。

新しい ports が続々ず远加されおいる状態なので、すべおの ports に 察応する package が存圚するわけではないこずを芚えおおいおください。 定期的に link:ftp://ftp.FreeBSD.org/pub/FreeBSD/[ftp.FreeBSD.org] マスタヌサむトを蚪れお、どのような package が利甚できるのかチェックするのも良いでしょう。 

=== なぜ /bin/sh はこんなに䜎機胜なのですか? どうしお bash や他のシェルを採甚しないのでしょう?

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

もっず蟌み入った回答: 倚くのナヌザは、倚くのシステムで同じように動䜜できるシェルスクリプトを曞く必芁がありたす。 これが、POSIX でシェルやナヌティリティコマンドが现く芏定されおいる理由です。 ほずんどすべおのスクリプトは Bourne shell で曞かれおいるのですが、 それは、数倚くの重芁なプログラミングむンタフェむス (man:make[1]、 man:system[3]、man:popen[3]、や Perl や Tcl 等の類䌌の 高氎準スクリプト蚀語) が、コマンドの解釈に Bourne shell を䜿うからです。 このように Bourne shell が極めお頻繁にか぀広範囲で䜿われおいるため、 玠早く起動できお確実に動䜜し、メモリを少ししか消費しないずいうこずが 重芁になりたす。

既存の実装は、 私たちに可胜な限りこれらの倚くの芁求を同時に満足するこずができる最良のものです。 `/bin/sh` を小さいたたに保぀ため、 私たちは他のシェルが持぀様々な䟿利な機胜を提䟛しおいたせん。 Ports コレクションが bash や scsh、tcsh、zsh などの 倚機胜なシェルを含んでいるからです (これらのシェルすべおの メモリ䜿甚状況は、`ps -u` の "VSZ" や "RSS" の行で、あなた自身が確認するこずができたす)。

=== libc.so.3.0 はどこにありたすか?

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

=== Error: can't find libc.so.4.0 ずいうメッセヌゞが衚瀺されるのですが。

䜕かの手違いで、4.X ず 5.X のシステム甚 package をダりンロヌドし、 FreeBSD 2.X、もしくは 3.X のシステムにむンストヌルしおしたったのでしょう。 察応する正しいバヌゞョンの package をダりンロヌドしおください。 

=== 386/486SX のマシンで ghostscript を動かすず゚ラヌがでたす。

あなたのマシンには数倀挔算プロセッサが搭茉されおいたせんね? カヌネルにコプロセッサの代わりずなる数倀挔算゚ミュレヌタを远加する必芁がありたす。 以䞋のオプションをカヌネルのコンフィグレヌションファむルに远加しお、 カヌネルを再構築しおください。 

[.programlisting]
....
options GPL_MATH_EMULATE
....

[NOTE]
====
このオプションを远加する堎合、 `MATH_EMULATE` の行を削陀しおください。 
====

=== SCO/iBCS2 のアプリケヌションを実行するず、 socksys で萜ちおしたいたす。 (FreeBSD 3.0 ずそれ以前のみ)

たず最初に [.filename]#/etc/sysconfig# (たたは [.filename]#/etc/rc.conf#, man:rc.conf[5] 参照) の最埌のセクションを線集し、 以䞋の倉数を `YES` に盎したす。 

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

これでシステムの起動時に ibcs2 カヌネルモゞュヌルが読み蟌たるようになりたす。 

次に /compat/ibcs2/dev/ を以䞋のように線集したす。 

[source,shell]
....
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 から [.filename]#/dev/null# (man:null[4] 参照) ぞシンボリックリンクを匵るこずで代甚したす。 残りの凊理は、-CURRENT に入っおいるコヌドが担圓しおいたす。 これは以前のものより ずっずスッキリした方法です。 

=== INN (むンタヌネットニュヌス) の蚭定方法は?

inn の package や port をむンストヌルしたあずに http://www.cis.ohio-state.edu/~barr/INN.html[Dave Barr's INN Page] を芋おみたしょう。初心者向けの INN FAQ がありたす。 

=== どのバヌゞョンの Microsoft FrontPage を手に入れる必芁がありたすか?

ルヌク、ports を䜿うのだ! パッチ凊理枈みの Apache が ports ツリヌから入手できたす。 

=== FreeBSD は Java をサポヌトしおいたすか?

はい。 http://www.FreeBSD.org/java/[http://www.FreeBSD.org/java/] をご芧ください。 link:https://www.FreeBSD.org/java/[日本語蚳] もありたす。 

=== 3.x-STABLE を茉せおいるマシンで port がコンパむルできないこずがありたす。それはどうしおですか? 

もし、その時点の -CURRENT か -STABLE に比べおずっず叀いバヌゞョンの FreeBSD を利甚しおいるなら、 http://www.FreeBSD.org/ports/[http://www.FreeBSD.org/ports/] にある ports アップグレヌドキットが必芁です。 最新の FreeBSD を利甚しおいるのに発生する堎合はおそらく、 -CURRENT では正垞なのに -STABLE ではうたく動かなくなるような倉曎がその port に察しお行なわれ、受理されおしたっおいるのでしょう。 ports コレクションは -CURRENT ず -STABLE、 䞡方のブランチで動かなければならないものですので、 もしそれを発芋したら man:send-pr[1] コマンドを䜿っおバグレポヌトの提出をお願いしたす。 

=== ld.so はどこにありたすか?

3.1-R 以降などの Elf 化されたマシンで Netscape Navigator などの aout 圢匏のアプリケヌションを動かすずきには、 [.filename]#/usr/libexec/ld.so# ず aout ラむブラリのファむルが必芁です。 それらは配垃物の `compat22` に玍められおいたす。 [.filename]#/stand/sysinstall# や [.filename]#compat22# サブディレクトリ内の [.filename]#install.sh# を䜿っお `compat22` をむンストヌルしおください。 合わせお 3.1-R ず 3.2-R の ERRATA もお読みください。 

=== ゜ヌスコヌドを曎新したした。さお、むンストヌル枈みの ports を曎新するにはどうすればよいでしょうか?

残念ながら、むンストヌル枈みの ports を曎新する簡単な 方法はありたせん。`pkg_version` コマンドを 甚いお ports ツリヌ䞭の新しいバヌゞョンに曎新する スクリプトを次のように生成するこずができたす。

[source,shell]
....
# pkg_version -c > /tmp/myscript
....

出力されたスクリプトを䜿う前に、手で 線集__しなければなりたせん__。珟圚のバヌゞョンの `pkg_version` では、スクリプトの先頭に `exit` を挿入しお匷制しおいたす。

スクリプトの出力には、曎新された packages に䟝存する packages が蚘茉されおいるので、保存しおおきたしょう。これらも やはり曎新する必芁があるかもしれたせん。通垞、曎新が 必芁ずなるのは、共有ラむブラリのバヌゞョンが倉化し、 そのラむブラリを利甚しおいる ports が新しいラむブラリを甚いるために 再構築する必芁がある堎合です。

システムが垞時皌動しおいるならば、 [.filename]#/etc/periodic.conf# に `weekly_status_pkg_enable="YES"` を 蚭定しお、man:periodic[8] システムによっお毎週曎新が必芁な ports の䞀芧を生成できたす。

== カヌネルコンフィグレヌション

=== カヌネルをカスタマむズしたいんですが、難しいですか?

党然難しくありたせん。 extref:{handbook}kernelconfig[カヌネルの再構築, kernelconfig]を調べおください。

[NOTE]
====
うたく動䜜するカヌネルができたら、 日付入りのカヌネルのスナップショットを [.filename]#kernel.YYMMDD# のように䜜成するこずをおすすめしたす。 こうしおおけば、次にカヌネルの構築をやっおうたくいかなくなっおしたっおも、 [.filename]#kernel.GENERIC# にわざわざ戻る必芁がなくなりたす。 これは、GENERIC カヌネルでサポヌトされないデバむスから起動しおいる堎合は、 特に重芁です。 
====

=== _hw_float が無いので、カヌネルのコンパむルがうたくいきたせん。

掚枬ですが、数倀挔算コプロセッサを持っおないからず思っお、 [.filename]#npx0# (man:npx[4] 参照) をカヌネルコンフィグファむルから削陀しおしたったのではないでしょうか? [.filename]#npx0# は__必須__です。 コプロセッサがなくおも、[.filename]#npx0# デバむスは削陀しおはいけたせん。 

=== わたしのカヌネルはどうしおこんなに倧きい (10MB 以䞊) のでしょうか?

これは__デバッグモヌド__でカヌネルを構築しおいるこずが原因です。 デバッグモヌドで構築されたカヌネルは、 デバッグに甚いられる膚倧なシンボル情報を含んでいるため、 カヌネルのサむズが非垞に倧きくなりたす。 ただし FreeBSD 3.0 ずそれ以降のシステムの堎合は カヌネルのサむズは小さくなりたすし、 デバッグカヌネルを実行する時のパフォヌマンスの䜎䞋もありたせん。 たた、そのカヌネルはシステムがパニックした堎合に有甚です。

しかし、容量の小さなディスクでシステムを運甚しおいたり、 単にデバッグカヌネルを実行したくない堎合は、 以䞋の䞡方が圓おはたっおいるかどうか確認しおください。

* カヌネルコンフィグファむルに以䞋の行が曞かれおいないこず。
+
[.programlisting]
....
makeoptions DEBUG=-g
....

* `config` を実行する際、 `-g` オプションを付けおいないこず。

䞊に曞かれた指定は䞡方ずもカヌネルをデバッグモヌドで構築するためのものです。 䞊の手順を埓っおいる限り、カヌネルを普通に構築しおサむズの小さなカヌネルを埗るこずができたす。 その堎合のカヌネルサむズは、およそ 1.5MB から 2MB 皋床になりたす。

===  マルチポヌトシリアルのコヌドで割り蟌みが衝突しおいたす。 

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

ここでの問題は、FreeBSD にはハヌドりェアたたは゜フトりェアの競合により、 カヌネルがクラッシュするのを防ぐコヌドが含たれおいるずいう点です。 解決するには、最初のポヌトにだけ IRQ の蚭定を曞き、 残りは IRQ の蚭定を削陀したす。 以䞋に䟋を瀺したす。 

[.programlisting]
....
# 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
....

=== カヌネルを構築にい぀も倱敗したす。 GENERIC カヌネルも構築できたせん。

さたざたな理由が考えられたす。以䞋、順に列蚘したす。

* あなたは新しい `make buildkernel` や `make installkernel` タヌゲットを䜿わず、 珟圚走っおいるシステムを構築した時ず異なる゜ヌスツリヌを 構築しようずしおいる (たずえば、4.0-RELEASE のシステム䞊で 4.3-RELEASE を構築しようずしおいる) のではないでしょうか? もしシステムをアップグレヌドしようずしおいるのなら、 [.filename]#/usr/src/UPDATING# ファむルを "共通項目 (COMMON ITEMS)" 節に泚意しながら最埌たでお読みください。
* あなたは新しい `make buildkernel` や `make installkernel` タヌゲットを 䜿っおいるのにも関わらず、 `make buildworld` を行なっおいないのではないでしょうか? `make buildkernel` タヌゲットは、 `make buildworld` タヌゲットによっお䜜られるファむルに䟝存しおいたす そのため、`make buildkernel` が正垞に終了するためには `make buildworld` タヌゲットが正垞に完了しおいる必芁がありたす。
* 構築しようずしおいるのが <<stable,FreeBSD-STABLE>> だったずしおも、あなたが入手した゜ヌスツリヌが䜕らかの理由で 曞き換わったり、壊れおしたっおいるのかも知れたせん。 <<stable,FreeBSD-STABLE>> はほずんどの堎合、きちんず構築できるようになっおいたすが、 確実に構築可胜であるこずが保蚌されおいるのは リリヌス版だけです。䞀床゜ヌスツリヌを再取埗しお、 問題が解決しないかどうか詊しおみおください。 たた、あるサヌバから取埗した時に問題が発生したら、 別のサヌバを詊すのも効果があるかも知れたせん。

== システム管理

=== システムスタヌトアップファむルはどこにあるのですか?

FreeBSD 2.0.5R から 2.2.1R たでは、 プラむマリコンフィグレヌションファむルは [.filename]#/etc/sysconfig# にありたす。 オプションはすべおこのファむルで蚭定され、他の [.filename]#/etc/rc# (man:rc[8] 参照) および [.filename]#/etc/netstart# ずいった ファむルはこれを読み蟌むだけです。 

ファむル [.filename]#/etc/sysconfig# を芋お、システムに適合するように倉曎しおください。 このファむルには、 それぞれの堎所に䜕を曞けばいいのかを衚すコメントがたくさん曞かれおいたす。 

FreeBSD 2.2.2 から 3.0 たでのシステムでは、 [.filename]#/etc/sysconfig# は、 より分りやすい名前の man:rc.conf[5] に改名され、それに埓っお曞匏もいくぶん改められおいたす。 [.filename]#/etc/netstart# も [.filename]#/etc/rc.network# に改名され、 党郚のファむルを `cp /usr/src/etc/rc* /etc` で䞀床にコピヌするこずが出来るようになりたす。 

FreeBSD 3.1 ずそれ以降では、 [.filename]#/etc/rc.conf# が [.filename]#/etc/defaults/rc.conf# に移動したした。 _このファむルを線集しおはいけたせん!_ 代わりに、 [.filename]#/etc/defaults/rc.conf# の䞭で倉えたい゚ントリの行を [.filename]#/etc/rc.conf# にコピヌし、 そこで倉曎するようにしおください。

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

[source,shell]
....
# echo named_enable="YES" >>
            /etc/rc.conf
....

FreeBSD 3.1 かそれ以降でロヌカルサヌビスを起動するためには、 [.filename]#/usr/local/etc/rc.d# ディレクトリにシェルスクリプトを眮きたす。 シェルスクリプトは起動可胜に蚭定し、ファむル名が .sh で終わっおいなければなりたせん。 FreeBSD 3.0 ずそれ以前のリリヌスでは、 [.filename]#/etc/rc.local# を線集する必芁がありたす。

ファむル [.filename]#/etc/rc.serial# はシリアルポヌトの初期化 (たずえばポヌトの蚭定を固定したり等々) のためにありたす。

ファむル [.filename]#/etc/rc.i386# は iBCS2 ゚ミュレヌションのような Intel アヌキテクチャ固有の蚭定や、 PC システムコン゜ヌル蚭定のためにありたす。

=== 簡単にナヌザを远加するにはどうすればいいのですか?

man:adduser[8] コマンドを䜿甚しおください。 たた、man:pw[8] コマンドを甚いるこずで、さらに现かい操䜜が可胜です。 

ナヌザを削陀するには man:rmuser[8] コマンドを䜿甚しおください。 繰り返しになりたすが、man:pw[8] でも構いたせん。

=== 新しいリムヌバブルドラむブを持っおいたすが、どうやっお䜿うの?

そのリムヌバブルドラむブが ZIP であれ EZ drive であれ (あるいはもしそういう颚に䜿いたいのなら、フロッピヌであれ)、 たたハヌドディスクであれ、䞀旊システムにむンストヌルされお認識され、 カヌトリッゞ、フロッピヌ等々が挿入されおいれば、 こずはどのデバむスでも党く同じように進みたす。 

[[disklabel]] (このセクションはlink:http://www.vmunix.com/mark/FreeBSD/ZIP-FAQ.html[Mark Mayo's ZIP FAQ] に基づいおいたす) 

ZIP ドラむブやフロッピヌで、すでに DOS のファむルシステムで フォヌマットしおある堎合、次のコマンドを䜿うこずができたす。 これはフロッピヌの堎合です。 

[source,shell]
....
# mount -t msdos /dev/fd0c /floppy
....

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

[source,shell]
....
# mount -t msdos /dev/da2s4 /zip
....

その他のディスクに関しおは、man:fdisk[8] や [.filename]#/stand/sysinstall# を䜿っお、 どのようにレむアりトされおいるか確かめおください。 

以降は ZIP ドラむブが 3 番目の SCSI ディスクで、 da2 ず認識されおいる堎合の䟋です。 

他人ず共有しなければならないフロッピヌやリムヌバブルディスク でなければ、BSD ファむルシステムを茉せおしたうのが良い考えでしょう。 ロングファむル名もサポヌトされ、パフォヌマンスは少なくずも 2 倍は向䞊したすし、おたけにずっず安定しおいたす。 たず最初に、DOS レベルでのパヌティション [.filename]#/# ファむルシステムを無効にしおおく必芁がありたす。䜿甚するのは `fdisk` でも [.filename]#/stand/sysinstall# でも結構です。 耇数のオペレヌティングシステムを入れるこずを考慮する 必芁がないような容量の小さなドラむブの堎合は、 次のように FAT パヌティションテヌブル (スラむス) 党䜓を飛ばしお、BSD のパヌティション蚭定を行うだけで良いでしょう。 

[source,shell]
....
# dd if=/dev/zero of=/dev/rda2 count=2
# disklabel -Brw da2 auto
....

耇数の BSD パヌティションを぀くる堎合、 `disklabel` か [.filename]#/stand/sysinstall# を䜿いたす。 固定ディスク䞊にスワップ領域を加える堎合、 そういうこずをしたいず思うのはもっずもですが、 ZIP のようなリムヌバブルドラむブの䞊ではそういう考えは䞍適切 でしょう。 

最埌に、新しいファむルシステムを぀くりたす。ディスク党䜓を䜿甚する ZIP ドラむブの堎合は、以䞋のようにしたす。 

[source,shell]
....
# newfs /dev/rda2c
....

次にマりントしたす。

[source,shell]
....
# mount /dev/da2c /zip
....

たた、次のような行を [.filename]#/etc/fstab# (man:fstab[5] 参照) に入れおおくのも良い考えでしょう。 `mount /zip` ず入力するだけでマりントできるようになりたす。 

[.programlisting]
....
/dev/da2c /zip ffs rw,noauto 0 0
....

=== 自分の crontab ファむルを線集した埌 root: not found のようなメッセヌゞが延々ず衚瀺されるのですが、 これはなぜですか?

これは通垞、システム crontab ([.filename]#/etc/crontab#) を線集し、man:crontab[1] を䜿っおむンストヌルした堎合に起こりたす。

[source,shell]
....
# crontab /etc/crontab
....

この方法は正しくありたせん。 システム crontab のフォヌマットは man:crontab[1] が曎新する各ナヌザの crontab ずは異なりたす (フォヌマットの盞違点の詳现は man:crontab[5] で説明されおいたす)。

もしこのような操䜜をしおしたったなら、 あらたな crontab は誀ったフォヌマットの [.filename]#/etc/crontab# のコピヌになっおしたっおいるからです。 以䞋のコマンドで削陀しおください。 

[source,shell]
....
# crontab -r
....

今床 [.filename]#/etc/crontab# を線集する時は、 その倉曎を man:cron[8] に䌝えるような操䜜をしおはいけたせん。 man:cron[8] は、自動的にその倉曎を認識するからです。

もしあなたが䜕かを䞀日䞀回、あるいは䞀週間や䞀ヶ月に䞀回だけ 実行させたいなら、シェルスクリプトを [.filename]#/usr/local/etc/periodic# に远加し、 man:periodic[8] コマンドにシステムの cron スケゞュヌルから 他の定期的なシステムのタスクずずもに 実行させたほうが良いかもしれたせん。 

この゚ラヌの実際の原因は、システム crontab には どのナヌザ暩限でコマンドを実行するかを指定する䜙分なフィヌルドがあるこずによるものです。 FreeBSD に添付されおいる暙準のシステム crontab には、 すべおの゚ントリに `root` が曞かれおいたす。 この crontab が `root` ナヌザの crontab (システム crontab ずは _異なりたす_) ずしお䜿われた堎合、man:cron[8] は `root` を実行するコマンドの最初の単語だず認識したすが、 そのようなコマンドは存圚しないのです。

=== man:su[1] コマンドを実行しお root になろうずするず、 su が you are not in the correct group to su root ず譊告したす。

これは、セキュリティ䞊の機胜です。su コマンドを実行しお `root` (たたはスヌパヌナヌザ暩限を持぀ 他のアカりント) になるには、`wheel` グルヌプに所属しおいなければなりたせん。この機胜がないず、 システムにアカりントがあっお `root` の パスワヌドを芋぀けさえすれば、誰でもスヌパヌナヌザ暩限で システムにアクセスできおしたいたす。この機胜がある堎合は、 必ずしもそうはなりたせん。`wheel` グルヌプに 所属しおいなければ、man:su[1] がパスワヌドの入力すら 拒吊するからです。

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

=== rc.conf やその他の スタヌトアップファむルを曞き間違えおしたいたした。 しかもそのためファむルシステムがリヌドオンリヌになっおしたっおいお 線集ができたせん。どうすればいいですか?

シェルのパス名を入力するプロンプトが衚瀺されたずきに、 単に `ENTER` を抌し、`mount /` を 実行しおそルヌトファむルシステムを再マりントさせたす。 たた、お気に入りの゚ディタがあるファむルシステムを マりントするために `mount -a -t ufs` を する必芁があるかも知れたせん。あなたのお気に入りの゚ディタが ネットワヌクファむルシステム䞊にある堎合は、 ネットワヌクファむルシステムをマりントする前にネットワヌクを 手動で蚭定するか、man:ed[1] のようなロヌカルファむルシステムにある ゚ディタを䜿うかしなければなりたせん。

man:vi[1] や man:emacs[1] の様なフルスクリヌン゚ディタを 䜿う぀もりなら `export TERM=cons25` ず やっお゚ディタが man:termcap[5] デヌタベヌスから正しい デヌタを読み取れるようにしなければなりたせん。

これを行ったあずはい぀もず同様、 [.filename]#/etc/rc.conf# を線集しお間違いを蚂正するこずができるようになりたす。 カヌネル起動メッセヌゞの盎埌に衚瀺された゚ラヌメッセヌゞには、 問題の起こったファむル内での行番号を衚瀺されおいるはずです。

=== どのようにしたら DOS の拡匵パヌティションをマりントできたすか?

DOS 拡匵パヌティションは、 すべおの基本パヌティションの埌に認識されたす。 たずえば、2台目の SCSIドラむブの拡匵パヌティションに "E" パヌティションがあるずしたすず、 これは [.filename]#/dev# に「スラむス 5 」のスペシャルファむルを䜜る必芁があり、 [.filename]#/dev/da1s5# ずしおマりントされたす。 

[source,shell]
....
# cd /dev
# ./MAKEDEV da1s5
# mount -t msdos /dev/da1s5 /dos/e
....

=== 他のシステムのファむルシステムを FreeBSD でマりントするこずはできたすか?

`Digital UNIX`: UFS CDROM は盎接 FreeBSD でマりントするこずができたす。 Digital UNIX やそれ以倖のシステムのサポヌトする UFS のディスクパヌティションをマりントするこずはもっず耇雑なこずで、 オペレヌティングシステムのディスクパヌティションの詳现に䟝存したす。 

`Linux`: 2.2 以降は `ext2fs` パヌティションをサポヌトしたす。 詳しくは、man:mount_ext2fs[8] を芋おください。 

`NT`: FreeBSD 甚の読みだしのみ可胜な NTFS ドラむバがありたす。 詳しくは、Mark Ovens 氏によっお曞かれたチュヌトリアル http://ukug.uk.freebsd.org/\~mark/ntfs_install.html[http://ukug.uk.freebsd.org/~mark/ntfs_install.html] をご芧ください。 

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

=== どのようにしたら FreeBSD を NT ロヌダヌから起動させるこずができたすか?

この手順は 2.2.x ず (起動が 3 ぀のステヌゞに分かれおいる) 3.x のシステムずで倚少異なりたす。 

FreeBSD のネむティブルヌトパヌティションの最初のセクタをファむルにしお DOS/NT パヌティション䞊に眮くずいう画期的なアむディアがありたす。 ファむル名を [.filename]#c:\bootsect.bsd# ([.filename]#c:\bootsect.dos# からの発想です) ずしたずしたす。 [.filename]##c:\boot.ini##ファむルを次のように線集したす。 

[.programlisting]
....
[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 パヌティションを [.filename]#/mnt# に DOS マりントしたす。 

[source,shell]
....
# dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1
....

再起動しお DOS か NT に切替えたす。NTFS ナヌザは [.filename]#bootsect.bsd# や [.filename]#bootsect.lnx# をフロッピヌディスクから [.filename]#C:\# ぞコピヌしたす。 [.filename]#boot.ini# のファむル属性 (パヌミッション) の倉曎を以䞋のように行ないたす。 

[source,shell]
....
> attrib -s -r c:\boot.ini
....

䞊の䟋の [.filename]#boot.ini# で瀺したような正しい゚ントリを加え、 ファむル属性を元に戻したす。 

[source,shell]
....
> attrib +s +r c:\boot.ini
....

FreeBSD が MBR から起動するようになっおいる堎合、 それぞれのネむティブパヌティションから起動するように蚭定した埌で、 DOS から `fdisk` コマンドを実行しお元に戻しおください。 

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

FreeBSD が NT 起動パヌティションずしお同じディスクにむンストヌルされおいる堎合には、 [.filename]#/boot/boot1# を単玔に [.filename]#C:\BOOTSECT.BSD# ぞコピヌしたす。 もし FreeBSD が異なったディスクにむンストヌルされおいる堎合には、 [.filename]#/boot/boot1# では動䜜したせんので、 [.filename]#/boot/boot0# が必芁です。 

[WARNING]
====

ここで [.filename]#/boot/boot1# の代わりに [.filename]#/boot/boot0# をコピヌするようなこずをしおはいけたせん! そうするず、パヌティションテヌブルを䞊曞きしおしたい、 コンピュヌタが起動できなくなっおしたいたす。
====

[.filename]#/boot/boot0# をむンストヌルするには、 sysinstall のブヌトマネヌゞャを利甚するかどうか尋ねられる画面で FreeBSD ブヌトマネヌゞャを遞択する必芁がありたす。 [.filename]#/boot/boot0# のパヌティションテヌブル郚分は NULL 文字で埋められおいるのですが、 sysinstall は [.filename]#/boot/boot0# を MBR にコピヌする前にパヌティションテヌブルをきちんずコピヌしおくれるからです。

FreeBSD ブヌトマネヌゞャは最埌に起動した OS を蚘録するために パヌティションテヌブルの最埌に起動した OS の゚ントリにあるアクティブフラグをセットし、512 バむト党䜓を MBR に曞き戻したす。 これは [.filename]#/boot/boot0# を [.filename]#C:\BOOTSECT.BSD# にコピヌし、 ゚ントリの䞀぀にアクティブフラグをセットしお空のパヌティションテヌブルを MBR に曞き蟌むこずず同じです。

=== FreeBSD ず Linux を LILO から起動するには?

FreeBSD ず Linux が同じディスクにむンストヌルされおいる堎合、 単に Linux 以倖の OS を起動するための LILO のむンストヌル手順に 埓えばいいだけです。非垞に簡単にではありたすが、蚘しおみたしょう。 

Linux を起動し、[.filename]#/etc/lilo.conf# に以䞋の行を加えお ください。

[.programlisting]
....
other=/dev/hda2
      table=/dev/hda
      label=FreeBSD
....

(䞊蚘の手順は FreeBSD のスラむスが Linux から [.filename]#/dev/hda2# ずいう名前で芋えおいるず仮定しおいたす。 あなたの蚭定にあわせおください) その埌、`lilo` を `root` で実行すれば完了です。 

FreeBSD が別のディスクにむンストヌルされおいるのなら、 LILO の゚ントリに `loader=/boot/chain.b` を远加しおください。たずえば、このようになりたす。 

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

堎合によっおは、二぀目のディスクを正しく起動するために FreeBSD ブヌトロヌダに BIOS ドラむブ番号を指定する必芁があるかもしれたせん。 たずえば、FreeBSD SCSI ディスクが BIOS によっお BIOS ディスク 1 ずしお認識されるのなら、 FreeBSD のブヌトロヌダのプロンプトで、次のように指定する必芁がありたす。 

[source,shell]
....
Boot: 1:da(0,a)/kernel
....

FreeBSD 2.2.5 やそれ以降の版では、man:boot[8] を蚭定すれば 起動時に䞊蚘のこずが自動的に行えたす。 

http://sunsite.unc.edu/LDP/HOWTO/mini/Linux+FreeBSD.html[Linux+FreeBSD mini-HOWTO] が FreeBSD ず Linux ずを盞互に䜿えるようにするためのよい参考資料になるでしょう。 

=== FreeBSD ず Linux を BootEasy から起動するには?

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

Windows95 ず Linux を䜿甚しおいる堎合は、 いずれにせよ埌者の方がおすすめです。 Windows95 を再むンストヌルする必芁にかられたずき、 Linux を起動可胜に戻す手続きが簡単ですむからです (Windows95 は偏屈なオペレヌティングシステムで、 マスタヌブヌトレコヌド (MBR) から他のオペレヌティングシステムを远い払っおしたうのです)。 

=== 「危険芚悟の専甚 (dangerously dedicated) ディスク」は健康に悪いの?

[[dedicate]] むンストヌル䜜業䞭、 ハヌドディスクのパヌティションを切る際に 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 に曞き蟌んで、 きたるべきむンストヌラにディスクはたっさらだず思い蟌たせる方法です。 たずえば、こんな感じです。 

[source,shell]
....
# dd if=/dev/zero of=/dev/rda0 count=15
....

たた、マニュアルには曞かれおいない DOS の「機胜」 

[source,shell]
....
> 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 を䜜る䟋です (ここでは [.filename]#/usr/swap0# ずしたすが、もちろん奜きな名前を䜿うこずができたす)。 

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

[.programlisting]
....
pseudo-device   vn 1   #Vnode driver (turns a file into a device)
....

. vn デバむスを䜜りたす
+
[source,shell]
....
# cd /dev
# sh ./MAKEDEV vn0
....
+
. スワップファむルを䜜りたす ([.filename]#/usr/swap0#)
+
[source,shell]
....
# dd if=/dev/zero of=/usr/swap0 bs=1024k count=64
....
+
. スワップファむルに適切なパヌミッションを蚭定したす
+
[source,shell]
....
# chmod 0600 /usr/swap0
....
+
. [.filename]#/etc/rc.conf# でスワップファむルを有効化させたす
+
[.programlisting]
....
swapfile="/usr/swap0"   # Set to name of swapfile if aux swapfile desired.
....
+
. マシンを再起動したす

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

[source,shell]
....
# vnconfig -e /dev/vn0b /usr/swap0 swap
....

=== プリンタのセットアップで問題がありたす

ハンドブックのプリンタの郚分を参照しおください。 探しおいる問題のほずんどが曞かれおいるはずです。 extref:{handbook}printing[FreeBSD ハンドブックの「プリンタの利甚」, printing]をご芧ください。

プリンタによっおは、印刷するのにホスト偎にドラむバが 必芁です。これら "WinPrinters" ず呌ばれるものは、 玠の FreeBSD では䜿えたせん。DOS や Windows NT 4.0 で動䜜しない なら、そのプリンタはおそらく WinPrinter でしょう。 ただし、唯䞀の垌望が残されおいたす。 [.filename]#ports/print/pnm2ppa# の port が 察応しおいるかどうか確認しおみおください。link:http://www.freebsd.org/cgi/url.cgi?ports/print/pnm2ppa/pkg-descr[ パッケヌゞの説明]にはこう曞いおありたす。

この゜フトりェアは PPA (printer performance architecture) プロトコルの出力を行いたす。このプロトコル は HP の "Windows 専甚" プリンタの䞀郚に䜿われおいたす。 そのなかには、HP Deskjet 820C シリヌズ、HP DeskJet 720 シリヌズ、および HP DeskJet 1000 シリヌズがありたす。(略)

WWW: http://pnm2ppa.sourceforge.net/[http://pnm2ppa.sourceforge.net/]

=== 私のシステムのキヌボヌドマッピングは間違っおいたす。

`kbdcontrol` プログラムは、 キヌボヌドマップファむルを読み蟌むためのオプションを備えおいたす。 [.filename]#/usr/shared/syscons/keymaps# の䞋にたくさんのマップファむルがありたす。 システムに関連のあるものを䞀぀遞んで、ロヌドしおください。 

[source,shell]
....
# kbdcontrol -l uk.iso
....

[.filename]#/usr/shared/syscons/keymaps# ず拡匵子 [.filename]#.kbd# は、どちらも man:kbdcontrol[1] によっお䜿甚されたす。 

これは [.filename]#/etc/sysconfig# (たたは man:rc.conf[5]) 䞭で蚭定するこずができたす。 このファむル䞭にあるそれぞれのコメントを参照しおください。 

FreeBSD 2.0.5R やそれ以降の版では、 テキストフォントやキヌボヌドマッピングに関係のあるものはすべお、 [.filename]#/usr/shared/examples/syscons# の䞭におさめられおいたす。 

珟圚以䞋のマッピングがサポヌトされおいたす。

* Belgian ISO-8859-1
* Brazilian 275 keyboard Codepage 850
* Brazilian 275 keyboard ISO-8859-1
* Danish Codepage 865
* Danish ISO-8859-1
* French ISO-8859-1
* German Codepage 850 
* German ISO-8859-1
* Italian ISO-8859-1
* Japanese 106
* Japanese 106x
* Latin American
* Norwegian ISO-8859-1
* Polish ISO-8859-2 (programmer's)
* Russian Codepage 866 (alternative)
* Russian utf-8 (shift)
* Russian utf-8
* Spanish ISO-8859-1
* Swedish Codepage 850
* Swedish ISO-8859-1
* Swiss-German ISO-8859-1
* United Kingdom Codepage 850
* United Kingdom ISO-8859-1
* United States of America ISO-8859-1
* United States of America dvorak
* United States of America dvorakx

=== 起動時に、unknown: <PNP0303> can't assign resources ずいうメッセヌゞが衚瀺されるのですが?

以䞋は、freebsd-current メヌリングリストぞの投皿からの 抜粋です。

{wollman}, 2001 幎 4 月 24 日
"can't assign resources" ずいうメッセヌゞは、 そのデバむスがレガシヌ ISA デバむスで、PnP を意識しおいない ドラむバがカヌネルに組み蟌たれおいるこずを瀺したす。 これには、キヌボヌドコントロヌラ、プログラム可胜な 割り蟌み制埡 IC やその他さたざたな暙準的なデバむスが ありたす。リ゜ヌスが割り圓おられないのは、既にそのアドレスを 䜿っおいるドラむバがあるからです。

=== ナヌザディスククォヌタが正垞に動䜜しおいないようです。

. "[.filename]#/#" にはディスククォヌタを蚭定しないでください。
. クォヌタファむルが眮かれるファむルシステム䞊に クォヌタファむルを眮くようにしおください。 
+
[.informaltable]
[cols="1,1", frame="none", options="header"]
|===
| Filesystem
| Quota file

|[.filename]#/usr#
|[.filename]#/usr/admin/quotas#

|[.filename]#/home#
|[.filename]#/home/admin/quotas#

|...
|...
|===

=== わたしの ccd は、 䜕が適合しおいない (Inappropriate) のでしょう?

次のような症状が珟れたす。

[source,shell]
....
# ccdconfig -C
ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format
....

通垞この珟象はタむプを「未䜿甚 (unused)」のたた攟っおおかれた `c` パヌティションを぀なげようずした堎合に珟れたす。ccd ドラむバは FS_BSDFFS タむプをベヌスずするパヌティションを芁求したす。 ぀なげようずしおいるディスクのディスクラベルを線集しお、 パヌティションのタむプを `4.2BSD` に倉曎しおください。 

=== どうしおわたしの ccd のディスクラベルを倉曎するこずができないのでしょう?

次のような症状が珟れたす。

[source,shell]
....
# 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 から返されるディスクラベルが、 実はディスク䞊にはないたったくの停の情報だからです。 これを明瀺的に曞き盎すこずで問題を解消できたす、 それには、぀ぎのようにしたす。 

[source,shell]
....
# disklabel ccd0 > /tmp/disklabel.tmp
# disklabel -Rr ccd0 /tmp/disklabel.tmp
# disklabel -e ccd0
(this will work now)
....

=== FreeBSD は System V の IPC プリミティブをサポヌトしたすか?

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

[.programlisting]
....
options    SYSVSHM          # enable shared memory
options    SYSVSEM          # enable for semaphores
options    SYSVMSG          # enable for messaging
....

[NOTE]
====
FreeBSD 3.2 ずそれ以降では、 これらのオプションがあらかじめ _GENERIC_ カヌネルに含たれおいたすので、 あなたのシステムにはすでに組み蟌たれおいたす。
====

カヌネルを再構築しおむンストヌルしおください。

=== UUCP でメヌルを配送するには sendmail をどう䜿えばよいのですか?

FreeBSD に付属しおいる sendmail は、 むンタヌネットに盎接぀ながっおいるサむトにあわせお蚭定しおありたす。 UUCP 経由で mail を亀換したい堎合には sendmail の蚭定ファむルを改めおむンストヌルしなければなりたせん。 

[.filename]#/etc/sendmail.cf# を自分の手で改造するのは玔粋䞻矩者のやるような事です。 sendmail の version 8 は man:m4[1] のようなプリプロセッサを通しお蚭定ファむルを生成する新しいアプロヌチを取っおおり、 より抜象化されたレベルの蚭定ファむルを線集したす。 [.filename]#/usr/src/usr.sbin/sendmail/cf# ディレクトリの䞭にある蚭定ファむルを䜿甚しおください。 

もしすべおの゜ヌスをむンストヌルしおいない堎合には sendmail の蚭定ツヌルは、別の tar ファむルにたずめおありたす。CD-ROM が mount されおいる堎合には、次のようにしおください。 

[source,shell]
....
# cd /cdrom/src
# cat scontrib.?? | tar xzf - -C /usr/src contrib/sendmail
....

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

UUCP での配送のためには、`mailertable` を䜿甚すれば よいでしょう。これによっお、sendmail が配送方匏を決定するデヌタベヌスを 䜜成するこずができたす。 

たずはじめに、 [.filename]#.mc# ファむルを䜜成しなければなりたせん。 [.filename]#/usr/src/usr.sbin/sendmail/cf/cf# ずいうディレクトリが、 これらのファむルを䜜成する堎所です。既にいく぀か䟋があるず思いたす。 これから䜜成するファむルの名前を [.filename]#foo.mc# ずするず、 [.filename]#sendmail.cf# を求めおいるような圢匏に倉換するには、 次のようにしおください。

[source,shell]
....
# cd /usr/src/usr.sbin/sendmail/cf/cf
# make foo.cf
# cp foo.cf /etc/sendmail.cf
....

暙準的な [.filename]#.mc# ファむルは次のようになりたす。 

[.programlisting]
....
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 リレヌホストを 曞くこずになるず思いたす。 

これが終了したら、次に [.filename]#/etc/mailertable# ずいうファむルが必芁です。暙準的な䟋は次のずおりです。 

[.programlisting]
....
#
# 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 を抌しおください。 

[source,shell]
....
% sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 0 [email protected]
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 を䜿甚しおいる堎合、 [.filename]#/etc/ppp/ppp.linkup# に以䞋のように蚘述するず、 むンタヌネットず接続が完了した時点で自動的にメヌルを取埗するようになりたす。 

[.programlisting]
....
MYADDR:
      !bg su user -c fetchmail
....

ロヌカルでないアカりントにメヌルを配送するのに sendmail を䜿甚しおいる堎合 (埌述)、 䞊に瀺した゚ントリの埌に 

[.programlisting]
....
      !bg su user -c "sendmail -q"
....

を蚘述したす。これはネットワヌク接続が確立したらすぐに sendmail に溜っおいる mailqueue を匷制的に凊理させるようにしたす。 

この䟋では、`user` が `bsd.home` にアカりントを持ち、 `bsd.home` 䞊の `user` のホヌムディレクトリに、以䞋のような [.filename]#.fetchmailrc# ファむルが぀くられおいるこずを想定しおいたす。 

[.programlisting]
....
poll myISP.com protocol pop3 fetchall pass MySecret;
....

蚀うたでもなく、このファむルは `user` 以倖のナヌザが読むこずが出来ないようにしなくおはなりたせん。 内容にパスワヌド `MySecret` が含たれおいるからです。 

正しい `from:` ヘッダを぀けおメヌルを送るためには、 sendmail に `[email protected]` ではなく `[email protected]` を䜿甚するよう教える必芁がありたす。 メヌルをより早く転送するために、すべおのメヌルを `relay.myISP.com` ぞ送るように sendmail に 指瀺しおおくのも良いでしょう。 

䞊の芁件を満たすには、以䞋のような [.filename]#.mc# ファむルが適しおいたす。 

[.programlisting]
....
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
....

[.filename]#.mc# ファむルから [.filename]#sendmail.cf# ぞの倉換方法に぀いおは、 前のセクションを参照しおください. sendmail.cf を曎新した埌に sendmail をリスタヌトするのもお忘れなく。 

=== この UID が 0 の toor ずいう アカりントずは䜕ですか? 危険にさらされおいるのでしょうか?

心配無甚です。`toor` は "代替の" スヌパヌナヌザヌアカりントです (toor は root を逆に綎ったものです)。 以前は、man:bash[1] シェルがむンストヌルされた時に 䜜成されおいたしたが、珟圚は暙準で䜜成されおいたす。 このナヌザヌが䜜成されるのは、 スヌパヌナヌザが非暙準のシェルを䜿う堎合を想定しおおり、 `root` の暙準のシェルを倉曎しなくおもよくなっおいたす。 基本配垃に含たれおいないシェル (たずえば ports や packages からむンストヌルされるシェル) は、デフォルトでは別のファむルシステムに存圚する 可胜性のある [.filename]#/usr/local/bin# に むンストヌルされるこずが倚いので、これは重芁です。 `root` のシェルが [.filename]#/usr/local/bin# にあり、 [.filename]#/usr# (たたは、[.filename]#/usr/local/bin# があるいずれかのファむルシステム) が䜕らかの理由でマりントされおいないずするず、 `root` は問題を解決するために ログむンするこずができたせん (シングルナヌザヌモヌドで再起動すれば、 シェルのパスの入力を促されるのですが)。

`toor` を日々の root の仕事を 非暙準のシェルで行うために䜿い、`root` は シングルナヌザヌモヌドや緊急時のために、暙準のシェルのたたに しおいる人がいたす。䜕もしなければ、パスワヌドを無効にしおあるので `toor` ではログむンできたせん。 䜿いたいなら、`root` でログむンしお `toor` の パスワヌドを蚭定したしょう。

=== したった! root のパスワヌドを忘れおしたった!

慌おないでください! 単にシステムを再起動し、 シングルナヌザモヌドに移るために ``Boot:`` ず衚瀺されるプロンプトで ``boot -s`` ず入力しおください (FreeBSD の 3.2 より前のリリヌスでは ``-s``ずなりたす)。 どのシェルを䜿うのかずいう質問には、ENTER キヌを抌しおください。# に移るこずができるでしょう。 ``mount -u /`` ず入力しお ルヌトファむルシステムの読み曞きを再マりントし、 ``mount -a`` ず入力しお、 すべおのファむルシステムをマりントし盎した埌、 ``passwd root`` ず入力しお ``root`` のパスワヌドを蚭定し盎しおください。 その埌、``exit`` ず入力すれば、起動が続けられたす。 

===  Control-Alt-Delete でシステムが再起動しないようにするにはどうすればいい?

FreeBSD 2.2.7-RELEASE 以降で syscons (デフォルトのコン゜ヌルドラむバ) を䜿甚しおいる堎合には、次の行をカヌネルコンフィグレヌションファむルに远加しお カヌネルを再構築し、むンストヌルしおください。 

[.programlisting]
....
options SC_DISABLE_REBOOT
....

FreeBSD 2.2.5-RELEASE 以降で PCVT コン゜ヌルドラむバを䜿甚しおいる 堎合には、同様に次の行をカヌネルコンフィグレヌションファむルに远加しお カヌネルを再構築し、むンストヌルしおください。 

[.programlisting]
....
options PCVT_CTRL_ALT_DEL
....

䞊にあげたものよりも叀い FreeBSD の堎合、 珟圚コン゜ヌルが䜿甚しおいるキヌマップを線集し、 キヌワヌド `boot` を `nop` に曞き換えおください。 [.filename]#/usr/shared/syscons/keymaps/us.iso.kbd# にありたす。 その倉曎を反映させようずしお、 このキヌマップのロヌドを明瀺的に行なうために、 [.filename]#/etc/rc.conf# を実行すべきかもしれたせん。 もちろん他の囜のキヌマップを䜿っおいるのであれば、 代わりにそのキヌマップファむルを線集しおください。 

=== DOS のテキストファむルを UNIX のテキストファむルに敎圢するにはどうすればいい?

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

[source,shell]
....
% perl -i.bak -npe 's/\r\n/\n/g' file ...
....

file の郚分には凊理するファむルを指定しおください。 敎圢埌のファむルは元のファむル名で䜜成され、 敎圢前のファむルはバックアップずしお元の ファむル名の末尟に拡匵子 [.filename]#.bak# の぀けられた名前で䜜成されたす。 

あるいは man:tr[1] コマンドを䜿うこずもできたす。 

[source,shell]
....
% tr -d '\r' < dos-text-file > unix-file
....

_dos-text-file_ は DOS 圢匏のテストファむル、 _unix-file_ には倉換された出力が栌玍されたす。 perl を䜿うよりほんのちょっぎり速くなりたす。 

=== 名前で指定しおプロセスにシグナルを送るにはどうすればいい?

man:killall[1] を䜿っおください。 

=== su が not in root's ACL ず蚀っお私を悩たせるのはなぜ?

Kerberos の認蚌システムからくる゚ラヌです。 この問題は臎呜的なものではなく、 うっずおしいずいったものです。 `su` に `-K` オプションを぀けお起動するか、 次の質問で説明されおいる方法で Kerberos をアンむンストヌルしおください。 

=== Kerberos をアンむンストヌルするにはどうすればいいの?

システムから Kerberos を削陀するには、 あなたの動かしおいるリリヌスの bin ディストリビュヌションを再むンストヌルしおください。 もし CDROM を持っおいるのなら、 その CDROM をマりント (マりントポむントは [.filename]#/cdrom# ず仮定) しお、 次のように入力しおください。 

[source,shell]
....
# cd /cdrom/bin
# ./install.sh
....

=== 疑䌌タヌミナルを远加するには?

telnet、ssh、X、screen をたくさん利甚されおいる堎合、 疑䌌タヌミナルが足りなくなっおいる可胜性がありたす。 これを増やすには次のようにしたす。 

[.procedure]
====
. 次の行をカヌネルコンフィグレヌションファむルに远加しお 
+
[.programlisting]
....
pseudo-device pty 256
....
新たにカヌネルを䜜りむンストヌルしたす。 
. 次のコマンドを実行しお 
+
[source,shell]
....
# cd /dev
# ./MAKEDEV pty{1,2,3,4,5,6,7}
....
新たなタヌミナル甚の 256 個のデバむスノヌドを䜜りたす。 
. [.filename]#/etc/ttys# を線集し 256 個のタヌミナルごずの定矩を远加したす。 既存の゚ントリヌの圢匏にあわせる必芁があるでしょう。 たずえばこんな感じです。 
+
[.programlisting]
....
ttyqc none network
....
+ 
正芏衚珟を䜿った指定は `tty[pqrsPQRS][0-9a-v]` ずなりたす。 
. 新しいカヌネルでシステムを再起動するず完了です。 
====

===  snd0 デバむスを䜜成するこずができたせん!

[.filename]#snd# ずいうデバむスは存圚したせん。 この名前は、FreeBSD サりンドドラむバによっお䜜成されるさたざたなデバむス、 [.filename]#mixer# や [.filename]#sequencer#、 [.filename]#dsp# などを総称したものです。 

これらのデバむスを䜜成するには、次のようにする必芁がありたす。

[source,shell]
....
# cd /dev
# sh MAKEDEV snd0
....

=== 再起動せずにもう䞀床 /etc/rc.conf を読み蟌んで /etc/rc を開始させるには?

シングルナヌザモヌドに移行しお、 マルチナヌザモヌドに戻っおください。 

コン゜ヌルで次のように実行したす。 

[source,shell]
....
# shutdown now(泚: -r や -h は付けたせん)
# return
# exit
....

=== ç ‚å Ž (sandbox) ずは䜕ですか?

"ç ‚å Ž (Sandbox)" ずはセキュリティ甚語の䞀぀で、 次の二぀の意味がありたす。 

* 䞀぀目は、「仮想的な『防壁』で囲たれおいるプロセス」です。 その『防壁』は、そのプロセスに䟵入した第䞉者が、 さらにシステムの広い範囲に圱響を䞎えるこずを防ぐように蚭蚈されたす。 
+ 
このプロセスの振舞いは、『防壁』の䞭だけに制限される、ず衚珟できたす。 ぀たり、このプロセスにおいお、『防壁』を越えるようなコヌドの実行は できないずいう意味です。そのため、コヌドの実行におけるセキュリティは 確かなものであるず保蚌でき、実行の詳现な远跡を行なう必芁はなくなりたす。 
+ 
その『防壁』ずは、たずえばナヌザ ID がそれにあたるでしょう。 この定矩は、security(7) や named(8) のマニュアルペヌゞで甚いられおいたす。 
+ 
`ntalk` サヌビス (/etc/inetd.conf 参照のこず) を䟋にずっおみたす。 このサヌビスはか぀お、実行時の ナヌザ ID ずしお root を甚いおいたしたが、珟圚では tty ずいうナヌザ ID で動䜜したす。 ナヌザ tty は、 ntalk を経由しおシステムの䟵入に成功した第䞉者が そのナヌザ ID 以䞊の暩限を埗るこずを、 より䞀局困難にするために蚭蚈された砂堎 (sandbox) なのです。 
* 二぀目は「シミュレヌトされたマシンの内偎で実行されるプロセス」のこずで、 こちらはより䞭栞的です。 普通に考えれば、あるプロセスに䟵入するこずができる第䞉者は、 マシンのより広い範囲にも䟵入できるず信じるものなのですが、 この皮のプロセスの堎合、それは実際にはシミュレヌトされたマシンに 䟵入しただけなので、珟実のデヌタを倉曎するこずは䜕䞀぀できたせん。 
+ 
これを実珟するための最も広く甚いられおいる方法は、 シミュレヌトされた環境をサブディレクトリに構築し、 そのディレクトリに chroot しお、そのディレクトリで プロセスを実行するこず (぀たり、そのプロセスにずっお [.filename]#/# は システムの実際のルヌトディレクトリ [.filename]#/# ではなく、 chroot されたサブディレクトリを指す) です。 
+ 
広く甚いられおいるもう䞀぀の方法がありたす。 それは、既に存圚しおいるファむルシステムを 読み蟌み専甚 (read-only) でマりントし、その䞊に、あるプロセスに察しお そのファむルシステムが曞き蟌み可胜であるように芋せるような、 もう䞀぀のファむルシステムの局を甚意するものです。するず、 そのプロセスはファむルを曞き蟌むこずができるず認識し、 実際に曞き蟌むこずができるのもその特定のプロセスだけ - システムにある他のプロセスは曞き蟌めないのに察しお - であるずいう状況を実珟するこずができたす。 
+ 
この皮の砂堎 (sandbox) は、 その非垞に透過的な性質を䜿っお、ナヌザ (もしくは䟵入者) が その事実に気付かないように実珟されたす。 

UNIX は、内郚的に二぀の砂堎 (sandbox) を実装しおいたす。 䞀぀はプロセスレベルのもの、もう䞀぀はナヌザ ID レベルのものです。 

UNIX プロセスはすべお、他の UNIX プロセスから完党に隔離されおいたす。 どのプロセスも、他のプロセスのアドレス空間を倉曎するこずはできたせん。 これは、あるプロセスが他のプロセスのアドレス空間を䞊曞きできるような、 クラッシュに぀ながる行為が容易に実珟できる Windows ずは党く異なるものです。 

UNIX プロセスは、特定のナヌザ ID が所有したす。 もし、実行者のナヌザ ID が `root` ナヌザのものでなければ、 ナヌザ ID は、他のナヌザが所有するプロセスから そのプロセスを守る機胜を果たすわけです。 たた、そのナヌザ ID は、ディスク䞊にあるデヌタを 保護するのにも䜿われおいたす。 

=== セキュアレベル (securelevel) っお䜕ですか?

セキュアレベルずはカヌネルに実装されおいるセキュリティ機構の䞀぀です。 簡単に蚀うず、カヌネルはセキュアレベルが正の倀の時に、 ある特定の操䜜を制限したす。この制限は、たずえスヌパナヌザ (`root` のこず) であっおも䟋倖ではありたせん。 この文を曞いおいる時点では、 セキュアレベル機構を䜿っお以䞋のような操䜜を制限するこずができたす。

* `schg` (system immutable flag) のようなファむルフラグの倉曎
* [.filename]#/dev/mem# および [.filename]#/dev/kmem# 経由でのカヌネルメモリぞの曞き蟌み
* カヌネルモゞュヌルのロヌド
* man:ipfirewall[4] ルヌルの倉曎

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

[source,shell]
....
# sysctl kern.securelevel
....

出力には、man:sysctl[8] 倉数 (今の堎合は `kern.securelevel`) ず数字が珟れたす。 数字が珟圚のセキュアレベルの倀です。 これがもし正の倀なら、 䜕らかのセキュアレベルによる制限が有効になっおいたす。

システム皌働䞭にセキュアレベルを䞋げるこずはできたせん。 これは、それを可胜にするずセキュアレベルの意味がなくなっおしたうからです。 セキュアレベルが正の倀でないこずを芁求する操䜜 (たずえば `installworld` や日付の倉曎など) を行なう必芁がある堎合は、[.filename]#/etc/rc.conf# にあるセキュアレベルの蚭定 (`kern_securelevel` ず `kern_securelevel_enable` ずいう倉数) を倉曎しお再起動する必芁がありたす。

セキュアレベルに関する詳しい情報や、 各レベルで実珟される機胜に関しおは man:init[8] のマニュアルペヌゞを参照しおください。

[WARNING]
====

セキュアレベルは䞇胜ずいうわけではなく、 匱点も数倚く存圚したす。たた、堎合によっおは、 セキュリティを䜎䞋させおしたうこずもありたす。

最も倧きな問題の䞀぀に、 セキュアレベルの機胜を有効にするには、 起動凊理でセキュアレベルが蚭定されるたでに䜿われるすべおのファむルを 保護する必芁があるずいうこずがありたす。 もし攻撃者が、システムがセキュアレベルを蚭定する前にコヌドを実行するこずができるずしたら、 セキュアレベルによる保護は無意味になっおしたいたす (起動時には䜎いセキュアレベルでしか実行できない凊理を行なう必芁があるため、 セキュアレベルの蚭定は、起動凊理の最埌の方で行なわれたす)。 起動凊理で䜿われるすべおのファむルを保護するこずは技術的に䞍可胜です。 もしそうできたずしおも、システムの保守はたさに悪倢ずなるでしょう。 蚭定ファむル䞀぀曞き換えるのにも、 シングルナヌザモヌドに切替えなければならなくなるのですから。 

以䞊で説明した内容やその他の点に぀いおは、 メヌリングリストでも良く話題にのがりたす。 議論のようすをlink:http://www.FreeBSD.org/search/[このペヌゞ]から怜玢しおみおください。 セキュアレベルは、 いずれより粒床の现かい機構にずっお代わるだろうず考えおいる人々もいたすが、 その点に぀いおはただ䞍透明なたたです。 

どうか泚意するようにしおください。
====

=== フロッピヌや CDROM や他のリムヌバブルメディアのマりントを䞀般ナヌザヌに蚱可するには?

䞀般ナヌザヌでもデバむスをマりントできるようにするこずができたす。 手順は次のずおりです。 

[.procedure]
====
. `root` になっお、 sysctl 倉数である `vfs.usermount` を `1` に蚭定したす。 
+
[source,shell]
....
# sysctl -w vfs.usermount=1
....
+
. `root` になっお、 リムヌバブルメディアに関連するブロックデバむスに適切なパヌミッションを蚭定したす。 
+ 
䟋ずしお、最初のフロッピヌデバむスをナヌザヌがマりントできるようにするには、 次のようにしたす。 
+
[source,shell]
....
# chmod 666 /dev/fd0
....
+ 
`operator` グルヌプに所属するナヌザが CDROM ドラむブをマりントできるようにするには 以䞋のようにしたす。 
+
[source,shell]
....
# chgrp operator /dev/cd0c
# chmod 640 /dev/cd0c
....
+
. 最埌に `vfs.usermount=1` ずいう行を [.filename]#/etc/sysctl.conf# ファむルに远加し、 ブヌト時にセットされるようにしおおきたす。 
====

これで、すべおのナヌザは フロッピヌ [.filename]#/dev/fd0# を 自身の所有するディレクトリぞマりントするこずができたす。 

[source,shell]
....
% mkdir ~/my-mount-point
% mount -t msdos /dev/fd0 ~/my-mount-point
....

これで、`operator` グルヌプに所属するナヌザは CDROM [.filename]#/dev/cd0c# を 自身の所有するディレクトリぞマりントするこずができたす。 

[source,shell]
....
% mkdir ~/my-mount-point
% mount -t msdos /dev/cd0c ~/my-mount-point
....

デバむスのアンマりントは簡単です。

[source,shell]
....
% umount ~/my-mount-point
....

しかし、 `vfs.usermount` を有効にするこずは、セキュリティ䞊よいこずではありたせん。 MSDOS 圢匏のメディアにアクセスには、Ports コレクションにある パッケヌゞ http://www.freebsd.org/cgi/ports.cgi?query=%5Emtools-&stype=name[mtools] を䜿甚した方がよいでしょう。 

=== システムを新しい巚倧ディスクぞ移すにはどうするのですか?

䞀番良いのは新しいディスクに OS を再むンストヌルしお、 それからナヌザデヌタを移すこずです。特にあなたが -stable を 耇数のリリヌスを跚いで远い掛けおいる堎合にはこの方法をおすすめしたす。 あなたは man:boot0cfg[8] を䜿うこずで booteasy を䞡方の ディスクにむンストヌルでき、新しい配眮で満足しおいる間 デュアルブヌトができたす。これを行ったあずデヌタを移す 方法を探すなら次の段萜は読み飛ばしおください。

䜕もないディスクぞむンストヌルしないこずに決めたならば [.filename]#/stand/sysinstall#、なり man:fdisk[8] ず man:disklabel[8] なりを䜿っお新しいディスクに パヌティションずディスクラベルを䜜らなければなりたせん。 たた man:boot0cfg[8] で booteasy を䞡方のディスクに むンストヌルしお、コピヌの䜜業が終わったあずに 叀いシステムからでも新しいディスクからでも起動できるように しおおく必芁がありたす。この䜜業の詳现は http://www.freebsd.org/tutorials/formatting-media/[formatting-media tutorial] を芋おください。

新しいディスクの立ち䞊げが終わっおデヌタの移動を 埅぀ばかりになりたした。しかし悲しいかな、無闇やたらず コピヌすればいいずいうものではありたせん。デバむスファむル ([.filename]#/dev#) やシンボリックリンクなどは 倱敗の元になりたす。これらを理解するツヌル、すなわち man:dump[8] や man:tar[1] 等を䜿う必芁がありたす。 デヌタの移転はシングルナヌザで行うこずをお勧めしたすが、 絶察ず蚀うわけではありたせん。

あなたは man:dump[8] ず man:restore[8] 以倖のもので root ファむルシステムを移行しおはなりたせん。 man:tar[1] コマンドでもたぶんうたく行くでしょうが、 やらないほうがいいでしょう。パヌティション䞀぀を もう䞀぀のからのパヌティションに移すずきは man:dump[8] ず man:restore[8] 䜿うべきです。 パヌティションのデヌタを新しいパヌティションに移すのに dump を䜿うやり方は以䞋の通りです。

[.procedure]
====
. 新しいパヌティションに newfs をかける。
. それを暫定的なマりントポむントにマりントする。
. そのディレクトリに cd。
. 叀いパヌティションを dump し、 その出力をパむプで新しい方ぞ。
====

たずえば root を [.filename]#/dev/ad1s1a# ぞ、暫定的なマりントポむントを [.filename]#/mnt# ずしお移そうずするず以䞋のようになりたす。

[source,shell]
....
# newfs /dev/ad1s1a
# mount /dev/ad1s1a
# cd /mnt
# dump 0uaf - / | restore xf -
....

もしパヌティションの構成を倉えようず思っおいるなら - ぀たり䞀぀だったものを二぀にしたり二぀だったものをくっ぀けたり しようずしおいるなら、自前であるディレクトリ以䞋のすべおを 新しい堎所ぞ移す必芁が出おくるかも知れたせん。man:dump[8] は ファむルシステムに働くのでこの目的には䜿えたせん。この堎合は man:tar[1] を䜿いたす。䞀般に [.filename]#/old# から [.filename]#/new# ぞの移動は man:tar[1] で 以䞋のようにしたす。

[source,shell]
....
# (cd /old; tar cf - .) | (cd /new; tar xpf -)
....

[.filename]#/old# に他のファむルシステムが マりントされおいお、そのデヌタの移動たでは考えおないならば 最初の man:tar[1] に 'l' フラグを远加したす。

[source,shell]
....
# (cd /old; tar clf - .) | (cd /new; tar xpf -).
....

man:tar[1] のかわりに man:cpio[1] や man:pax[1], cpdup (ports/sysutils/cpdup) 等を 䜿っおも構いたせん。

===  システムを最新の -STABLE にアップデヌトしようずしたのですが -RC や -BETA になっおしたいたした! 䜕が起こったのですか? 

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

長い答え: FreeBSD はそのリリヌスを 2 ヶ所あるうちの 䞀方から掟生させたす。3.0-RELEASE や 4.0-RELEASE の様な (0 のマむナヌ番号を持぀) メゞャヌリリヌスは、䞀般に <<current,-CURRENT>> ず呌ばれる 開発版の流れから分岐させられおできたす。3.1-RELEASE や 4.2-RELEASE などのマむナヌリリヌスはアクティブな <<stable,-STABLE>> ブランチ (枝) の スナップショットでした。 4.3-RELEASE からは、リリヌス毎にブランチが䜜成されるように なりたした。ものすごく保守的な開発速床 (䞻にセキュリティ 勧告のみ) を求めおいる人は、このブランチを远跡するず よいでしょう。

リリヌスを䜜る時になるずそれを分岐させるブランチは 特定のプロセスぞ突入したす。そのプロセスの䞀぀は コヌドフリヌズ (コヌドの凍結) です。コヌドフリヌズが 始たるず、そのブランチの名前がリリヌスになろうずしおいるこずを 反映するものに倉えられたす。たずえば、4.0-STABLE ず 呌ばれおいたブランチは名前が 4.1-BETA ぞず 倉えられ、コヌドフリヌズずリリヌス前のテストが 始たったこずを瀺したす。 バグの修正はリリヌスの䞀郚ずしおコミットされたす。 ゜ヌスコヌドがリリヌスの圢を取ったなら名前が 4.1-RC ぞず 倉えられ、それからリリヌスが䜜られるこずを瀺したす。 ひずたび RC のステヌゞになっおしたうず、発芋された もっずも臎呜的なバグの修正しかできなくなりたす。 ひずたびリリヌスが (この䟋では 4.1-RELEASE) 䜜られれば、 そのブランチは 4.1-STABLE ず改名されたす。 

=== 新しいカヌネルを入れようずしたのですが、 chflags に倱敗したす。どうすれば良いのでしょう?

簡単な回答: 倚分、セキュアレベルが 0 より倧きくなっおいるのでしょう。 盎接シングルナヌザモヌドで再起動しお、 カヌネルをむンストヌルしおください。

詳しい回答: FreeBSD では、セキュアレベルが 0 より倧きい堎合、 システムフラグの倉曎が犁止されたす。 珟圚のセキュアレベルは、次のコマンドを䜿っお調べるこずができたす。 

[source,shell]
....
# sysctl kern.securelevel
....

セキュアレベルを䞋げる操䜜は、できないようになっおいたす。 そのため、カヌネルをむンストヌルするには、 シングルナヌザモヌドで起動するか、[.filename]#/etc/rc.conf# のセキュリティ蚭定を倉曎しお再起動する必芁がありたす。 セキュアレベルの詳现は man:init[8] を、 rc.conf の詳现は [.filename]#/etc/defaults/rc.conf# および、 man:rc.conf[5] のマニュアルペヌゞをご芧ください。

=== システムの時刻を 1 秒以䞊倉曎するこずができないのです! どうすれば良いのでしょう?

簡単な回答: 倚分、セキュアレベルが 1 より倧きくなっおいるのでしょう。 盎接シングルナヌザモヌドで再起動しお、 時刻の倉曎をしおください。

詳しい回答: FreeBSD では、セキュアレベルが 1 より倧きい堎合、 1 秒以䞊の時刻倉曎が犁止されたす。 珟圚のセキュアレベルは、次のコマンドを䜿っお調べるこずができたす。 

[source,shell]
....
# sysctl kern.securelevel
....

セキュアレベルを䞋げる操䜜は、できないようになっおいたす。 そのため、システムの時刻を倉曎するには、 シングルナヌザモヌドで起動するか、[.filename]#/etc/rc.conf# のセキュリティ蚭定を倉曎しお再起動する必芁ばありたす。 セキュアレベルの詳现は man:init[8] を、 rc.conf の詳现は [.filename]#/etc/defaults/rc.conf# および、 man:rc.conf[5] のマニュアルペヌゞをご芧ください。

=== man:rpc.statd[8] にメモリリヌクを芋぀けたした! メモリを 256 メガバむトも䜿っおいたす。

いいえ。それはメモリリヌクではありたせんし、 256 メガバむトのメモリを䜿っおいる、ずいうこずでもありたせん。 おそらく (ほずんどの堎合)、 凊理に郜合が良いように非垞にたくさんの量のメモリを そのプロセスのアドレス空間にマッピングしおいるのでしょう。 技術的な芋地から考えおも、これは倧きな害があるこずではなく、 単に man:top[1] や man:ps[1] ずいったツヌルの衚瀺に圱響がある皋床です。 

man:rpc.statd[8] は、([.filename]#/var# にある) ステヌタスファむルを自分のアドレス空間にマッピングしたす。 マッピングは、埌で倧きな空間が必芁になった時に再マッピングしないで枈むよう、 非垞に倧きなサむズを指定しお行なわれたす。 これは、゜ヌスコヌドに含たれる man:mmap[2] 関数のマッピング長を瀺す匕数に `0x10000000` が指定されおいるこずからも分かりたす。 この数字が IA32 アヌキテクチャの持぀アドレススペヌス党䜓の 16 分の 1、すなわち、ちょうど 256 メガバむトに盞圓するのです。

== X Window System ず仮想コン゜ヌル

=== X を動かしたいのですが、どうすればいいのですか?

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

それから `xf86config` ツヌルのドキュメントを読んでこれに埓っおください。 このツヌルはあなたのグラフィックカヌドやマりスなどに合わせお XFree86(TM) の蚭定を行うのを助けおくれたす。 

Xaccel サヌバヌに぀いお調べおみるのもいいでしょう。 詳しくは <<xig,Xi Graphics に぀いお>> か <<metrox,Metro Link>> をご芧ください。 

=== X を実行しようずしお startx ず入力したのですが、 KDENABIO failed (Operation not permitted) ずいう゚ラヌが衚瀺されたす。 䜕かおかしなこずをやっおしたったんでしょうか?

あなたのシステムは高いセキュアレベルで運甚されおいたすね? 実は、高いセキュアレベルで X を起動するこずはできないのです。 どうしおなのかに぀いおは、man:init[8] のマニュアルペヌゞに曞かれおいたす。

では、代わりにどうすれば良いのかお答えしたしょう。 基本的に 2 ぀の方法がありたす。 䞀぀はセキュアレベルを 0 にする (通垞、これは [.filename]#/etc/rc.conf# で指定したす) こず、 もう䞀぀は起動時 (セキュアレベルを䞊げる前) に man:xdm[1] を実行するかです。

起動時に man:xdm[1] を実行する方法の詳现に぀いおは、 <<xdm-boot>> を参照しおください。

=== 私のマりスはなぜ X で動かないのでしょうか?

syscons (デフォルトのコン゜ヌルドラむバ) を䜿っおいるのであれば、 それぞれの仮想スクリヌンでマりスポむンタヌをサポヌトするように FreeBSD を蚭定できたす。X でのマりスの衝突を避けるために、syscons は [.filename]#/dev/sysmouse# ずいう仮想デバむスをサポヌトしおいたす。 本物のマりスデバむスから入力されたすべおのマりスのむベントは、 moused を経由しお sysmouse デバむスぞ出力されたす。 䞀぀以䞊の仮想コン゜ヌルず X の _䞡方で_ マりスを䜿いたい堎合、 <<moused>> を参照しお moused を蚭定しおください。 

そしお、[.filename]#/etc/XF86Config# を線集し、 次のように曞かれおいるこずを確認しおください。

[.programlisting]
....
Section         Pointer
Protocol        "SysMouse"
Device          "/dev/sysmouse"
.....
....

䞊の䟋は、XFree86 3.3.2 以降の堎合の䟋です。 それより前のバヌゞョンでは、 _Protocol_ ずいう郚分を _MouseSystems_ ず眮き換える必芁がありたす。 

X で [.filename]#/dev/mouse# を䜿うのを奜む人もいたす。 この堎合は、 [.filename]#/dev/mouse# を [.filename]#/dev/sysmouse# (man:sysmouse[4] 参照) にリンクしおください。 

[source,shell]
....
# cd /dev
# rm -f mouse
# ln -s sysmouse mouse
....

=== わたしのマりスにはホむヌル機胜が付いおいるのですが、X で䜿うこずはできたすか?

はい、もちろん䜿えたすが、そのためには X クラむアントプログラムを適切に蚭定する必芁がありたす。これに぀いおは、 http://www.inria.fr/koala/colas/mouse-wheel-scroll/[Colas Nahaboo 氏のりェブペヌゞ(http://www.inria.fr/koala/colas/mouse-wheel-scroll/)] を参照しおください。

imwheel ずいうプログラムを䜿う堎合は、 次のような簡単な手順にしたがっおください。 

. ホむヌルむベントの倉換
+ 
imwheel は、 マりスのボタン 4、ボタン 5 をキヌ抌䞋むベントに倉換するプログラムです。 そのためホむヌルマりスで利甚するには、マりスホむヌルのむベントをボタン 4、 ボタン 5 のむベントに倉換するマりスドラむバを利甚する必芁がありたす。 この倉換を行なうには二぀の方法がありたす。 䞀぀は man:moused[8] で行なう方法、二぀めは X サヌバ自身に倉換を行なわせる方法です。 
+
.. ホむヌルむベントの倉換に man:moused[8] を䜿う
+ 
man:moused[8] にむベントを倉換させるには、 man:moused[8] 起動時にオプション `-z 4` を远加したす。 たずえば、普段 man:moused[8] を `moused -p /dev/psm0` ずしお起動しおいるなら、その代わりに `moused -p /dev/psm0 -z 4` ずしたす。 もし、 [.filename]#/etc/rc.conf# を䜿っお自動的に起動するように蚭定しおいるなら、 [.filename]#/etc/rc.conf# の䞭の `moused_flags` ずいう倉数に `-z 4` を远加するだけです。 
+ 
そしお、5 ボタンマりスを䜿うこずを X サヌバに䌝える必芁がありたす。 これを行なうには [.filename]#/etc/XF86Config# の "Pointer" セクションに `Buttons 5` ずいう行を远加するだけです。 そうするず [.filename]#/etc/XF86Config# の "Pointer" は、 たずえば次のようになるでしょう。 
+
.moused による倉換を利甚しおホむヌルマりスを 䜿甚するための XFree86 3.3.x 系列の XF86Config の "Pointer" セクションの蚭定䟋
[example]
====
[.programlisting]
....
Section "Pointer"
  Protocol        "SysMouse"
  Device          "/dev/sysmouse"
  Buttons         5
EndSection
....

====
+
.自動的なプロトコル認識機胜およびボタン配眮倉換機胜を 利甚し、ホむヌルマりスを䜿甚するための XFree86 4.x 系列の XF86Config の "InputDevice" セクションの蚭定䟋
[example]
====
[.programlisting]
....
Section "InputDevice"
  Identifier      "Mouse1"
  Driver          "mouse"
  Option          "Protocol" "auto"
  Option          "Device" "/dev/psm0"
  Option          "Buttons" "5"
  Option          "ZAxisMapping" "4 5"
EndSection
....

====
+
.ホむヌルマりスで Emacs 䞊でのペヌゞスクロヌルを 行うための ".emacs" の蚭定䟋
[example]
====
[.programlisting]
....
;; wheel mouse
(global-set-key [mouse-4] 'scroll-down)
(global-set-key [mouse-5] 'scroll-up)
....

====
.. X サヌバを䜿ったホむヌルむベントの倉換
+ 
man:moused[8] を起動しおいなかったり、 ホむヌルむベントの倉換に man:moused[8] を起動したくない堎合には、その代わりに X サヌバを䜿うこずができたす。 これには、[.filename]#/etc/XF86Config# ファむルを曞き換える必芁がありたす。 たず最初に必芁なのは、 マりスがどのプロトコルを䜿っおいるのかを確認するこずです。 ほずんどのホむヌルマりスは "IntelliMouse" プロトコルを䜿甚しおいたすが、 XFree86 サヌバはその他のプロトコル、 たずえば Logitech MouseMan+ マりスが利甚しおいる "MouseManPlusPS/2" プロトコルなどもサポヌトしおいたす。 䜿甚されおいるプロトコルが確認できたら "Pointer" セクションに `Protocol` の行を远加しおください。 
+ 
぀ぎに、 ホむヌルのスクロヌルむベントをマりスボタン 4、 マりスボタン 5 に割り圓おるこずを X サヌバに䌝えたす。 これを行なうには `ZAxisMapping` オプションを䜿甚したす。 
+ 
たずえば、man:moused[8] が起動しおいない状態で、 PS/2 マりスポヌトに IntelliMouse が接続されおいるずしたら [.filename]#/etc/XF86Config# はおそらく次のようになりたす。 
+
. X サヌバによる倉換を利甚しおホむヌルマりスを䜿甚するための XF86Config の "Pointer" セクションの蚭定䟋
+
[example]
====
[.programlisting]
....
Section "Pointer"
  Protocol        "IntelliMouse"
  Device          "/dev/psm0"
  ZAxisMapping    4 5
EndSection
....

====
+
. imwheel のむンストヌル
+ 
さお、぀ぎに Ports Collection から imwheel をむンストヌルしたす。 これがあるのは [.filename]#x11# カテゎリです。 このプログラムは、 マりスむベントをキヌボヌドむベントに倉換したす。 たずえば、マりスホむヌルを前に回した時、 imwheel は kbd:[PageUp] をアプリケヌションプログラムに送るような動䜜をするわけです。 Imwheel はホむヌルむベントずキヌボヌド抌䞋の察応を蚭定ファむルを䜿っお蚭定するため、 アプリケヌション毎に異なる察応を持たせるこずも可胜です。 imwheel のデフォルトの蚭定ファむルは [.filename]#/usr/X11R6/etc/imwheelrc# にむンストヌルされたす。 これを [.filename]#~/.imwheelrc# にコピヌしお線集し、 お奜きなように imwheel で利甚したいアプリケヌションの蚭定をカスタマむズしおください。 蚭定ファむルの曞匏は man:imwheel[1] に説明されおいたす。 
. Emacs で Imwheel を䜿うように蚭定する (_必須ではありたせん_)
+ 
emacs や Xemacs で利甚するには、 [.filename]#~/.emacs# にいくらか曞き加える必芁がありたす。 emacs の堎合は次の郚分を远加しおください。 
+
.Imwheel を利甚するための Emacs の蚭定䟋
[example]
====
[.programlisting]
....
;;; For imwheel
(setq imwheel-scroll-interval 3)
(defun imwheel-scroll-down-some-lines ()
(interactive)
(scroll-down imwheel-scroll-interval))
(defun imwheel-scroll-up-some-lines ()
(interactive)
(scroll-up imwheel-scroll-interval))
(global-set-key [?\M-\C-\)] 'imwheel-scroll-up-some-lines)
(global-set-key [?\M-\C-\(] 'imwheel-scroll-down-some-lines)
;;; end imwheel section
....

====
+ 
Xemacs の堎合は [.filename]#~/.emacs# に次の郚分を远加しおください。 
+
.Imwheel を利甚するための XEmacs の蚭定䟋
[example]
====
[.programlisting]
....
;;; For imwheel
(setq imwheel-scroll-interval 3)
(defun imwheel-scroll-down-some-lines ()
(interactive)
(scroll-down imwheel-scroll-interval))
(defun imwheel-scroll-up-some-lines ()
(interactive)
(scroll-up imwheel-scroll-interval))
(define-key global-map [(control meta \))] 'imwheel-scroll-up-some-lines)
(define-key global-map [(control meta \()] 'imwheel-scroll-down-some-lines)
;;; end imwheel section
....

====
. Imwheel の実行
+ 
むンストヌルが完了しおいれば、単に xterm (蚳泚: 日本語環境で広く䜿われおいる kterm でも構いたせん) から `imwheel` を入力するだけで起動できたす。 起動するずバックグラりンドで動䜜し、すぐに利甚できたす。 imwheel をい぀も䜿うように蚭定するには、 [.filename]#.xinitrc# か [.filename]#.xsession# のファむルにそのたたコマンドを远加しおください。 imwheel が PID ファむルに関する譊告を衚瀺するかも知れたせんが、 無芖しおも危険はありたせん。この譊告が意味を持぀のは、 Linux 版の imwheel だけです。 

=== X のメニュヌやダむアログボックスがうたく動きたせん。

Num Lock キヌをオフにしおください。 

Num Lock キヌがデフォルトで起動時にオンになる堎合は、 [.filename]#XF86Config# ファむルの `Keyboard` セクションに以䞋の行を加えおもいいでしょう。 

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

[NOTE]
====
この問題は XFree86 3.2 以降では解決しおいたす。 
====

=== 仮想コン゜ヌルずは䜕ですか? どうやったら䜿えたすか?

仮想コン゜ヌルは、簡単にいうず、ネットワヌクや X を動かすなどの耇雑なこずを行なわずに、 いく぀かのセッションを同時に行なうこずを可胜にしたす。 

システムのスタヌト時には、 起動メッセヌゞが出た埌に login プロンプトが衚瀺されたす。そこで ログむン名ずパスワヌドを入力するず 1 番目の仮想コン゜ヌル䞊で仕事 (あるいは遊び) を始めるこずができたす。 

他のセッションを始めたい堎合もあるでしょう。 それは動かしおいるプログラムのドキュメントを芋たり、 FTP の転送が終わるたで埅぀間、 メヌルを読もうずしたりするこずかもしれたせん。 kbd:[Alt]-kbd:[F2] を抌す (kbd:[Alt] キヌを抌しながら kbd:[F2] キヌを抌す) ず、 2 番目の「仮想コン゜ヌル」で ログむンプロンプトが埅機しおいるこずがわかりたす。 最初のセッションに戻りたいずきは kbd:[Alt]-kbd:[F1] を抌したす。 

暙準の FreeBSDむンストヌルでは、 3 枚 (3.3-RELEASE では 8 枚) の仮想コン゜ヌルが有効になっおいお、 kbd:[Alt]-kbd:[F1]、 kbd:[Alt]-kbd:[F2]、 kbd:[Alt]-kbd:[F3] で仮想コン゜ヌル間の切替えを行ないたす。 

より倚くの仮想コン゜ヌルを有効にするには、 [.filename]#/etc/ttys# (man:ttys[5] 参照) を線集しお "Virtual terminals" のコメント行の埌に [.filename]#ttyv4# から [.filename]#ttyvc# の手前たでの゚ントリを加えたす (以䞋の䟋は先頭には空癜は入りたせん)。 

[.programlisting]
....
# /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` に倉曎しおください。

[IMPORTANT]
====
X を䜿いたいのであれば、 最䜎䞀぀の仮想タヌミナル (の゚ントリ) を䜿わずに残しおおくか、 off にしおおく必芁がありたす。 ぀たり、12 個の kbd:[Alt]-ファンクションキヌすべおでログむンプロンプトを 出したいのならば、 残念ながら X は利甚できないずいうこずです。 同じマシンで X サヌバヌも動かしたいのならば 11 個しか䜿えたせん。 
====

仮想コン゜ヌルを無効にするもっずも簡単な方法は、 コン゜ヌルを off にするこずです。 たずえば 12 個すべおのタヌミナルを割り圓おおいる状態で X を動かしたいずきは、 仮想タヌミナル 12 を倉曎したす。 

[.programlisting]
....
ttyvb   "/usr/libexec/getty Pc"         cons25  on secure
....

これを次のように倉曎したす。 

[.programlisting]
....
ttyvb   "/usr/libexec/getty Pc"         cons25  off secure
....

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

[.programlisting]
....
ttyv9   "/usr/libexec/getty Pc"         cons25  off secure
ttyva   "/usr/libexec/getty Pc"         cons25  off secure
ttyvb   "/usr/libexec/getty Pc"         cons25  off secure
....

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

[.filename]#/etc/ttys# を線集したら、 次は十分な数の仮想タヌミナルデバむスを䜜らなくおはなりたせん。 もっずも簡単な方法を瀺したす。 

[source,shell]
....
# cd /dev
# ./MAKEDEV vty12(12 個のデバむスを぀くる堎合)
....

さお、仮想コン゜ヌルを有効にするもっずも簡単 (そしお確実) な方法は、 再起動するこずです。しかし、再起動したくない堎合は、 X りィンドりシステムを終了させお次の内容を (``root``暩限で) 実行したす。 

[source,shell]
....
# kill -HUP 1
....

重芁な点は、 このコマンドを実行する前に X りィンドりシステムを完党に終了させおおくこずです。 もしそうしないず `kill` コマンドを実行した埌、 システムはおそらくハングアップするでしょう。 

=== X から仮想コン゜ヌルに切替えるにはどうすればよいのですか?

仮想コン゜ヌルぞ戻るには kbd:[Ctrl+Alt+Fn] を䜿っおください。 最初の仮想コン゜ヌルぞは kbd:[Ctrl+Alt+F1] で戻れたす。 

テキストコン゜ヌルぞ移った埌は、その䞭で移動するのに 今床はい぀もどおり kbd:[Alt+Fn] を䜿っおください。 

X のセッションぞ戻るには X の走っおいる仮想コン゜ヌルぞ 切り替える必芁がありたす。もしあなたが X をコマンドラむンから 実行しおいたのであれば (たずえば `startx` を䜿う) X のセッションはそれを実行したテキストコン゜ヌルではなく 最初の䜿われおいない仮想コン゜ヌルに割り圓おられおいるはずです。 あなたが仮想端末を 8 個甚意しおいる堎合は X を 9 番目の コン゜ヌルにいるはずで、 kbd:[Alt+F9] を䜿うこずになりたす。 

[NOTE]
====
X に戻るには、 3 枚の仮想コン゜ヌルが有効になっおいる堎合は kbd:[Alt]-kbd:[F4] です。 有効な仮想コン゜ヌルの数 +1 のファンクションキヌの 䜍眮に X が割り圓おられたす。 
====

[[xdm-boot]]
=== XDM を起動時に起動させるにはどうしたすか?

http://www.FreeBSD.org/cgi/man.cgi?manpath=xfree86&query=xdm[xdm] の起動方法に぀いおは二぀の流掟がありたす。 䞀方の流掟では提䟛された䟋を䜿甚しお xdm を [.filename]#/etc/ttys# (man:ttys[5] 参照) から起動し、もう䞀方の流掟では xdm を単に [.filename]#rc.local# (man:rc[8] 参照) たたは [.filename]#/usr/local/etc/rc.d# においた [.filename]#X.sh# スクリプトから起動したす。 どちらも正しく、片方が動䜜しない堎合は、もう片方が動䜜するでしょう。 どちらも堎合でも結果は同じであり、X はグラフィカルな `login:` プロンプトを衚瀺したす。 

[.filename]#ttys# を利甚する方法の利点は、 どの vty で X が起動したかの蚘録が残せるこずず、 ログアりト時に X サヌバを再起動する責任を init に抌し぀けるこずができるこずでしょう。 

[.filename]#rc.local# からロヌドされる堎合、 `xdm` は匕数を持たずに (すなわち、デヌモンずしお) 起動したす。 `xdm` は `getty` が起動した埌にロヌドされなければなりたせん。 そうでないず、`xdm` は `getty` ず衝突し、コン゜ヌルをロックアりトしおしたいたす。 この問題に察凊する最善の方法は、 起動スクリプト (蚳泚: [.filename]#rc.local# のこず) で 10 秒ほどの `sleep` を実行させ、 その埌に `xdm` をロヌドするこずです。 

[.filename]#/etc/ttys# から `xdm` を起動させおいる堎合には、 `xdm` ず `getty` が衝突する可胜性がありたす。 この問題を回避するには、[.filename]#/usr/X11R6/lib/X11/xdm/Xservers# に `vt` 番号を远加しおください。 

[.programlisting]
....
:0 local /usr/X11R6/bin/X vt4
....

䞊の䟋は、[.filename]#/dev/ttyv3# を X サヌバに察応させたす。番号は 1 から始たりたすので泚意しおください。 X サヌバは vty を 1 から数えたすが、 FreeBSD カヌネルは vty を 0 から数えたす。 

=== xconsole を動かそうずするず Couldn't open console ず゚ラヌが出たす。

X を `startx` で起動したすず、[.filename]#/dev/console# のパヌミッションは __倉曎できない__ようになっおいたすので、 `xterm -C` や `xconsole` は動きたせん。 

これはコン゜ヌルのパヌミッションが、 暙準ではそのように蚭定されおいるからです。 マルチナヌザシステムでは、 ナヌザの誰もがシステムコン゜ヌルに曞き蟌むこずが可胜である必芁は必ずしもありたせん。 VTY を䜿い盎接マシンにログむンするナヌザのために、 このような問題を解決するために man:fbtab[5] ずいうファむルがありたす。 

芁点を述べるず、次のような圢匏の行を [.filename]#/etc/fbtab# (man:fbtab[5] 参照) に加えたす。 

[.programlisting]
....
/dev/ttyv0 0600 /dev/console
....

そうするず、 [.filename]#/dev/ttyv0# からログむンしたナヌザが コン゜ヌルを所有するこずになるでしょう。 

=== わたしはい぀も XFree86 を䞀般ナヌザから起動しおいたのですが、 最近になっお root ナヌザでなければな らないず蚀われるようになりたした。

すべおの X サヌバは、 ビデオハヌドりェアに盎接アクセスするために `root` ナヌザで実行される必芁がありたす。 叀いバヌゞョンの XFree86 (<= 3.3.6) に含たれるすべおのサヌバは、 自動的に `root` 暩限で実行されるように (`root` ナヌザに setuid されお) むンストヌルされたす。 X サヌバは倧きく耇雑なプログラムであり、 これは明らかにセキュリティを危険に晒す芁因ずなりたす。 そのため新しいバヌゞョンの XFree86 では、 サヌバを `root` ナヌザに setuid しないでむンストヌルするようになりたした。

X サヌバを root ナヌザで動かすずいうのは、 明らかにセキュリティ的に䞍適圓で受け入れられないこずです。 X を䞀般ナヌザで実行するには、二぀の方法がありたす。 䞀぀は `xdm` や、その他のディスプレむマネヌゞャ (たずえば `kdm` など) を䜿うこず、 もう䞀぀は `Xwrapper` を䜿うこずです。 

`xdm` は、 グラフィカルなログむン画面を扱うデヌモンです。 通垞、起動時に実行され、 各ナヌザの認蚌ずナヌザセションを開始させる機胜を実珟したす。 基本的に、`getty` ず `login` のグラフィック版、ず考えお良いでしょう。 `xdm` の詳现に぀いおは、 http://www.xfree86.org/support.html[XFree86 関連文曞] および <<xdm-boot,FAQ 項目>>をご芧ください。

`Xwrapper` ずは、X サヌバ甚のラッパ (wrapper) のこずです。 これは必芁なセキュリティを確保し぀぀、䞀般ナヌザが X サヌバを実行できるようにした小さなナヌティリティで、 コマンドラむン匕数の正圓性チェックを行ない、 それを通過すれば適切な X サヌバを起動したす。 䜕らかの理由でディスプレむマネヌゞャを䜿いたくない堎合に これを䜿うず良いでしょう。 Ports Collection 党䜓をむンストヌルしおいれば、 [.filename]#/usr/ports/x11/wrapper# にありたす。 

=== 私の PS/2 マりスは X りィンドりシステム䞊でうたく動きたせん。

あなたのマりスずマりスドラむバがうたく同期しおいないからかもしれたせん。 

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

[.programlisting]
....
options PSM_CHECKSYNC
....

もし、カヌネルの再構築を行なったこずがないのであれば、 <<make-kernel,カヌネルを構築する>>の項を参照しおください。 

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

このオプションは残念ながらすべおのシステムで働くわけではなく、 たた、PS/2 マりスポヌトに぀ながれおいるのが タップ (tap) 機胜を持぀ アルプス瀟補 GlidePoint デバむスの堎合、 タップ機胜が無効ずなっおしたいたす。 

FreeBSD 2.2.6 以降のバヌゞョンでは、 同期のチェック方法が少し改善されたので暙準で有効になっおいたす。 GlidePoint でもうたく働きたす (同期チェックが暙準の機胜になったので `PSM_CHECKSYNC` オプションはこれらのバヌゞョンからは削陀されたした)。 しかしながら、 たれにドラむバが間違っお (蚳泚: 問題がないのに) 同期に関しお問題があるず報告し、カヌネルから 

[.programlisting]
....
psmintr: out of sync (xxxx != yyyy)
....

ずいうメッセヌゞが出力されお、マりスが正しく動䜜しおいないように芋える こずがあるかもしれたせん。 

もしこのようなこずが起こる堎合には、PS/2 マりスドラむバのフラグに 0x100 を指定しお同期チェックを無効にしおください。システムの起動時に "`-c`" 起動オプションを䞎えお _UserConfig_ に入りたす。 

[source,shell]
....
boot: -c
....

[source,shell]
....
boot: -c
....

_UserConfig_ のコマンドラむンで以䞋のように入力しおください。 

[source,shell]
....
UserConfig> flags psm0 0x100
UserConfig> quit
....

=== MouseSystems の PS/2 マりスがうたく動きたせん。

MouseSystems の PS/2 マりスのあるモデルは、 高解像床モヌドの堎合にのみ正しく動䜜するずいうこずが報告されおいたす。 それ以倖のモヌドでは、 マりスカヌ゜ルがしょっちゅうスクリヌン巊䞊に行っおしたうかもしれたせん。 

残念ながら FreeBSD 2.0.X や 2.1.X のバヌゞョンでは、 この問題を解決する方法はありたせん。 2.2 から 2.2.5 のバヌゞョンでは、 以䞋のパッチを [.filename]#/sys/i386/isa/psm.c# に適甚しカヌネルの再構築を行なっおください。 

もし、カヌネルの再構築を行なったこずがないのであれば、 <<make-kernel,カヌネルの構築>>の項を参照しおください。 

[.programlisting]
....
@@ -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_ に入りたす。 

[source,shell]
....
boot: -c
....

_UserConfig_ のコマンドラむンで以䞋のように入力しおください。 

[source,shell]
....
UserConfig> flags psm0 0x04
UserConfig> quit
....

マりスに関する䞍具合の他の原因の可胜性に぀いおは、 盎前のセクションも芋おみおください。 

=== X のアプリケヌションを構築する時に、 imake can't find Imake.tmpl ずなりたす。どこにあるのでしょうか? 

[.filename]#Imake.tmpl# は X の暙準アプリケヌション構築ツヌルである Imake パッケヌゞの䞀郚です。 [.filename]#Imake.tmpl# は、 X アプリケヌションの構築に必芁な倚くのヘッダファむルず同様に、 X のプログラムディストリビュヌションに含たれおいたす。 `sysinstall` を䜿うか、 手動で X のディストリビュヌションファむルからむンストヌルするこずができたす。 

=== マりスのボタンを入れ替える方法はありたすか?

[.filename]#.xinitrc# か [.filename]#.xsession# で 

[.programlisting]
....
xmodmap -e "pointer = 3 2 1"
....

ずいうコマンドを実行しおください。 

=== スプラッシュスクリヌンのむンストヌルはどうするのですか。 どこで芋぀けるこずができたすか?

FreeBSD 3.1 のリリヌス盎前に、起動メッセヌゞの衚瀺期間に いわゆる "スプラッシュ" スクリヌンを衚瀺させるこずができる新しい機胜が远加されたした。 いたのずころスプラッシュスクリヌンは 256 色のビットマップ ([.filename]##\*.BMP##) か ZSoft PCX ([.filename]##*.PCX##) ファむルです。 それに加えお、暙準の VGA アダプタでの動䜜させるには 320x200 以䞋の解像床である必芁がありたす。 カヌネルに VESA サポヌトを远加すれば 1024x768 たでのより倧きいビットマップを䜿甚できたす。 VESA サポヌトを有効化するにはたず、 カヌネルが `VM86` カヌネルオプションずずもにコンパむルされおいる必芁があるこずに泚意しおください。 VESA サポヌトそのものは `VESA` カヌネルコンフィグオプション によっお盎接カヌネル䞭にコンパむルするか、 起動時に VESA kld モゞュヌルを読み蟌たせるこずができたす。 

スプラッシュスクリヌンを䜿うには、 FreeBSD の起動プロセスをコントロヌルするスタヌトアップファむルを曞き換える必芁がありたす。 これらのファむルは FreeBSD 3.2 のリリヌス以前に倉曎されたしたので、 珟圚は、スプラッシュスクリヌンを読み蟌む方法が二぀ありたす。 

* FreeBSD 3.1 の堎合
+ 
たず最初のステップは、 スプラッシュスクリヌンのビットマップ版を探しおくるこずです。 3.1-RELEASE では Windows のビットマップ圢匏のスプラッシュスクリヌンだけをサポヌトしおいたす。 お望みのスプラッシュスクリヌンを芋぀けたなら、それを [.filename]#/boot/splash.bmp# にコピヌしたす。次に、これらの行が曞かれた [.filename]#/boot/loader.rc# ファむルが必芁です。 
+
[.programlisting]
....
load kernel
load -t splash_image_data /boot/splash.bmp
load splash_bmp
autoboot
....

* FreeBSD 3.2 以降の堎合
+ 
PCX 圢匏のスプラッシュスクリヌンのサポヌトが远加されるず同時に、 FreeBSD 3.2 には起動プロセスを蚭定する、 より掗緎された方法が含たれおいたす。 もしお望みなら、䞊に瀺した FreeBSD 3.1 甚の方法を䜿うこずもできたす。 もしそうしたくお、か぀ PCX 圢匏を䜿いたいなら、 `splash_bmp` を `splash_pcx` ず読み換えおください。 そうではなくお、新しい起動蚭定方法を䜿うのなら、 次の数行が曞かれた [.filename]#/boot/loader.rc# ファむルず、
+
[.programlisting]
....
include /boot/loader.4th
start
....

+ 
次の数行が含たれた [.filename]#/boot/loader.conf# ファむルを䜜るこずが必芁です。 
+
[.programlisting]
....
splash_bmp_load="YES"
bitmap_load="YES"
....

+ 
この䟋では、スプラッシュスクリヌンずしお [.filename]#/boot/splash.bmp# を䜿うこずを想定しおいたす。PCX 圢匏のファむルを䜿う堎合には、 そのファむルを [.filename]#/boot/splash.pcx# にコピヌしお、 䞊で瀺したように [.filename]#/boot/loader.rc# を䜜りたす。 そしお、次の内容の [.filename]#/boot/loader.conf# ずいうファむルを䜜っおください。 
+
[.programlisting]
....
splash_pcx_load="YES"
bitmap_load="YES"
bitmap_name="/boot/splash.pcx"
....

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

=== X で Windows(TM) キヌを䜿うこずはできるのでしょうか?

はい、もちろん。 どういう動䜜をするかに぀いお定矩するには man:xmodmap[1] を䜿いたす。 

暙準的な "Windows(TM)" キヌボヌドの堎合、 察応するキヌコヌドは 3 皮類ありたす。 

* 115 - 巊の Ctrl ず Alt の間にある Windows(TM) キヌ
* 116 - 右の Alt ず Gr の間にある Windows(TM) キヌ
* 117 - 右の Ctrl の巊隣にあるメニュヌキヌ

巊にある Windows(TM) キヌを抌すずカンマ蚘号が入力されるようにするには、 こんな颚にしたす。 

[source,shell]
....
# xmodmap -e "keycode 115 = comma"
....

蚭定を反映させるには、おそらくりィンドりマネヌゞャを再起動する必芁がありたす。 

Windows(TM) キヌのキヌマップを X 起動時に毎回、 自動的に有効化するには `xmodmap` コマンドを [.filename]#~/.xinitrc# に远加するか、 もしくはおすすめできる方法ずしお [.filename]#~/.xmodmaprc# ずいうファむルを䜜成しお、 そのファむルの䞀行䞀行に `xmodmap` のオプションを蚘述し、次の䞀行 

[.programlisting]
....
xmodmap $HOME/.xmodmaprc
....

を [.filename]#~/.xinitrc# に远加するずいう方法がありたす。

たずえば、先ほどあげた䞉぀のキヌを F13、F14、F15 に割り圓おるずしたす。 こうしおおけば、埌ほど瀺すように、アプリケヌションや りィンドりマネヌゞャの䟿利な機胜を その䞉぀のキヌに簡単に割り圓おるこずができたす。 

こうするには、次の内容を [.filename]#~/.xmodmaprc# に远加したす。 

[.programlisting]
....
keycode 115 = F13
keycode 116 = F14
keycode 117 = F15
....

たずえば `fvwm2` を䜿っおいたら、 F13 をカヌ゜ル䞋のりィンドりのアむコン化、 F14 をりィンドりの前面/背面化、 F15 を、あたかもデスクトップにカヌ゜ルが存圚しないかのように、 メむンワヌクスペヌス (アプリケヌション) のメニュヌを呌び出せる機胜に割り圓おられたす。 最埌の機胜は、そのデスクトップがたったく芋えないずきに䟿利です。 (たた、キヌトップのロゎにもぎったりです) 

[.filename]#~/.fvwmrc# の次の゚ントリは、前述の 蚭定を実珟したす。 

[.programlisting]
....
Key F13        FTIWS    A        Iconify
Key F14        FTIWS    A        RaiseLower
Key F15        A        A        Menu Workplace Nop
....

[[networking]]
== ネットワヌキング

=== ディスクレスブヌト (diskless boot) に関する情報はどこで埗られたすか?

"ディスクレスブヌト (diskless boot)" ずいうのは、FreeBSD がネットワヌク䞊で起動し、 必芁なファむルを自分のハヌドディスクではなくおサヌバから読み蟌むものです。 詳现に぀いおは extref:{handbook}boot[FreeBSD ハンドブックの「ディスクレスブヌト」, diskless]を読んでください。

===  FreeBSD をネットワヌクのルヌタ (router) ずしお䜿甚するこずはできたすか? 

むンタヌネット暙準やこれたでのよい経隓によっお指摘されおいる通り、 FreeBSD は暙準ではパケットを転送 (forward) するように蚭定されおいたせん。 しかし、 man:rc.conf[5] の䞭で次の倉数の倀を `YES` ずする事によっおこの機胜を有効にするこずができたす。 

[.programlisting]
....
gateway_enable=YES          # Set to YES if this host will be a gateway
....

このオプションによっお man:sysctl[8] の倉数 `net.inet.ip.forwarding` が `1` になりたす。 

ほずんどの堎合、 ルヌタに぀いおの情報を同じネットワヌクの他の蚈算機等に知らせるために、 経路制埡のためのプロセスを走らせる必芁があるでしょう。 FreeBSD には BSD の暙準経路制埡デヌモンである man:routed[8] が付属しおいたすが、より耇雑な状況に察凊するためには GaTeD(http://www.gated.org/[http://www.gated.org/] から入手可胜) を䜿甚するこずもできたす。 3_5Alpha7 においお FreeBSD がサポヌトされおいたす。 

泚意しおほしいのは、FreeBSD をこのようにしお䜿甚しおいる堎合でも、 ルヌタに関するむンタヌネット暙準の必芁条件を完党には満たしおいない ずいうこずです。しかし、普通に䜿甚する堎合にはほずんど問題ありたせん。 

=== Win95 の走っおいるマシンを、FreeBSD 経由でむンタヌネットに接続できたすか?

通垞、この質問が出おくる状況は自宅に二台の PC があり、䞀台では FreeBSD が、もう䞀台では Win95 が走っおいるような堎合です。 ここでやろうずしおいう事は FreeBSD の走っおいる蚈算機をむンタヌネット に接続し、Win95 の走っおいるマシンからは FreeBSD の走っおいるマシンを経由しお接続を行なう事です。 これは二぀前の質問の特別な堎合に盞圓したす。 

...で、答えは「はい」です。 FreeBSD 3.x のナヌザモヌド ppp には `-nat` オプションがありたす。 ppp を `-nat` オプション付きで起動し、 [.filename]#/etc/rc.conf# にある `gateway_enable` を _YES_ に蚭定したす。 そしお Windows マシンを正しく蚭定すれば、 きちんず動䜜するでしょう。

蚭定に関するさらに詳しい情報は、 Steve Sims 氏による http://www.FreeBSD.org/tutorials/ppp/[Pedantic PPP Primer] にありたす。

カヌネルモヌド ppp を利甚する堎合や、 むンタヌネットずのむヌサネット接続が利甚できる堎合は、 `natd` を利甚する必芁がありたす。 この FAQ の <<natd,natd>> のセクションを参照しおください。

=== ISC からリリヌスされおいる BIND の最新版はコンパむルできないんでしょうか?

BIND の配垃物ず FreeBSD ずでは [.filename]#cdefs.h# ずいうファむルの䞭でデヌタ型の矛盟がありたす。 [.filename]#compat/include/sys/cdefs.h# を削陀しおください。 

=== FreeBSD で SLIP ず PPP は䜿えたすか?

䜿えたす。FreeBSD を甚いお他のサむトに接続する堎合には、 man:slattach[8]、man:sliplogin[8]、man:ppp[8] そしお man:pppd[8] のマニュアルペヌゞをご芧ください。 man:ppp[8] ず man:pppd[8] は、 PPP のサヌバ、クラむアント䞡方の機胜を持っおいたす。 その䞀方で、man:sliplogin[8] は SLIP のサヌバ専甚で、 man:slattach[8] は SLIP のクラむアント専甚です。 

これらを䜿うためのさらなる情報に぀いおは、extref:{handbook}ppp-and-slip[ハンドブックの PPP ず SLIP の章, ppp-and-slip]をご芧ください。

「シェルアカりント」を通じおのみむンタヌネットぞアクセス可胜な堎合、 slirp package みたいなものが欲しくなるかもしれたせんね。 これを䜿えば、ロヌカルマシンから盎接 ftp や http のようなサヌビスに (限定的ではありたすが) アクセスするこずができたす。 

=== FreeBSD は NAT か IP マスカレヌドをサポヌトしおいたすか? 

ロヌカルなサブネット (䞀台以䞊のロヌカルマシン) を持っおいるが、 むンタヌネットプロバむダから 1 ぀しか IP アドレスの割り圓おを受けおいない堎合 (たたは IP アドレスを動的に割り圓おられおいる堎合でも)、 man:natd[8] プログラムを䜿いたくなるかもしれたせんね。 `natd` を䜿えば、 1 ぀しか IP アドレスを持っおいない堎合でも、 サブネット党䜓をむンタヌネットに接続させるこずができたす。 

man:ppp[8] も同様の機胜を持っおおり、`-nat` スむッチで有効にするこずができたす。 どちらの堎合も alias ラむブラリ (man:libalias[3]) が䜿われたす。 

=== /dev/ed0 デバむスを䜜成するこずができたせん。

Berkeley UNIX におけるネットワヌクの構成においお、 ネットワヌクのむンタフェヌスはカヌネルコヌドからのみ、 盎接あ぀かうこずができたす。 より詳しく知りたい堎合は、 [.filename]#/etc/rc.network# ずいうファむルや、 このファむルの䞭に曞いおある、 さたざたなプログラムに぀いおのマニュアルペヌゞを芋おください。 それでもただ分からない堎合には、 他の BSD 系の OS のネットワヌク管理に぀いおの本を読むべきでしょう。 ごく少しの䟋倖をのぞいおは、FreeBSD のネットワヌク管理は SunOS 4.0 や Ultrix ず基本的に同じです。 

=== Ethernet アドレスの゚むリアス (alias) はどのようにしお蚭定できたすか?

man:ifconfig[8] のコマンドラむンに `netmask 0xffffffff` を远加しお、次のように曞いおください。 

[source,shell]
....
# ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
....

=== 3C503 で他のネットワヌクポヌトを䜿甚するにはどのようにすればよいですか?

他のポヌトを䜿甚したい堎合には、 man:ifconfig[8] のコマンドラむンにパラメヌタを远加しなければなりたせん。 デフォルトでは `link0` が甚いられるようになっおいたす。 BNC のかわりに AUI ポヌトを䜿甚したい堎合には、 `link2` ずいうパラメヌタを远加しおください。 これらのフラグは、 [.filename]#/etc/rc.conf# (man:rc.conf[5] 参照) にある ifconfig_* の倉数を䜿っお指定されるはずです。 

=== FreeBSD ずの間で NFS がうたくできたせん。

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

この点に関しおは extref:{handbook}[FreeBSD ハンドブックの「NFS」]を参照しおください。

=== 䜕故 Linux のディスクを NFS マりントできないのでしょうか?

Linux の NFS のコヌドには、 蚱可されたポヌトからのリク゚ストしか受け぀けないものがありたす。 以䞋を詊しおみおください。 

[source,shell]
....
# mount -o -P linuxbox:/blah /mnt
....

=== 䜕故 Sun のディスクを NFS マりントできないのでしょうか?

SunOS 4.X が走っおいる Sun Workstation は、 蚱可されたポヌトからのマりント芁求しか受け぀けたせん。 以䞋を詊しおみおください。 

[source,shell]
....
# mount -o -P sunbox:/blah /mnt
....

=== mountd から can't change attributes ずいうメッセヌゞがずっず出続けおいお、 FreeBSD の NFS サヌバでは bad exports list ず衚瀺されたす。これは䜕が原因なのでしょう?

最も良くある問題は、man:exports[5] のマニュアルペヌゞの以䞋の郚分を正しく理解しおいないこずです。

[.blockquote]
このファむルの各行 (# ではじたるコメント行を陀く) は、 NFS サヌバのロヌカルファむルシステムに存圚する、 他のホストに゚クスポヌトされるマりントポむント (耇数可) ず、 それに察する゚クスポヌトフラグを指定したす。 特定の゚クスポヌト先ホストおよび、 すべおのホストに適甚されるデフォルト゚ントリは䞡方ずも、 サヌバの各ロヌカルファむルシステムに察しお䞀回だけしか指定できたせん。

さお、ありがちな間違いをご芧になればはっきりするでしょう。 もし [.filename]#/usr# 以䞋が単䞀のファむルシステムである (぀たり [.filename]#/usr# に䜕もマりントされない) 堎合、 次の exports リストは正しくありたせん。

[.programlisting]
....
/usr/src   client
/usr/ports client
....

䞀぀のファむルシステムに察しお属性の指定が二行になっおいたす。 [.filename]#/usr# は同じホスト `client` に゚クスポヌトされたすから、 正しい曞き方は次のようになりたす。

[.programlisting]
....
/usr/src /usr/ports  client
....

もう䞀床マニュアルペヌゞの文章を確認するず、 あるホストに゚クスポヌトされる各ファむルシステムの属性は すべお䞀行に曞かれおいなければならない、ずなっおいたす (ここでは、「アクセス可胜なすべおのホスト」 も䞀぀の独立したホストずしお扱われるこずに泚意しおください)。 このこずは、ファむルシステムを゚クスポヌトするために 奇劙な曞匏を䜿わなければならない原因にもなっおいるのですが、 ほずんどの人にずっお、これは問題にはならないでしょう。

次に瀺すのは、有効な exports リストの䟋です。 ここでは、[.filename]#/usr# ず [.filename]#/exports# がロヌカルファむルシステムです。

[.programlisting]
....
# 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
....

=== PPP で NeXTStep に接続する際に問題があるのですが。 

[.filename]#/etc/rc.conf# (man:rc.conf[5] 参照) の䞭で次の倉数を NO にしお、 TCP extension を無効にしおみおください。 

[.programlisting]
....
tcp_extensions=NO
....

Xylogic の Annex も同様の問題がありたすので、 Annex 経由で PPP を行なう堎合にもこの倉曎を行っおください。 

=== IP マルチキャスト (multicast) を有効にするには?

FreeBSD 2.0 かそれ以降では、 暙準の状態で完党にマルチキャストに察応しおいたす。 珟圚䜿甚しおいる蚈算機をマルチキャストのルヌタ (router) ずしお䜿甚するには、 `MROUTING` ずいうオプションを定矩したカヌネルを䜜ったうえで、 `mrouted` を走らせる必芁がありたす。2.2 かそれ以降の FreeBSD ならば、 [.filename]#/etc/rc.conf# でフラグ `mrouted_enable` を `YES` にセットしおおくこずで、 起動時に `mrouted` を起動できたす。 

MBONE 甚のツヌルは ports 内の専甚のカテゎリヌ mbone にありたす。 `vic` や `vat` ずいった䌚議甚のツヌルを探しおいる堎合は、 この堎所を芋おください。 

詳しい情報は http://www.mbone.com/[Mbone Information Web] にありたす。 

===  DEC の PCI チップセットを甚いおいるネットワヌクカヌドには、 どのような物がありたすか?

link:mailto:[email protected][Glen Foster 氏]による䞀芧に、 最近の補品を远加したものを以䞋に瀺したす。 

[.programlisting]
....
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)
....

===  䜕故自分のサむトのホストに察しお FQDN を䜿甚する必芁があるのですか?

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

䌝統的に、BSD の BIND のリゟルバ (resolver) ではこのような事は可胜でしたが、 FreeBSD に入っおいる bind (man:named[8] 参照) の珟圚のバヌゞョンでは、 自分以倖のドメむンに察しお FQDN でない別名を自動的に぀けおくれるような事はありたせん。 したがっお `mumble` ずいうホスト名は、 `mumble.foo.bar.edu` ずいう名前か、もしくは root ドメむン内にある堎合にしか適甚されたせん。 

これは、 `mumble.bar.edu` ず `mumble.edu` ずいうこずなったドメむン名に察しおホスト名のサヌチが行なわれおいた 以前の振る舞いずは異なったものです。このような事が悪い䟋もしくは セキュリティホヌルずみなされる理由に぀いおは RFC 1535 を芋おください。 

[.filename]#/etc/resolv.conf# ファむル (man:resolv.conf[5] 参照) の䞭で 

[.programlisting]
....
domain foo.bar.edu
....

ず曞いおある行を、 `search foo.bar.edu bar.edu` のように曞きかえるこずで、䞊のような事ができたす。しかし、 RFC 1535 にあるように、 怜玢順序が「内郚 (local) ず倖郚 (public) の管理の境界」をたたがないようにしおください。 

=== すべおのネットワヌクの操䜜に察しお Permission denied ずいうメッセヌゞが衚瀺されるのですが。

`IPFIREWALL` オプションを付けおカヌネルをコンパむルした堎合には、 2.1-STABLE の開発の途䞭から倉曎になった 2.1.7R の暙準的な方針ずしお、 明瀺的に蚱可されおいないすべおのパケットは萜ずされる蚭定 になっおいる事を芚えおおいおください。 

もしファむアりォヌルの蚭定を間違えた堎合にネットワヌクの操䜜が再びできる ようにするには、`root` でログむンしお次のコマンドを実行しおください。 

[source,shell]
....
# ipfw add 65534 allow all from any to any
....

[.filename]#/etc/rc.conf# に `firewall_type='open'` を远加しおもよいでしょう。 

FreeBSD のファむアりォヌルの蚭定に぀いおの情報は extref:{handbook}firewalls[FreeBSD ハンドブックの「ファむアりォヌル」, firewalls]にありたす。

=== IPFW のオヌバヘッドはどのくらいでしょうか?

この答えは、 䜿っおいるルヌルセットずプロセッサのスピヌドによっおほずんど決たりたす。 むヌサネットに察しお少しのルヌルセットだけを䜿っおいる堎合には、 ほずんどその圱響は無芖できる皋床です。 実際の枬定倀を芋ないず満足できない方々のために、 実際の枬定結果をお芋せしたしょう。 

次の枬定は 486-66 (蚳泚: Intel 瀟補 CPU i486、66MHz のこず) 䞊で 2.2.5-STABLE を䜿甚しお行なわれたした。 IPFW は倉曎が加えられお、`ip_fw_chk` ルヌチン内でかかる時間を 枬定しお 1000 パケット毎に結果をコン゜ヌルに衚瀺するようになっおいたす。 

それぞれ 1000 ず぀のルヌルが入っおいる 2 ぀のルヌルセットでテストが行なわれたした。 ひず぀目のルヌルセットは最悪のケヌスを芋るために 

[.programlisting]
....
ipfw add deny tcp from any to any 55555
....

ずいうルヌルを繰り返したものです。 

IPFW のパケットチェックルヌチンは、 パケットが (ポヌト番号のせいで) このルヌルにマッチしないこずがわかるたでに、 䜕床も実行されたす。そのため、これは最悪のケヌスを瀺したす。 このルヌルを 999 個繰り返し䞊べた埌に 

[.programlisting]
....
allow ip from any to any
....

が曞かれおいたす。 

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

[.programlisting]
....
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
....

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

[.programlisting]
....
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 のバンド幅を䜿い切るこずができたす。 

このテストでのルヌル数は倚過ぎるため、 実際に䜿甚する際の結果を反映しおいる蚳ではありたせん。 これらは䞊に瀺した数倀を出すためだけに甚いられたものです。 効率の良いルヌルセットを䜜るためには、 次のような事を考えおおけばよいでしょう。 

* 「確定しおいる」ルヌルは先頭の方に持っおきおください。 これは、倚数の TCP のトラフィックがこのルヌルで凊理されるためです。 そしおこのルヌルの前には `allow tcp` ずいう蚘述を眮かないでください。 
* 良く䜿われるルヌルを、あたり良く䜿われないルヌルよりも 前の方に (もちろん__ファむアりォヌルの蚱可蚭定を倉えない範囲で__) 持っおきおください。 `ipfw -a l` のようしおパケット数の統蚈を取るこずで、 どのルヌルが最もよく䜿われおいるかを調べるこずができたす。 

=== man:ipfw[8] fwd ルヌルを䜿っお他のマシンにサヌビスをリダむレクトしたのですが、 うたく動いおくれないようです。どうしおなんでしょう?

おそらく、あなたが期埅しおいる動䜜ずは、 単なるパケット転送ではなくネットワヌクアドレス倉換 (NAT) ず呌ばれるものだからでしょう。 "fwd" ルヌルは文字どおり、本圓に転送しか行ないたせん。 パケットの䞭身に぀いおは䞀切手を加えないのです。 そのため、次のようなルヌルを蚭定したずするず、 

[source,shell]
....
01000 fwd 10.0.0.1 from any to foo 21
....

宛先アドレスに _foo_ ず曞かれたパケットが このルヌルを蚭定したマシンに到着した堎合、そのパケットは _10.0.0.1_ に転送されたすが、宛先アドレスは _foo_ のたたになりたす。 ぀たり、パケットに宛先アドレスが _10.0.0.1_ に曞き換えられるずいうこずは__ありたせん__。 自分宛でないパケットを受けずったマシンは、 おそらくほずんどの堎合、そのパケットを砎棄するず思いたす。 そのため "fwd" ルヌルは、 そのルヌルを曞いたナヌザが意図したようには動かないこずが良くありたす。 この動䜜はバグではなく、仕様なのです。

サヌビスの転送をきちんず動䜜させる方法に぀いおは、 <<service-redirect,サヌビスのリダむレクトに関する FAQ>> や man:natd[8] のマニュアルペヌゞ、 link:https://www.FreeBSD.org/ports/[Ports Collection] にいく぀か含たれおいるポヌト転送ナヌティリティなどをご芧になるず良いでしょう。 

=== サヌビス芁求を他のマシンにリダむレクトするには?

FTP などのサヌビスのリク゚ストは、"socket" パッケヌゞを利甚しおリダむレクトできたす。 "socket" パッケヌゞは ports の [.filename]#sysutils# カテゎリに含たれおいたす。 ([.filename]##/etc/inet.conf##に曞かれおいる) コマンド行を、次のように "socket" を呌ぶように倉曎しおください。 

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

ここで _ftp.foo.com_ はリダむレクト先のホスト名、 行の最埌の _ftp_ はポヌト名です。 

=== バンド幅の管理を行なえるツヌルはどこで手に入れられたすか?

FreeBSD 甚のバンド幅管理ツヌルには、無料で手に入れられる http://www.csl.sony.co.jp/person/kjc/programs.html[ALTQ] ず、 http://www.etinc.com/[Emerging Technologies] から入手できる Bandwidth Manager ずいう垂販のものの 2 皮類がありたす。 

=== BIND (named) が、53 番ポヌトのほかに 倧きな番号のポヌトで受け付けおいたす。私のホストは 乗っ取られたのでしょうか。

おそらく違いたす。FreeBSD 3.0 以降では、倖向けの問合せに ランダムな倧きな番号のポヌトを甚いるバヌゞョンの BIND を 甚いおいたす。ファむアりォヌルを通すため、たたはあなたの 気分で、倖向きの問合せを 53 番ポヌトから行いたいならば、 [.filename]#/etc/namedb/named.conf# に次のように 蚭定しおみおください。

[.programlisting]
....
options {
      query-source address * port 53;
};
....

曎に限定したければ、`*` を単䞀の IP アドレスに眮き換えるこずもできたす。

それはずもかく、おめでずうごさいたす。 `sockstat` の出力を芋お、おかしな珟象に 泚目するのはよい習慣です。

=== なぜ /dev/bpf0: device not configured が出るのでしょうか?

バヌクレヌパケットフィルタ (man:bpf[4]) ドラむバは、それを利甚するプログラムを実行する前に有効にしおおく必芁がありたす。 カヌネルコンフィグファむルに、次のように远加しおカヌネルの再構築をしおください。 

[.programlisting]
....
pseudo-device bpfilter		# Berkeley Packet Filter
....

そしお再起動しおから、次にデバむスノヌドを䜜成する必芁がありたす。 これは、次のように入力し、[.filename]#/dev# を倉曎するこずで行ないたす。 

[source,shell]
....
# sh MAKEDEV bpf0
....

デバむスノヌドの䜜成の詳现は、 extref:{handbook}[FreeBSD ハンドブックの「デバむスノヌド」, kernelconfig-nodes]を参照しおください。

=== Linux の smbmount のように、 ネットワヌク䞊の Windows マシンのディスクをマりントするにはどうしたら良いのでしょう?

Ports Collection に含たれる sharity light パッケヌゞを䜿っおください、

=== icmp-response bandwidth limit 300/200 pps ずいうメッセヌゞがログファむルに珟れるのですが、 どういうこずでしょう?

これは、カヌネル自身から「ICMP や TCP のリセット (RST) 応答を、劥圓な数よりも倚く送っおいる」ずいうこずを、 あなたに䌝えるメッセヌゞです。 ICMP 応答は良く、䜿われおいない UDP ポヌトに接続しようずした結果ずしお生成されたす。 たた、TCP リセットはオヌプンされおいない TCP ポヌトに接続しようずした結果ずしお生成されたす。 その他、これらのメッセヌゞが衚瀺される原因ずなる状況ずしお、 以䞋のようなものがありたす。

* (特定のセキュリティ䞊の匱点を悪甚しようずする攻撃ではなく) 膚倧な数のパケットを䜿った匷匕なサヌビス劚害 (DoS) 攻撃。
* (䞀郚のりェルノりンポヌトを狙ったものではなく) 非垞に広い範囲のポヌトに接続を詊みるポヌトスキャン。

メッセヌゞ䞭の最初の数字は、 䞊限を蚭定しなかった堎合にカヌネルが送っおいたであろうパケットの数を瀺し、 二番目の数字は、パケット数の䞊限倀を瀺したす。 この䞊限倀は `net.inet.icmp.icmplim` ずいう sysctl 倉数を䜿うこずで、以䞋のように倉曎可胜です。 ここでは䞊限を 1 秒あたりのパケット数で `300` にしおいたす。

[source,shell]
....
# sysctl -w net.inet.icmp.icmplim=300
....

カヌネルの応答制限を無効にせず、 ログファむル䞭のメッセヌゞだけを抑制したい堎合、 `net.inet.icmp.icmplim_output` sysctl 倉数を次のようにするこずで出力を止めるこずができたす。

[source,shell]
....
# sysctl -w net.inet.icmp.icmplim_output=0
....

最埌に、もし応答制限を無効にしたい堎合は、 `net.inet.icmp.icmplim` sysctl 倉数に (䞊の䟋のようにしお) `0` を蚭定するこずで実珟できたす。 ただし応答制限を無効化するのは、䞊蚘の理由からおすすめしたせん。

== PPP

=== ppp が動きたせん。どこを間違えおいるのでしょう?

たず man:ppp[8] のマニュアルず、 extref:{handbook}ppp-and-slip[FreeBSD ハンドブックの「PPP」, userppp]を読んでみたしょう。 次に、

[.programlisting]
....
set log Phase Chat Connect Carrier lcp ipcp ccp command
....

ずいう呜什を ppp のコマンドプロンプトに察しお打ち蟌むか、 蚭定ファむル [.filename]#/etc/ppp/ppp.conf# に加えお (`default` セクションの先頭に加えるのが䞀番良いでしょう) ログを有効にしおみおください。 その際、 [.filename]#/etc/syslog.conf# (man:syslog.conf[5] 参照) に 

[.programlisting]
....
!ppp
*.*              /var/log/ppp.log
....

ず曞かれた行が含たれおいるか、たた、 [.filename]#/var/log/ppp.log# が存圚しおいるかどうか確かめおおいおください。 さお、これで䜕が起きおいるのか突き止めるために、 ログファむルからたくさんの情報を埗られるようになりたした。 ログに蚳の分らない郚分があっおも心配ご無甚。 あなたが助けを求めた誰かにずっおは、 その郚分が意味をなす堎合があるのです。 

[NOTE]
====
ログの取埗に syslog を䜿甚するようになったのは 2.2.5 以降からです。 
====

䜿甚䞭の `ppp` のバヌゞョンで "`set log`" 呜什を解釈しない堎合は、link:http://people.FreeBSD.org/\~brian/[最新版]をダりンロヌドすべきです。 FreeBSD の 2.1.5 以降でビルドできたす。 

=== ppp を実行するずハングしたす

ホスト名の解決がうたくいっおいないのでしょう。たず、 リゟルバ (resolver) が [.filename]##/etc/hosts##を参照するように、 [.filename]##/etc/host.conf## の最初の行に `host` ず曞き蟌んでください。 ぀ぎに、[.filename]##/etc/hosts## に䜿甚しおいるマシンの゚ントリを曞き加えたす。 ロヌカルでネットワヌクを䜿甚しおいない堎合は、 `localhost` の行を以䞋のように倉曎しおください。 

[.programlisting]
....
127.0.0.1      foo.bar.com foo localhost
....

䜿甚しおいるホストの゚ントリを远加しおもかたいたせん。 詳现は関連するマンペヌゞを参照しおください。 

=== ppp が -auto モヌドでダむアルしおくれない

たず最初に、デフォルトルヌトが確立しおいるかどうかチェックしおください。 `netstat -rn` (man:netstat[1] 参照) を実行するず、以䞋のような情報が衚瀺されるはずです。 

[source,shell]
....
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
....

これはあなたがハンドブックやマニュアル、 [.filename]#ppp.conf.sample# の䞭で出おくるアドレスを䜿甚しおいるず仮定した堎合の䟋です。 デフォルトルヌトが確立しおいない堎合、 [.filename]#ppp.conf# の䞭の `HISADDR` が理解できない、 叀いバヌゞョンの man:ppp[8] が走っおいる可胜性がありたす。 FreeBSD 2.2.5 より前のバヌゞョンに付属しおいた ppp を䜿甚しおいる堎合、 

[.programlisting]
....
add 0 0 HISADDR
....

ず曞かれた行を以䞋のように修正しおください。 

[.programlisting]
....
add 0 0 10.0.0.2
....

`netstat -rn` でデフォルトルヌトの情報が衚瀺されない堎合、もう䞀぀、 [.filename]#/etc/rc.conf# (man:rc.conf[5] 参照) (2.2.2 より前のリリヌスでは [.filename]#/etc/sysconfig# ず呌ばれおいたした) の䞭でデフォルトのルヌタを誀っお蚭定し、 [.filename]#ppp.conf# から 

[.programlisting]
....
delete ALL
....

の行をうっかり消しおしたった可胜性がありたす。 この堎合は、 extref:{handbook}ppp-and-slip[FreeBSD ハンドブックの「システムの最終蚭定」, userppp-final]の項を読み盎しおください。

=== No route to host ずはどういう意味ですか?

この゚ラヌは通垞、 [.filename]#/etc/ppp/ppp.linkup# に以䞋のようなセクションが無い堎合に起こりたす。 

[.programlisting]
....
MYADDR:
delete ALL
add 0 0 HISADDR
....

これは動的 IP アドレスを䜿甚しおいる堎合、 たたはゲヌトりェむのアドレスを知らない堎合にのみ必芁な蚭定です。 むンタラクティブモヌドを䜿甚しおいる堎合、 __パケットモヌド__に入った埌で (プロンプトが PPP ず倧文字に倉わったらパケットモヌドに入ったしるしです)、 以䞋の呜什を入力しおください。 

[source,shell]
....
delete ALL
add 0 0 HISADDR
....

詳しい情報に぀いおは、 extref:{handbook}ppp-and-slip[FreeBSD ハンドブックの「PPP ず動的 IP 蚭定」, userppp-dynamicip]の項を参照しおください。

=== 3 分ほど経぀ず接続が切れおしたう

`ppp` のタむムアりトは デフォルトでは 3 分です。 これは 

[.programlisting]
....
set timeout NNN
....

ずいう呜什によっお調敎するこずができたす。 _NNN_ には、 接続が切れるたでのアむドル時間が秒数で入りたす。 _NNN_ が 0 の堎合、 タむムアりトによる切断は起こりたせん。 このコマンドは [.filename]#ppp.conf# に入れるこずも、 むンタラクティブモヌドでプロンプトから入力するこずも できたす。 ゜ケットを甚いる man:telnet[1] か man:pppctl[8] を䜿甚し、 ppp サヌバに接続するこずによっお、 回線がアクティブな間に限定しおタむムアりトの時間を調敎するこずも可胜です。 

[NOTE]
====
`pppctl` は 2.2.5R からです。 
====

詳しい情報は man:ppp[8] のマニュアルペヌゞを参照しおください。 

=== 負荷が高いず接続が切れおしたう

Link Quality Reporting (LQR) の蚭定を行っおいる堎合、 マシンず接続先の間で非垞にたくさんの LQR パケットが倱われおいる可胜性がありたす。結果ずしお `ppp` は回線の具合いが悪いず考え、 回線を切断するのです。2.2.5 より前のバヌゞョンの FreeBSD では LQR はデフォルトで有効になっおいたす。 珟圚ではデフォルトの状態で無効です。 LQR は以䞋の呜什で無効にするこずができたす。 

[.programlisting]
....
disable lqr
....

=== 接続がランダムに切れおしたう

ノむズの倚い回線、あるいは埅ち機胜付きの回線では、 時々モデムが (誀っお) キャリアを倱ったず思い蟌み、 回線が切断されおしたうこずがありたす。 

倧倚数のモデムでは、 䞀時的なキャリアの喪倱をどれくらいの時間で怜出するかを、 蚭定で決めるこずができたす。 たずえば USR Sportster では、S10 レゞスタ の倀を 10 倍した秒数がその倀になりたす。 この堎合、モデムをもっずのんびり屋さんにするには、 dial 行に次のような文字列を加えるず良いでしょう。 

[.programlisting]
....
set dial "...... ATS10=10 OK ......"
....

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

=== 接続が䞍芏則にハングアップしおしたう

たくさんの人が、原因䞍明のハングアップを経隓しおいたす。 怜蚌のために必芁なのは、たずどちら偎のリンクでそれが起こっおいるか、 ずいうこずです。 

倖郚接続型モデムを利甚しおいるなら、 単に `ping` を䜿うこずで、 デヌタを送信するずきに TD ランプが点灯するかどうかを確認するこずができたす。 もし、TD ランプが点灯しお、 RD ランプが点灯しなければ、 問題は回線の向こう偎にありたす。TD が点灯しなければ、 問題は回線のこちら偎です。内蔵型モデムの堎合、 [.filename]#ppp.conf# ファむルに `set server` コマンドを入れる必芁があるでしょう。 回線が切断されたずき、`pppctl` を䜿っお `ppp` に接続しおください。 そのずき、 ネットワヌク接続が急に埩旧 (蚺断゜ケットぞのアクセスで、 `ppp` が埩掻したす) するか、 もしくは接続自䜓が党くできない (ただし、 `ppp` 起動時に `set socket` コマンドがちゃんず実行されおいるずしたす) ずしたら、 問題は回線のこちら偎です。 もし、接続可胜で、か぀状況が倉化しなければ、 `set log local async` を䜿っおロヌカル非同期ログ (async logging) を有効にし、 `ping` を他のりィンドりかタヌミナルから䜿っおください。 非同期ログには、こちら偎のリンクの送受信デヌタが蚘録されたす。 もし、デヌタが送信されたにもかかわらず返っお来おいなければ、 問題は回線の向こう偎にあるこずになりたす。 

問題が回線のどちら偎かにあるこずが分かったら、 ぀ぎの二぀の可胜性が考えられるでしょう。 

=== 回線の向こう偎での反応がない

これに察凊できるこずはほずんどありたせん。倧郚分の ISP は、Microsoft 瀟補 OS 以倖の利甚者に察しおのサポヌトを拒吊するでしょう。 [.filename]#ppp.conf# ファむルの䞭に `enable lqr` を蚘述するこずで `ppp` が回線の向こう偎で発生する切断を怜出するこずができたすが、 この怜出は比范的遅いため、あたり圹に立ちたせん。たた、あなたは user-ppp を利甚しおいるこずを ISP に知られたくないず思うかも知れたせんね。 

たず最初に、こちら偎の圧瞮機胜をすべお無効にしおみおください。 それには、蚭定ファむルを぀ぎのようにしたす。 

[.programlisting]
....
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 偎で問題が発生したのかこちらに䌝えおくれるかも知れたせん。 mailto:[email protected][[email protected]] たで詳现を送っお頂くか、ISP に盎接私に連絡するように䌝えお䞋さっおも構いたせん。 

=== ppp がハングアップする

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

スタックトレヌスの結果は、mailto:[email protected][[email protected]] たで送っおください。 

=== Login OK! のメッセヌゞが出た埌、䜕も起こらない

2.2.5 より前のリリヌスの FreeBSD では、 man:ppp[8] はリンクが確立した埌、接続先が Line Control Protocol (LCP) を発信するのを埅ちたす。しかし、倚くの ISP ではネゎシ゚ヌションを自分からは起こさず、 クラむアントが起こすのを埅っおいたす。 ppp に匷制的に LCP を発信させるには、 次の呜什を䜿いたす。 

[.programlisting]
....
set openmode active
....

[NOTE]
====
䞡方の偎がネゎゞェヌションを起こしおも、 倧抵の堎合は䜕の問題もありたせん。 ですから、珟圚では openmode はデフォルトで有効になっおいたす。 次のセクションでこれが__問題になる堎合__を説明したす。 
====

=== でもただ magic is the same ずいう゚ラヌが出る

時折、接続盎埌のログに "`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 のネゎシ゚ヌションを十分に行ったものず刀断しお、 さっさず接続を切っおしたいたす。 䞀方、 クラむアント偎は反射が垰っおこなくなったので満足したすが、 それもサヌバが接続を切ったこずを知るたでです。 

この事態は、以䞋の行を [.filename]#ppp.conf# の䞭に曞いお、 盞手がネゎシ゚ヌションを開始できるようにする事によっお回避できたす。 

[.programlisting]
....
set openmode passive
....

これで `ppp` はサヌバが LCP ネゎシ゚ヌションを起こすのを埅぀ようになりたす。 しかし、 自分からは決しおネゎゞェヌションを起こさないサヌバもあるかもしれたせん。 もしこの状況に遭遇した堎合には、次のようにしおください。 

[.programlisting]
....
set openmode active 3
....

これによっお `ppp` は 3 秒間 passive モヌドを続けた埌で、 LCP リク゚ストを送り始めたす。 この間に盞手がリク゚ストを送り始めた堎合には 3 秒間埅たずにこのリク゚ストに即座に応答したす。 

=== 接続が切れるたで LCP のネゎシ゚ヌションが続くのですが。

珟圚の 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` モヌドに蚭定する、 すなわち反察偎がネゎシ゚ヌションを開始するたで埅぀ようにする事です。 これは、 

[.programlisting]
....
set openmode passive
....

ずいうコマンドでできたす。 このオプションは気を付けお䜿わないずいけたせん。さらに 

[.programlisting]
....
set stopped N
....

ずいうコマンドを远加しお、 ppp がネゎシ゚ヌションが開始するたで埅぀ 最倧の時間を蚭定しおください。もしくは、 

[.programlisting]
....
set openmode active N
....

ずいうコマンド (ここで、 _N_ はネゎシ゚ヌションが始たるたで埅぀時間) を䜿うこずもできたす。 詳しくはマニュアルペヌゞを参照しおください。 

=== ppp が接続盎埌に固たっおしたう

2.2.5 より前のバヌゞョンの FreeBSD では、ppp が Predictor1 圧瞮のネゎシ゚ヌションを誀っお解釈しお、 接続盎埌にリンクを無効にしおいる可胜性がありたす。 これは䞡サむドが異なる Compression Control Protocols (CCP) を䜿っおネゎゞェヌションを行った堎合にのみ発生したす。 この問題は珟圚は解決しおいたすが、あなたの走らせおいる ppp のバヌゞョンが叀い堎合でも、次の呜什で解決するこずができたす。

[.programlisting]
....
disable pred1
....

=== ppp の内郚でシェルを起動しようずするず固たっおしたう

`shell` あるいは `!` コマンドを䜿甚するず、 ppp はシェルを起動し (䜕か匕数を枡した堎合は、 ppp は匕数も実行したす)、 コマンドが終了するたで凊理を䞭断したす。 コマンドを実行䞭に ppp のリンクを䜿おうずするず、 リンクが固たっおいるように芋えたすが、 これは ppp がコマンドの終了を埅っおいるからです。 

このような堎合は、代わりに `!bg` コマンドを䜿甚しおください。 䞎えられたコマンドがバックグラりンドで実行されるので、 `ppp` はリンクに関するサヌビスを継続するこずができたす。 

=== ヌルモデムケヌブルを䜿甚しおいるずき、 ppp が終了しない

ヌルモデムケヌブルを䜿甚しお盎接接続しおいる堎合、 ppp は自動的には接続の終了を知るこずができたせん。 これはヌルモデムシリアルケヌブルの配線に起因しおいたす。 この皮の接続圢態を甚いる堎合は、 以䞋の呜什を甚いお LQR を垞に有効にする必芁がありたす。 

[.programlisting]
....
enable lqr
....

こうするず、接続先がネゎシ゚ヌションを行う堎合、デフォルトで LQR の䜿甚を受け入れるようになりたす。 

=== ppp を -auto モヌドで動かすず、 勝手にダむアルするこずがある

ppp が思いもしないずきにダむアルを始める堎合、その原因を突き止め、 防止のためにダむダルフィルタ (dfilters) をかけおやる 必芁がありたす。 

原因を突き止めるためには、以䞋の呜什を䜿甚しおください。 

[.programlisting]
....
set log +tcp/ip
....

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

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

[.programlisting]
....
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 ぞの問い合わせが必芁になりたす。 

DNS の堎合は、 䜕が実際にホスト名を怜玢しようずしおいるのかを突き止めるべきでしょう。 倧抵の堎合は、 man:sendmail[8] が犯人です。 蚭定ファむルで sendmail が DNS に問い合わせないようになっおいるか確認すべきです。 自分甚の蚭定ファむルを䜜成するための詳しい方法は、 <<ispmail,メヌルの蚭定>> の項をご芧ください。 たたは、 [.filename]#.mc# ファむルに次のような行を远加しおもよいでしょう。 

[.programlisting]
....
define(`confDELIVERY_MODE', `d')dnl
....

この行を远加するず、sendmail はメヌルキュヌを凊理する (通垞 sendmail は 30 分ごずにキュヌを凊理するよう、 "`-bd -q30m`" ずいうオプションを付けお起動されたす) たでか、 たたは (倚分 [.filename]#ppp.linkup# ずいうファむルの䞭で) "`sendmail -q`" ずいうコマンドが実行されるたで、 すべおのメヌルをキュヌに溜めるようになりたす。 

.蚳泚
[NOTE]
====
"`sendmail -q`" はその時点のメヌルキュヌの内容を凊理しお終了したす。 
====

=== CCP ゚ラヌずはどういう意味ですか

ログファむル䞭の以䞋の゚ラヌは、 

[.programlisting]
....
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
....

のネゎシ゚ヌションにおいお `ppp` は Predictor1 圧瞮を甚いるべく䞻匵したのに察しお、 接続先は圧瞮を䜿甚しないこずを䞻匵した堎合に起こりたす。 このメッセヌゞには䜕の害もありたせんが、 出るのが嫌なら、以䞋の呜什を甚いおこちら偎でも Predictor1 圧瞮を無効にするこずで察応できたす。 

[.programlisting]
....
disable pred1
....

=== ファむル転送の途䞭で、ppp が IO ゚ラヌを出しお固たっおしたう

FreeBSD 2.2.2 以前のバヌゞョンの [.filename]#tun# ドラむバには、[.filename]#tun# むンタフェヌスの MTU のサむズより倧きなパケットを受け取るこずができないずいうバグがありたした。 MTU のサむズより倧きなパケットを受け付けるず IO ゚ラヌが起こり、 `syslogd` 経由で蚘録されるのです。 

`ppp` の仕様では、 LCP のネゎシ゚ヌションを行う堎合を含む__どのような堎合でも__最䜎 1500 オクテットの Maximum Receive Unit (MRU) を受け入れる必芁がありたす。 ですから、MTU を 1500 以䞋に蚭定した堎合でも、ISP はそれに関係なく 1500 の倧きさのパケットを送っおくるでしょう。 そしおこのむケおない機胜にぶちあたっお、 リンクが固たるのを目にするこずになるのです。 

FreeBSD 2.2.2 以前のバヌゞョンでは、MTU を決しお 1500 より小さくしないこずで、 この問題を回避するこずができたす。 

=== どうしお ppp は接続速床をログに残さないんでしょう?

モデムずの「やり取り」すべおの行をログに残すには、 以䞋のようにしお接続速床のログの有効化を行っおください。 

[.programlisting]
....
set log +connect
....

これは man:ppp[8] に最埌にくるこずが芁求されおいる "`expect`" ずいう文字列がくるたでのすべおのものをログに蚘録させたす。 

接続速床はログにずりたいけれど、PAP や CHAP を䜿っおいる (その結果、ダむダルスクリプト䞭の `CONNECT` 以降に党く「やりずり」を行わない - "`set login`" スクリプトには䜕も曞かない) のであれば、 ppp に "`expect`" を含んだ `CONNECT` 行すべおがくるたで埅たせるようにしないずいけたせん、 以䞋のようになりたす。 

[.programlisting]
....
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
....

ここで、`CONNECT` を受信しおから、 䜕も送らず、埩垰改行 (linefeed) を埅っおいたす、 ppp に `CONNECT` の応答すべおを読み蟌たせおいるわけです。 

=== 私の chat スクリプトでは \ ずいう文字を PPP が解釈しおくれたせん。

`PPP` は蚭定ファむルを読み蟌むずきに、 `set phone "123 456 789"` のような文字列を正しく解釈し、 番号が実際に__1 ぀の__匕数であるず理解したす。 """ ずいう文字を指定するには、バックスラッシュ (backslash; "`\`") で゚スケヌプしなければなりたせん。 

`chat` の各匕数が解釈されるずきには、 "`\P`" や "`\T`" のような特別な゚スケヌプシヌケンス (マニュアルペヌゞ参照のこず) を芋付けるために、 もう 1 回、字句解析を行いたす。 このように字句解析は 2 回繰り返されたすので、 正しい回数だけ゚スケヌプ凊理を行わないずいけたせん。 

モデムにたずえば "`\`" のような文字を送りたい堎合には、 次のようにする必芁がありたす。

[.programlisting]
....
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
....

実際にモデムに送られる文字列は次のようになりたす。 

[.programlisting]
....
ATZ
OK
AT\X
OK
....

他の䟋ですず 

[.programlisting]
....
set phone 1234567
            set dial "\"\" ATZ OK ATDT\\T"
....

は次のようになりたす。 

[.programlisting]
....
ATZ
OK
ATDT1234567
....

=== ppp が segmentation fault になるのですが、 ppp.core ファむルがありたせん

ppp (や他のプログラム) は決しお core を吐いおはいけたせん。 ppp は実効 uid が 0 で動いおいたすので、 オペレヌティングシステムは ppp を終了させる前にディスクに core むメヌゞを曞き蟌みたせん。 しかし ppp は実際にはセグメンテヌション違反や、 他の core を吐く原因ずなるようなシグナルによっお終了しおおり、 __さらに__最新のバヌゞョン (このセクションの始めを芋おください) を䜿甚しおいるならば、次のようにしおください。 

[source,shell]
....
% tar xfz ppp-*.src.tar.gz
% cd ppp*/ppp
% echo STRIP= >>Makefile
% echo CFLAGS+=-g >>Makefile
% make clean all
% su
# make install
# chmod 555 /usr/sbin/ppp
....

これでデバッグ可胜なバヌゞョンの ppp がむンストヌルされたす。 `root` で ppp を実行し、 すべおの特暩が無効になっおいるようにする必芁があるでしょう。 ppp を実行する時には、 カレントディレクトリが `make` したディレクトリであるようにしおください。 

これで、ppp がセグメンテヌション䟋倖を受け取ったずきには [.filename]#ppp.core# ずいう名前の core ファむルを吐くようになりたす。core が 吐かれたら次のようにしおください。 

[source,shell]
....
% su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
..
(gdb) f 0
..
(gdb) i args
..
(gdb) l
..
....

質問する際には、これらすべおの情報を提䟛しお、 問題点の分析ができるようにしおください。 

`gdb` の䜿い方に慣れおいる堎合には、実際に dump の原因ずなった理由やそのアドレス、 関連した倉数の倀なども調べる事ができるでしょう。 

=== auto モヌドでダむアルをするようなプロセスが接続されない。 

これは ppp がロヌカル偎の IP アドレスを、 動的に通信盞手ず亀枉するように蚭定されおいる時に発生する良く知られた障害でした。 最新のバヌゞョンでは、 この問題は修正されおいたす。 `iface` をマニュアルペヌゞから怜玢しおみおください。 

これは、最初のプログラムが man:connect[2] を呌び出した時、[.filename]#tun# むンタヌフェむスの IP アドレスが、 ゜ケットの終端に割り圓おられおしたうずいう問題です。 カヌネルは、 倖ぞ出おいく最初のパケットを䜜り、それを [.filename]#tun# デバむスぞ曞き蟌みたす。 そしお ppp は、 そのパケットを読み蟌んで接続を確立したす。 ppp は動的に IP アドレスを割り圓おるため、 もしむンタヌフェむスのアドレスが倉化しおしたうず、 最初に割り圓おられた゜ケット終端の IP アドレスは無効になっおしたいたす。 そのため、それ以降盞手に送られるすべおのパケットは通垞、 盞手に届くこずはないでしょう。もし仮に届いたずしおも、 既にこちらの IP アドレスは倉曎されおいるので、 どんな反応も最初のマシンには戻っおきたせん。 

この問題に察凊する理論的な方法がいく぀かありたす。もし可胜なら、 盞手が再床、同じ IP アドレスを割り圓おおくれるこずが䞀番です ``:-)``ppp の珟圚のバヌゞョンはこれを行ないたすが、 他のほずんどの実装はそういった動䜜をしたせん。 

我々の偎から察凊できる最も簡単な方法は、[.filename]#tun# むンタヌフェむスの IP アドレスを固定する事です。たたそのかわりに、 倖に出おいくパケットを倉曎しお、 発信元 IP アドレスをむンタヌフェむスの IP アドレスから、亀枉によっお埗られた IP アドレスに、 適宜曞きかえる事によっおも察凊できたす。 これは、基本的に ppp の最新バヌゞョンにある `iface-alias` オプションが行なっおいるこずず同じです (man:libalias[3] および、ppp の `-nat` スむッチにも関係したす)。それは、以前の IP アドレスをすべお管理し、 それらを最埌の亀枉によっお埗られた IP アドレスに察しお NAT 機胜を有効化したす。

もう 1 ぀の (おそらく最も信頌できる) 方法は、bind された すべおの゜ケットの IP アドレスを、 異なるものに倉曎できるシステムコヌルを実装するこずです。 pppは、 新しい IP アドレスが割り圓おられた時、 このシステムコヌルを甚いお実行されおいるプログラムにある、 すべおの゜ケットを曞きかえおやるわけです。 同じシステムコヌルが、DHCP クラむアントが利甚する゜ケットを 匷制的に再 bind するのにも䜿うこずができるでしょう。 

3 ぀目の方法は、IP アドレスを指定しないでむンタヌフェむスを利甚できるようにするこずです。 倖に出おいくパケットは、最初の `SIOCAIFADDR` ioctl の完了たで、 255.255.255.255 ずいう IP アドレスが䞎えられたす。 これによっお、゜ケットは垞に bind するこずができたす。 発信元 IP アドレスを倉曎するのは ppp の仕事です。ただし、 それは発信元 IP アドレスが 255.255.255.255 になっおいお、IP アドレスず IP チェックサムを倉曎する必芁がある堎合だけです。 これは、カヌネルが䞍適切に蚭定されたむンタヌフェむスぞは 異垞なパケットを送出しようずするこずを利甚しお、なにか他の 仕組みが遡及的に修正を行っおくれるこずを前提にしおいる、 割り切った方法ではありたす。 

=== 䜕故ほずんどのゲヌムが -nat スむッチ付きだず動かないんですか?

libalias を䜿っおいる時にゲヌムなどの類のものが動䜜しない理由は、 倖偎にあるマシンが接続しようずしおいるか、内偎にあるマシンに (䜙蚈な) UDP パケットを送信しようずしおいるからです。 内偎のマシンにこれらのパケットを送るべきかに぀いお、 NAT ゜フトりェアは関知したせん。 

うたく動かすためには、 実行䞭のものが問題の発生しおいる゜フトりェアだけであるかを確認し、 ゲヌトりェむの [.filename]#tun# むンタフェヌスに察しお `tcpdump` を実行するか、 ゲヌトりェむ䞊で `ppp` の TCP/IP ログ蚘録を有効化 ("`set log +tcp/ip`") しおください。

行儀の悪い゜フトりェアを起動する際に、 ゲヌトりェむマシンを通過するパケットを監芖すべきです。 倖偎から䜕かパケットが戻っおきた時に、 そのパケットは砎棄されるでしょう (それが問題なのです)。 これらのパケットのポヌト番号に泚意しお、 その行儀の悪い゜フトりェアを停止しおください。 これを数回繰り返しおポヌト番号が垞に同じであるかを確認しおみおください。 同じであった堎合は、 [.filename]#/etc/ppp/ppp.conf# の適切なセクションに次の行を入れるず、 その゜フトりェアは動䜜するようになるでしょう。 

[.programlisting]
....
nat port proto internalmachine:port port
....

ここで _proto_ は `tcp` か `udp` であり、 _internalmachine_ はパケットを送りたいマシン、そしお _port_ はパケットの送信先のポヌト番号です。 

䞊蚘のコマンドを倉曎せずに、 他のマシン䞊でその゜フトりェアを䜿甚できるようにはしたくないかもしれたせん。 そしお同時に二぀の内郚のマシン䞊でその゜フトりェアを実行するこずは、 この質問の範囲を超えおいたす。結局、倖偎の䞖界からは、 内郚ネットワヌク党䜓がただ䞀぀のマシンずしお芋えるのです。 

ポヌト番号が垞に同じずは限らない堎合、さらに䞉぀のオプションがありたす。 

. libalias でサポヌトするようにし、結果を送り付ける。 特定の堎合の䟋は [.filename]#/usr/src/lib/libalias/alias_*.c# にありたす ([.filename]#alias_ftp.c# は良いプロトタむプです)。これには通垞、倖向きの特定のパケットを読み、 内郚の蚈算機のある特定のポヌトぞの接続を開始するような呜什が、 倖郚の蚈算機察しお送られおいるこずを芋分け、 埌続のパケットがどこに行けばいいのかが分かるように、 ゚むリアステヌブル䞭の "_route_" の郚分を蚭定する、ずいう䜜業が含たれたす。 
+ 
これは最も難しい方法ですが、最も良い方法でもありたすし、゜フトりェアが 耇数の蚈算機で動くようにできたす。 
. プロキシ (proxy) を䜿う。アプリケヌションが、たずえば socks5 をサポヌトしおいるか、(cvsup のように) "passive" オプションを持っおいるずこの方法が䜿えたす。 "passive" ずは盞手偎のほうから接続を求めおくるこずを避けるためにあるオプションです。 
. "`nat addr`" を䜿っおなんでもかんでも内郚の蚈算機に向けお流しおしたう。 これはちょっず無理矢理な解決法です。 

=== 有甚なポヌト番号のリストはありたせんか?

ただ出来おいたせん。しかし、 これは (関心を持っお頂けるならば) そういったリストにしおいく予定です。 それぞれの䟋にある _internal_ は、 ゲヌムで遊ぶマシンの IP アドレスに眮き換えおください。 

Asheron's Call::
[.programlisting]
....
nat port udp internal:65000 65000
....

手動でゲヌムのポヌト番号を 65000 に倉曎しおください。 マシンが耇数ある堎合は、それぞれのマシンに重耇しないポヌト番号 (぀たり 65001、65002 など) を蚭定し、その蚭定ごずに `nat port` の行を远加したす。

Half Life::
[.programlisting]
....
nat port udp internal:27005 27015
....

PCAnywhere 8.0::
[.programlisting]
....
nat port udp internal:5632 5632
nat port tcp internal:5631 5631
....

Quake::
[.programlisting]
....
nat port udp internal:6112 6112
....
このように蚭定する代わりに、 http://www.battle.net/support/proxy/[www.battle.net] で Quake のプロキシ (proxy) がサポヌトされおいるか調べおもいいでしょう。 

Quake2::
[.programlisting]
....
alias port udp internal:27901 27910
....

Red Alert::
[.programlisting]
....
nat port udp internal:8675 8675
nat port udp internal:5009 5009
....

=== FCS ゚ラヌっお䜕?

FCS ずは ``F``rame ``C``heck ``S``equence (フレヌムチェックシヌケンス) の略です。 個々の ppp パケットには、 送受信するデヌタが正しいかを調べるためのチェックサムが含たれおいたす。 受信したパケットの FCS が正しくない堎合は、そのパケットは廃棄され、 HDLCFCS カりントが増やされたす。 HDLC ゚ラヌの数は、 `show hdlc` コマンドを䜿っお衚瀺できたす。 

リンクの品質が悪かったり、 シリアルドラむバがパケットを取りこがしおいたりするず、 FCS ゚ラヌがたびたび発生したす。 FCS ゚ラヌは、 圧瞮プロトコルの速床䜎䞋の原因にはなりたすが、 特に心配する必芁はありたせん。 倖付けモデムを䜿っおいる堎合は、 ケヌブルがちゃんずシヌルドされおいるかを確認しおください。 そうでない堎合、 FCS ゚ラヌの原因ずなる堎合がありたす。 

接続盎埌からリンクがフリヌズし、倧量の FCS ゚ラヌが発生する堎合は、 リンクが 8 ビットクリヌンでない可胜性がありたす。 ゜フトりェアフロヌ制埡 (XON/XOFF) が䜿われおいないこずを確認しおください。 どうしおも゜フトりェアフロヌ制埡を䜿わなければならない堎合は、 `set accmap 0x000a0000` コマンドを䜿甚しお、 ppp に `^Q` ず `^S` を゚スケヌプさせおください。 

リモヌトホストが PPP プロトコルを䜿甚しおない堎合も、倧量の FCS ゚ラヌが発生したす。 この堎合はログをずりながら__非同期__で接続し、 ログむンプロンプトやシェルプロンプトが送られお来おいないか確認しおください。 

ログファむルにリンクを終了した原因ずなるような蚘録がない堎合は、 リモヌトホスト (プロバむダ?) の管理者に、 セッションを終了された理由を尋ねおください。 

[[PPPoEwithNAT]]
=== ゲヌトりェむで PPPoE を実行するず MacOS や Windows 98 ずの接続がフリヌズしおしたうのですが、 これはなぜなのでしょうか?

Michael Wozniak mailto:[email protected][[email protected]] 氏が、この珟象に関しお説明しおくれたした。 たた、Dan Flemming mailto:[email protected][[email protected]] 氏は MacOS での解決策を提䟛しおくれたした。 情報の提䟛に感謝したす。 

これは、いわゆる「ブラックホヌルルヌタ (Black Hole router)」に原因がありたす。 Windows 98 ず MacOS (および、おそらく他の Microsoft 瀟補 OS) の TCP パケット送出は、 PPPoE のフレヌム (Ethernet の MTU は暙準で 1500) に入らないような倧きなセグメントサむズを芁求したす。 __そしおさらに__分割犁止 ("don't fragment") フラグビットを (TCP パケットにデフォルトで) セットするのですが、 Telco のルヌタは、分割が必須 ("must fragment") であるこずを瀺す ICMP メッセヌゞを、接続しようずするりェブサむトに察しお送出したせん (぀たり、ルヌタは正しく ICMP パケットを送出しおいるのですが、 りェブサむトのファむアりォヌルがそれを萜ずしおいるのです)。 そのためりェブサヌバが PPPoE 接続に察しお倧きすぎるフレヌムを送出するず Telco のルヌタはそのフレヌムを捚おおしたい、 芋ようずしたペヌゞが衚瀺されないずいう症状が珟われたす (MSS より小さいペヌゞや画像は衚瀺されたす)。 ほずんどの Telco PPPoE 蚭定は、暙準でこのように蚭定されおいるようです。 (ああ、圌らがルヌティングプログラムの䜜り方を理解しおさえいれば...)。 

䞀぀の解決法は、Windows 95/98 マシンで regedit を䜿い、 次のレゞストリ゚ントリを远加するこずです。 

[.programlisting]
....
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Class\NetTrans\0000\MaxMTU
....

レゞストリ゚ントリは、"1450" の倀 (もっず正確に蚀うず、TCP パケットを PPPoE フレヌムに完党に適合させるには "1464" であるべきでですが、 "1450" ずするず、珟われる可胜性がある他の IP プロトコルに察しお゚ラヌマヌゞンを確保するこずができたす) にする必芁がありたす。 このレゞストリキヌは、Windows2000 で `Tcpip\Parameters\Interfaces\ID for adapter\MTU` に移されたずいう報告がありたした。 

FreeBSD/NAT/PPPoE ルヌタず共存させるために Windoze の MTU を倉曎する方法に関する詳现は、 http://search.support.microsoft.com/kb[Microsoft Knowledge Base] にある、 番号 "Q158474 - Windows TCPIP Registry Entries"、 および番号 "Q120642 - TCPIP & NBT Configuration Parameters for Windows NT" を参照しおください。 

残念なこずに、MacOS には TCP/IP 蚭定を倉曎する方法がありたせん。 しかし、link:http://www.softworks.com/[Sustainable Softworks 瀟] が販売しおいる OTAdvancedTuner (OT は OpenTransport ずいう MacOS の TCP/IP スタックの名前のこず) のような商甚゜フトりェアが存圚したす。 この゜フトりェアは、ナヌザから TCP/IP 蚭定の倉曎を行なうこずを可胜にしたす。 MacOS NAT ナヌザはドロップダりンメニュヌから `ip_interface_MTU` を遞択し、 ボックスにある `1500` の代わりに `1450` を入力し、 `Save as Auto Configure` の隣のボックスをクリックしお `Make Active` をクリックする必芁がありたす。 

ppp の最新版 (2.3 かそれ以降) には、自動的に MSS を適切な倀に調節する `enable tcpmssfixup` コマンドがありたす。 この機胜は暙準で有効になっおいたす。 もし旧バヌゞョンの ppp を䜿わなければならない状況にあるなら、 tcpmssd の port をご芧になるず良いでしょう。

=== どれにも圓おはたらない! どうしたらいいの?

これたでのすべおの質問に圓おはたらない堎合、蚭定ファむル、 ppp の実行方法、ログファむルの該圓郚分ず `netstat -rn` コマンドの出力 (接続前ず接続埌) を含む、 あなたの持っおいるすべおの情報を {freebsd-questions} や link:news:comp.unix.bsd.freebsd.misc[comp.unix.bsd.freebsd.misc] ニュヌスグルヌプぞ送っおください。誰かがあなたを正しい方向ぞ導いおくれるでしょう。 

== シリアル接続

このセクションでは、FreeBSD でシリアル接続をする時の䞀般的な質問に答えたす。 PPP および SLIP に぀いおは、 <<networking>>のセクションを参照しおください。 

=== どうやったら FreeBSD がシリアルポヌトを認識したこずを知る事ができたすか?

FreeBSD のカヌネルが起動する時、カヌネルはその蚭定にしたがっお、 システムのシリアルポヌトを怜出したす。起動時に衚瀺されるメッセヌゞをよく芳察するか、 起動埌に次のコマンドを実行する事によっお確認できたす。 

[source,shell]
....
dmesg | grep sio
....

ここに䞊に挙げたコマンドの出力䟋を瀺したす。

[source,shell]
....
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
....

これは、二぀のシリアルポヌトを瀺しおいたす。1 番目は、 irq が 4 で `0x3f8` のポヌトアドレスを䜿甚しおいたす。 そしお、16550A-type UART チップが存圚したす。 2 番目は、同じチップを䜿っおいたすが、 irq は 3 で、`0x2f8` のポヌトアドレスを䜿甚しおいたす。内蔵のモデムカヌドは、 通垞のシリアルポヌトず同じように扱われたすが、 垞時シリアルポヌトにモデムが接続されおいるずいう点で異なりたす。 

GENERIC カヌネルは、䞊の䟋ず同じ irq ずポヌトアドレスの蚭定の二぀のシリアルポヌトをサポヌトしおいたす。 これらの蚭定があなたのシステムに合わない堎合、 たたはモデムカヌドを远加した堎合やカヌネルの蚭定以䞊にシリアルポヌトを持っおいる堎合は、 カヌネルを再構築しおください。 詳しくは、 <<make-kernel,カヌネルの構築>>の項を参照しおください。 

===  どうやったら FreeBSD がモデムカヌドを認識したこずを知るこずができたすか?

前の質問を参照しおください。 

=== FreeBSD 2.0.5 にアップグレヌドしたら tty0X が芋぀からなくなっおしたったのですが

心配ありたせん。 [.filename]#ttydX# に統合されたした。 ただ、叀い蚭定ファむルのすべおを曎新する必芁がありたす。 

=== どうやったら FreeBSD でシリアルポヌトにアクセスできたすか?

3 番目のポヌト [.filename]#sio2# (man:sio[4] をご芧ください。DOS では、[.filename]#COM3# ず呌ばれたす。) には、 ダむダルアりトデバむスずしおは [.filename]#/dev/cuaa2#、 ダむダルむンデバむスずしお [.filename]#/dev/ttyd2# がありたす。 それではこの䞡者にはどのような違いがあるのでしょうか? 

たず、ダむダルむンの時には [.filename]#ttydX# を䜿いたす。 [.filename]#/dev/ttydX# をブロッキングモヌドでオヌプンするず、プロセスは察応する [.filename]#cuaaX# デバむスがむンアクティブになるのを埅ちたす。 次に CD 信号がアクティブになるのを埅ちたす。 [.filename]#cuaaX# デバむスをオヌプンするず、シリアルポヌトが [.filename]#ttydX# デバむスによっおすでに䜿われおいないかどうかを確認したす。 もしこのポヌトが䜿甚可胜であれば、ポヌトの䜿甚暩を [.filename]#ttydX# から「奪い取る」のです。たた、 [.filename]#cuaaX# デバむスは CD 信号を監芖したせん。 この仕組みず自動応答モデムによっお、 リモヌトナヌザヌをログむンさせたり、 同じモデムでダむダルアりトしたりするこずができ、 システムのあらゆるトラブルの面倒を芋るこずができるでしょう。 

=== マルチポヌトシリアルカヌドをサポヌトさせるにはどうしたらよいのでしょうか?

繰り返しになりたすが、 <<make-kernel,カヌネルコンフィグレヌション>>のセクションでは、 あなたのカヌネルの蚭定に぀いおの情報が埗られるでしょう。 マルチポヌトシリアルカヌドを䜿甚するためには、カヌネルの蚭定ファむルに、 カヌドの持぀それぞれのシリアルポヌトに察応する man:sio[4] の行を蚘述する必芁がありたす。しかし、 irq ずベクタアドレスは䞀぀の゚ントリにのみ蚘述しおください。 カヌド䞊のすべおのポヌトは䞀぀の irq を共有しなければなりたせん。 䞀貫性を持たせるためにも、 最埌のシリアルポヌトの所で irq を指定しおください。 たた、`COM_MULTIPORT` オプションも付けおください。 

次に瀺す䟋は、AST の 4 ポヌトシリアルカヌドを irq 7 で蚭定したものです。 

[.programlisting]
....
options "COM_MULTIPORT"
device sio4 at isa? port 0x2a0 tty flags 0x781
device sio5 at isa? port 0x2a8 tty flags 0x781
device sio6 at isa? port 0x2b0 tty flags 0x781
device sio7 at isa? port 0x2b8 tty flags 0x781 irq 7 vector siointr
....

このフラグはマスタポヌトがマむナヌ番号 7 (`0x700`) を持っおいお、 怜出時の蚺断機胜を有効にし (`0x080`)、 そしおすべおのポヌトで irq を共有する (`0x001`) ずいうこずを意味しおいたす。 

=== FreeBSD で耇数のマルチポヌトシリアルカヌド間で irq を共有するこずはできたすか?

珟圚のずころはできたせん。それぞれのカヌド毎に異なった irq を䜿っおください。 

===  ポヌトにデフォルトのパラメヌタを蚭定する事は出来たすか?

[.filename]#ttydX# デバむス (たたは [.filename]#cuaaX# デバむス) は、 アプリケヌションのためにオヌプンする暙準的なデバむスです。 プロセスがそのポヌトをオヌプンする時、 プロセスはデフォルトの端末 I/O 蚭定を取埗したす。 これらの蚭定は次のコマンドで確認するこずができたす。 

[.programlisting]
....
stty -a -f /dev/ttyd1
....

このデバむスに察する蚭定を倉曎した堎合、 その蚭定はデバむスをクロヌズするたで有効です。 デバむスを再オヌプンした堎合、それらの蚭定はデフォルトに戻っおしたいたす。 デフォルトの蚭定に倉曎を加えるために、 「初期蚭定」デバむスをオヌプンし、 蚭定を修正するこずができたす。 たずえば、CLOCAL モヌド、8 ビット、 XON/XOFF フロヌ制埡ずいう蚭定を [.filename]#ttyd5# のデフォルトにしたい堎合、次のように行なっおください。 

[.programlisting]
....
stty -f /dev/ttyid5 clocal cs8 ixon ixoff
....

この蚭定を行なうためのコマンドを蚘述するのに適切なファむルは、 [.filename]#/etc/rc.serial# です。 これでアプリケヌションが [.filename]#ttyd5# をオヌプンした時に、 これらの蚭定をデフォルトで取埗したす。 しかし、こういったリンクによる蚭定は倉曎可胜です。 

「蚭定固定」デバむスを調敎しおやるこずによっお、 アプリケヌションによる蚭定の倉曎を犁止するこずができたす。 たずえば、[.filename]#ttyd5# の通信速床を 57600bps に固定するには、次のように行っおください。 

[source,shell]
....
# stty -f /dev/ttyld5 57600
....

これにより、アプリケヌションは [.filename]#ttyd5# をオヌプンし、ポヌトの通信速床を倉曎しようずしたすが、 通信速床は 57600bps のたたになりたす。 

圓然のこずながら、初期蚭定デバむスおよび、蚭定固定デバむスは `root` のみが曞き蟌みできるようになっおいなければなりたせん。 しかし、man:MAKEDEV[8] スクリプトはデバむス゚ントリを䜜成する時に、 このような蚭定は__行いたせん__。 

=== どのようにしたらモデム経由でダむダルアップログむンができるのでしょうか?

぀たり、むンタヌネットサヌビスプロバむダヌになりたいのですね。 それにはたず、1 台ないし耇数の自動応答モデムが必芁です。 モデムには、キャリアヌを怜出した時には CD 信号を出力し、 そうでない堎合には出力しないこずが必芁ずされたす。 たた DTR 信号が on から off になった時には、 電話回線を切断し、モデム自身をリセットしなければなりたせん。 おそらく、RTS/CTS フロヌ制埡を䜿うか、 ロヌカルフロヌ制埡をたったく䜿わないかのどちらかでしょう。 最埌に、コンピュヌタずモデムの間は固定速床でなければなりたせん。 ただ、(ダむダルアップの発呌者に察しお芪切であるためには、 ) こちらのモデムず盞手偎のモデムの間の速床を、 モデム間で自動調敎できるようにすべきでしょう。 

倚くあるヘむズコマンド互換モデムに察しお、次のコマンドはこれらの蚭定を行ない、 その蚭定を䞍揮発性メモリヌに保存したす。 

[.programlisting]
....
AT&C1&D3&K3&Q6S0=1&W
....

MS-DOS のタヌミナルプログラムに頌らずに AT コマンドを送出するには、 <<direct-at,「AT コマンドを入力するには」>>のセクションを参照しおください。 

次に、モデム甚の゚ントリを [.filename]#/etc/ttys# (man:ttys[5] 参照) に䜜成したしょう。 このファむルには、 オペレヌティングシステムがログむンを埅っおいるすべおのポヌトが蚘述されおいたす。 以䞋のような行を远加しおください。 

[.programlisting]
....
ttyd1 "/usr/libexec/getty std.57600" dialup on insecure
....

この行は、2 番目のシリアルポヌト ([.filename]#/dev/ttyd1#) には、 57600bps の通信速床でノンパリティ (`std.57600`: これは [.filename]#/etc/gettytab# に蚘述されおいたす。man:gettytab[5] 参照) のモデムが接続されおいるこずを瀺しおいたす。 このポヌトの端末タむプは `dialup` です。 たたこのポヌトは、`on` すなわちログむン可胜であり、`insecure` です。 これは `root` がこのポヌトから盎接ログむンするのは、 蚱可されおいないずいうこずを意味したす。 このようなダむダルむンポヌトに察しおは、 [.filename]#ttydX# の゚ントリを䜿甚しおください。 

これが䞀般的な、タヌミナルタむプずしお `dialup` を䜿う方法です。倚くのナヌザヌは、 [.filename]#.profile# や [.filename]#.login# で、 ログむン時の端末タむプが `dialup` であった堎合には、 実際の端末タむプをナヌザヌに問い合わせるように蚭定しおいたす。 この䟋は、ポヌトが `insecure` でした。このポヌトで `root` になるには、 䞀般ナヌザヌずしおログむンし、それから "link:http://www.FreeBSD.org/cgi/man.cgi?su[su]" を䜿っお `root` になっおください。 もし、`secure` を指定したならば、 盎接 `root` がそのポヌトからログむンできたす。 

[.filename]#/etc/ttys# に倉曎を加えた埌は、HUP シグナル (SIGHUP) を man:init[8] プロセスに送る必芁がありたす。 

[source,shell]
....
# kill -HUP 1
....

この操䜜は `init` プロセスに [.filename]#/etc/ttys# を再読み蟌みさせたす。 これにより、init プロセスは `getty` プロセスをすべおの `on` ずなっおいるポヌトに起動させたす。 次のようにしお、ポヌトがログむン可胜かを知るこずができたす。 

[source,shell]
....
% ps -ax | grep '[t]tyd1'
....

ログむン可胜であれば、次のような出力が埗られるはずです。 

[source,shell]
....
747 ??  I      0:00.04 /usr/libexec/getty std.57600 ttyd1
....

=== ダムタヌミナルを FreeBSD マシンに接続するにはどうしたらよいのでしょうか?

もし、他のコンピュヌタヌを FreeBSD の端末ずしお接続したいのならば、 お互いのシリアルポヌト間を぀なぐヌルモデムケヌブル (蚳泚: リバヌスケヌブルもしくはクロスケヌブルずも呌ばれたす) を甚意しおください。 もし、既補の端末を䜿う堎合は、付属するマニュアルを参照しおください。 

そしお、[.filename]#/etc/ttys# (man:ttys[5] 参照) を䞊ず同じように倉曎しおください。 たずえば、WYSE-50 ずいう端末を 5 番目のポヌトに接続するならば、 次のような゚ントリを䜿甚しおください。 

[.programlisting]
....
ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure
....

この䟋は、[.filename]#/dev/ttyd4# ポヌトにノンパリティ、 端末タむプが wyse50、通信速床が 38400bps (`std.38400`: この蚭定は、 [.filename]#/etc/gettytab# に蚘述されおいたす。man:gettytab[5] 参照) の端末が存圚しおおり、 `root` のログむンが蚱可されおいる (`secure`) であるこずを瀺しおいたす。 

=== どうしお tip や cu が動かないのですか?

おそらくあなたのシステムでは man:tip[1] や man:cu[1] は `uucp` ナヌザヌか、 `dialer` グルヌプによっおのみ実行可胜なのでしょう。 `dialer` グルヌプは、 モデムやリモヌトシステムにアクセスするナヌザヌを管理するために、 䜿甚するこずができたす。 それには、[.filename]#/etc/group# ファむルの `dialer` グルヌプにあなた自身を远加しおください。 

そうする代わりに、次のようにタむプするこずにより、 あなたのシステムの党ナヌザヌが `tip` や `cu` を実行できるようになりたす。 

[source,shell]
....
# chmod 4511 /usr/bin/cu
# chmod 4511 /usr/bin/tip
....

=== 私の Hayes モデムはサポヌトされおいないのですが、 どうしたらいいのでしょうか。

実際、 man:tip[1] のオンラむンマニュアルは叀くなっおいたす。 すでに、Hayes ダむアラが実装されおいたす。 [.filename]#/etc/remote# ファむル (man:remote[5] 参照) で、 "`at=hayes`" ず指定しおください。 

Hayes ドラむバは、最近のモデムの新しい機胜である、 `BUSY`、 `NO DIALTONE`、 `CONNECT 115200` などのメッセヌゞを認識できるほど賢くはなく、 単に混乱を起こすだけです。 man:tip[1] を䜿う堎合には (``ATX0&W``ずするなどしお)、 これらのメッセヌゞを衚瀺させないようにしなくおはいけたせん。 

たた、`tip` のダむダルのタむムアりトは 60 秒です。 モデムのタむムアりト蚭定はそれより短くすべきであり、 そうしないず `tip` は通信に問題があるず刀断するでしょう。 `ATS7=45&W` を実行しおください。 

実際、デフォルトの `tip` は Hayes の完党なサポヌトをしおいるわけではありたせん。 解決方法は [.filename]#/usr/src/usr.bin/tip/tip# の䞋の [.filename]#tipconf.h# を倉曎するこずです。 もちろん、これには゜ヌス配垃ファむルが必芁です。 

"`#define HAYES 0`" ず蚘述されおいる行を "`#define HAYES1`" ず倉曎し、そしお "`make`" ず "`make install`" を実行したす。これでうたく動䜜するでしょう。 

=== これらの AT コマンドを入力するには?

[.filename]#/etc/remote# ファむル (man:remote[5] 参照) の䞭で "direct" ゚ントリを䜜りたす。 たずえばモデムが 1 番目のシリアルポヌトである [.filename]#/dev/cuaa0#に接続されおいる堎合、 次のようにしたす。

[.programlisting]
....
cuaa0:dv=/dev/cuaa0:br#19200:pa=none
....

モデムがサポヌトする最倧の bps レヌトを `br` フィヌルドに䜿いたす。 そしお `tip cuaa0` (man:tip[1] 参照) を実行するず、モデムが利甚できるようになりたす。 

[.filename]##/dev/cuaa0##がシステムに存圚しない堎合は、次のようにしたす。 

[source,shell]
....
# cd /dev
# ./MAKEDEV cuaa0
....

たたは `root` になっお以䞋のように cu を䜿いたす。 

[source,shell]
....
# cu -lline -sspeed
....

_line_ にはシリアルポヌト (たずえば [.filename]#/dev/cuaa0#)を指定したす。 そしお _speed_ には接続する速床 (たずえば `57600`) を指定したす。 その埌 AT コマンドを実行したら、 `~.` ず入力すれば終了したす。 

=== pn 機胜の <@> 蚘号が䜿えたせん!

電話番号 (pn) 機胜の䞭での `<@>` 蚘号は、 `tip` に [.filename]#/etc/phones# にある電話番号を参照するように䌝えたす。しかし `<@>` の文字は [.filename]#/etc/remote# のような蚭定ファむルの䞭では特殊文字ずなりたす。 そこで、バックスラッシュを䜿っお゚スケヌプを行いたす。 

[.programlisting]
....
pn=\@
....

=== コマンドラむンから電話番号を指定するには?

"`generic`" ゚ントリず呌ばれるものを [.filename]#/etc/remote# ファむル (man:remote[5] 参照) に远加したす。 たずえば、次のようにしたす。 

[.programlisting]
....
tip115200|Dial any phone number at 115200 bps:\
:dv=/dev/cuaa0:br#115200:at=hayes:pa=none:du:
tip57600|Dial any phone number at 57600 bps:\
:dv=/dev/cuaa0:br#57600:at=hayes:pa=none:du:
....

そしお "`tip -115200 5551234`" のように利甚できたす。 man:tip[1] より man:cu[1] を䜿いたい堎合、 `cu` の `generic` ゚ントリを䜿いたす。 

[.programlisting]
....
cu115200|Use cu to dial any number at 115200bps:\
:dv=/dev/cuaa1:br#57600:at=hayes:pa=none:du:
....

そしお "`cu 5551234 -s 115200`" ず実行したす。 

=== 毎回 bps レヌトを入力しなければいけたせんか?

`tip1200` や `cu1200` 甚の゚ントリを蚘述し、 適切な通信速床を `br` フィヌルドに蚭定したす。 man:tip[1] は 1200bps が正しいデフォルト倀であるずみなすので、 "`tip1200`" ゚ントリを参照したす。 もちろん 1200bps を䜿わなければならないわけではありたせん。 

=== タヌミナルサヌバを経由しお耇数のホストぞアクセスしたいのですが。

毎回接続されるのを埅っお "`CONNECT <host>`" ず入力するかわりに、 `tip` の `cm` 機胜を䜿いたす。 たずえば、[.filename]#/etc/remote# (man:remote[5] 参照) に次のような゚ントリを远加したす。 

[.programlisting]
....
pain|pain.deep13.com|Forrester's machine:\
:cm=CONNECT pain\n:tc=deep13:
muffin|muffin.deep13.com|Frank's machine:\
:cm=CONNECT muffin\n:tc=deep13:
deep13:Gizmonics Institute terminal server:\
:dv=/dev/cuaa2:br#38400:at=hayes:du:pa=none:pn=5551234:
....

これで、"`tip pain`" や "`tip muffin`" ず実行するず `pain` や `muffin` のホストに接続するこずができ、 "`tip deep13`" を実行するずタヌミナルサヌバに接続したす。 

===  tip を䜿っおそれぞれのサむトの耇数の回線に接続できたすか?

これは倧孊に電話回線がいく぀かあっお、 数千人の孊生が接続しようずする堎合によくある問題です。 

あなたの倧孊の゚ントリを [.filename]#/etc/remote# ファむル (man:remote[5] 参照) に䜜成しお、 `pn` のフィヌルドには `<\@>` を䜿いたす。 

[.programlisting]
....
big-university:\
:pn=\@:tc=dialout
dialout:\
:dv=/dev/cuaa3:br#9600:at=courier:du:pa=none:
....

そしお [.filename]#/etc/phones# ファむル (man:phones[5] 参照) に倧孊の電話番号の䞀芧を曞きたす。 

[.programlisting]
....
big-university 5551111
big-university 5551112
big-university 5551113
big-university 5551114
....

man:tip[1] は䞀連の電話番号を䞊から順に詊みお、 最終的に接続できなければあきらめたす。リトラむを続けさせたい堎合は、 `tip` を while ルヌプに入れお実行したす。 

=== CTRL+P を 1 回送るために 2 床抌す必芁があるのはなぜ?

kbd:[CTRL]+kbd:[P] は通垞「匷制 (force)」文字であり、 man:tip[1] に次の文字がリテラルデヌタであるこずを䌝えたす。 匷制文字は「倉数の蚭定」を意味する `~s` ゚スケヌプによっお、 他の文字にするこずができたす。 

"`~sforce=<single-char>`" ず入力しお改行したす。 _<single-char>_ は、任意の 1 バむト文字です。 _<single-char>_ を省略するず `NUL` 文字になり、 これは kbd:[CTRL]+kbd:[2] や kbd:[CTRL]+kbd:[SPACE] を抌しおも入力できたす。 いく぀かのタヌミナルサヌバで䜿われおいるのを芋ただけですが、 _<single-char>_ に kbd:[SHIFT]+kbd:[CTRL]+kbd:[6] に割り圓おるのもよいでしょう。 

[.filename]#$HOME/.tiprc# に次のように定矩するこずで、 任意の文字を匷制文字ずしお利甚できたす。 

[.programlisting]
....
force=<single-char>
....

=== 打ち蟌んだ文字が突然すべお倧文字になりたした??

kbd:[CTRL]+kbd:[A] を抌しおしたい、kbd:[caps-lock] キヌが壊れおいる堎合のために蚭蚈された man:tip[1] の "raise character" モヌドに入ったのでしょう。 既に述べた `~s` を䜿っお、 "raisechar" をより適切な倀に倉曎しおください。 もしこれら䞡方の機胜を䜿甚しないのであれば、 匷制文字ず同じ蚭定にするこずもできたす。 

以䞋は kbd:[CTRL]+kbd:[2] や kbd:[CTRL]+kbd:[A] などを頻繁に䜿う必芁のある Emacs ナヌザにうっお぀けの [.filename]#.tiprc# ファむルのサンプルです。 

[.programlisting]
....
force=^^
raisechar=^^
....

`^` は kbd:[SHIFT]+kbd:[CTRL]+kbd:[6] です。 

=== tip でファむルを転送するには?

もし他の UNIX のシステムず接続しおいるなら、 `~p` (送信) や `~t` (受信) でファむルの送受信ができたす。 これらのコマンドは、盞手のシステムの䞊で man:cat[1] や man:echo[1] を実行するこずで送受信をしたす。曞匏は以䞋のようになりたす。 

[.programlisting]
....
~p <ロヌカルのファむル名> [<リモヌトのファむル名>]
~t <リモヌトのファむル名> [<ロヌカルのファむル名>]
....

この方法でぱラヌチェックを行いたせんので、 zmodem などの他のプロトコルを䜿った方がよいでしょう。 

=== tip から zmodem を実行するには?

たず始めに、FreeBSD Ports Collection から zmodem プログラムのいずれか (lrzszず rzsz の、通信カテゎリヌの2 ぀のプログラムのどちらか) をむンストヌルしたす。 

ファむルを受信するには、リモヌト偎で送信プログラムを起動したす。 そしお、kbd:[Enter] キヌを抌しおから "`~C rz`" (lrzsz をむンストヌルした堎合は "`~C lrz`") ず入力するず、 ロヌカル偎ぞのファむルの受信が始たりたす。 

ファむルを送信するには、リモヌト偎で受信プログラムを起動したす。 そしお、kbd:[Enter] キヌを抌しおから "`~C sz <files>`" (lrzsz をむンストヌルした堎合は "`~C lsz <files>`") ず入力するず、リモヌト偎ぞのファむルの送信が始たりたす。 

=== 蚭定が正しいのにもかかわらず、FreeBSD がシリアルポヌトを芋付けられたせん。

マザヌボヌドやシリアルカヌドが Acer の UART チップを䜿った物の堎合、 FreeBSD の [.filename]#sio# ドラむバでは正しく怜出する事が出来たせん。 この問題を解決するためには、 http://www.lemis.com/serial-port-patch.html[www.lemis.com] からパッチを入手しおください。 

== その他の質問

=== FreeBSD は Linux より倚くのスワップ領域を消費するのはなぜですか?

実際にはそうではありたせん。 FreeBSD は Linux よりもスワップを倚く䜿っおいるように芋えるだけです。 この点における FreeBSD ず Linux の䞻な違いは、 FreeBSD はより倚くのメむンメモリを有効利甚できるようにするため、 完党にアむドルになったものやメむンメモリ䞊の䜿われなくなったペヌゞを、 スワップにあらかじめ積極的に移動しおいるずいうこずです。 Linux では、 最埌の手段ずしおペヌゞをスワップに移動させるだけずいう傟向がありたす。 このスワップの䜿い方は、 メむンメモリをより効果的に䜿甚するこずによっおバランスが保たれおいたす。 

FreeBSD はこのような状況では先手策を取りたすが、 システムが本圓に空き状態の時に、 理由も無くペヌゞをスワップしようず決めるこずはないずいうこずに泚意しおください。 したがっお、 倜䞭に䜿わずにおいたシステムが朝起きたずき、 すべおペヌゞアりトされおいるずいうこずはないのです。 

=== ほずんどプログラムは実行されおいないのに、 どうしお man:top[1] は非垞に少ない free memory を報告するのでしょうか?

簡単に蚀えば、free memory ずは無駄になっおいるメモリのこずだからです。 プログラムが確保しおいるメモリ以倖のすべおのメモリは、 FreeBSD カヌネル内でディスクキャッシュずしお利甚されたす。 この倀は man:top[1] においお `Inact`、 `Cache Buf` ずしお衚瀺され、 それぞれは異なる゚ヌゞングレベル (蚳泚: デヌタがどれだけ叀いかを瀺す評䟡倀) でキャッシュされた党デヌタを衚したす。 デヌタがキャッシュされるず蚀うのは、 最近アクセスされたデヌタであれば、 再床そのデヌタをアクセスするためにシステムが遅いディスクにアクセスする必芁がない、 ずいうこずを意味したす。 そのため、党䜓のパフォヌマンスが向䞊したす。 䞀般的に、man:top[1] で衚瀺される `Free` メモリが小さい倀を瀺すこずは良いこずで、 自由に䜿えるメモリの残量が__本圓に__少ない、 ずいうこずを衚しおいるわけではありたせん。

=== FreeBSD の実行フォヌマットの a.out、ELF ずはどのようなものですか? たた、a.out、ELF を䜿う理由は䜕でしょう?

FreeBSD が䜕故 ELF フォヌマットを利甚しおいるのかを理解するためには、 たず UNIXにおいお珟圚「優勢」な 3 皮類の実行フォヌマットに぀いお いくらか知っおおく必芁がありたす。 

[NOTE]
====
FreeBSD 3.x より前の FreeBSD では a.out フォヌマットが䜿われおいたした。
====

* man:a.out[5]
+ 
最も叀く 「由緒正しい」 unix オブゞェクトフォヌマットです。 マゞックナンバを含む短くおコンパクトなヘッダが先頭にあり、 これがフォヌマットの特城ずされおいたす (man:a.out[5] に詳现な内容がありたす)。 ロヌドされる 3皮類のセグメント、 `.text`、 `.data`、 `.bss` ず加えおシンボルテヌブルず文字列テヌブルを含みたす。 
* COFF
+ 
SVR3 のオブゞェクトフォヌマットです。 ヘッダは単䞀のセクションテヌブルから成り、 `.text`、 `.data`、 `.bss` セクション以倖の郚分を持぀こずができたす。 
* ELF
+ 
COFFの埌継です。耇数のセクションをサポヌトし、32-bit ず 64-bitのいずれの倀も可胜です。倧きな欠点の䞀぀は、ELF はそれぞれのシステムアヌキテクチャ毎に単䞀の ABI のみが存圚するずいう仮定で蚭蚈されおいるこずです。 この仮定はたったく正しくありたせん。 商甚の SYSV の䞖界でさえそうです (少なくずも SVR4、 Solaris、SCO の 3皮類の ABI がありたす)。 
+ 
FreeBSD はこの問題を解決するための詊みずしお、 既知の ELF 実行ファむルに ABI に応じた情報を __曞き加える__ナヌティリティを提䟛しおいたす。 詳しくは man:brandelf[1] のマニュアルペヌゞを参照しおください。 

FreeBSD は䌝統的な立堎をずり、数倚くの䞖代の BSD のリリヌスで詊され、実蚌されおきた man:a.out[5] フォヌマットを䌝統的に䜿甚しおいたす。 い぀かは FreeBSD システムでネむティブ ELF バむナリを䜜り、 実行するこずができるようになるかもしれたせんが、 初期の頃 FreeBSD では ELF をデフォルトのフォヌマットに倉曎するずいう動きは ありたせんでした。なぜでしょうか? ずころで Linux においおは、 ELF ぞの苊痛をずもなった倉曎は、 その時に [.filename]#a.out# 実行フォヌマットから逃れたずいうよりは、 ゞャンプテヌブルベヌスの共有ラむブラリのメカニズムの柔軟性の䜎さからの脱华でした。 これはベンダや開発者党䜓にずっお、 共有ラむブラリの䜜成が非垞に難しかった原因でした。 ELF のツヌルには共有ラむブラリの問題を解決するこずができるものが提䟛されおおり、 たたいずれにせよ䞀般的に「進歩」しおいるず考えられたす。 このため移行のコストは必芁なものずしお容認され、 移行は行なわれたした。 

FreeBSD の堎合は、共有ラむブラリのメカニズムは Sun の SunOS 圢匏の共有ラむブラリの メカニズムに極めお近いものになっおいお、 非垞に䜿いやすいものになっおいたす。 しかしながら、FreeBSD では 3.0 から ELF バむナリをデフォルトのフォヌマットずしお公匏にサポヌトしおいたす。 a.out 実行フォヌマットはよいものを私達に提䟛しおくれおいるものの、 私たちの䜿っおいるコンパむラの䜜者である GNU の人々は a.out フォヌマットのサポヌトをやめおしたったのでした。 このこずは、 私たちに別バヌゞョンのコンパむラずリンカを保守するこずを䜙儀なくされるこずずなり、 最新の GNU 開発の努力による恩恵から遠ざかるこずになりたす。 その䞊、ISO C++ の、 ずくにコンストラクタやデストラクタがらみの芁求もあっお、今埌の FreeBSD のリリヌスでネむティブの ELF のサポヌトされる方向ぞず話が進んでいたす。 

=== それにしおも、なぜそんなに倚くのフォヌマットがあるのですか?

もうおがろげになっおしたった暗い過去に、単玔なハヌドりェアがありたした。 この単玔なハヌドりェアは、単玔で小さなシステムをサポヌトしおいたした。 a.out はこの単玔なシステム (PDP-11) での䜜業を行なうバむナリずしお完党に適したものだったのです。 人々はこの単玔なシステムから UNIX を移怍する際に、a.out フォヌマットをそのたた䜿いたした。ずいうのは Motorola 68k、VAXen、 ずいったアヌキテクチャぞの UNIX の初期の移怍ではこれで十分だったからです。 

やがおある聡明な゚ンゞニアが、 ゜フトりェアでちょっずしたトリックを䜿うこずを決めたした。 圌はいく぀かのゲヌトを削り取っお CPU のコアをより速く走らせるこずができたのです。 これは新しい皮類のハヌドりェア (今日では RISC ずしお知られおいたす) で動いたのです。 a.out はこのハヌドりェアには適しおいなかったので、 このハヌドりェア䞊で倚くのフォヌマットが、 限定された単玔な a.out フォヌマットでのものよりもより良いパフォヌマンスを出すこずを目指しお開発されたのです。 COFF、ECOFF、 そしおいく぀かの有名でないフォヌマットが ELF が暙準になる前に開発され、 それらの限界が探求されたのです。 

さらに、プログラムサむズは巚倧になり、 ディスク (および物理メモリ) は䟝然ずしお盞察的に小さかったため、 共甚ラむブラリのコンセプトが誕生したした。 たた、VM システムはより耇雑なものになりたした。 これらの個々の進歩は a.out フォヌマットを䜿甚しお遂げられたしたが、 その有甚性は新しい機胜ずずもにどんどん広がっおきたした。 これらに加え、実行時に必芁なものを動的にロヌドする、 たたは初期化コヌドの実行埌にプログラムの䞀郚を砎棄し、 コアメモリおよびスワップ空間を節玄するずいう芁望が高たりたした。 プログラミング蚀語はさらに耇雑になり、`main` 関数の前に自動的にコヌルされるコヌドの芁望が高たりたした。 倚くの機胜拡匵が行なわれ、a.out フォヌマットがこれらすべおを実珟できるようになり、 それらはしばらくは基本的に動䜜しおいたした。 やがお、a.out はコヌドでのオヌバヘッドず耇雑さを増倧させずに、 これらの問題すべおを凊理するこずに無理がでおきたした。 䞀方、ELF はこれらの問題の倚くを解決したすが、 珟状皌働しおいるシステムからの切替えは厄介なものになるでしょう。 そのため ELF は、a.out のたたでいるこずが ELF ぞの移行よりももっず厄介なものになるたで埅぀必芁がありたした。 

しかし時が経぀に぀れ、FreeBSD のビルドツヌルの元ずなったツヌル矀 (特にアセンブラずロヌダ) ず FreeBSD のビルドツヌル矀は異なった進化の経路をたどりたした。 FreeBSD のツリヌでは、共有ラむブラリが远加され、 バグフィックスも行われたした。 もずもずのツヌル矀を䜜成した GNU の人たちは、プログラムを曞き盎し、 クロスコンパむラのサポヌト、 異なるフォヌマットを任意に取り蟌む機胜などを远加しおいきたした。 倚くの人々が FreeBSD をタヌゲットずしたクロスコンパむラの構築を詊みたしたが、 FreeBSD の䜿っおいる `as` ず `ld` の叀いプログラムコヌドはクロスコンパむルをサポヌトしおおらず、 うたくいきたせんでした。 新しい GNU のツヌル矀 (binutils) は、 クロスコンパむル、共有ラむブラリ、C++ 拡匵などの機胜をサポヌトしおいたす。 さらに数倚くのベンダが ELF バむナリをリリヌスしおいたす。 FreeBSD にずっお ELF バむナリが実行できるこずは、 非垞にメリットがありたす。ELF バむナリが FreeBSD で動くのなら、a.out を動かすのに手間をかける必芁はありたせんね。 長い間忠実によく働いた老いた銬は、 そろそろ牧草地で䌑たせおあげたしょう。 

ELF は a.out に比べおより衚珟力があり、 ベヌスのシステムに察しおより幅広い拡匵性を提䟛できたす。 ELF 甚のツヌルはよりよく保守されおいたす。 たた倚くの人にずっお重芁なクロスコンパむルもサポヌトしおいたす。 ELF の実行速床は、ほんの少し a.out より遅いかもしれたせんが、 実際に速床の差をはかるのは困難でしょう。 ELF ず a.out の間には、ペヌゞマッピング、 初期化コヌドの凊理など倚くの違いがありたすが、 ずりたおお重芁なものはありたせん。しかし違いがあるのは確かです。ほどなく、 GENERIC カヌネルから a.out のサポヌトが倖されたす。 a.out のプログラムを実行する必芁性がなくなれば、 最終的に a.out のサポヌトはカヌネルから削陀されたす。 

=== シンボリックリンクの蚱可属性を chmod で倉えられないのはなぜですか?

シンボリックリンクは蚱可属性を持ちたせん。 たた man:chmod[1] のデフォルト動䜜は、 シンボリックリンクをたどっおリンク先のファむルの蚱可属性を倉曎するようになっおいたせん。 そのため、 [.filename]#foo# ずいうファむルがあり、 このファむルぞのシンボリックリンク [.filename]#bar# があったずするず、 以䞋のコマンドは垞に成功したす。 

[source,shell]
....
% chmod g-w bar
....

しかしこの堎合、[.filename]#foo# の蚱可属性は倉曎されたせん。

この堎合、"`-H`" か "`-L`" のどちらかのオプションを "`-R`" ず同時に䜿う必芁がありたす。 man:chmod[1] ず man:symlink[7] のマニュアルペヌゞにはもっず詳しい情報がありたす。 

[WARNING]
====

"`-R`" オプションは__再垰的に__ man:chmod[1] を実行したす。ディレクトリやディレクトリぞのシンボリックリンクを `chmod` する堎合は気を぀けおください。 シンボリックリンクで参照されおいる単䞀のディレクトリのパヌミッションを倉曎したい堎合は、 man:chmod[1] をオプションを぀けずに、 シンボリックリンクの名前の埌ろにスラッシュ ("[.filename]#/#") を぀けお䜿いたす。たずえば、"[.filename]#foo#" がディレクトリ "[.filename]#bar#" ぞのシンボリックリンクである堎合、 "[.filename]#foo#" (実際には "[.filename]#bar#") のパヌミッションを倉曎したい堎合には、このようにしたす。 

[source,shell]
....
% chmod 555 foo/
....

埌ろにスラッシュを぀けるず、 man:chmod[1] はシンボリックリンク "[.filename]#foo#" を远いかけおディレクトリ "[.filename]#bar#" のパヌミッションを倉曎したす。 
====

=== ログむン名がいただに 8 文字に制限されおいるのはなぜですか?

`UT_NAMESIZE` を倉曎しおシステム党䜓を䜜り盎せば十分で、 それだけでうたくいくだろうずあなたは考えるかもしれたせん。 残念ながら倚くのアプリケヌションやナヌティリティ (システムツヌルも含めお) は、 小さな数倀を構造䜓やバッファなどに䜿っおいたす (必ずしも "8" や "9" ではなく、 "15" や "20" などの倉った倀を䜿うものもありたす)。 (固定長のレコヌドを期埅するずころで可倉長レコヌドになるため、 ) 台無しになったログファむルを埗るこずになるずいうこずだけでなく、 Sun の NIS のクラむアントの堎合は問題が起きたすし、他の UNIX システムずの関連においおこれら以倖の問題も起きる可胜性がありたす。 

しかし、FreeBSD 3.0 以降では 16 文字ずなり、 倚くのナヌティリティのハヌドコヌドされた名前の長さの問題も解決されたす。 実際にはシステムのあたりに倚くの郚分を修正するために、 3.0 になるたでは倉曎が行われたせんでした。 

それ以前のバヌゞョンでは、これらの問題が起こった堎合に、 問題を自分自身で発芋し、解決できるこずに絶察的な自信がある堎合は [.filename]#/usr/include/utmp.h# を線集し、 `UT_NAMESIZE` の倉曎にしたがっお、 長いナヌザ名を䜿うこずができたす。 たた、 `UT_NAMESIZE` の倉曎ず䞀臎するように [.filename]#/usr/include/sys/param.h# の `MAXLOGNAME` 曎新しなくおはなりたせん。 最埌に、゜ヌスからビルドする堎合は [.filename]#/usr/include# を毎回アップデヌトする必芁があるこずを忘れないように! [.filename]#/usr/src/..# 䞊のファむルを倉曎しおおいお眮き換えたしょう。 

=== FreeBSD 䞊で DOS のバむナリを動かすこずはできたすか?

はい、FreeBSD 3.0 からは、 統合ず改良が重ねられた BSDI の doscmd DOS ゚ミュレヌションサブシステムを䜿っおできるようになりたした。 今なお続けられおいるこの努力に興味を持っお参加しおいただけるなら、 link:{freebsd-emulation} ぞメヌルを送っおください。 

FreeBSD 3.0 以前のシステムでは、 pcemu ずいう巧劙なナヌティリティが FreeBSD Ports Collection にあり、 8088 の゚ミュレヌションず DOS のテキストモヌドアプリケヌションを動かすに十分な BIOS サヌビスを行ないたす。これは X りィンドりシステムが必芁です (XFree86 ずしお提䟛されおいたす)。 

=== どこで無料の FreeBSD のアカりントを取埗できたすか?

FreeBSD はいずれのサヌバヌにもアクセスを開攟しおいたせんが、 Unix システムぞの自由なアクセスを提䟛しおいるずころがありたす。 費甚はたちたちで、限定されたサヌビスが利甚できたす。

M-Net ずしおも知られる http://www.arbornet.org/[Arbornet, Inc] は 1983 幎から Unix システムぞのアクセスを提䟛しおいたす。 System III が動䜜する Altos に始たり、1991 幎には BSD/OS に移行したした。2000 幎 6 月には、再び FreeBSD に 移行しおいたす。M-Net には SSH たたは telnet 経由で アクセスするこずができ、FreeBSD ゜フトりェア䞀匏が 利甚できるようになっおいたす。ただし、ネットワヌク接続は 䌚員ず、非営利組織ずしお運営されおいるシステムに寄付をする 埌揎者に制限されおいたす。たた、M-Net は掲瀺板システムず 双方向チャットも提䟛しおいたす。

http://www.grex.org/[Grex] は、 掲瀺板システムず双方向チャット゜フトりェアが同じであるこずも含め、 M-Net ずよく䌌たサむトを提䟛しおいたす。しかし、 マシンは Sun 4M で、SunOS が動䜜しおいたす。

=== sup ずは䜕で、 どのようにしお䜿うものなのでしょうか?

http://www.FreeBSD.org/cgi/ports.cgi?^sup[SUP] ずは、゜フトりェアアップデヌトプロトコル (Software Update Protocol) で カヌネギヌメロン倧孊 (CMU) で開発ツリヌの同期のために開発されたした。 私たちの䞭心開発ツリヌをリモヌトサむトで同期させるために䜿っおいたした。 

SUP はバンド幅を浪費したすので、今は䜿っおいたせん。 ゜ヌスコヌドのアップデヌトの珟圚のおすすめの方法は extref:{handbook}mirrors[FreeBSD ハンドブックの「CVSup」, cvsup]にありたす。

=== FreeBSD をクヌルに䜿うには?

いいえ。 私たちは 250 マむクログラムの LSD-25 をあらかじめ䞎えおおいたボランティアに察する、 目隠し味芚テストを倧量に行なっおいたす。 35% のボランティアは FreeBSD はオレンゞのような味がするず蚀っおいるのに察し、 Linux は玫煙のような味わいがあるず蚀っおいる人もいたす。 䞡方のグルヌプずも枩床の䞍䞀臎に぀いおは䜕も觊れおいたせん。 この調査で、非垞に倚くのボランティアがテストを行なった郚屋から䞍思議そうに出おきお、 このようなおかしな結果を瀺したこずに私たちは圓惑させられたした。 私たちは、ほずんどのボランティアは Apple にいお圌らの最新の「匕っかいお匂いをかぐ」GUI を䜿っおいるのではないかず考えおいたす。 私たちは奇劙な叀い仕事をしおいるのでしょう! 

真面目に蚀うず、FreeBSD や Linux は共に "HLT" (停止) 呜什をシステムのアむドル (idle) 時に䜿い、 ゚ネルギヌの消費を抌えおいたすので熱の発生も少なくなりたす。 たた、APM (advanced power management) を蚭定しおあるなら FreeBSD は CPU をロヌパワヌモヌドにするこずができたす。 

=== 誰かが私のメモリカヌドをひっかいおいるのですか??

その通り! BSD の文曞には良く、デヌモン (daemon) ずいう蚀葉が出おきたす。 ほずんどの人は知らないのですが、 デヌモンずは、あなたのコンピュヌタを䟝り代ずする、 玔粋で非物質的な存圚のこずです。 メモリから聞こえるひっかくような音は、 さたざたあるシステム管理タスクの扱いをいかに最善なものにするか、 ずいったこずを決めるずきにデヌモンたちが亀わす、 かん高いささやき声なのです。 

この雑音が聞こえたずき、DOS から "`fdisk /mbr`" ずいうプログラムを実行すれば、 うたくデヌモンを远い出すこずができるでしょう。 でも、デヌモンはそれに歯向かっお `fdisk` の実行をやめさせようずするかも知れたせん。 もし、それを実行しおいるずきにスピヌカならビル ゲむツ (Bill Gates) の悪魔のささやきが聞こえおきたら、 すぐに立ち䞊がっお逃げおください。決しお振り返っおはいけたせん! BSD のデヌモンたちが抌え蟌んでいた双子のデヌモン、DOS ず Windows が解攟され、 あなたの魂を氞遠の砎滅ぞ導こうずマシンを再び支配しおしたうこずでしょう。 それを知った今や、遞べず蚀われたら、 むしろひっかき音に慣れる方を遞ぶのではありたせんか? 

=== "MFC" ずはどういう意味ですか

MFC ずは、 「CURRENT ずの合流 (Merged From -CURRENT)」の頭文字をずったものです。 CVS ログで -CURRENT から -STABLE ブランチぞの合流を瀺したす。 

=== "BSD" ずはどういう意味ですか?

この蚀葉は、仲間うちだけに分かる隠語で䜕ずかずいう意味です。 文字どおりに蚳すこずはできたせんが、 BSD の蚳は「F1 のレヌシングチヌム」か「ペンギンはおいしいスナック」、 あるいは「俺たちゃ Linux より排萜は利いおるぜ」ずかそのぞんだず蚀っおおけばおっけヌでしょう。 `:-)`

冗談はさおおき、BSD ずは、Berkeley CSRG (コンピュヌタシステム評議䌚) が圌らの UNIX の配垃圢態の名前ずしお圓時遞んだ "Berkeley Software Distribution" の略です。 

=== リポゞトリ・コピヌ (repo-copy) ずは䞀䜓䜕のこずでしょう?

repo-copy ("repository copy" の略) ずは、 CVS リポゞトリの䞭で盎接ファむルをコピヌするこずを瀺す甚語です。

repo-copy を行なわない堎合を考えたす。 リポゞトリの䞭の異なる堎所にファむルをコピヌしたり、 移動したりする必芁性が生じるず、コミッタヌは ファむルを新しい堎所に眮くために `cvs add` を、 そしお叀いファむルが削陀される堎合は、叀いファむルに察しお `cvs rm` を実行するでしょう。

この方法の欠点は、ファむルの倉曎履歎 (たずえば CVS ログの゚ントリ) が新しい堎所にコピヌされないこずです。 FreeBSD プロゞェクトではこの倉曎履歎をずおも有甚なものだず考えおいるため、 前述の方法の代わりにリポゞトリコピヌが良く甚いられたす。 この操䜜は `cvs` プログラムを利甚するのではなく、 リポゞトリの管理担圓者がリポゞトリの䞭でファむルを盎接コピヌするこずによっお行なわれたす。

=== なんでバむク小屋 (bikeshed) の色にたで気を䜿わなければいけないんですか?

䞀蚀で蚀っおしたえば、そうすべきではありたせん。 もう少し詳しく説明したしょう。 たずえば、あなたがバむク小屋を建おる技術を持っおいたずしたす。 しかしそれは、塗ろうずしおいる色が気に入らないからず蚀っお、 他人がバむク小屋を建おようずしおいるのを止めお良い理由にはなりたせんよね。 これは、自分の行動に぀いお十分な理解を持っおいるなら、 あなたは现かな機胜すべおにわたっお議論する必芁はないこずを瀺す比喩です。 ある倉曎によっお産み出されるノむズの総量は、 その倉曎の耇雑さに反比䟋するのだず蚀っおいる人達もいたす。

さらに詳しく、完党な回答を玹介したしょう。 Poul-Henning Kamp は、 「man:sleep[1] は分数の秒数を匕数ずしお取るべきか」ずいう 非垞に長い議論の埌で、 "link:http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers[A bike shed (any colour will do) on greener grass...]" ずいうタむトルの長文を投皿したした。 関係のある郚分だけを以䞋に掲茉したす。

1999 幎 10 月 2 日 freebsd-hackers にお Poul-Henning Kamp
"このバむク小屋、どうだろう?" 誰かがたずねたした。 

長い...ずいうか、むしろ叀い話になりたすが、 䞭身はわりず簡単な話です。パヌキン゜ン (C. Northcote Parkinson) は 1960 幎代初頭に "パヌキン゜ンの法則" ず呌ばれる本を曞きたした。 この䞭にはさたざたな経営の力孊に関する掞察が含たれおいたす。 

[ この本に関する解説があったが省略 ]

バむク小屋に関連する䟋ずしお、 もう䞀぀の重芁な構成芁玠ずなっおいるのは原子力発電所です。 この本の幎代がわかりたすね。

パヌキン゜ンは、あなたが重圹䌚に出垭しお 数癟䞇から数10億ドル芏暡の原子力発電所の建蚭の承認を埗る こずはできるでしょうが、あなたが建おたいのがバむク小屋ならば、 終わりなき議論に巻き蟌たれるだろうず蚀っおいたす。

パヌキン゜ンはこのように説明しおいたす。 これは原発が䜙りに巚倧で高䟡で耇雑なので誰もこれを䞀手に握るこずができず、 それを詊みるくらいならむしろ、手が出せなくなる前に 他の誰かがすべおを詳现にチェックするこずを 匕き受けるこずに頌るのです。 リチャヌド・ファむンマン (Richard P. Feynmann) は、 ロスアラモスでこの手の重芁な経隓を䜕床も芋おきたず本に曞いおいたす。 

䞀方でバむク小屋の堎合は、誰でも週末にこれを䜜り䞊げるこずができ、 しかも TV の詊合を芋る時間があたるほどです。 なので、どんなに準備が敎えおあっお、どんなに蚈画が順圓であったずしおも、 わたしは仕事をやっおいるよ、 わたしは泚意を払っおいるよ、そしお わたしは__ここ__にいるよ、 ずいうこずを瀺そうずする人が必ず珟れたす。

デンマヌクではこれを「指王を぀ける」ず呌んでいたす。 これは個人的なプラむドや名声を求め、 ある堎所を指し瀺しお「ここ! ここは__俺__が やったんだぜ」ずいうようなものです。 これは政治家に芋られる匷い特城ですが、 その他のほずんどの人もこういう颚に振舞う可胜性はあるのです。 生也きのセメントに぀けられた足跡のこずを考えればお分かりでしょう。

=== ひず぀の電球を取り替えるのに、䜕人の FreeBSD ハッカヌが必芁?

1,172人です。 

* 電球が消えおいるず -CURRENT で文句を蚀うのに 23 人。
* 蚭定䞊の問題で -questions で話をすべきこずに぀いお隒ぐのに 4 人。
* それを send-pr (蚳泚: 障害報告) するのに 3 人 (そのうちのひず぀は間違っお doc カテゎリに送り぀けられたうえに、 内容が「暗くなった」ずいうだけのもの)。
* buildworld を倱敗させ、5 分埌には元に戻されるような電球を テストもせずにコミットするのに 1 人。
* send-pr した人に、パッチが含たれおいないず「いちゃもん」を付けるのに 8 人。
* buildworld が倱敗するず文句を蚀うのに 5 人。
* 自分のずころではちゃんず動く、 cvsup したタむミングが悪かったんだろうず答えるのに 31 人。
* 新しい電球のためのパッチを -hackers に投げるのに 1 人。
* 自分は 3 幎も前にパッチを䜜ったが、それを -CURRENT に投げたずきには無芖されただけだった、 自分は send-pr のシステムには嫌な経隓があるず (おたけに、 提案された新しい電球には柔軟性が無いずたで) 文句を蚀うのに 1 人。
* 電球が基本システムに組み蟌たれおいない、 committer はコミュニティの意芋を聞くこず無しにこんなこずをする暩利は無いず叫び、 「こんなずきに -core は䜕をやっおるんだ!?」ずわめきちらすのに 37 人。
* 自転車眮き堎の色に文句を蚀うのに 200 人。
* パッチが man:style[9] 違反だず指摘するのに 3 人。
* 提案された新しい電球は GPL の䞋にあるず文句を蚀うのに 70 人。
* GPL ず BSD ラむセンスず MIT ラむセンスず NPL ず、 某 FSF 創立者らの個人的な健康法の優䜍性に぀いおの論争を戊わすのに 586 人。
* スレッドのあちこちの枝を -chat や -advocacy に移動するのに 7 人。
* 提案された電球を、叀いのよりずっず薄暗いのにコミットしおしたうのに 1 人。
* FreeBSD に薄暗い電球を付けるくらいなら真っ暗のほうがたしだずいう、 コミットメッセヌゞぞの凄たじい非難の嵐によっお、 それを元に戻すのに 2 人。
* 薄暗い電球が垳消しにされたこずに察しおどなり声で口論し、 -core の声明を芁求するのに 46 人。
* もし FreeBSD をたたごっちに移怍するこずになったずきに郜合がいいように、 もっず小さな電球を芁求するのに 11 人。
* -hackers ず -chat の S/N比に文句を蚀い、 抗議のため講読を取りやめるのに 73 人。
* 「unsubscribe」「どうやったら講読をやめられるんですか?」 「このメヌリングリストからわたしを倖しおください」ずいった メッセヌゞを、䟋のフッタをくっ぀けお投皿するのに 13 人。
* みんなが激論を戊わせるのに忙がしくお気付かない間に、 䜜業䞭の電球をコミットするのに 1 人。
* 新しい電球は TenDRA を䜿っおコンパむルされた堎合に 0.364% も明るくなる (ただし電球を立方䜓にしなければならない)、 だから FreeBSD は EGCS から TenDRA に倉えるべきだず指摘するのに 31 人。
* 新しい電球は矎しさに欠けおいるず文句を蚀うのに 1 人。
* 「MFC っお䜕ですか?」ず聞くのに 9 人 (send-pr した人も含む)。
* 電球が取り替えられおから 2 週間も消えっぱなしだず文句を蚀うのに 57 人。

[NOTE]
.{nik} による远蚘:
====
これには爆笑したした。 

それからわたしは考えたした。 「ちょっず埅およ? このリストのどこかに、 『これを文曞にたずめるのに 1人』ずいうのがあっおもいいんじゃないか?」 

それからわたしは悟りを開いたのです `:-)`
====

__この項目の著䜜暩は Copyright (c) 1999 {des} にありたす。 無断で䜿甚しないでください。__

== たじめな FreeBSD ハッカヌだけの話題

=== SNAP ずか RELEASE ずかは䜕?

珟圚、FreeBSD の http://www.FreeBSD.org/cgi/cvsweb.cgi[CVS リポゞトリ] には、䞉぀のアクティブ/準アクティブなブランチがありたす (アクティブな開発ブランチは䞉぀しか存圚しないため、 おそらく RELENG_2 ブランチの倉曎は幎に 2 回だけになるでしょう)。

* `RELENG_2_2` 通称 _2.2-STABLE_
* `RELENG_3` 通称 _3.X-STABLE_
* `RELENG_4` 通称 _4-STABLE_
* HEAD 通称 `-CURRENT` あるいは _5.0-CURRENT_

HEAD は他の二぀ず違っお、 実際のブランチタグではなく、 __「current、 分岐しおいない開発本流」__のための単なるシンボリックな定数です。 私たちはこれを `-CURRENT` ず呌んでいたす。 

珟圚、 "-CURRENT" は 5.0 の開発本流であり、 `4.0-STABLE` ブランチ、 ぀たり `RELENG_4` は 2000 幎 3 月に "-CURRENT" から分岐しおいたす。 

`2.2-STABLE` ブランチ、 `RELENG_2_2` は 1996 幎 11 月に "-CURRENT" から分岐したした。 これは保守が完党に終了しおいたす。 

=== 自分甚のカスタムリリヌスを構築するには?

リリヌスを構築するには䞉぀のこずが必芁です。たず、 man:vn[4] ドラむバが組み蟌たれたカヌネルを実行させおいる必芁がありたす。 以䞋をカヌネルコンフィグレヌションファむルに远加し、 カヌネルを䜜り盎しおください。 

[.programlisting]
....
pseudo-device vn         #Vnode driver (turns a file into a device)
....

次に、CVS リポゞトリ党䜓を手元においおおく必芁がありたす。 これを入手するには extref:{handbook}mirrors[CVSUP, cvsup] が䜿甚できたすが、supfile で release の名称を cvs にしお 他のタグや date フィヌルドを削陀する必芁がありたす。

[.programlisting]
....
*default prefix=/home/ncvs
*default base=/a
*default host=cvsup.FreeBSD.org
*default release=cvs
*default delete compress use-rel-suffix

## Main Source Tree
src-all
src-eBones
src-secure

# Other stuff
ports-all
www
doc-all
....

そしお `cvsup -g supfile` を実行しお自分のマシンに CVS リポゞトリ党䜓をコピヌしたす...。 

最埌に、ビルド甚にかなりの空き領域を甚意する必芁がありたす。 そのディレクトリを [.filename]#/some/big/filesystem# ずしお、 䞊の䟋で CVS リポゞトリを [.filename]#/home/ncvs# に眮いたものずするず、 以䞋のようにしおリリヌスを構築したす。 

[source,shell]
....
# setenv CVSROOT /home/ncvs
 # or export CVSROOT=/home/ncvs
# cd /usr/src
# make buildworld
# cd /usr/src/release
# make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
....

[NOTE]
====
ただし、すでに [.filename]#/usr/obj# 以䞋に構築物が存圚しおいるなら、buildworld の必芁は__ありたせん__。
====

凊理が終了するず、 リリヌス党䜓が [.filename]#/some/big/filesystem/release# に構築され、完党な FTP むンストヌル甚の配垃物が [.filename]#/some/big/filesystem/release/R/ftp# に䜜成されたす。 -current 以倖の開発ブランチの SNAP を自分で構築したい堎合は、 `RELEASETAG=SOMETAG` を䞊の `make release` のコマンドラむンに远加したす。 たずえば、`RELEASETAG=RELENG_2_2` ずするず最新の 2.2-STABLE snapshot が構築されたす。 

=== カスタムのむンストヌルディスクを䜜るにはどうすればいいのですか? 

[.filename]#/usr/src/release/Makefile# のいろいろなタヌゲットずしおむンストヌルディスク、 ゜ヌス、バむナリアヌカむブを䜜る完党な凊理を自動的に行なうようになっおいたす。 [.filename]#Makefile# に十分な情報がありたす。 しかし、実行には "make world" が必芁で、 倚くの時間ずディスクの容量が必芁です。 

=== make world を行なうず既存のバむナリを䞊曞きしおしたうのですが。

ええ、それが䞀般的な考え方です。名前が瀺しおいるように "make world" はすべおのシステムのバむナリを最初から䜜り盎したすので、結果ずしお、 クリヌンで䞀貫性のある環境を埗るこずができたす (これがそれだけ長い時間がかかる理由です)。 

環境倉数 ``DESTDIR`` を ``make world`` や ``make install`` を実行する時に定矩しおおくず、新しく䜜られたバむナリは ``${DESTDIR}``を ``root`` ずみなしたディレクトリツリヌにむンストヌルされたす。 あるでたらめな共有ラむブラリの倉曎やプログラムの再構築によっお ``make world`` は倱敗するこずもありたす。 

=== システム起動時に (bus speed defaulted) ずメッセヌゞが出たす。 

Adaptec の 1542 SCSI ホストアダプタは、 ナヌザが゜フトりェア的にバスアクセス速床の蚭定を行なうこずができたす。 以前のバヌゞョンの 1542 ドラむバは、 䜿甚可胜な最倧の速床を求めおアダプタをその蚭定にしようずしたした。 これは特定のナヌザのシステムでは問題がある事がわかり、 珟圚ではカヌネルコンフィグオプションに "TUNE_1542" が加えられおいたす。 これを䜿甚するず、これが働くシステムではディスクが速くなりたすが、 デヌタの衝突が起きお速くはならないシステムもあるでしょう 

=== むンタヌネットアクセスに制限があっおも current を远いかけられたすか?

はい、 extref:{handbook}[CTM システム]を䜿っお、 ゜ヌスツリヌ党䜓のダりンロヌドを__行なわず__に远いかけるこずができたす。

=== どのようにしお配垃ファむルを 240KB に分割しおいるのですか?

比范的新しい BSD ベヌスのシステムでは、 `split` に任意のバむト境界で分割する "`-b`" オプションがありたす。 

以䞋は [.filename]#/usr/src/Makefile# からの䟋です。 

[.programlisting]
....
bin-tarball:
            (cd ${DISTDIR}; \
            tar cf - . \
            gzip --no-name -9 -c | \
            split -b 240640 - \
            ${RELEASEDIR}/tarballs/bindist/bin_tgz.)
....

=== 私はカヌネルに拡匵を行ないたした。 誰に送ればいいですか? 

extref:{handbook}[FreeBSD ハンドブックの「FreeBSD ぞの貢献」]を参照しおください。

あなたのアむディアに感謝したす! 

=== PnP ISA カヌドの怜出ず初期化はどのように行なうのですか? 

link:mailto:[email protected][Frank Durda IV 氏] より: 

芁点は、ホストが認識されおいないボヌドを探す時に、すべおの PnP ボヌドが応答するこずのできる少数の I/O ポヌトがあるずいうこずです。 それにより、PnP プロヌブルヌチンが開始したずき、PnP ボヌドが存圚するなら、すべおの PnP ボヌドは自分のモデル番号を返したす。 そのポヌトを I/O read するずプロヌブルヌチンは問いに察するワむアヌド-OR された "yes" を埗たす。この堎合は 少なくずも 1 ビットが ON になりたす。 そしお、プロヌブルヌチンはモデル ID (Microsoft/Intel によっお割り圓おられおいたす)が X より小さいボヌドを "オフラむン" にするこずができたす。 この操䜜を行ない、問い合わせに応答しおいるボヌドがただ 残っおいるかどうかを調べたす。 もし "`0`" が返っおくるなら X より倧きな ID を持぀ボヌドはないこずになりたす。 今床は "X" よりも小さな倀を持぀ボヌドに぀いお問い合わせたす。 もしあるのであれば、 プロヌブルヌチンはモデル番号が X より小さいこずを知りたす。 今床は、X-(limit/4) より倧きな倀を持぀ボヌドをオフラむンにしお問い合わせを繰り返したす。 この ID の範囲による準バむナリサヌチを十分繰り返すこずにより、 プロヌブルヌチンはマシンに存圚するすべおの PnP ボヌドの倀を最終的に埗るこずができたす。その繰り返しの回数は 2^64 よりはるかに少ない回数です。 

ID は二぀の 32-bit (぀たり 64bit) フィヌルド + 8 bit チェックサムからなりたす。最初の 32 bits はベンダの識別子です。 これは公衚されおはいたせんが、 同䞀のベンダから䟛絊されおいる異なるタむプのボヌドでは異なる 32-bit ベンダ ID を持぀こずができるように考えられたす。 補造元を特定するだけのために 32-bit はいくらか過剰です。 

䞋䜍の 32-bit はシリアル番号、 むヌサネットアドレスなどのボヌドを特定するものです。 ベンダは䞊䜍 32 bits が異なっおいないのであれば、 䞋䜍 32-bit が同䞀である 2枚目のボヌドを補造するこずはありたせん。 したがっお、同じタむプの耇数のボヌドをマシンにいれるこずができ、 この堎合でも 64-bit 党䜓ではナニヌクです。 

32-bit のフィヌルドはすべおを 0 にするこずはできたせん。 これは初期化のバむナリサヌチの間ワむアヌド-OR によっお 0 ではない ビットを参照するからです。 

システムがすべおのボヌドの䞎えられた ID を認識するず、 それぞれのボヌドに察応した凊理を䞀぀ず぀ (同䞀の I/O ポヌトを通しお) 行ないたす。 そしお、利甚できる割り蟌みの遞択などのボヌドが必芁ずするリ゜ヌスを怜出したす。 すべおのボヌドに぀いおこの情報を集めたす。 

この情報はハヌドディスク䞊の ECU ファむルなどの情報ずたずめられ、 マザヌボヌドの BIOS にも結合されたす。 マザヌボヌド䞊のハヌドりェアぞの ECU ず BIOS PnP のサポヌトは通垞は統合されおいたすが、 呚蟺機噚に぀いおは真の PnPであるずはいえたせん。 しかし、BIOS の情報に ECU の情報を加えお調査するこずで、 プロヌブルヌチンは PnP デバむスが再配眮できなくなるこずを避けるこずができたす。 

それから、再床 PnP デバむスにアクセスし、I/O、DMA、IRQ、 メモリマップアドレスの蚭定をしたす。 デバむスはこのアドレスに芋えるようになり、 次に再起動するたでこの䜍眮を占めたす。しかし、 あなたの望む時に移動させるこずが䞍可胜である、 ずいっおいるわけではありたせん。 

以䞊の話では倧きく単玔化をしおありたすが、 基本的な考え方は埗られたでしょう。 

マむクロ゜フトは、ボヌドのロゞックが察立する I/O サむクルではデコヌドしおいない (蚳泚: おそらく read 時しかデコヌドされおいず write 時はポヌトが空いおいるずいう意味でしょう)、 プラむマリプリンタのステヌタスポヌトのいく぀かを PnP のために占有したした。 私は初期の PnP の提案レビュヌ時に IBM 玔正のプリンタボヌドでステヌタスポヌトの write のデコヌドがされおいるずいうこずに気が぀きたしたが、 MS は "tough (頑固、䞍運、無法な)" ず蚀っおいたす。 そしおプリンタのステヌタスポヌトぞアドレスの蚭定のために write を行なっおいたす。たた、 そのアドレス + `0x800` ず read のための 3番目の I/O ポヌトが `0x200` から `0x3ff` の間のどこかに眮かれるでしょう。 

=== FreeBSD は、他のアヌキテクチャをサポヌトしないんですか? 

いく぀かのグルヌプの人々が、FreeBSD の他のアヌキテクチャぞの移怍に関心を瀺しおおり、 FreeBSD/AXP (ALPHA) はこれらの成果ずしおはずおも成功したものの䞀぀です。 FreeBSD/AXP は珟圚 link:ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha/[ftp://ftp.FreeBSD.org/pub/FreeBSD/alpha] から入手できたす。 ALPHA ぞの移怍版が珟圚動く機皮は増え぀぀あり、 その䞭には AlphaStation、AXPpci、PC164、Miata そしお Multia ずいったモデルが含たれおいたす。 珟状に぀いおの情報を埗るには mailto:[email protected][[email protected]]<<mailing,メヌリングリスト>>に参加しおください。 

その他に FreeBSD の SPARC アヌキテクチャぞの移怍がありたす。 プロゞェクトぞの参加に興味がある方は mailto:[email protected][[email protected]]<<mailing,メヌリングリスト>> に参加しおください。 進行䞭のプラットホヌムのリストにもっずも最近远加されたのが IA-64 ず PowerPCです。詳现は mailto:[email protected][[email protected]] および/あるいは mailto:[email protected][[email protected]]<<mailing,メヌリングリスト>>に参加しおください。 新しいアヌキテクチャに関する䞀般的な議論に぀いおは 新しいアヌキテクチャに関する䞀般的な議論に぀いおは mailto:[email protected][[email protected]]<<mailing,メヌリングリスト>> ぞ参加しおください。 

=== デバむスドラむバを開発したので、メゞャヌ番号が欲しいのですが。

これは、開発したドラむバを公開するかどうかに䟝存したす。 公開するのであれば、ドラむバの゜ヌスコヌド、 [.filename]#files.i386# の倉曎、 コンフィグファむルのサンプル、 デバむスが䜿うスペシャルファむルを䜜成する man:MAKEDEV[8] のコヌドを私たちに送っおください。 公開する぀もりがない堎合、ラむセンスの問題により公開できない堎合は、 キャラクタメゞャヌ番号 32 および、 ブロックメゞャヌ番号 8 がこのような目的のために予玄されおいたす。 これらの番号を䜿甚しおください。 どちらの堎合であれ、ドラむバに関する情報を {freebsd-hackers} に流しお頂けるず助かりたす。 

=== 代替のディレクトリ配眮ポリシヌ

珟圚䜿われおいるディレクトリの配眮ポリシヌは、 私が 1983 幎に曞いたものから党く倉曎されおいたせん。 私は圓初の配眮ポリシヌを、オリゞナルの fast filesystem のために曞き、 たったく改定しおいたせん。 このポリシヌはシリンダグルヌプを䜿い尜くすのを防ぐにはうたくいきたしたが、 お気づきの方もいる通り find の動䜜には䞍適切です。 ほずんどのファむルシステムの内容は、 深さ優先怜玢 (ftw ずも呌ばれたす) によっお䜜られたアヌカむブから、 抜出 (restore) しお䜜成されたす。この際、 ディレクトリは、シリンダグルヌプにたたがっお配眮され、 以降の深さ優先怜玢を行うには、 考え埗る限り最悪の状態になりたす。 もし䜜成するディレクトリの総数がわかっおいれば、 解決方法はありたす。(総数/シリンダグルヌプ数) 個のディレクトリを、 シリンダグルヌプごずにたずめお䜜成すれば良いのです。 もちろん最適なディレクトリ配眮になるように、 総数を予枬する方法を考えなければなりたせん。 しかし仮にシリンダグルヌプあたりのディレクトリ数を 10 くらいの小さな数に固定しおしたったずしおも、 倧幅な改善が望めるでしょう。 このポリシヌを甚いるべきリストア䜜業を、通垞の䜜業 (おそらく既存のポリシヌを䜿甚したほうが良いでしょう) を区別するには、 10 秒間の間に䜜成されたディレクトリを最倧 10 個たでたずめお単䞀のシリンダグルヌプに曞き蟌むずいう手順が䜿えるでしょう。 ずにかく私の結論は、そろそろ実隓を始めお芋る時期だろうずいうこずです。 

=== カヌネルパニックを最倧限に利甚する

[NOTE]
====
この節は、freebsd-current <<mailing,メヌリングリスト>>に {wpaul} 氏が投皿したメヌルを、 {des} 氏が校正し、[] 内のコメントを远加しお匕甚したものです。 
====

[.programlisting]
....
From: Bill Paul <[email protected]>
Subject: Re: the fs fun never stops
To: [email protected]
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
Cc: [email protected]
....

_[<[email protected]> が以䞋のパニックメッセヌゞを投皿したした。]_

[.programlisting]
....
> Fatal trap 12: page fault while in kernel mode
> fault virtual address   = 0x40
> fault code              = supervisor read, page not present
> instruction pointer     = 0x8:0xf014a7e5
                              ^^^^^^^^^^
> stack pointer           = 0x10:0xf4ed6f24
> frame pointer           = 0x10:0xf4ed6f28
> code segment            = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, def32 1, gran 1
> processor eflags        = interrupt enabled, resume, IOPL = 0
> current process         = 80 (mount)
> interrupt mask          =
> trap number             = 12
> panic: page fault
....

このようなメッセヌゞが衚瀺された堎合、問題が起きる状況を確認しお、 情報を送るだけでは十分ではありたせん。 䞋線を぀けた呜什ポむンタ倀は重芁な倀ですが、 残念ながらこの倀は構成に䟝存したす。぀たり、 この倀は䜿っおいるカヌネルのむメヌゞに䟝存するのです。 もしスナップショットなどの GENERIC カヌネルを䜿っおいるのであれば、 他の人間が問題のある関数に぀いお远詊をするこずができたすが、 カスタマむズされたカヌネルの堎合は、 䜿っおいる本人にしか問題の起こった堎所は特定できないのです。 

䜕をすれば良いのでしょう? 

[.procedure]
====
. 呜什ポむンタ倀をメモしたす。 `0x8:` ずいう郚分は今回必芁ありたせん。 必芁なのは `0xf0xxxxxx` ずいう郚分です。 
. システムが再起動したら、以䞋の操䜜を行いたす。 
+
[source,shell]
....
% nm -n /kernel.that.caused.the.panic | grep f0xxxxxx
....
ここで、`f0xxxxxx` は呜什ポむンタ倀です。 カヌネルシンボルのテヌブルは関数の゚ントリポむントを含み、 呜什ポむンタ倀は、関数内郚のある点であり最初の点ではないため、 この操䜜を行っおも完党に䞀臎するものが衚瀺されない堎合もありたす。 この堎合は、 最埌の桁を省いおもういちどやっおみおください。 このようになりたす。 
+
[source,shell]
....
% nm -n /kernel.that.caused.the.panic | grep f0xxxxx
....
これでも䞀臎しない堎合は、 桁を枛らしながら䜕らかの出力があるたで繰り返しおください。 䜕か出力されたら、 それがカヌネルパニックを匕き起こした可胜性のある関数のリストです。 これは、問題点を芋付ける正確な方法ではありたせんが、䜕もないよりたしです。 
====

このようなパニックメッセヌゞを投皿しおいる人はよく芋掛けたすが、 このように、呜什ポむンタ倀を、 カヌネルシンボルテヌブルの䞭の関数ず぀き合わせお調べおいる人はたれです。 

パニックの原因を突き止める最良の方法は、クラッシュダンプをずり、 man:gdb[1] でスタックトレヌスを行うこずです。 

どっちにしろ、私は普通以䞋のようにしたす。 

[.procedure]
====
. カヌネルコンフィグファむルを䜜りたす。 カヌネルデバッガが必芁そうであれば `options 'DDB'` を加えおも良いです (私は氞久ルヌプが起こっおいそうな堎合に、 ブレヌクポむントを蚭定するのに䜿っおいたす)。 
. `config -g KERNELCONFIG` ずしおビルドディレクトリを蚭定したす。 
. `cd /sys/compile/KERNELCONFIG; make` を実行したす。 
. カヌネルのコンパむルが終了するのを埅ちたす。
. `make install` を実行したす。
. 再起動したす。
====

man:make[1] プロセスは぀のカヌネル、 [.filename]#kernel# ず [.filename]#kernel.debug# をビルドしたす。 [.filename]#kernel# は [.filename]#/kernel# ずしおむンストヌルされ、 [.filename]#kernel.debug# は man:gdb[1] のデバッグ甚シンボル情報を取り出すために利甚されたす。 

確実にクラッシュダンプをずるには、[.filename]#/etc/rc.conf# を線集しお `dumpdev` を䜿甚しおいるスワップパヌティションに指定する必芁がありたす。 こうするず man:rc[8] スクリプトから man:dumpon[8] コマンドが実行され、 クラッシュダンプ機胜が有効になりたす。 手動で man:dumpon[8] コマンドを実行しおもかたいたせん。 パニックの埌、クラッシュダンプは man:savecore[8] コマンドを䜿甚しお取り出すこず ができたす。 `dumpdev` が [.filename]#/etc/rc.conf# で蚭定されおいれば、 man:rc[8] スクリプトから man:savecore[8] が自動的に実行され、クラッシュダンプを [.filename]#/var/crash# に保存したす。 

[NOTE]
====
FreeBSD のクラッシュダンプのサむズは、 ふ぀う物理メモリサむズず同じです。 ぀たり 64MB のメモリを積んでいれば、 64MB のクラッシュダンプが生成されるこずになりたす。 [.filename]#/var/crash# に十分な空き容量があるこずを確認しおください。手動で man:savecore[8] を実行すれば、 もっず空き容量のあるディレクトリにクラッシュダンプを保存できたす。 `options MAXMEM=(foo)` ずいう行をカヌネルコンフィグファむルに远加するこずで、 カヌネルのメモリ䜿甚量を制限できたす。 たずえば 128MB のメモリがある堎合も、 カヌネルのメモリ䜿甚量を 16MB に制限し、クラッシュダンプのサむズも 128MB ではなく 16MB にするこずができたす。 
====

クラッシュダンプを取り出せたら、 以䞋のように man:gdb[1] を䜿っおスタックトレヌスをずりたす。 

[source,shell]
....
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
(gdb) where
....

必芁な情報が 1 画面に収たらないこずも倚いので、できれば man:script[1] を䜿っお出力を蚘録したす。 strip しおいないカヌネルむメヌゞを䜿うこずで、 すべおのデバッグシンボルが参照でき、 パニックの発生したカヌネルの゜ヌスコヌドの行が衚瀺されおいるはずです。 通垞、正確なクラッシュぞの過皋を远跡するには、 出力を最埌の行から逆方向に読たなければなりたせん。 たた man:gdb[1] を䜿っお、 倉数や構造䜓の内容を衚瀺させ、 クラッシュした時のシステムの状態を調べられたす。 

もしあなたがデバッグ狂で、同時に別のコンピュヌタを利甚できる環境にあれば、 man:gdb[1] をリモヌトデバッグに䜿うこずもできたす。 リモヌトデバッグを䜿うず、あるコンピュヌタ䞊の man:gdb[1] を䜿っお、 別のコンピュヌタのカヌネルをデバッグできたす。 ブレヌクポむントの蚭定、カヌネルコヌドのステップ実行など、 ふ぀うのプログラムのデバッグず倉わりたせん。 コンピュヌタを 2 台䞊べおデバッグするチャンスにはなかなか恵たれないので、 私はただリモヌトデバッグを詊したこずはありたせん。 

[NOTE]
.Bill による远蚘:
====
DDB を有効にしおいおカヌネルがデバッガに 萜ちたら、ddb のプロンプトで "`panic`" ず入力すれば、匷制的にパニックを起こしクラッシュダンプさせるこずができたす。 パニックの途䞭で、再びデバッガに萜ちるかもしれたせんが、 "`continue`" ず入力すれば、 クラッシュダンプを最埌たで実行させられたす。 
====

=== dlsym() が ELF 実行圢匏では動䜜しなくなりたす!

ELF のツヌル類は、 デフォルトでは実行圢匏の䞭に定矩されおいるシンボルを、 ダむナミックリンカから芋えるようにはしたせん。 このため、`dlopen(NULL, flags)` を呌び出しお埗られたハンドルに察しお、 `dlsym()` で探玢を行っおも、 こういったシンボルを芋぀けられたせん。 

もし、あなたがプロセスの䞭心にあたる実行圢匏の䞭にあるシンボルを探玢したければ、 ELF リンカ (man:ld[1]) に `-export-dynamic` オプションを付けお実行圢匏をリンクする必芁がありたす。 

=== カヌネルアドレス空間を倧きくしたり、 小さくするにはどうしたら良いのですか?

カヌネルアドレス空間は、FreeBSD 3.X 䞊で 256MB、FreeBSD 4.X 䞊で 1GB がデフォルトになっおいたす。 負荷の高いネットワヌクサヌバ (たずえば倧きな FTP、HTTP サヌバ) を運甚する堎合は、256MB では足りないこずに気付くかも知れたせん。 

では、アドレス空間を倧きくするにはどうしたら良いのでしょうか? それには、二぀の段階を螏みたす。たず、 より倧きいアドレス空間を割り圓おるこずをカヌネルに知らせる必芁がありたす。 次に、カヌネルはアドレス空間の先頭にロヌドされるため、 アドレスの先頭が倩井 (蚳泚:カヌネルアドレス空間の最䞋端アドレスのこず) ず ぶ぀かるこずのないように、ロヌドアドレスを今たでより䜎䜍に蚭定する必芁がありたす。 

最初の段階は、[.filename]#src/sys/i386/include/pmap.h# にある `NKPDE` の倀を増加させるこずで行ないたす。 ここに 1GB のアドレス空間にするために、どのようにすれば良いかを瀺したす。 

[.programlisting]
....
#ifndef NKPDE
#ifdef SMP
#define NKPDE                   254     /* addressable number of page tables/pde's */
#else
#define NKPDE                   255     /* addressable number of page tables/pde's */
#endif  /* SMP */
#endif
....

正確な `NKPDE` の倀を蚈算するには、 望みのアドレス空間の倧きさ (メガバむト単䜍) を 4 で割っお、 それから単䞀プロセッサ (UP) なら 1、SMP なら 2 を匕き算しおください。 

次の段階を行なうには、ロヌドアドレスを正確に蚈算するこずが必芁です。 単玔に、アドレス空間の倧きさ (バむト単䜍) を 0x100100000 から匕き算しおください。 1GB アドレス空間の堎合、その結果は 0xc0100000 になりたす。 そしお、[.filename]#src/sys/i386/conf/Makefile.i386# にある LOAD_ADDRESS に、今蚈算した倀を入れたす。たた、次のように [.filename]#src/sys/i386/conf/kernel.script# のセクションの始めの方にあるロケヌションカりンタにも同じ倀を入れおください。 

[.programlisting]
....
OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(btext)
SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0xc0100000 + SIZEOF_HEADERS;
.interp     : { *(.interp)    }
....

それが完了したら、`config` し盎しおカヌネルを再構築しおください。 おそらく、man:ps[1]、man:top[1] などに䞍具合が出るでしょう。 それらを正垞にするために、`make world` (もしくは、倉曎した [.filename]#pmap.h# を [.filename]#/usr/include/vm/# にコピヌした埌に、 [.filename]#libkvm#、 `ps` および `top` を手動で再構築するこず) を行なうべきです。 

[NOTE]
====
カヌネルアドレス空間の倧きさは、4MB の倍数である必芁がありたす。
====

[NOTE]
.{dg} 氏による補足:
====
カヌネルアドレス空間は 2 の乗数である必芁があるず思いたすが、 それが確かなこずかどうかははっきりしおいたせん。 昔の起動コヌドには、良く高䜍アドレスビットのトリックが䜿われおいたため、 少なくずも 256MB の粒床であるこずが想定されおいたず思いたす。 
====

== 謝蟞

FreeBSD Core Team
この FAQ に぀いお問題を芋぀けたり、䜕か登録したい堎合は、 {faq-team} たでメヌルを送っおください。 フィヌドバックしおくれるみなさんには感謝感謝なのです。 みなさんに手䌝っおもらわないずこの FAQ はよくなりたせんから! 

{jkh}::
たたに起こす FAQ の䞊べ替えや曎新の発䜜

{dwhite}::
freebsd-questions メヌリングリストでの矩務を超えたサヌビス

{joerg}::
Usenet (NetNews) での矩務を超えたサヌビス

{wollman}::
ネットワヌク節の執筆ず文曞敎圢

Jim Lowe::
マルチキャストに぀いお

{pds}::
FreeBSD FAQ タむピング機械奎隷

FreeBSD チヌム::
䞍平を蚀ったり、うめいたり、情報提䟛しおくれたり

あず、抜けおしたった他の方々に察しお、謝眪ず心からの感謝を捧げたす! 

== FreeBSD FAQ 日本語化に぀いお

FreeBSD 日本語ドキュメンテヌションプロゞェクトは、 FreeBSD 関係の日本語文曞が少ないこずを嘆いた数人の FreeBSD ナヌザの提唱によっお 1996 幎 2 月 26 日にスタヌトし、 FreeBSD 日本語ハンドブックの䜜成をはじめずした掻動を行なっおきたした。 FreeBSD FAQ の日本語化に぀いおはオリゞナルの翻蚳䜜業だけでなく、 日本囜内に固有の話題に぀いおも広く情報を集め、 日本の FreeBSD ナヌザにずっお真に有益なドキュメントを提䟛しようず考えおいたす。 オリゞナルの FAQ は日毎に曎新されおおり、 私たちもたたこれに远い付くために䜜業を続けおいきたす。もちろん、新しいメンバも倧歓迎です。 日本語翻蚳版に぀いお、䜕かお気づきの点がありたしたら、 日本語ドキュメンテヌションプロゞェクト <[email protected]> たでご連絡ください。 たた、もし私たちの䜜業を手䌝っおくれるなら、 http://www.jp.FreeBSD.org/doc-jp/[FreeBSD 日本語ドキュメンテヌションプロゞェクトのペヌゞ]をご芧の䞊、是非参加しおください。 

=== 翻蚳者 (五十音順)

* 有村 光晎 <[email protected]>
* 䞀宮 亮 <[email protected]>
* 岩厎 満 <[email protected]>
* 内川 喜章 <[email protected]>
* 栗山 æ·³ <[email protected]>
* こがよういちろう <[email protected]>
* 今野 元之 <[email protected]>
* 杉村 貎士 <[email protected]>
* 䞭井 幞博 <[email protected]>
* にしか <[email protected]>
* 花井 浩之 <[email protected]>
* はらだ きろう <[email protected]>
* 広瀬 昌䞀 <[email protected]>
* 穏間 康匘 <[email protected]>
* むらたしゅういちろう <[email protected]>
* 山䞋 æ·³ <[email protected]>

=== 査読者 (五十音順)

* 浅芋 è³¢ <[email protected]>
* 岩厎 満 <[email protected]>
* 内川 喜章 <[email protected]>
* 倧橋 健 <[email protected]>
* 栗山 æ·³ <[email protected]>
* 今野 元之 <[email protected]>
* 䜐䌯 隆叞 <[email protected]>
* 杉村 貎士 <[email protected]>
* 花井 浩之 <[email protected]>
* 浜田 盎暹 <[email protected]>
* はらだ きろう <[email protected]>
* 日野 浩志 <[email protected]>
* 檜山 卓 <[email protected]>
* 広瀬 昌䞀 <[email protected]>
* むらたしゅういちろう <[email protected]>
* 若井 久史 <[email protected]>

=== 䜜業環境敎備 (五十音順)

* 䞀宮 亮 <[email protected]>
* 岩厎 満 <[email protected]>
* 䞋川 英敏 <[email protected]>
* 鈎朚 秀幞 <[email protected]>

[bibliography]
[[bibliography]]
== 有甚な曞籍

[[biblio-44sysman]]
[biblio-44sysman] 4.4BSD System Manager's Manual. Computer Systems Research Group, University of California, Berkeley. O'Reilly and Associates. 1st Edition. June 1994. 804 pages. ISBN 1-56592-080-5.

[[biblio-44userman]]
[biblio-44userman] 4.4BSD User's Reference Manual. Computer Systems Research Group, University of California, Berkeley. O'Reilly and Associates. 1st Edition. June 1994. 905 pages. ISBN 1-56592-075-9.

[[biblio-44suppman]]
[biblio-44suppman] 4.4BSD User's Supplementary Documents. Computer Systems Research Group, University of California, Berkeley. O'Reilly and Associates. 1st Edition. June 1994. 712 pages. ISBN 1-56592-076-7.

[[biblio-44progman]]
[biblio-44progman] 4.4BSD Programmer's Reference Manual. Computer Systems Research Group, University of California, Berkeley. O'Reilly and Associates. 1st Edition. June 1994. 866 pages. ISBN 1-56592-078-3.

[[biblio-44progsupp]]
[biblio-44progsupp] 4.4BSD Programmer's Supplementary Documents. Computer Systems Research Group, University of California, Berkeley. O'Reilly and Associates. 1st Edition. June 1994. 596 pages. ISBN 1-56592-079-1.

[[biblio-44kernel]]
[biblio-44kernel] The Design and Implementation of the 4.4BSD Operating System. McKusick M. K. [FAMILY Given], Marshall Kirk [FAMILY Given], Bostic Keith [FAMILY Given], Karels Michael J [FAMILY Given], 、 Quarterman John [FAMILY Given]. Addison-Wesley. Reading MA . 1996. ISBN 0-201-54979-4.

[[biblio-nemeth3rd]]
[biblio-nemeth3rd] Unix System Administration Handbook. Nemeth Evi [FAMILY Given], Snyder Garth [FAMILY Given], Seebass Scott [FAMILY Given], Hein Trent R. [FAMILY Given], 、 Quarterman John [FAMILY Given]. Prentice-Hall. 3rd edition. 2000. ISBN 0-13-020601-6.

[[lehey3rd]]
[lehey3rd] The Complete FreeBSD. Lehey Greg [FAMILY Given]. Walnut Creek. 3rd edition. June 1999. 773 pages. ISBN 1-57176-246-9.

[[biblio-mckusick-1]]
[McKusick et al, 1994] Berkeley Software Architecture Manual, 4.4BSD Edition. McKusick M. K. [FAMILY Given], Karels M. J. [FAMILY Given], Leffler S. J. [FAMILY Given], Joy W. N. [FAMILY Given], 、 Faber R. S. [FAMILY Given]. 5:1-42.