diff --git a/ja_JP.eucJP/books/faq/book.sgml b/ja_JP.eucJP/books/faq/book.sgml index 92b8e90cbc..9eebe24b7e 100644 --- a/ja_JP.eucJP/books/faq/book.sgml +++ b/ja_JP.eucJP/books/faq/book.sgml @@ -1,8765 +1,8780 @@ FreeBSD 2.X についての FAQ (よくある質問とその答え) The FreeBSD Documentation Project -$FreeBSD: doc/ja_JP.eucJP/books/faq/book.sgml,v 1.8 1999/10/02 01:20:29 kuriyama Exp $ +$FreeBSD: doc/ja_JP.eucJP/books/faq/book.sgml,v 1.9 1999/10/02 02:15:56 kuriyama Exp $ これは FreeBSD システムバージョン 2.X についての FAQ です. 特に断わりがない限りはどの項目も FreeBSD 2.0.5 以降のものを想定しています. <XXX>のついている項目はまだ作業中のものです. この FreeBSD ドキュメンテーション プロジェクトに協力したいと思ったら, FreeBSD ドキュメンテーションプロジェクトメーリングリスト <freebsd-doc@FreeBSD.ORG> まで (英語で) 電子メールを送ってください. このドキュメントの最新バージョンは, いつでも 日本国内版 FreeBSD World Wide Web サーバや FreeBSD World Wide Web サーバで 見ることができます. また, HTML 形式のものを HTTP で ダウンロードすることもできます. これらを gzip で圧縮したものが FreeBSD FTP サーバ に置かれています. また, FAQ の検索も可能です. 日本語版の作成は FreeBSD 日本語ドキュメンテーションプロジェクトが オリジナルの英語版をもとにしておこなっています. 日本語訳および, 日本語版のみに関することは FreeBSD 日本語ドキュメンテーションプロジェクト <doc-jp@jp.FreeBSD.ORG> において日本語で議論されています. 必要に応じて日本語ドキュメンテーションプロジェクトから 本家ドキュメンテーションプロジェクトに対してフィードバックを おこないますので, 英語が得意でない方は FreeBSD 日本語ドキュメンテーションプロジェクト <doc-jp@jp.FreeBSD.ORG> まで日本語で コメントをお寄せください. また, この FreeBSD FAQ とは別に, 日本の FreeBSD ユーザ有志によって メーリングリスト FreeBSD-users-jp や ニュースグループ fj.os.bsd.freebsd などへの投稿 をもとに作成された QandA が公開されています. 特に日本語環境など日本固有の話題 が充実していますので, こちらも合わせてご覧ください. まえがき 訳: くりやま <kuriyama@opt.phys.waseda.ac.jp>, 花井 浩之 <hanai@jp.FreeBSD.org>, 中井 幸博 <nakai@mlab.t.u-tokyo.ac.jp>, 今野 元之 <motoyuki@jp.FreeBSD.ORG>, 杉村 貴士 <sugimura@jp.FreeBSD.org>. 5 November 1997. FreeBSD 2.X FAQ へようこそ! この FAQ の目的は? Usenet の FAQ がそうであるように, この文書も FreeBSD オペレーティングシステムに関して頻繁に尋ねられる質問を 網羅することを目的としています (もちろんそれに対する答えも!). FAQ は本来バンド幅を減らし, 同じ質問が何度も繰り返されるのを 避けるために作られたものですが, 最近は有用な情報源と 見なされるようになってきました. この FAQ をできる限り有用なものにしようと, あらゆる努力が はらわれています. もし何かしらの改善案が浮かんだら, ぜひ FAQ 管理者 まで メールを送ってください. FreeBSD って何? FreeBSD 2.X はカリフォルニア大学バークレイ校が i386 系の プラットフォーム向けにリリースした 4.4BSD-lite をもとにした UN*X ライクなオペレーティングシステムです. 間接的には同じ バークレイ校の Net/2 を William Jolitz が i386 系に移植した 386BSD も基にしていますが, 386BSD のコードはほとんど残って いません. FreeBSD についての詳細と, 何ができるかについては FreeBSD のホームページ を参照してください. FreeBSD は企業やインターネットサービスプロバイダ, 研究者, コンピュータ専門家, 学生, 家庭のユーザなどにより, 業務や教育, 娯楽に用いられています. これらに関しては FreeBSD ギャラリー を参照してください. FreeBSD に関するより詳しい情報は FreeBSD ハンドブック を参照してください. FreeBSD が目指しているもの FreeBSD プロジェクトの目的は, いかなる用途にも使用でき, 何ら 制限のないソフトウェアを供給することです. 私たちの多くは, コード (そしてプロジェクト) に対してかなりの投資をしてきており, これからも多少の代償はあっても投資を続けて行くつもりです. ただ, 他の人達にも同じような負担をするように主張している わけではありません. FreeBSD に興味を持っている一人残らず 全ての人々に, 目的を限定しないでコードを提供すること. これが, 私たちの最初のそして最大の「任務」であると信じて います. そうすれば, コードは可能な限り広く使われ, 最大の 恩恵をもたらすことができるでしょう. これが, 私たちが熱烈に 支持しているフリーソフトウェアの最も基本的な目的であると, 私は信じています. 私たちのソースツリーに含まれるソースのうち, GNU 一般公有使用許諾 (GPL) または GNU ライブラリ 一般公有使用許諾 (GLPL) に従っているものについては, 多少制限が 科されています. ただし, ソースコードへのアクセスの 保証という, 一般の制限とはいわば逆の制限 (訳注1) です. ただし GPL ソフトウェアを商用で利用する場合, さらに複雑になるのは 避けられません. そのため, それらのソフトウェアを, より制限の 少ない BSD 著作権に従ったソフトウェアで置き換える努力を, 可能な限り日々続けています. (訳注1) GPL では, 「ソースコードを実際に受け取るか, あるいは, 希望しさえすればそれを入手することが可能であること」を求めています. どうして FreeBSD と呼ばれているのですか? 無料 (free) で使うことができる (商利用も含む). オペレーティングシステムの完全なソースコードが自由に (freely) 手に入り, 商利用・非商利用にかかわらず, 最低限の制限で他の仕事への利用, 配布, 導入が可能. 改良やバグフィックスがある場合, 誰でも (free) その コードを提出でき, ソースツリーに加えることができます (いくつかの簡単な条件には従ってもらいます). 母国語が英語でない読者のために, ここでは ``free'' という単語が 二通りに用いられていることを指摘しておくとわかりやすいかも しれません. ひとつは「無料である」ということ, もうひとつは 「自分のやりたいようにできる」ということです. FreeBSD のコードで できない いくつかのこと (自分が書いたものだと偽るなど) を 除けば, あなたは自分のやりたいことをやることが可能なのです. FreeBSD の最新バージョンは? 3.2 が最新の stable バージョンで, 1999 年 5 月にリリースされました. また, これは最新の release バージョンでもあります. 簡単に言ってしまうと, -stable は最新の -current のスナップショットのすばらしい新機能の数々よりも, 安定性と変更回数の 少なさを好む ISP や他の企業のユーザをターゲットにしています. リリースはこの二種類の "ブランチ" で行なわれますが, (-stable と比較すると多少)不安定な動作があるということを 許容できるなら, 必要となるのは -current の方だけでしょう. 各リリースは 数カ月毎にしか行なわれません. 多くの人々が FreeBSD のソースをそのリリースよりも 最新の状態に維持している ( FreeBSD-current と FreeBSD-stable に関する質問も参照して下さい) のですが, ソースというのは常に改変され続けているため, そうすることは一種の慣例になっています. FreeBSD-currentって何? FreeBSD-current は オペレーティングシステムのの開発バージョンで, やがて 4.0-RELEASE となります. よってこれは, そこに携わっている開発者や, どんな障害をも乗り越えていけるタフな愛好家たちにとってのみ 興味深いものです. -current の使用に際しての詳細は ハンドブック の 関連するセクション を参照してください. オペレーティングシステムに馴染みがない場合や一時的な問題か 本物の問題かを見極める能力がない場合は, FreeBSD-current を 使うべきではありません. このブランチは時々急激に拡張されたり, ビルドできない状態になることもちょっちゅうあります. FreeBSD-current を使う人は, 問題を分析して「小さな欠陥」では なく間違いであると思われるものだけを報告できるものと想定され ています. 「make world したら group 関係でエラーがでました」 のような質問は -current メーリングリストでは軽蔑の眼差しで あしらわれることもあります. 時たま, -current の開発コードから snapshot が作成され, snapshot の中からは 配布 CD-ROM が作成されることもあります. それぞれの snapshot には以下のような目的があります: インストールプログラムの最新版のテスト. 試してみたいけれど, 基礎的な所から毎日変わるような ものを追いかける時間もバンド幅も無い, という人にも -current を使えるようにする. また, そのような人たち のシステム移行のための手っ取り早い方法を提供する. あとでとんでもないことをしてしまった時のために, 問題となるコードの特定の参照基準点を保存しておく. (通常は CVS がこういうハプニングのような恐ろしい事態を防止して いるんですけどね :) テストが必要な新しい機能を, できる限り多くの 隠れテスターに試してもらう. どんな目的であれ, snapshot が「製品レベルの品質」であるとの考えに 基づく要求は行わないでください. 安定性やテスト十分性にこだわる人は 完全なリリースから離れてはいけません. 4.0-current および 3.0-stable ブランチ両方の snapshot は, 平均的に一日に一度生成されており, ftp://current.freebsd.org/pub/FreeBSD/ から直接入手することが できます. FreeBSD-stable のコンセプトって何? FreeBSD 2.0.5 がリリースされた後, 私たちは FreeBSD の開発を 2 系統に分割することにしました. 一つは -stable というブランチで, バグの修正はしっかりテストされ, 機能の強化は少しずつしか行われません (急な変更や実験的機能を望まない, インターネットサービスプロバイダや営利企業向け). もう一方のブランチは -current で, 2.0 がリリースされて以来 4.0-RELEASE (そしてその後も) へ向けて脈々と 続いているものです. ASCII で描いた簡単な図がわかりやすいかは自信がありませんが, こんな感じになります: 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年3月) | | | [2.2-stable] *BRANCH* 2.2.1 -> 2.2.2-RELEASE -> 2.2.5 -> 2.2.6 -> 2.2.7 -> 2.2.8 [終了] | (1997年3月) (97年10月) (98年4月)(98年7月)(98年12月) | | 3.0-SNAPs (1997年第一四半期開始) | | 3.0.0-RELEASE (1998年10月) | | [3.0-stable] *BRANCH* 3.1 (Feb 1999) -> 3.2 -> ... 今後の 3.x リリース群 ... | (1999年5月) | \|/ + [4.0-current として継続中] -current ブランチは 4.0 とその先へ向けてゆっくりと進化を続けており, 以前の 2.2-stable ブランチが 2.2.8 のリリースをもって終了しました. 3.0-stable がそれに替り, 1999 年の第三四半期に 3.3 がリリースされます. 4.0-current が現在の "current branch" であり, 最初の 4.0 系列の リリースは 2000年第一四半期の予定です. FreeBSD のリリースはいつ作られるのですか? 原則的には, FreeBSD コアチームは新しい機能やバグフィックスが 充分集まり, リリースの安定性を損なうことが無いようにさまざま な変更が十分に安定しているという条件を満たしている場合にのみ, 新しいバージョンの FreeBSD をリリースします. たとえこの用心深さが新しい機能が使えるようになることを 待ち望んでいるユーザを欲求不満にさせるとしても, 多くのユーザは このことを FreeBSD の最も良い所の一つだと考えています. 平均的には, だいたい 4 ヶ月ごとにリリースが作成されます. もう少し刺激が欲しい (あるいは待ち遠しい) 方々向けに SNAP というものが存在し, これは特にリリースに近付いてきた数ヶ月 ぐらいの期間により頻繁に公開されます. FreeBSD は PC 用だけしかないの? 現在 FreeBSD 3.x は x86 アーキテクチャと同様, DEC Alpha でも動作します. また, SPARC への移植という興味深い話もありますが, このプロジェクトの詳細については未だ不透明です. 異なるアーキテクチャのマシンを 持っていて, ゆっくり待てないという場合には次の URL を 参照してください. NetBSD または OpenBSD. 誰が FreeBSD の責任者? プロジェクトの全体的な方向性や, 誰にソースツリーにコードの 書き込み権限を与えるか, などといった FreeBSD プロジェクトに関する 重要な意思決定は 15 名からなる コアチーム によってなされます. ソースツリーを直接変更できる人はもっと多く, 150 名以上の ソースツリー管理者 (committer) がいます. しかし, 通常の変更ではないものはで先行して議論されますが, この議論への参加については一切の制限はありません. どこから FreeBSD を入手できますか? FreeBSD のすべての主要なリリースは anonymous FTP 経由で FreeBSD FTP サイト から入手できます: 現在の 2.2-stable リリース, 2.2.8R は FreeBSD 2.2.8-RELEASE にあります. 現在の 3.0-stable, 3.0-RELEASE は 3.0-RELEASE にあります. メンテナンスモードに入っている RELENG_2_2 ブランチ (2.2.8 以降) に基づき一日に一回, 2.2 Snapshot リリースが作成されます. RELENG_2_2 ブランチは現在, 保守要員によって注意深く保守されており, セキュリティや信頼性面での強い必要性がなければ, 変更が加えられる ことはありません. 3.2-RELEASE へ向けた 3.0 Snapshot リリースも一日に一回, RELENG_3 ブランチ (3.0-release 以降) に基づいて作成されます. 4.0 Snapshot リリースは ブランチ用に一日に一回 作成されており, これらは純粋に最先端の開発者およびテスターのために 提供されています. また, FreeBSD は CD-ROM でも入手でき, 次のところでオーダできます. Walnut Creek CDROM 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: WC Orders address WWW: WC Home page オーストラリアでは, 次のところに問い合わせてください. 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 のメーリングリストについて知りたいのですが? 完全な情報が ハンドブックのメーリングリストの節にあります. FreeBSD の西暦 2000 年問題に関する情報はどこにありますか? FreeBSD Y2K のページ に, 完全な情報があります. FreeBSD のニュースグループは何がありますか? 完全な情報が ハンドブックのニュースグループの節にあります. FreeBSD の IRC (Internet Relay Chat) について何か情報はありますか? あります. FreeBSD チャットチャンネルのもっとも主要な IRC ネットワークホストは以下の通りです: EFNet の Channel #FreeBSD は FreeBSD 関係の フォーラムですが, そこでは技術的サポートを期待しては いけません. そこにいる人たちはあなたをマニュアルページを 読むとか研究をするとかといった苦労から遠ざけようとします. まず第一に, これはチャットチャンネルであり, そこにある トピックスは恋人募集, スポーツ, 核兵器といったようなものであり, FreeBSD も同列に扱われています. 一応注意しましたからね! irc.chat.org のサーバー上にあります. DALNET の Channel #FreeBSD はアメリカでは irc.dal.net, ヨーロッパでは irc.eu.dal.net にあります. UNDERNET の Channel #FreeBSD はアメリカでは us.undernet.org, ヨーロッパでは eu.undernet.org にあります. ここも EFNet と同様のことがいえます. 助けてもらいたくて質問したり かしこまって教えを乞うことはしてはいけません. ここは チャットチャンネルでありヘルプチャンネルではありません. 最後に, BSDNET の #FreeBSD に入ることもできます. BSD 専用の小さなチャットネットワークで irc.FreeBSD.org にあります. このネットワークは EFNET, UNDERNET, DALNET のような無法地帯ではなく, より技術的なサポートをおこなおうとしていますが, 閑古鳥が鳴いている 状態です. なぜ BSDNET で FreeBSD 関係の質問に答えてくれる ボランティアがいないのでしょう? それぞれのチャンネルは別個のもので互いに接続されていません. チャットのスタイルも違っているので自分のチャットのスタイルにあった ものを見つけるために一つ一つ試すのもいいでしょう. あらゆる種類の IRC トラフィックのため, 失礼なことをいう若い人たち (年輩の方は少数です) に機嫌を損ねたり手に負えなくなっても 気にしてはいけません. FreeBSD の本 FreeBSD ドキュメンテーションプロジェクトがありますので, doc メーリングリストにコンタクトしてみてください (さらに参加すればもっとよいでしょう). <freebsd-doc@FreeBSD.ORG>. このリストは FreeBSD のドキュメントに関して議論するためのものです. FreeBSD に関する質問に対しては questions というメーリングリストがあります: <freebsd-questions@FreeBSD.ORG>. FreeBSD の「ハンドブック」もあり, FreeBSD ハンドブック から読むことができます. 現在作業中ですので不完全な部分もあることに注意してください. FreeBSD のガイド本の決定版は Greg Lehey が書いた ``The Complete FreeBSD'' で Walnut Creek CDROM Books から出版されて います. 現在は第二版になっていて, インストール, システム管理ガイド, プログラム設定のヘルプ, マニュアルページまでの内容が 1,750 ページに わたって書かれています. この本は (そして現在の FreeBSD リリースは) Walnut Creek, CheapBytes, または 最寄りの書店で注文することができます. ISBN コードは 1-57176-227-2 です. しかし, FreeBSD 2.2.X は Berkeley 4.4BSD-Lite2 ベースなので, ほとんどの 4.4BSD のマニュアルが FreeBSD 2.2.X にも応用できます. O'Reilly and Associates が以下のマニュアルを出版しています. 4.4BSD System Manager's Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 804 pages ISBN: 1-56592-080-5 4.4BSD User's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 905 pages ISBN: 1-56592-075-9 4.4BSD User's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 712 pages ISBN: 1-56592-076-7 4.4BSD Programmer's Reference Manual By Computer Systems Research Group, UC Berkeley 1st Edition June 1994, 886 pages ISBN: 1-56592-078-3 4.4BSD Programmer's Supplementary Documents By Computer Systems Research Group, UC Berkeley 1st Edition July 1994, 596 pages ISBN: 1-56592-079-1 WWW 経由で以下の URL から, これらの詳細な説明を読むことができます. 4.4BSD books description. 販売数が少ないためこれらの マニュアルは入手しにくいかもしれません. 4.4BSD のカーネル構成についてより徹底的に知りたいのなら, これなら間違いないでしょう: McKusick, Marshall Kirk, Keith Bostic, Michael J Karels, and John Quarterman. The Design and Implementation of the 4.4BSD Operating System. Reading, Mass. : Addison-Wesley, 1996. ISBN 0-201-54979-4 システム管理について参考になる本は次のものです. Evi Nemeth, Garth Snyder, Scott Seebass & Trent R. Hein, ``Unix System Administration Handbook'', Prentice-Hall, 1995 ISBN: 0-13-151051-7 注意 初版のものではなく, 赤いカバーの第二版であるか 確認してください. この本は TCP/IP だけでなく DNS, NFS, SLIP/PPP, sendmail, INN/NNTP, 印刷などの基礎を扱っています. 高価ですが (およそ US$45-$55), 買う価値はあります. また, 色々なツールのソースコードが入った CD-ROM が付属しています. しかし, それらのほとんどは FreeBSD 2.2.6R CD-ROM に収録されています (さらに FreeBSD CD-ROM の収録物の方がより新しい場合があります). Problem Report (障害報告) データベースにアクセスする方法は? ユーザ変更要求のすべてが公開されている Problem Report データベースは 障害報告の 提出 と 問い合わせ の web ベースのインタフェースを通して, 問い合わせ (または提出) をおこなうことができます. また, send-pr(1) コマンドを使用して, 電子メール経由で障害報告や変更要求を提出することもできます. FAQ の ASCII/Postscript 版はどこで手に入りますか? 最新の FAQ は FreeBSD Web サーバやほかのミラーサイトから Postscript 形式やプレインテキストで取ってくることができます. (7 ビット ASCII と 8-bit Latin1) PostScript として (約 370KB): http://www.freebsd.org/FAQ/FAQ.ps ASCII テキストとして (約 220KB): http://www.freebsd.org/FAQ/FAQ.ascii ISO 8859-1 テキストとして (約 220KB): http://www.freebsd.org/FAQ/FAQ.latin1 ハンドブックの ASCII/Postscript 版はどこで手に入りますか? 最新のハンドブックは FreeBSD Web サーバやほかのミラーサイトから Postscript 形式やプレインテキストで取ってくることができます. (7 ビット ASCII と 8-bit Latin1) PostScript として (約 1.7MB): http://www.freebsd.org/handbook/handbook.ps ASCII テキストとして (約 1080KB): http://www.freebsd.org/handbook/handbook.ascii ISO 8859-1 テキストとして (約 1080KB): http://www.freebsd.org/handbook/handbook.latin1 ASCII のハンドブックはプレインテキストではありません! 正確には, FAQ やハンドブックの ASCII や Latin1 の版は厳密な プレインテキストではありません. それらはドットマトリクスプリンタへ 直接出力するための下線や重ね刷り文字が含まれています. もしそれらを 人間が読める形になったものが欲しかったら, そのファイルを col に 通してください. $ col -b < inputfile > outputfile FreeBSD の Web のミラーサイトになりたいです! 承知しました! Web ページをミラーするにはいくつかの手段があります. CVSUP を使います. cvsup.freebsd.org から CVSUP を使うことで 整形されたファイルを取ってくることができます. 次の行をあなたの cvsup ファイルに加えてください. www release=current hostname=/home base=/usr/local/etc/cvsup prefix=/usr/local/www/data/www.freebsd.org delete old use-rel-suffix rsync を使います. the mirroring page を見てください. ftp mirror を使います. あなたの好きな ftp mirror ツールを使って FTP サーバに置いてある web サイトのコピーをダウンロードすることが できます. 単に ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/www から始めてみましょう. このドキュメントを何語かに翻訳したいのですが. 報酬は支払えませんが, もしドキュメントの翻訳を提出してくださったら フリーの CD や T シャツ, そしてハンドブックにある貢献者一覧に登録する といった手配は行うことでしょう. その他の情報 以下のニュースグループには FreeBSD ユーザに直接関係のある 議論が行われてます. comp.unix.bsd.freebsd.announce (moderated) comp.unix.bsd.freebsd.misc comp.unix.bsd.misc Web 上のリソース: FreeBSD の Home Page. ラップトップ PC を持っている方は, 迷うことなく 日本の細川 達己氏の Mobile Computing のページ を見ましょう. SMP (Symmetric MultiProcessing) に関する情報は, SMP サポートページをご覧ください. FreeBSD のマルチメディア アプリケーションに関する情報は, マルチメディアのページをご覧ください. 特に Bt848 ビデオキャプチャーチップに興味のある方は, リンクをたどってみてください. FreeBSD handbook には本当に完璧な 参考図書 の一覧があり, 買うべき本をさがしている方は読む価値があります. インストール 訳: 岩崎 満 <iwasaki@jp.FreeBSD.org> むらたしゅういちろう <mrt@mickey.ai.kyutech.ac.jp> .8 November 1997. FreeBSD を入手するにはどのファイルをダウンロードすればいいですか? 通常は floppies/boot.flp というファイルの フロッピーディスクイメージが一つだけ必要になります. 1.44MB の フロッピーディスクに書き込み, そこからブートしてその他のファイル群を ダウンロードします (インストールプログラムが TCP/IP 接続, テープ, CD-ROM, フロッピーディスク, DOS パーティションなど, インストールに必要なもの すべてに関する処理を担当します). 自分で配布ファイルをダウンロードする必要がある場合 (たとえば DOS ファイルシステムからのインストールなど), おすすめの配布ファイル構成は 以下の通りです. bin/ manpages/ compat*/ doc/ src/ssys.* この手続きの完全な説明と, 一般的なインストール時の問題については ハンドブックのインストールの節 を参照してください. ブートフロッピーイメージが一枚のフロッピーディスクに納まらないみたい! 3.5 インチ (1.44MB) のフロッピーディスクには 1474560 バイトのデータを 格納できます. ブートイメージはちょうど 1474560 バイトの大きさです. ブートフロッピーディスクを準備する際のよくある間違いには 以下のものがあります. FTP によってフロッピーイメージをダウンロードする際に, binary モードにしていなかった. FTP クライアントの中には転送モードのデフォルトを ascii モードにしてクライアント側システムの慣習にあうようにすべての行末の 文字を変更するものがあります. この場合は常にブートイメージが 壊れたものになります. ダウンロードしたブートイメージのサイズを チェックしてください. サーバ上のものと 正確に 同じでない場合, ダウンロードの処理を疑いましょう. これを回避するには, サーバに接続してイメージのダウンロードを 開始する前に, FTP のコマンドプロンプトで binary とタイプします. ブートイメージを DOS の copy コマンド (または GUI の同等のツール) でフロッピーディスクへ転送した. copy のようなプログラムは, 直接起動するように作成された ブートイメージに関してはうまく処理できません. イメージにはフロッピーディスクの完全な中身がトラック単位で 格納されており, フロッピーディスク上に通常のファイルとして 格納されるようには想定されていません. FreeBSD のインストール に記述されているように, ローレベルのツール (例 fdimage または rawrite) を使用して ``raw'' の状態でフロッピーディスクに 転送する必要があります. FreeBSD のインストールについての説明書はどこにありますか? インストールの説明書は次のところにあります. ハンドブックの「FreeBSD のインストール」の章 FreeBSD を動作させるには何が必要ですか? 386 以上の PC, 5MB 以上の RAM, そして最低 60MB の ハードディスク容量が必要となります. ローエンドの MDA カード でも動作しますが, X11R6 を使うには VGA かそれ以上のビデオカード が必要となります. の節も併せてご覧ください. 4 MB しかメモリがないのですが, インストールできますか? 4MB のシステムにインストールできた FreeBSD の最新版は FreeBSD 2.1.7 でした. 2.2 のように, 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 環境全体を 新たに作る必要があります. /usr/src/release/floppies/Makefile にあるコードでフロッピーディスクイメージ「だけ」を作れるはずですが, まだ完全なものにはなっていません. カスタムの release 環境をつくるには の指示にしたがってください. 自分の PC に複数のオペレーティングシステムを入れるには? multi-OS のページ をご覧ください. 同じマシンで Windows 95 と共存できますか? まず Windows 95 をインストールして, そのあとで FreeBSD を インストールしてください. FreeBSD のブートマネージャが Win95 と FreeBSD のブート管理をしてくれるようになります. Windows 95 を後にインストールした場合はひどいことに, 問い合わせることもなくブートマネージャを上書きしてしまいます. そうなってしまった場合は次の節をご覧ください. Windows 95 がブートマネージャを潰しちゃった! どうやって戻すの? ブートマネージャの再インストールの方法として, FreeBSD では 以下に示す二通りの方法が用意されています: DOS を起動し, FreeBSD の配布物の中にある tools/ ディレクトリ へ移動し, bootinst.exe を探してみてください. そして次のように実行してください: bootinst.exe boot.bin ブートマネージャが再インストールされます. FreeBSD のブートフロッピーディスクから起動し, 「カスタム」 インストールメニューを選択し, 続いて「パーティション」を 選択します. ブートマネージャがインストールされていたドライブ (多分最初のもの) を選択し, パーティションエディタにたどり着いたら, (何も変更せず) そのまま (W)rite を指定します. 確認のメッセージ が出ますので「はい」と答え, ブートマネージャ選択の画面で確実に "Boot Manager" を選択します. これでブートマネージャがディスクに再び書き込まれます. インストールメニューから抜けてリブートするとハードディスクは 元通りになります. 不良ブロックのあるディスクにインストールできますか? FreeBSD の不良ブロックの扱い (bad144 コマンド) は, (ひいき目に見ても) 100% 完全ではなく, 残念ながら 多数の不良ブロックのある IDE や ESDI ドライブは FreeBSD では使用できないと言わざるをえません! でも, 非常に多くの IDE ベースのシステムで動作しているようですので, 簡単にあきらめて しまう前にとりあえず試してみましょう. 不良ブロックのある SCSI ドライブの場合は, を参照してください. インストーラからブートしたら変なことになりました! インストーラからブートしようとしたときに, マシンが固まってし まうとか自然とリブートしてしまうといった現象であれば, 次の三つの項目を確認してください:- 新品の, フォーマットしたての, エラーフリーの フロッピーディスクを使っていますか? (三年間もベッドの下に 放置されていた雑誌の付録みたいなやつではなくて, 買ってきたばかりの新品が好ましいですね) フロッピーイメージをバイナリモードでダウンロード しましたか? (困った顔をしないでください. 私たちの中 で一番優秀な人でさえ, 少なくとも一回はバイナリファイルを ASCII モードで思いがけずダウンロードしたことがあるのです!) Windows95 や Windows NT のような最近ご流行の オペレーティングシステムを使用している場合, システムを シャットダウンしてありのままの本物の DOS を再起動 しましたか? これらの OS は, ディスク作成プログラム のようなハードウェアに直接書き込みをおこなうプログラムに 干渉できます: GUI の中の DOS シェル内部で動作している 場合でも, この問題は発生します. また, Netscape でブートイメージをダウンロードする場合も問題 があることが報告されていますので, できれば別の FTP クライアント を使うのがよいでしょう. あれ! テープからインストールできません! 2.1.7R をテープからインストールする場合, tar ブロックサイズ を 10 (5120 バイト) にしたテープを作る必要があります. デフォルト の tar ブロックサイズは 20 (10240 バイト) で, このデフォルトサイズで作られたテープでは 2.1.7R を インストールすることはできません. もしこうしたテープを使うと, レコードサイズが大き過ぎるというエラーが起きることになります. パラレルライン (PLIP) 経由でふたつの FreeBSD box を接続したい Laplink パラレルケーブルを用意してください. 両方の PC の kernel に lpt ドライバが組み込まれていることを確認してください. $ dmesg | grep lp lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface パラレルインタフェースに Laplink パラレルケーブルを接続します. root になって両方で lp0 のネットワークインタフェースパラメータを設定します. 例えば, ホスト max と moritz を接続したい場合, max <-----> moritz IP Address 10.0.0.1 10.0.0.2 max 側で次のようにして # ifconfig lp0 10.0.0.1 10.0.0.2 moritz 側でも # ifconfig lp0 10.0.0.2 10.0.0.1 のようにします. 以上です! lp(4) と lpt(4) のマニュアルページも参照してください. また, /etc/hosts にホストの追加もしましょう. 127.0.0.1 localhost.my.domain localhost 10.0.0.1 max.my.domain max 10.0.0.2 moritz.my.domain moritz 動作確認は次のようにします: max 側: $ ifconfig lp0 lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 $ netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire moritz max UH 4 127592 lp0 $ ping -c 4 moritz PING moritz (10.0.0.2): 56 data bytes 64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms 64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms 64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms 64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms --- moritz ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms ラップトップ PC に PLIP (パラレルライン IP) 経由でインストールできますか? 次のようにして二つのコンピュータを Laplink パラレルケーブル を通して接続してください: +----------------------------------------+ |A-name A-End B-End Descr. Port/Bit | +----------------------------------------+ |DATA0 2 15 Data 0/0x01 | |-ERROR 15 2 1/0x08 | +----------------------------------------+ |DATA1 3 13 Data 0/0x02 | |+SLCT 13 3 1/0x10 | +----------------------------------------+ |DATA2 4 12 Data 0/0x04 | |+PE 12 4 1/0x20 | +----------------------------------------+ |DATA3 5 10 Strobe 0/0x08 | |-ACK 10 5 1/0x40 | +----------------------------------------+ |DATA4 6 11 Data 0/0x10 | |BUSY 11 6 1/0x80 | +----------------------------------------+ |GND 18-25 18-25 GND - | +----------------------------------------+ また, Mobile Computing についての ページもご覧ください. ハードディスクドライブには, どのジオメトリを使うべきでしょうか? (ここでディスクの「ジオメトリ」とは, ディスクのシリンダ, ヘッダ, トラック当りのセクタの数を意味しています - 便宜上, 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と一緒にに配布されているフリー で使えるユーティリティに ``pfdisk''(FreeBSD CD-ROM の toolsディレクトリかいろいろな FTP サイトにあります) と呼ばれるものがあり, ディスク上の他のオペレーティングシステム が使用しているジオメトリを調べるのに役立ちます. そして, この ジオメトリ情報をパーティションエディタに入力することができます. ディスクの分割の仕方で何か制限はありますか? はい. BIOS がカーネルをブートできるようにルートパーティションが 1024 シリンダ以内にあることを確認する必要があります (これは FreeBSD ではなく PC の BIOS の制限です). SCSI ドライブでは, 通常はルートパーティションが最初の 1024MB に収まっていることが前提となります (または拡張 BIOS トランスレーション が有効になっている場合は最初の 4096MB - 他の質問をご覧ください). IDE でそれに相当する値は 504MB となります. (訳注: E-IDE 対応の BIOS 搭載マシンの場合は IDE の 504MB という 制限はありません.) 大容量ディスクを持っていますが, ディスクマネージャは使えますか? FreeBSD は Ontrack Disk Manager を認識し, これを考慮にいれます. 他のディスクマネージャはサポートしません. ディスク全体を FreeBSD で使いたい場合は, ディスクマネージャ は必要ありません. BIOS が扱える容量いっぱいで (通常は 504MB) ディスクの設定をおこなうと, FreeBSD は実際の容量を算出する はずです. MFM コントローラ付きの古いディスクを使っている場合は, FreeBSD に使用するシリンダ数を詳細に指定する必要があります. FreeBSD と他のオペレーティングシステムが入っているディスクを 使用したい場合は, ディスクマネージャなしでもできるでしょう: FreeBSD のブートパーティションと他のオペレーティングシステム 用のスライスが最初の 1024 シリンダ内に収まっている事を確認 するだけです. 気になる方は, ブートパーティションを 20 メガバイト ぐらいにして大きめにするととよいでしょう. FreeBSD のブート時に ``Missing Operationg System'' と表示されます これは FreeBSD や DOS, そのほかの OS がディスク領域 のとらえ方で衝突 しあっていることから起こる典型的な例です. こうなったら FreeBSD をインストールし直す以外にはありませんが, 他のところで説明した手順にしたがってやれば, ほぼ間違いなくうまくいくはずです. ブートマネージャの `F?' プロンプトが表示されません. これはすでに前に質問されている問題のもう一つの症状です. BIOS のジオメトリと FreeBSD のジオメトリ設定が一致していないのです! コントローラや BIOS がシリンダの変換 (``>1GB ドライブの サポート'' とも呼ばれます) をサポートしていたら, その設定を無効化して FreeBSD をインストールし直してみてください. 16MB を越えるメモリを搭載していますが, 何か問題が起こりますか? 性能問題以外は無しです. FreeBSD 2.X は bounce-buffer をサポートしており, バスマスタリングコントローラは 16MB より上のメモリ領域に アクセスできます. (ISA デバイスを使用している場合のみ必要 となりますが, 一部の EISA と VLB デバイスでも必要な場合 があります.) また, もっと多くのメモリを搭載している場合, Compaq や利用可能な メモリサイズを正しく報告しない他の BIOS を使用している場合は, の節をご覧ください. ソースを全部インストールする必要はありますか? 一般的には「いいえ」です. しかし最低でも, ``base'' ソースキット (これにはこの FAQ で述べられているファイルの いくつかが含まれています) と, ``sys'' (kernel) ソースキット (これにはカーネルのソースが含まれています) をインストール する事を強くおすすめします. 通常, 何かの実行にソースが必要 になる事はありません. しかし, カーネルをコンフィグレーション するためのプログラム config を実行する時は例外です. カーネルのソースをインストールしなくてもよい例として, どこか 別の場所からカーネルのソースを読み込み専用で NFS マウントする 事ができ, またそこから新しいバイナリを作成できるようになって います. (カーネルソースの制限があるので, 直接 /usr/src を マウントする事はおすすめできません. それよりもどこか別の ディレクトリにマウントして, ソースツリーの複製ができるように 適切にシンボリックリンクを張ってください.) ソースをネットワーク上に持ち, そこからシステムをビルド するようにしておけば, FreeBSD の将来のリリースへのアップグレード がずっと簡単になります. 実際にソースのサブセットを選択するには, システムインストール ツールの「配布ファイル」メニューにある「カスタム」メニュー を使用します. また, src/install.sh スクリプトでも 与える引数によってソース配布ファイルの一部分をインストールできます. カーネルは作り直さなくちゃならないんですか? カーネルを新しく作り直すのは元々 FreeBSD のインストール時に どうしても必要なことでした. でも最近のリリースでは, とても ユーザフレンドリなカーネル設定ツールの恩恵を受けています. FreeBSD のブートプロンプト (boot:) で "-c" と打てば ビジュアルな設定画面になり, ほとんどの一般的な ISA カードに ついてのカーネルの設定をすることができるのです. 今でも, 必要なデバイスドライバだけを組み込んだカーネルを 作ることはよい事とされています. ほんのちょっとだけメモリを 節約できますからね. でもほとんどのシステムでは, もはや どうしてもやらなくちゃならないことではないのです. アメリカ合衆国国外に住んでいますが, DES 暗号化ソフトウェアは使えますか? DES スタイルの暗号化コードの使用が絶対避けられないものでない 場合は, よりよいセキュリティで輸出規制のない FreeBSD の デフォルトの暗号化コードが使用できます. FreeBSD 2.0 ではパスワードの デフォルトのスクランブラは MD5 ベースになっています. これは, パスワード破りのプログラムに対して DES よりも CPU パワーを要求し, またより長いパスワードを使うことできます. いまどき MD5 ベースの crypt を使用しない理由があるとすれば, それは FreeBSD とそれ以外のシステムで同じ password エントリを 使用しているぐらいのもんでしょう. DES 暗号化アルゴリズムを合法的に合衆国国外に持ち出す事 ができないため, 合衆国国外のユーザは合衆国の FTP サイト から該当するソフトウェア (secrdist の部分) を 持ち出してはいけません. しかし, これに代わる libcrypt が, オーストラリアの David Burren によって書かれたソースをベースに作られています. これは合衆国国外のいくつかの FTP ミラーサイトで公開されています. この制限の課せられていない libcrypt のソースと, それを 使ったプログラムのバイナリは, 以下の FTP サイトから入手する 事ができます: 南アフリカ ftp://ftp.internat.freebsd.org/pub/FreeBSD ftp://storm.sea.uct.ac.za/pub/FreeBSD ブラジル ftp://ftp.iqm.unicamp.br/pub/FreeBSD フィンランド ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt 訳注: 日本国内では以下のサイトにあります. 日本 ftp://jaz.jp.freebsd.org/pub/FreeBSD-internat この合衆国国外向けの securdist は, 合衆国国内向けの securedist をちょうど置き換えるように使う事ができます. この securedist は合衆国国内版のパッケージと同じ方法で インストールできます (詳しい方法はインストールノートを ご覧ください). DES 暗号化コードをインストールしたい場合は, 他のアプリケーションをインストールする前に, なるべく早い段階で インストールしておく必要があります. 合衆国国外のユーザは, お願いですからいかなる暗号化ソフトウェア も合衆国内からダウンロードしないでください. ダウンロードされた サイトの管理者は, 法律的にとても難しく困難な立場に立たされる 事になります. 合衆国以外向けの Kerberos も開発されつつあります. 現在の バージョンは anonymous FTP で braae.ru.ac.za から 入手できます. また, 合衆国国外向けの暗号化ソフトウェアに関する議論のための もあります. より詳しい情報については, メールの本文に ``help'' とだけ書いて <majordomo@braae.ru.ac.za> まで送ってください. ブートフロッピーで起動すると, ``Probing Devices...'' の画面でハングアップします. IDE Zip か Jaz ドライブが接続されていたら, それを取り外して もう一度試してみましょう. ブートフロッピーはこの種のドライブを誤認して しまうのです. システムがインストールされた後は, そのドライブを再度接続することができます. うまくいけばこの問題は将来のリリースで解決されるでしょう. インストール終了後にシステムをリブートすると, ``panic: cant mount root'' のエラーとなります. このエラーはディスクデバイスについてブートブロックとカーネルの 認識が混乱しているために起こります. このエラーは通常 2 台の IDE ディスクがそれぞれ別の IDE コントローラのマスターかシングルデバイス として接続されているシステムにおいて, FreeBSD がセカンダリ IDE コントローラに接続されたディスクにインストールされている場合に発生します. ブートブロックは FreeBSD が wd1 (2 台目の BIOS ディスク) にインストール されていると認識するのに対し, カーネルは セカンダリ IDE の 1 台目の ハードディスクである wd2 にインストールされていると認識するのです. デバイスプローブの後で, カーネルはブートブロックがブートディスクだと 認識したディスクである wd1 を mount しようとします. 実際には ブートディスクは wd2 なので失敗してしまうのです. この問題を解決するには, 以下のどれか一つを行ってください: Boot: プロンプトで, 1:wd(2,a)kernel と入力してエンターキーを押します. システムが起動したら, echo "1:wd(2,a)kernel" > /boot.config というコマンドを実行してこれをデフォルトのブート文字列とします. FreeBSD のディスクをプライマリ IDE コントローラに接続して, ハードディスクが連続したドライブ番号で認識されるようにします. カーネルのコンフィグレーションファイルで wd の行を以下のように 変更してからカーネルを再構築 を行い, 新しいカーネルをインストールします. 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 へ変更 ディスクの接続を変更して元の設定に戻したい場合は, ディスクを お望みの設定の通りの接続に戻してからリブートします. システムは正常に起動するはずです. メモリの大きさの制限は? メモリは, (論理的な) 限界は 4 ギガバイトです. 1 ギガバイトのものは すでにテストがされています. 普通は i386 の PC ではそれ以上のメモリを サポートしているものを買うことはできません. ffs ファイルシステムの大きさの制限は? ffs ファイルシステムは, 論理的な最大の上限は 8 テラバイト (2G ブロック) か, デフォルトのブロックサイズを 8K とすると 16 テラバイトとなります. 実際問題として, 1 テラバイトのソフトウェアの限界がありますが, 修正すれば 4 テラバイトのファイルシステムが可能です (実際に存在します). 一つの ffs のファイルの最大のサイズは, ブロックサイズが 4K の場合で 約 1 ギガブロック (4 テラバイト) です. maxfilesize ---------------------------------- 2.2.7 3.0 fs block size -stable -current works should-work ------------- ------- -------- ----- ----------- 4K 4T-1 4T-1 4T-1 4+T 8K 32+G 8T-1 32+G 16T-1 16K 128+G 16T-1 128+G 32T-1 32K 512+G 32T-1 512+G 64T-1 64K 2048+G 64T-1 2048+G 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 テラバイトのファイルを格納するには? わたしのところではフロッピーにいくつかの実際のファイルを保存しています :-). 最大のファイルサイズは最大のディスクサイズとはあまり関係はありません. 最大のディスクサイズは 1TB です. ファイルサイズがディスクサイズより 大きくなりうるというのは仕様です. 以下の例は, 32K のディスク容量 (3 つの間接ブロックと 1 つのデータブロック) を使って, 小さなルートパーティションに 8T-1 の大きさのファイルを作成します. ここでの dd コマンドは 大きなファイルが扱えるものが必要です. ttyv0:bde@alphplex:/tmp/q> 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 . ttyv0:bde@alphplex:/tmp/q> sh foo Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/sd0a 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/sd0a 64479 27734 31587 47% / ttyv0:bde@alphplex:/tmp/q> exit Bruce Evans, September 1998 + + + +新しいカーネルをコンパイルしたのですが, ブート時に + "archsw.readin.failed" というエラーメッセージが + 表示されるようになってしまいました. + +起動させるには, ブートプロセスのセカンドステージにおいて + 起動したいカーネルを直接指定してください. + それには, ローダが始動する前, | が表示されている時に何かキーを押します. + これは特に, カーネルのソースをアップグレードして, 構築したカーネルを + make world しないで インストールしてしまった場合に + 起こります, この場合の動作はサポートされていません. + 必ず make world を実行してください. + ハードウェアコンパチビリティ 訳: にしか <nishika@cheerful.com>.12 November 1997. FreeBSD は, どんなハードディスクドライブをサポートしているのですか? FreeBSD は, EIDE と SCSI ハードディスクドライブをサポート しています (互換コントローラも含みます: 次の節参照). また オリジナルの "Western Digital" インタフェースを使用している すべてのドライブも (MFM, RLL, ESDI, もちろん IDE も) サポートしています. 独自仕様のインタフェースを使用する ESDI コントローラでは動作しないものがあり, WD1002/3/6/7 とその互換インタフェースと衝突します. どの SCSI コントローラをサポートしているのですか? ハンドブック に記されている完全なリストを参照 してください. どんな 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 には動作しないものもあるようです. Walnut Creek の FreeBSD 2.2 CD-ROM からは CD からの直接ブートが サポートされています. 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 をお使いでしたら, kernelコンフィグレーションファイルに scbus0, da0, ppbus0, vp0 の各ドライバが記述されていることを 確認してください. (GENERIC kernel には vp0 以外の全てが入っています). これら全てのドライバがあれば, パラレルポートのドライブは /dev/da0s4 となります. ディスクは mount /dev/da0s4 /mnt または mount_msdos /dev/da0s4 /mnt (DOS ディスクの場合) でマウント できます. それから および についても 確認しておいてください. では, JAZ や EZ, それからその他のリムーバブルドライブはサポートしていますか? FreeBSD では, IDE バージョンの EZ ドライブを除くすべての SCSI デバイスは, SCSI のディスクと同等に扱われます. また IDE EZ は IDE ドライブと同等となります. システム稼働中のメディア交換について FreeBSD が どれほどうまく動くか定かではありません. もちろんメディアを入れ替える前に そのドライブをマウント解除しなければいけないでしょうし, FreeBSD がそれらを認識するにはブート時に外部ユニットにも電源が投入されている ことを確認しなければいけないでしょう. も参照. どのマルチポートシリアルカードをサポートしていますか? 一覧は その他のデバイス の節にあります. 無名のカードにもうまく動くものがあり, 特に AST 互換といわれているものに多く見られます. カード設定の詳細な情報は, sio オンラインマニュアルを参照してください. 珍しいバスマウスを持っているのですが, どのように設定すればいいのですか? FreeBSD は Microsoft, Logitech, ATI 等のメーカーから出ているバスマウス と InPort バスマウスをサポートしています. バスマウスのデバイスドライバ は GENERIC カーネルに標準で含まれています. もしバスマウスのデバイス ドライバを含むカーネルを自分で構築する場合には, カーネルコンフィグレーションファイルに以下の行を忘れずに加えて下さい. device mse0 at isa? port 0x23c tty irq5 vector mseintr 通常バスマウスには専用のインタフェースカードが附属しています. インタフェースカードによってはポートアドレスや割り込み番号を上記の 設定以外に変更できるかもしれません. 詳しくはバスマウスのマニュアルと mse オンラインマニュアルを参照してください. PS/2 マウス(マウスポートマウス, キーボードマウス) を使うには, どのように設定すればいいのですか? あなたが 2.2.5 以降のバージョン FreeBSD を使っているのなら, 必要なドライバの psm はカーネルに含まれていて有効になっています. カーネルはブート時に PS/2 マウスを検出するでしょう. あなたの使っている FreeBSD が比較的新しいけれど前のバージョン (2.1.x 以降) のものなら, インストールの時に, 単にカーネルのコンフィグレーションのメニュー上で PS/2 マウスを有効化するだけです, あるいは後で boot: プロンプト上で -c を指定することでもメニューは現れます. デフォルトでは無効に設定されていますので, 明示的に 有効化してあげないといけません. あなたの使っている FreeBSD が比較的古いものなら, カーネルコンフィグレーションファイルに以下の行を加えて カーネルを再コンパイルする必要があります. device psm0 at isa? port "IO_KBD" conflicts tty irq 12 vector psmintr カーネルの再構築についてよく知らないのであれば, ハンドブックの FreeBSD カーネルのコンフィグレーション を参照してください. ブート時にカーネルが psm0 を検出したら, psm0 のエントリが /dev の中にあることを確認してください. 以下のようにします. cd /dev; sh MAKEDEV psm0 これは root でログインしているときにおこなってください. X Window System 以外の環境でマウスを使うことは可能ですか? もしデフォルトのコンソールドライバである syscons を使っているので あれば, テキストコンソール上でマウスを使ってテキストのカットアンド ペーストができます. マウスデーモンである moused を起動し, 仮想コンソール でマウスポインタを有効にして下さい. moused -p /dev/xxxx -t yyyy vidcontrol -m on ここで xxxx はマウスのデバイス名, yyyy はマウスの プロトコルタイプです. サポートされているプロトコルタイプについては moused オンラインマニュアルを参照してください. システムを起動する時に自動的に moused を起動したい場合には, FreeBSD 2.2.1 では以下の変数を /etc/sysconfig で設定して下さい. mousedtype="yyyy" mousedport="xxxx" mousedflags="" FreeBSD 2.2.2 以降のバージョンでは /etc/rc.conf で以下のように 設定して下さい. moused_type="yyyy" moused_port="xxxx" moused_flags="" FreeBSD 2.2.6 以降では, マウスデーモンは比較的古いシリアルマウス でない限りマウスのプロトコルタイプを自動判別できます. プロトコルタイプ として ``auto'' を指定すると自動判別を行なおうとします. マウスデーモンを実行中は, マウスデーモンと他のプログラム, 例えば X Window System, の間でマウスへのアクセスを調整しなければなりません. この問題に ついては を御覧下さい. テキストコンソールでマウスを使ってテキストのカットアンドペーストをするにはどうしたらよいのですか? マウスデーモンを起動したあと ( を参照して下さい), ボタン1 (左ボタン)を押しながらマウスを動かして範囲を指定して下さい. ボタン2 (中ボタン)またはボタン3 (右ボタン)をクリックするとテキスト カーソルの位置に選択した範囲のテキストがペーストされます. FreeBSD 2.2.6 以降ではボタン2 をクリックするとペーストされ, ボタン3 をクリックした場合には既存の選択範囲が現在のマウスポインタの位置まで 延長または短縮されます. もしマウスに中ボタンがないなら, moused の オプションを使って中ボタンのエミュレーションをするか, 他のボタンを 中ボタンとして使う事ができます. 詳しくは moused オンラインマニュアルを参照してください. 私のマウスには可愛いホイールやボタンがついているのですが, これは FreeBSD では使えるのですか? 答えは残念ながら「場合によります」です. こうしたマウスの付加的な機能は 大抵の場合特殊なドライバを必要とします. マウスのデバイスドライバや ユーザのプログラムがそのマウスに対する固有のサポートをしていない場合には 標準的な 2ボタンまたは 3ボタンマウスのように振舞います. ラップトップ PC のマウス/トラックボール/タッチパッドは使えますか? を参照してください. 加えて, にあるモーバイルコンピューティングの ページもご覧ください. どんなテープドライブをサポートしていますか? FreeBSD は SCSI, QIC-36 (QIC-02 インタフェース付き) および QIC-40/80 (フロッピーベース) テープドライブをサポートしています. これらには 8-mm (Exabyte と呼ばれています) や DAT ドライブも含まれています. QIC-40/80 ドライブは遅いことが知られています. 初期の 8-mm ドライブの中には SCSI-2 とまったく互換性を持たないものがあります. これらは FreeBSD 上では動作しません. どんなテープチェンジャーをサポートしていますか? FreeBSD 2.2 は ch デバイスと chio コマンドを使用した SCSI チェンジャーをサポートしています. 実際のチェンジャーの制御方法の詳細は, chio のマニュアルページにあります. 使用している製品が, AMANDA などのようにチェンジャーに対応済みのものでない場合は, 次のことについて留意してください. それらの製品は任意のポイント間のテープの移動を制御するだけなので, テープがどのスロットに入っているか, 現在ドライブにあるテープが どのスロットに戻るべきかを把握しておく必要があります. どんなサウンドカードをサポートしていますか? FreeBSD は SoundBlaster, SoundBlaster Pro, SoundBlaster 16, Pro Audio Spectrum 16, AdLib それから Gravis UltraSound サウンドカードを サポートしています. MPU-401 やその互換カードも機能に制限はあるものの サポートされています. マイクロソフトサウンドシステムのスペックに準拠 したカードも, pcm ドライバでサポートされています. 注 これらはサウンドについてのみの話です! これらのドライバは CD-ROM, SCSI, カード上にあるジョイスティックをサポートしていません (SoundBlaster は例外です). SoundBlaster SCSI インタフェースと非 SCSI CD-ROM はサポートしていますが, そのデバイスからはブートできません. どんなネットワークカードをサポートしていますか? より完全な一覧については イーサネットカード の節を参照してください. 数値演算コプロセッサを持っていません - 何かまずいでしょうか? 注意 これらは 386/486SX/486SLC を持っている場合に影響します - ほかのマシンでは CPU に内蔵されています. 一般にこれらは問題とはなりません. しかし, 数値演算エミュレーションコードの パフォーマンスか正確さのいずれかを選択する状況があります. ( についての節をご覧ください). とくに, X 上で弧を描く際にとても遅くなることでしょう. 数値演算コプロセッサを購入されることを強くおすすめします. とても役立つことでしょう. 注 他の数値演算コプロセッサよりも優れたコプロセッサもあります. これは言いにくいことなのですが, Intel を買うために躍起になる人もいないでしょう. それが FreeBSD 上で動くという確信がないのなら, クローンにご用心を. 2.x で, 他にどのドライバがサポートされていますか? ハンドブック に記されている, サポートされている他のデバイスの一覧を参照して下さい. パワーマネージメント機能付きのラップトップ PC を持っています. FreeBSD は一部のマシンの APM をサポートしています. LINT カーネルコンフィグファイル の APM の部分をご覧ください. Micron システムがブート時に固まってしまいます. 特定の Micron 製のマザーボードの中には, PCI BIOS が規格通りに 実装されていないために FreeBSD の起動に失敗するものがあります. その BIOS は, PCI デバイスをあるアドレスで設定したと報告するにも 関わらず, 実際にはそうしていないのです. この問題を回避するには, BIOS の ``Plug and Play Operating System'' を無効に設定して下さい. より詳しい情報は http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html#micron を御覧下さい. 新しい Adaptec コントローラを持っているのですが, FreeBSD が検出できないようです. 新しい AIC789x シリーズの Adaptec チップは, 3.0 でデビューした CAM SCSI フレームワークでサポートされています. 2.2-STABLE のパッチは ftp://ftp.FreeBSD.org/pub/FreeBSD/development/cam/ にあります. CAM システムが 入っている高機能ブートフロッピーは http://www.FreeBSD.org/~abial/cam-boot/ にあります. どちらの場合に しても, 作業を始める前に README をお読み下さい. 内蔵の Plug & Play モデムを持っているのですが, FreeBSD が検出できないようです. モデムの PnP ID を シリアルドライバの PnP ID リストに追加する必要が あるでしょう. Plug & Play サポートを有効にするには, controller pnp0 をコンフィグレーションファイルに付け加えた新しいカーネルをコンパイルして, その後システムをリブートして下さい. カーネルは, 検出した全てのデバイスの PnP ID を表示します. モデムの欄にある PnP ID を /sys/i386/isa/sio.c の 2777 行目くらいにあるテーブルに書き入れて下さい. テーブルを見つけるには, 構造体 ``siopnp_ids[]'' の文字列 ``SUP1310'' を探すようにして下さい. カーネルを作り直したら, インストールし, リブートして下さい. モデムが検出 されるはずです. 起動時のコンフィグレーションの際に, `pnp' コマンドを使用して PnP の 設定をマニュアルで行なわなければならないかもしれません. その場合, モデムを 検出させるためのコマンドは pnp 1 0 enable os irq0 3 drq0 0 port0 0x2f8 のようになります. シリアルコンソールで boot: プロンプトを表示するにはどうすればいい? options COMCONSOLE を指定してカーネルを構築して下さい. そして /boot.config を作成して とだけ書き入れて下さい. その後, キーボードをシステムから抜いて下さい. /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 を御覧下さい. 対称型マルチプロセッシング (SMP) をサポートしていますか? SMP は 3.0-STABLE と以後のリリースでしかサポートされていません. トラブルシューティング 訳: 内川 喜章 <yoshiaki@kt.rim.or.jp>.10 November 1997. ハードディスクに不良ブロックがあります! SCSI ディスクの場合は自動的に再マップする機能があるはずです. しかし, 理解し難い理由から多くのドライブがこの機能が無効化 されて出荷されています... これを有効化するには, 最初のデバイスのモードページを変更する 必要があります. これは次のコマンドを実行することで, FreeBSD 上でおこなうことができます (root 権限でおこないます). scsi -f /dev/rsd0c -m 1 -e -P 3 そして, AWRE と ARRE の値を 0 から 1 へ変更します:- AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 以下は, Ted Mittelstaedt から寄せられたものです. IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です. 最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で 出荷されています. また, 今日の IDE ハードディスクメーカは, 出荷以降に不良ブロックが発生することに関して保証を提供していて, 不良ブロックのあるディスクドライブを交換するサービスを行なっています. もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら, IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして, そのドライブに使ってみてください. この種のプログラムは大抵, ドライブの制御部分に対して不良ブロックを再走査し, 不良ブロックを使用不能にするようにセットすることができます. ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの 正常な部分であり, 一般的に言って障害を表すものではありません. PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの 使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS を経由する OS にとっては有効に働きますが, FreeBSD のディスクドライバは BIOS を利用しません. そのため, 代替として bad144 という機構が存在します. bad144 は, wd ドライバにだけ作用し, SCSI ドライバに利用することは *できません*. bad144 は, 検出された不良セクタをスペシャルファイルに 記録するという働きを持っています. bad144 を利用する上で, 注意しなければならない点が一つあります. それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに 置かれるということです. このファイルには, ディスクの先頭の付近, /kernel ファイルが位置しているであろう部分で発生した不良セクタが 記録されています. したがって, このファイルは BIOS コールを使って カーネルファイルを読み込む起動プログラムがアクセス可能でなければなりません. これはつまり, bad144 を利用するディスクは, 1024 シリンダ, 16 ヘッド, 63 セクタを超えてはならないということを意味し, bad144 を利用したディスクが実質 500MB を超えられないことになります. bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で, "Bad Block" 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で 機能します. ディスクは, 1024 シリンダ以内でなければなりません. ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し, トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に 対する膨張によって, ディスクが微小変形することにより発生する不良セクタを 確実に検出するためです). 大容量の ESDI ドライブのように, 1024 シリンダを超えるディスクの場合, DOS 上でそのディスクが利用できるように, ESDI コントローラは特殊な変換モードを 利用します. fdisk の "set geometry" コマンドを使って "変換された(translated)" ジオメトリに切替えると, wd ドライバは この変換モードを解釈できます. その際, FreeBSD パーティションを作成するのに "dangerously dedicated" モードを 利用してはいけません. このモードは, そのようなジオメトリを無視するからです. たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても, 已然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD パーティションを作成しようとしてしまうでしょう. ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は, 手動でブロック数を入力し, パーティションを作成する必要があります. 大容量の ESDI ディスクを ESDI コントローラでセットアップするには, ちょっとしたトリックを使います. まず, DOS のディスクで起動して そのディスクを DOS パーティションとしてフォーマットします. そして FreeBSD を起動し, インストーラの fdisk 画面で DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます. ジオメトリ情報を DOS が利用しているものと同一に再設定し, DOS パーティションを削除して "cooperative" FreeBSD パーティションを 先程記録したブロックサイズを使って作成して下さい. そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を 有効にして下さい. 実際のインストールでは, ファイルシステムが作成される前に bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます). 不良セクタファイルを作成中に何らかの障害が発生したなら, システムを再起動して, もう一度最初からやり直しになります. おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう. (やり直しは, DOS によるフォーマットとパーティション確保を含みます) もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら, ドライブの交換を考えて下さい. 不良ブロックは, 時間とともに悪化するからです. 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 に合わせる必要があるでしょう. 742a EISA カードには, の節で説明している 「16 MB を越える」ことによる問題はありません. これは Vesa-Local Buslogic SCSI カードで発生する問題です. HP Netserver 上のオンボード SCSI コントローラが認識されません. 基本的にこれは既知の問題です. HP Netserver マシンの EISA オンボード SCSI コントローラは EISA のスロット番号 11 を占有しますが, 「本当の」EISA スロットはすべてそれよりも 前のアドレスに配置されているのです. 残念ながら, 10 番以上の EISA スロットは PCI に割り当てられたアドレス空間 と衝突し, FreeBSD の自動コンフィグレーションは, 現状ではうまくこの状況を 処理できていないのです. ですから現時点での最良の方法は, カーネルオプションの EISA_SLOTS を 12 に変え, アドレス空間の衝突がないかの ようなふりをさせることです :) ハンドブックのカーネルの構築 に記述されているようにしてカーネルをコンパイルし, 構築してください. もちろん, これはこのようなマシンにインストールする際に 卵が先か鶏が先か」といった問題を生み出すことになります. この問題を回避するために, ユーザコンフィグ (UserConfig) の中には特別な仕組みが組み込まれています. このとき ``visual'' インタフェースは使用せず, コマンドラインインタフェースを使用してください. 単純に eisa 12 quit とプロンプト上から打ち込み, 後は普通にインストールをおこなってください. とにかくカスタムカーネルのコンパイルとインストールをおこなうことを おすすめしますが, dset も現時点ではこの値の変更を認識するようになっています. うまくいけば, 将来のバージョンではこの問題が解決していることでしょう. 注: HP Netserver では危険覚悟の専用ディスクは 使用できません. 詳細については をご覧ください. この CMD640 IDE コントローラはどこかおかしいようです. それは壊れているのです. 両方のチャンネルを同時に制御できないのです. 現在ではこのチップを使っているシステムでは自動的に検出して うまく動かすためのしくみが使えるようになっています. くわしくは マニュアルページのディスクドライバ (man 4 wd) を参照してください. CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1 あるいは 2.2.2 を使っている場合でセカンダリのチャネルを 使いたいのであれば options "CMD640" を有効にしてカーネルを 作り直してください. これは 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'' と言われます. mount にマウントしたいデバイスのタイプを指定する必要 があります. デフォルトでは mount はファイルシステムを ``ufs'' とみなします. CDROM のファイルシステムを マウントしたいのであれば ``'' と mount オプションをつけて明示する必要があります. これはもちろん CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 現行の 2.1.5R, 2.2R でも同様です) 自動的に Rock Ridge 拡張 (長いファイル名への対応) をうまく解釈します. CDROM のデバイス ``/dev/cd0c'' を /mnt にマウントしたい場合の例では, 次のようにします: mount -t cd9660 /dev/cd0c /mnt デバイスの名前はインタフェースによっては別の名前になっている かもしれないので注意してください (``/dev/cd0c'' は この場合の例です). オプション ``'' によって ``mount_cd9660'' コマンドが実行されることに注意 してください. このため例は次のようにすることもできます: mount_cd9660 /dev/cd0c /mnt CDROM をマウントしようとすると ``Device not configured'' と言われます. これは 一般的に CDROM ドライブの中に CDROM が入っていないか, ドライブがバス上に見えないことを意味します. ドライブに CDROM を入れるか, IDE (ATAPI) であれば master/slave の状態をチェック してください. CDROM ドライブに CDROM を入れてから認識するまで 数秒かかりますので少し待ってみてください. SCSI CDROM ではバスリセットへの応答時間が遅いために失敗する ことがあるかもしれません. SCSI CDROM を持っている場合は カーネルコンフィグレーションファイルに以下の行を加えて 再コンパイルして試してみてください. options "SCSI_DELAY=15" (訳注: 現在の GENERIC カーネルでは上の設定はデフォルトに なっています. 問題のある場合は SCSI_DELAY の数値を増やして みてください.) 私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう? パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら, プリンタボートを ``polled'' モードに設定してみてください: lptcontrol -p HP の新しいプリンタのいくつかは割り込みモードでは 使えないようです. (完全にわかったわけではありませんが) タイミングの問題のように思われます. 私のプログラムは時々 ``Signal 11'' のエラーで止まってしまいます. これはハードウェア (メモリ, マザーボードなど) の不具合いが 原因です. PC でメモリテストプログラムを動かしてみてください. ただしメモリが正常に動作していると報告されたとしても, ぎりぎりで メモリテストにパスしたメモリは, 処理の内容 (例えば kernel のコンパイルや特にシステムの負荷が高いような場合には, Adaptec 1542 などの SCSI コントローラのバスマスタ DMA など) によっては問題が起きる可能性は大いにあります. SIG11 FAQ (後で URLを示します) では遅いメモリが一般的に問題 を起こしがちであることを指摘しています. BIOS セットアップで ウエイトステート数を増やすかメモリを速いものに交換してください. 私の場合はキャッシュ RAM やオンボードキャッシュコントローラ の問題でした. このような問題ではないか確認するために BIOS セットアップでオンボード (セカンダリ) キャッシュを無効にして みてください. 以下のところには広い範囲の FAQ があります. the SIG11 problem FAQ ブートの時に画面が真っ暗になって同期も取れません. これは ATI Mach 64 ビデオカードの既知の問題です. この問題はカードがアドレス2e8を使い, 4番目のシリアルポート もここを使うということにあります. sio.c ドライバのバグ (仕様?) のため4番目のシリアルポートがなくても, 通常この アドレスを使う sio3 (4 番目のポートにあたります) を無効にしても, ドライバはこのアドレスをさわります. バグが修正されるまでは, 次のようにして対処してください. ブートプロンプトが出たら と入力します (これによりカーネルはコンフィグレーションモードに入ります). sio0, sio1, sio2 ,sio3 (これらすべて) を無効にします. これによって sio ドライバは 動作しなくなります -> 問題はありません. exit とタイプしてブートを続行します. もしシリアルポートを有効にしたいのであれば以下の変更をおこなって 新しいカーネルを作る必要があります. /usr/src/sys/i386/isa/sio.c の中で1ヵ所ある 0x2e8 という文字列を探し, この文字列とその手前にある コンマを削除します (後ろのコンマは残します). 後は通常の手続き にしたがって新しいカーネルを作ります. この対処をおこなった後でもまだ X ウィンドウシステムはうまく 動かないかもしれません. いくつかの新しい ATI Mach 64 ビデオカード (特に ATI Mach Xpression) は現在のバージョンの XFree86 では動きません. X を起動するとスクリーンが真っ暗 になったり, 奇妙な動き方をしたりします. より新しい X サーバ はもっとうまく動きます. the XFree86 site を見てベータリリースへのリンクを追ってください. 以下のファイルを持ってきましょう. AccelCards, BetaReport, Cards, Devices, FILES, README.ati, README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc, X312BMa64.tgz 古いファイルをこの新しいバージョンのファイルに置き換え, xf86config をもう一度実行します. 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!'' と言ってパニックします. 注: メッセージは, ``mb_map too small!'' の場合もあります. このパニックは, ネットワークバッファ (特に mbuf クラスタ) の仮想メモリが無くなったことを示します. 以下のオプションを カーネルコンフィグファイルに追加して mbuf クラスタに使用できる 仮想メモリの量を増やしてください. options "NMBCLUSTERS=<n>" <n> には, 同時に使用したい TCP コネクションの数に応じて 512 から 4096 までの数値を指定できます. とりあえず 2048 を 試してみるのを勧めます. これでパニックは完全の予防できるはずです. mbuf クラスタの割り当て／使用状況については, netstat -m で知ることができます. name="netstat -m"> で知ることができます. NMBCLUSTERS の デフォルト値は 512 + MAXUSERS * 16 です. 新しいカーネルでリブートすると ``CMAP busy panic'' となってパニックを起こしてしまいます. ファイル /var/db/kvm_*.db において範囲外のデータを 検出するためのロジックは失敗することがあり, こうした矛盾のある ファイルを使用することでパニックを引き起こすことがあります. これが起こったなら, シングルユーザでリブートした後に, 以下のコマンドを実行してください. rm /var/db/kvm_*.db ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます これは Ultrastor SCSI Host Adapter と衝突しています. ブート時に kernel configuration メニューに入り, 問題を起こしている 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 <user@domain.net>... 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" を追加してください. もはや現在の sendmail FAQ は sendmail release とは一緒には保守されて いません. しかし次のネットニュースに定期的に投稿されてます. comp.mail.sendmail, comp.mail.misc, comp.mail.smail, comp.answers, news.answers. また, メール経由でコピーを入手する場合は mail-server@rtfm.mit.edu 宛まで本文に "send usenet/news.answers/mail/sendmail-faq" と書いて送ります. リモートマシン上のフルスクリーンアプリケーションがうまく動かない リモートマシンのターミナルタイプが FreeBSD のコンソールで つかわれている cons25 以外のものです. この問題を解決する方法はいろいろあります: リモートマシンに login した後, shell 変数の TERM に ansi か sco のいずれかを設定します. ローカル側で screen のような VT100 エミュレータを使用します. screen は一つのターミナルの中で複数のセッションを 並列動作させることができますし, 本来の機能も優れています. リモートマシンのターミナルデータベースに cons25 のエントリをインストールします. Xを起動してリモートマシンに xterm から login します. (訳注: 日本語が必要な場合は kterm 等を 利用します) 私のマシンで "calcru: negative time..." と表示されるのですが これは, 割り込みに関連するさまざまな不具合によって発生します. あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません. この症状を再現させる一つの方法として, パラレルポート上で, TCP/IP を 大きな MTU で走らせるというものがあります. グラフィックアクセラレータがこの症状を起こすことがありますが, その場合はまず, カードの割り込み設定を確認して下さい. この問題の副作用として, プロセスが "SIGXCPU exceeded cpu time limit" というメッセージとともに終了してしまう, というものがあります. 1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で この問題が解決しないなら, 次の sysctl 変数をセットしてください. sysctl -w kern.timecounter.method=1 これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べれば おそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら, カーネルオプションの "NTIMECOUNTER" を大きな値に増やして下さい. "NTIMECOUNTER=20" にまで増やしても解決しない場合は, 計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを 意味します. 商用アプリケーション 訳: 山下 淳 <junkun@esys.tsukuba.ac.jp>.10 November 1997. 注 この章はまだまだ情報が足りません. 情報を追加してくれる ような企業を待ち望んでいます. FreeBSD グループはここに載っている 企業からの金銭的な支援を期待してはいませんので, 奉仕作業の 一つとして掲載しています (そして FreeBSD が係わる宣伝は, 長い目で見ると FreeBSD に対してよい方向へ働くと思っています). 私たちは商用ソフトウェアベンダーに, ここで製品を宣伝してもらう ことを望んでいます. 詳しくは, 商用ソフトウエアベンダ一覧のページ をご覧ください. FreeBSD 用の Motif はどうやったら手に入りますか FreeBSD 用の ELF 版 Motif 2.1 に関する情報は から 手に入れることができます. この製品は以下の物が含まれています: OSF/Motif manager, xmbind, panner, wsm. uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ, およびダイナミックライブラリ デモンストレーションプログラム 注文する際には FreeBSD 用の Motif であることをきちんと 確認してください. NetBSD や OpenBSD 用の Motif もまた, Apps2go から販売されています. 現在, FTP によるダウンロードのみ利用可能です. より詳しい情報は Apps2go WWW page 問い合わせは Sales または Support 電子メールアドレス. もしくは phone (817) 431 8775 or +1 817 431-8775 他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は から手に入れることができます. この製品は以下の物が含まれています: 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 も Metri Link から販売されています. 現在, CDROM および FTP によるダウンロードが利用可能です. FreeBSD 用の a.out 版 Motif 2.0 に関する情報は から 手に入れることができます. この製品は以下の物が含まれています: 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 はどうやったら手に入りますか 以前, より FreeBSD 用の CDE が 販売されていましたが, 現在は既に販売が終了しています. KDE 多くの点で CDE と類似しているオープンソースの X11 デスクトップ環境です. 高機能な商用 X サーバってあるんですか? はい, Xi Graphics と Metro Link から, FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています. Metro Link は, FreeBSD のパッケージ操作ツールを利用することで 容易に設定が行なえるほか, 数多くのビデオボードをサポートした 高機能な X サーバを提供しています. 配布はバイナリ形式のみで, FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます. また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif も販売しています(前を参照). より詳しい情報は Metro Link WWW page 問い合わせは Sales または Support 電子メールアドレス もしくは phone (954) 938-0283 or +1 954 938-0283 Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード をサポートしています. サーバはバイナリのみが含まれます. FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています. Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています. バージョン 5.0 の「互換デモ」が無料で入手できます. また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照). より詳しい情報は Xi Graphics WWW page 問い合せは Sales または Support もしくは phone (800) 946 7433 or +1 303 298-7478. FreeBSD 用のデータベースシステムはありますか? もちろんです. FreeBSD のウェブサイトにある 商用ベンダー というセクションをご覧下さい. また, Ports コレクションの データベース のセクションも参考になるでしょう. Oracle を FreeBSD 上で動かすことはできますか? はい. Linux 版 Oracle を FreeBSD でセットアップするための方法は, 次に示すページに詳しく書かれています. http://www.scc.nl/~marcel/howto-oracle.html http://www.lf.net/lf/pi/oracle/install-linux-oracle-on-freebsd ユーザアプリケーション 訳: 山下 淳 <junkun@esys.tsukuba.ac.jp> 広瀬 昌一 <shou@kt.rim.or.jp> .8 November 1997. そういうユーザアプリケーションはどこにあるの? FreeBSDに port (移植) されたソフトウェアパッケージについては, ports のページ をご覧下さい. このリストには現在 1800 を越える項目があり, しかも毎日更新されています. このページを小まめに訪れるか, freebsd-announce を購読すると, 新しく入った ports を定期的にチェックすることが できます. 大部分の ports は 2.2 と 3.x および 4.0 ブランチで利用できるはずです. 多くは 2.1.x 系のシステムでも同様に動作するでしょう. FreeBSD のリリースが出る度に, そのリリースの時点での ports ツリーの スナップショットが撮られ, ports/ ディレクトリに 納められることになっています. また, ``package'' という考えも採用されています. これは基本的には gzip されたバイナリディストリビューションに, インストール時に 環境に合わせた作業が必要になった場合にそれを執り行う多少の英知を 付け加えたものです. package を使えば, どのようなファイルが 配布物として含まれているかと言った細かい事柄にいちいち煩わされる ことなく, 簡単にインストールやアンインストールを繰り返す ことができます. インストールしたい package があるなら, /stand/sysinstall の, 「インストール後の FreeBSD の設定を行う」の下にある package のインストールメニューを使うか, package のファイル名を 指定して pkg_add(1) を使用して下さい. package の ファイル名には通常末尾に .tgz がついています. CDROM をご使用の方は, CD の packages/All ディレクトリから それらのファイルを利用することができます. また, 以下の場所から, FreeBSD の各種バージョンにあわせた package をダウンロードする こともできます. 2.2.8-release/2.2.8-stable 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-2.2.8/ 3.2-release/3.2-stable 用 ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/packages-3-stable/ 4.0-current 用 ftp://ftp.FreeBSD.ORG/pub/FreeBSD/ports/i386/packages-4-current/ お近くのミラーサイトもご利用下さい. 新しい ports が続々と追加されている状態なので, 全ての ports に 対応する package が存在するわけではないことを覚えておいてください. 定期的に ftp.FreeBSD.org マスターサイトを訪れて, どのような package が利用できるのかチェックするのも良いでしょう. libc.so.3.0 はどこにありますか? 2.1.x のシステムで 2.2/3.x/4.0 用の package を動かそうとしていますね. 前のセクションを読んで, システムに合った正しい port/package を 入手してください. 386/486SX のマシンで ghostscript を動かすとエラーがでます. あなたのマシンには数値演算プロセッサが塔載されていませんね? カーネルにコプロセッサの代わりとなる数値演算エミュレータを 追加する必要があります. 以下のオプションをカーネルのコンフィグレーションファイルに 追加して, カーネルを再構築してください. options GPL_MATH_EMULATE 注 このオプションを追加する場合, MATH_EMULATE の行を削除してください. SCO/iBCS2 のアプリケーションを実行すると, socksys で落ちてしまいます. まず最初に /etc/sysconfig (または /etc/rc.conf) の中の 最後のセクションを編集し, 以下の変数をYESに直します. # Set to YES if you want ibcs2 (SCO) emulation loaded at startup ibcs2=NO これでシステムの起動時に ibcs2 カーネルモジュールが読み込まるようになります. 次に /compat/ibcs2/dev/ を以下のように編集します: lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 X0R@ -> /dev/null lrwxr-xr-x 1 root wheel 7 Oct 15 22:20 nfsd@ -> socksys -rw-rw-r-- 1 root wheel 0 Oct 28 12:02 null lrwxr-xr-x 1 root wheel 9 Oct 15 22:20 socksys@ -> /dev/null crw-rw-rw- 1 root wheel 41, 1 Oct 15 22:14 spx open や close の処理は, socksysから /dev/null へ シンボリックリンクを張ることで代用します. 残りの処理は, -current に入っているコードが担当しています. これは以前のものより ずっとスッキリした方法です. ローカルでの X のソケット接続に spx ドライバを使いたい のであれば, システムをコンパイルする際にSPX_HACK を定義してください. INN (インターネットニュース) の設定方法は? inn の package や port をインストールしたあとに Dave Barr's INN Page を見てみましょう. 初心者向けの INN FAQ があります. どのバージョンの Microsoft FrontPage を手に入れる必要がありますか? ルーク, Ports を使え! パッチ処理済みの Apache が ports ツリーから 入手できます. FreeBSD は Java をサポートしていますか? はい. http://www.FreeBSD.org/java をご覧ください. 日本語訳 もあります. 3.x-stable を載せているマシンで port がコンパイルできないことがあります. それはどうしてですか? もし, その時点の -current か -stable に比べて ずっと古いバージョンの FreeBSD を利用しているなら, http://www.FreeBSD.org/ports/ にある ports アップグレードキットが必要です. 最新の FreeBSD を利用しているのに発生する場合はおそらく, -current では正常なのに -stable ではうまく動かなくなるような 変更がその port に対して行なわれ, 受理されてしまっているのでしょう. ports コレクションは -current と -stable, 両方のブランチで動かなければならないものですので, もしそれを発見したら send-pr(1) コマンドを使ってバグレポートの提出をお願いします. ld.so はどこにありますか? 3.1-R 以降などの Elf 化されたマシンで Netscape Navigator などの aout 形式のアプリケーションを動かすときには, /usr/libexec/ld.so と aout ライブラリのファイルが必要です. それらは配布物の compat22 に納められています. /stand/sysinstall や compat22 サブディレクトリ内の install.sh を 使って compat22 をインストールしてください. 合わせて 3.1-R と 3.2-R の ERRATA もお読みください. カーネルコンフィグレーション 訳: はらだ きろう <kiroh@jp.FreeBSD.org>.10 November 1997. カーネルをカスタマイズしたいんですが, 難しいですか? 全然難しくありません. ハンドブックのカーネルコンフィグレーションの節を調べてください. 注: うまく動作するカーネルができたら, 日付入りのカーネル のスナップショットを kernel.YYMMDD のように作成することを おすすめします. こうしておけば, 次にカーネルの構築をやってうまく いかなくなってしまっても, kernel.GENERIC にわざわざ戻る 必要がなくなります. これは, GENERIC kernel でサポートされない デバイスからブートしている場合は, 特に重要です (経験者は語るってやつです). _hw_float が無いので, カーネルのコンパイルがうまくいきません. 推測ですけど, 数値演算コプロセッサを持ってないからと思って, npx0 をカーネルコンフィグファイルから削除しちゃったんじゃ ないですか? npx0 は必須です. コプロセッサがなくても, npx0 デバイスは削除してはいけません. マルチポートシリアル関連のコードでの, 割り込みの競合 Q. マルチポートシリアルをサポートするコードを含んだ カーネルをコンパイルしようとすると, 最初のポートだけ検出され, 残りのポートは割り込みの競合のためスキップされたと言われます. どうやったらいいでしょうか? A. ここでの問題は, FreeBSD にはハードウェアまたは ソフトウェアの競合によってカーネルがクラッシュするのを防ぐ コードが含まれているという点です. 解決するには, 最初のポート にだけ IRQ の設定を書き, 残りは IRQ の設定を削除します. 以下に例を示します. # # Multiport high-speed serial line - 16550 UARTS # device sio2 at isa? port 0x2a0 tty irq 5 flags 0x501 vector siointr device sio3 at isa? port 0x2a8 tty flags 0x501 vector siointr device sio4 at isa? port 0x2b0 tty flags 0x501 vector siointr device sio5 at isa? port 0x2b8 tty flags 0x501 vector siointr QIC-40/80 ドライブのサポートを有効にするには? GENERIC コンフィグファイルの以下の行のコメントを外して ください (もしくは使用するコンフィグファイルに追加してください). そして fdc の行に, ``flags 0x1'' を追加してください. controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 flags 0x1 vector fdintr disk fd0 at fdc0 drive 0 ^^^^^^^^^ disk fd1 at fdc0 drive 1 #tape ft0 at fdc0 drive 2 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次に, /dev/ft0 デバイスを作成します. /dev/ に移動して, 以下のコマンドを実行します. sh ./MAKEDEV ft0 これは, 1 番目のドライブの例です. 2 番目には ft1 を使い, 以降は同様にしてください. /dev/ft0 デバイスは, ``ft'' と呼ばれる特別な コマンドを使用して書き込みをおこなえます. 詳細については ft のマニュアルページを参照してください. 以前のバージョンの ft には, 不良テープメディアの扱いに問題があります. ft がテープの同じ部分を行ったり来たりしているようであれば, の /usr/src/sbin/ft から最新の ft を取得して試してみてください. システム管理 訳: にしか <nishika@cheerful.com>.12 November 1997. システムスタートアップファイルはどこにあるのですか? 2.0.5R から 2.2.1R までは, プライマリコンフィグレーションファイルは /etc/sysconfig にあります. オプションはすべて, このファイルと /etc/rc および /etc/netstartといった, 別のファイルに指定されています. ファイル /etc/sysconfig を見て, システムに適合するように 変更してください. このファイルはそれぞれの場所に何を書けばいいのかを表す コメントがたくさん書かれています. 2.2.2 に続くリリース と 3.0 では, /etc/sysconfig は, より分りやすい名前の rc.conf に改名され, それに従って 書式もいくぶん改められます. /etc/netstart も /etc/rc.network に改名され, 全部のファイルを cp /usr/src/etc/rc* /etcで一度にコピーすることが 出来るようになります. ファイル /etc/rc.local は常にここにあり, INN や http といった追加のサービス開始や カスタムオプションを記述するために使われるでしょう. ファイル /etc/rc.serial はシリアルポートの初期化 (例えばポートの設定を固定したり等々) のためにあります. ファイル /etc/rc.i386 は iBCS2 エミュレーションのような Intel アーキテクチャ固有の設定や PC システムコンソール設定のためにあります. 2.1.0R からは, "ローカル" スタートアップファイルをディレクトリ /etc/sysconfig (または /etc/rc.conf) の中に作って指定することもできます: # Location of local startup files. local_startup=/usr/local/etc/rc.local.d .sh で終わるそれぞれのファイルは, アルファベット順に実行されます. ファイル名を変えることなくある一定の順序で確実に実行したいのであれば, 順序が保証されるように以下のようにして, それぞれのファイルの頭に数値をつけるようなデザインを 使うことができます: 10news.sh 15httpd.sh 20ssh.sh この方法は見苦しく (あるいは SysV のように :-)) なりますが, /etc/rc.local を 手品のような編集でソートするようなことなく ローカルの追加パッケージを使うためには, シンプルでしかもよく使われる 手法ではあります. ほとんどの ports/packages は /usr/local/etc/rc.d をローカルスタートアップディレクトリ であると仮定しています. 簡単にユーザを追加するにはどうすればいいのですか? adduser コマンドを使用してください. また, pw コマンドを用いることで, さらに細かい操作が可能です. また, ユーザを削除するには rmuser コマンドを使用してください. FreeBSD システムに新しいハードディスクを追加するには? www.FreeBSD.org に書かれているディスクフォーマット チュートリアルを参照して下さい. 新しいリムーバブルドライブを持っていますが, どうやって使うの? そのリムーバブルドライブが ZIP であれ EZ drive であれ (あるいはもしそういう風に使いたいのなら, フロッピーであれ), またハードディスクであれ, 一旦システムにインストールされて認識され, カートリッジ, フロッピー等々が挿入されていれば, ことはどのデバイスでも全く同じように進みます. (このセクションはMark Mayo's ZIP FAQ に基づいています.) ZIP ドライブやフロッピーで, すでに DOS のファイルシステムで フォーマットしてある場合, 次のコマンドを使うことができます. これはフロッピーの場合です. mount -t msdos /dev/fd0c /floppy 出荷時の設定の ZIP ディスクではこうです. mount -t msdos /dev/da2s4 /zip その他のディスクに関しては, fdisk や /stand/sysinstall を使って, どのようにレイアウト されているか確かめてください. 以降は ZIP ドライブが 3 番目の SCSI ディスクで, da2 と認識されている場合の例です. 他人と共有しなければならないフロッピーやリムーバブルディスク でなければ, BSD ファイルシステムを載せてしまうのが良い考えでしょう. ロングファイル名もサポートされ, パフォーマンスは少なくとも 2 倍は向上しますし, おまけにずっと安定しています. まず最初に, DOS レベルでのパーティション / ファイルシステムを 無効にしておく必要があります. 使用するのは fdisk でも /stand/sysinstall でも結構です. 複数のオペレーティングシステムを入れることを考慮する 必要がないような容量の小さなドライブの場合は, 次のように FAT パーティションテーブル (スライス) 全体を飛ばして, BSD のパーティション設定を行うだけで良いでしょう. dd if=/dev/zero of=/dev/rda2 count=2 disklabel -Brw da2 auto 複数の BSD パーティションをつくる場合, disklabel か /stand/sysinstall を使います. 固定ディスク上にスワップ領域 を加える場合はそういうことをしたいと思うのはもっともですが, ZIP のようなリムーバブルドライブの上ではそういう考えは不適切 でしょう. 最後に, 新しいファイルシステムをつくります. ディスク全体を使用する ZIP ドライブの場合は, 以下のようにします. newfs /dev/rda2c 次にマウントします. mount /dev/da2c /zip また, 次のような行を /etc/fstab に入れておくのも良い考えでしょう. "mount /zip" と入力するだけでマウントできるようになります. /dev/da2c /zip ffs rw,noauto 0 0 どのようにしたら DOS の拡張パーティションをマウントできますか? DOS 拡張パーティションはすべての基本パーティションの後に 認識されます. たとえば, 2台目の SCSIドライブの拡張パーティションに "E" パーティションがあるとしますと, これは /dev にスライス 5 のスペシャルファイルを作る必要があり, /dev/da1s5 としてマウントされます. # cd /dev # ./MAKEDEV da1s5 # mount -t msdos /dev/da1s5 /dos/e 他のシステムのファイルシステムを FreeBSD でマウントすることはできますか? Digital UNIX UFS CDROM は直接 FreeBSD でマウント することができます. Digital UNIX やそれ以外のシステムのサポートする UFS のディスクパーティションをマウントすることはもっと複雑 なことで, オペレーティングシステムのディスクパーティション の詳細に依存します. Linux: 2.2 以降は ext2fs パーティションをサポートします. マニュアルの mount_ext2fs を見てください. より多くの情報があります. NT: FreeBSD 用の読みだしのみ可能な NTFS ドライバがあります. より詳しくは, Mark Ovens 氏によって書かれたチュートリアル http://www.users.globalnet.co.uk/~markov/ntfs_install.html を 見てください. この問題について他の情報があれば, 他の人から感謝されるでしょう. どのようにしたら FreeBSD を NT ローダーからブートさせることができますか? FreeBSD のネイティブルートパーティションの最初のセクタを ファイルにして DOS/NT パーティション上に置くという画期的な アイディアがあります. ファイル名を c:\bootsect.bsd (c:\bootsect.dos からの発想です) としたとします. c:\boot.ini ファイルを次のように編集します: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows NT" C:\BOOTSECT.BSD="FreeBSD" C:\="DOS" この手順では DOS, NT, FreeBSD その他が同じディスクのそれぞれの fdisk パーティションにインストールされているとしています. 私の場合は, DOS と NT は最初のパーティション, FreeBSDは 2番目にあります. また, FreeBSD は MBR を使わずに, ネイティブパーティションから ブートするようにインストールしてあります. (訳注: FreeBSD のインストールではブートマネジャを使わずに標準 MBR を使う場合に相当します) (もし NTFS に変換してしまっているなら) DOS フォーマットの フロッピーディスクか FAT パーティションを /mnt に DOS マウントします. dd if=/dev/rda0a of=/mnt/bootsect.bsd bs=512 count=1 リブートして DOS か NT に切替えます. NTFS ユーザは bootsect.bsd や bootsect.lnx をフロッピーディスクから C:\ へコピーします. boot.ini のファイル属性 (パーミッション) の変更を以下のようにおこないます: attrib +s +r c:\boot.ini 上の例の boot.ini で示したような正しいエントリを加え, ファイル属性を元に戻します. attrib -r -s c:\boot.ini FreeBSD が MBR からブートするようになっている場合, それぞれのネイティブパーティションからブートするように設定した後で, DOS から ``fdisk'' コマンドを実行して元に戻してください. FreeBSD と Linux を LILO からブートするには? FreeBSD と Linux が同じディスクにインストールされている場合, 単に Linux 以外の OS をブートするための LILO のインストール手順に 従えばいいだけです. 非常に簡単にではありますが, 記してみましょう: Linux をブートし, /etc/lilo.conf に以下の行を加えて ください: other=/dev/hda2 table=/dev/hda label=FreeBSD (上記の手順は FreeBSD のスライスが Linux から /dev/hda2 という名前で見えていると仮定しています; あなたの設定にあわせて ください) その後, lilo を root で実行すれば完了です. FreeBSD が別のディスクにインストールされているのなら, LILO の エントリに ``loader=/boot/chain.b'' を追加してください. 例えば, このようになります: other=/dev/dab4 table=/dev/dab loader=/boot/chain.b label=FreeBSD 場合によっては, 二つ目のディスクを正しく起動するために FreeBSD ブートローダに BIOS ドライブ番号を指定する必要があるかもしれません. 例えば, FreeBSD SCSI ディスクが BIOS によって BIOS ディスク 1 と して認識されるのなら, FreeBSD のブートローダのプロンプトで, 次の ように指定する必要があります: Boot: 1:da(0,a)/kernel FreeBSD 2.2.5 やそれ以降の版では, ブート時に上記のことを行なう だけで自動的に boot(8) が設定されます. Linux+FreeBSD mini-HOWTO が FreeBSD と Linux とを相互に 使えるようにするためのよい参考資料になるでしょう. FreeBSD と Linux を BootEasy からブートするには? LILO をマスターブートレコード (MBR) ではなく Linux のブート パーティションにインストールしてください. これで BootEasy から LILO をブートできるようになります. Windows95 と Linux を使用している場合は, いずれにせよ後者の方が お勧めです. Windows95 を再インストールする必要にかられたとき, Linux をブート可能に戻す手続きが簡単ですむからです (Windows95 は偏屈なオペレーティングシステムで, マスターブートレコード (MBR) から他のオペレーティングシステムを追い払ってしまうのです). 「危険覚悟の専用 (dangerously dedicated) ディスク」は健康に悪いの? インストール作業中, ハードディスクのパーティションを切る際に 2 つの方法を選ぶことができます. デフォルトの方法では, fdisk の テーブルエントリ (FreeBSD ではスライスと呼ばれる) を使って, 自身のパーティションを使用する FreeBSD のスライスを, 同じマシン の他のオペレーティングシステムと互換性のある形にします. それに付随して, ブートセレクタをインストールすれば, ディスク上の 使用可能なオペレーティングシステムを切り替えることができます. もう一つの方法はディスク全てを FreeBSD で使うというもので, この 場合ほかのオペレーティングシステムとの互換性を考慮しないことに なります. では, なぜこれが 「危険覚悟の」と言われるのでしょう? このモードのディスクが, 通常の PC のユーティリティが有効な fdisk テーブルと見なす情報を持っていないからです. ユーティリティの出来 如何によりますが, そのようなディスクを発見したとき, 警告を 出すものもあります. また, もっと悪い場合, 確認も通告もなしに BSD のブートストラップにダメージを与えるものもあるでしょう. さらには, 「危険覚悟の」ディスクレイアウトは多数の BIOS, AWARD (例えば HP Netserver や Micronics システム, 他多数で 使用されていた) や Symbios/NCR (人気のあるSCSI コントローラ 53C8xx 用) などを混乱させることが分かっています. これは完全な リストではありません. 他にもまだまだあります. この混乱の兆候は, 起動時にシステムがロックするというだけでなく, FreeBSD のブート ストラップが自分自身を見つけられないために表示する "read error" というメッセージなどにも現れることでしょう. そもそもいったいなぜこのモードがあるのでしょうか? これは わずかに数キロバイトのディスク容量を節約するのみであり, 新規 インストールで実際に問題を生ずるのです. 「危険覚悟の」モードの 起源は新しい FreeBSD インストーラでの, BIOS から見えるディスクの 「ジオメトリ」の値とディスク自身との整合性という, もっとも一般的な 問題のひとつを回避したいという要求が背景にあります. 「ジオメトリ」は時代遅れの概念ですが, 未だに PC BIOS と ディスクへの相互作用の中核をなしています. FreeBSD のインストーラが スライスを作る時, ディスク上のスライスを BIOS が見つけられる ようにスライス位置をディスク上に記録します. それが誤っていれば, 起動できなくなってしまうでしょう. 「危険覚悟の」モードはこれを, 問題を単純にすることで 回避しようとします. 状況によってはこれでうまくいきます. しかし次善の策として使われているに過ぎません. この問題を 解決するもっと良い方法はいくらでもあるのです. では, インストール時に「危険覚悟の専用」モードが必要になる 状況を回避するにはどうすればよいのでしょうか? まず BIOS が報告するディスクのジオメトリの値を覚えておくことから はじめましょう. ``boot:'' プロンプトで ``-v'' を指定するか ローダで ``boot -v'' と指定して, ブート時にカーネルにこの値を 表示させることができます. インストーラが起動する直前に, カーネルがジオメトリ値のリストを表示するでしょう. パニックを起こさないでください. インストーラが起動するのを待ち, 逆スクロールでさかのぼって値を確認してください. 普通は BIOS ディスクユニット番号は, FreeBSD がディスクを検出する順序と同様であり, 最初に IDE, 次に SCSI となります. ディスクをスライシングする際に, FDISK の画面で表示される ディスクのジオメトリが正しいことを確認してください (BIOS の 返す値と一致しいるか). 万一ちがっていたら ``g'' を押して 修正してください. ディスクにまったくなにもない場合や他の システムから持ってきたディスクの場合は, これをおこなう必要が あるかもしれません. これはそのディスクから起動させようと している場合にのみ問題になることに注意してください. FreeBSD はそのディスクをうまい具合いに他のディスクと区別して くれます. ディスクのジオメトリについて BIOS と FreeBSD 間で一致させる ことができたら, この問題はほぼ解決したと思ってよいでしょう. そしてもはや「危険覚悟の専用」モードは必要ありません. しかし, まだブート時に恐怖の ``read error'' メッセージが出るようで あれば, お祈りを捧げて新しいディスクを買いましょう. もう失うものは何もありません. 「危険覚悟の専用ディスク」を通常の PC での使用法に 戻すには, 原則として 2 つ方法があります. 1 つは十分な NULL バイトを MBR に書き込んで, きたるべきインストーラにディスク はまっさらだと思い込ませる方法です. 例えば, こんな感じです. dd if=/dev/zero of=/dev/rda0 count=15 また, マニュアルには書かれていない DOS の「機能」 fdisk /mbr は, BSD ブートストラップを追い払ってくれる上に, 新しいマスターブートレコードをインストールしてくれます. どのようにしたらスワップ領域を増やせますか? スワップパーティションのサイズを増やすのが最良の方法ですが, 別のディスクを追加しなくて済むという利点のある方法があります. 経験から得た一般的な方法はメインメモリの 2倍程度のスワップ領域を とるというものです. しかしごく小さなメインメモリしかない場合は, それ以上のスワップを構成したいと思うでしょう. また, 将来のメモリの アップグレードに備え, 後でスワップの構成を変更する必要がないように 十分なスワップを構成しておくことは良い考えです. スワップを別のディスク上に追加することは, 単純に同じディスク上 にスワップを追加する場合よりも高速に動作するようになります. 例に挙げれば, あるディスク上のソースをコンパイルしているとして, スワップが別のディスク上に作られていれば, これらが同じディスク上 にある場合よりも断然速いです. SCSI ディスクの場合は特にそうだと言えます. ディスクが複数ある場合, スワップパーティションを各ディスクに 作るように構成すると, 使用中のディスク上にスワップを置いたとしても, 通常の場合は有益です. 一般的に, システムにある高速なディスクには スワップを作るようにすべきでしょう. FreeBSD はデフォルトでインターリーブなスワップデバイスを 4つまで サポートします. 複数のスワップパーティションを構成する際に, 普通はそれらを大体同じくらいの大きさにして作りたいところですが, カーネルのコアダンプを取るのに都合が良いようにメインの スワップパーティションを大きめにとる人もいます. メインのスワップパーティションはカーネルのコアがとれるように 最低でも実メモリと同じ大きさにすべきでしょう. IDE ドライブは同時に同じチャネル上の複数のドライブには アクセスできません (FreeBSD は mode 4 をサポートしていないので, すべての IDE ディスク I/O は ``programmed'' です). IDE の場合であってもやはり, スワップを別のハードディスク上に 作成することをおすすめします. ドライブは実に安いものです, 心配するだけ無駄です. NFS 越しにスワッピングさせる方法は, スワップ用の ローカルディスクが無い場合にのみ推奨されます. NFS 越しのスワッピングは遅く, FreeBSD 4.x より前のリリースでは 効率が悪いのですが, 4.0 以降ではそれなりに高速になります. そうはいっても, 利用できるネットワークの太さに制限されますし, NFS サーバに余計な負荷がかかります. これは 64MBの vn-swap を作る例です (ここでは /usr/swap0 としますが, もちろん好きな名前を使うことができます). カーネルが次の行を含むコンフィグファイルから構成されているかを 確認します. GENERIC カーネルには, この行が含まれています. pseudo-device vn 1 #Vnode driver (turns a file into a device) vn デバイスを作ります cd /dev sh ./MAKEDEV vn0 スワップファイルを作ります (/usr/swap0) dd if=/dev/zero of=/usr/swap0 bs=1024k count=64 /etc/rc.conf でスワップファイルを有効化させます swapfile="/usr/swap0" # Set to name of swapfile if aux swapfile desired. マシンをリブートします スワップファイルをすぐに有効化させたいのなら以下のようにタイプします vnconfig -ce /dev/vn0c /usr/swap0 swap プリンタのセットアップで問題があります ハンドブックのプリンタの部分を参照してください. 探している問題のほとんどが書かれているはずです. ハンドブック中のプリンタの利用をご覧ください. 私のシステムのキーボードマッピングは間違っています. kbdcontrol プログラムは, キーボードマップファイルを読み込むための オプションを備えています. /usr/share/syscons/keymaps の下にたくさんのマップファイルがあります. システムに関連のあるものを一つ選んで, ロードしてください. kbdcontrol -l uk.iso /usr/share/syscons/keymaps と拡張子 .kbd は どちらも kbdcontrol によって使用されます. これは /etc/sysconfig (または rc.conf) 中で設定することができます. このファイル中にあるそれぞれのコメントを参照してください. 2.0.5R やそれ以降の版では, テキストフォントやキーボードマッピングに 関係のあるものはすべて, /usr/share/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 koi8-r (shift) Russian koi8-r 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 ユーザディスククォータが正常に動作していないようです. '/' にはディスククォータを設定しないでください, クォータファイルが置かれるファイルシステム上に クォータファイルを置くようにしてください. つまり: FS QUOTA FILE /usr /usr/admin/quotas /home /home/admin/quotas ... わたしの ccd の何が適合していない (Inappropriate) のでしょう? このような症状が現れます: # ccdconfig -C ccdconfig: ioctl (CCDIOCSET): /dev/ccd0c: Inappropriate file type or format # 通常この現象はタイプを ' 未使用 (unused)' のまま放っておかれた 'c' パーティションをつなげようとした場合に現れます. ccd ドライバは FS_BSDFFS タイプをベースとするパーティションを要求します. つなげようとしているディスクのディスクラベルを編集して, パーティションのタイプを '4.2BSD' に変更してください. どうしてわたしの ccd のディスクラベルを変更することができないのでしょう? このような症状が現れます: # disklabel ccd0 (it prints something sensible here, so let's try to edit it) # disklabel -e ccd0 (edit, save, quit) disklabel: ioctl DIOCWDINFO: No disk label on disk; use "disklabel -r" to install initial label # これは ccd から返されるディスクラベルが, 実はディスク上にはない まったくの偽の情報だからです. これを明示的に書き直すことで 問題を解消できます, このようになります: # disklabel ccd0 > /tmp/disklabel.tmp # disklabel -Rr ccd0 /tmp/disklabel.tmp # disklabel -e ccd0 (this will work now) FreeBSD は System V の IPC プリミティブをサポートしますか? はい. FreeBSD は System-V スタイルの IPC をサポートします. 共有メモリ, メッセージ, セマフォが含まれます. 以下の行を カーネルコンフィグファイルに加えると, サポートが有効になります. options SYSVSHM options "SHMMAXPGS=64" # 256Kb of sharable memory options SYSVSEM # enable for semaphores options SYSVMSG # enable for messaging コンパイルしてインストールしてください. 注: GIMP を実行したい場合は, SHMMAXPGS を 4096(16M) くらい馬鹿でかい数字に増やす必要があります. X11R6 の共有メモリは 256Kb で十分です. UUCP で mail を配送するには sendmail をどう使えばよいのですか? FreeBSD に付属している sendmail は, インターネットに直接 つながっているサイトにあわせて設定してあります. UUCP 経由で mail を交換したい場合には sendmail の設定ファイルを改めてインストール しなければなりません. /etc/sendmail.cfを自分の手で改造するのは純粋主義者の やるような事です. sendmailの version 8 は m4 のような プリプロセッサを通して設定ファイルを生成する新しいアプローチを 取っており, より抽象化されたレベルの設定ファイルを編集します. 以下のディレクトリの中にある設定ファイルを使用してください. /usr/src/usr.sbin/sendmail/cf もしすべてのソースをインストールしていない場合には sendmail の設定ツールは, 別の tar ファイルにまとめてあります. CD-ROM が mount されている場合には, 次のようにしてください. cd /usr/src tar -xvzf /cdrom/dists/src/ssmailcf.aa これはたった数 100Kbyte ですから心配ないでしょう. cf ディレクトリにある README に, m4 での設定の基本的な説明があります. UUCP での配送のためには, mailertable を使用すれば よいでしょう. これによって, sendmail が配送方式を決定するデータベースを 作成することができます. まずはじめに, .mc ファイルを作成しなければなりません. /usr/src/usr.sbin/sendmail/cf/cf というディレクトリが, これらのファイルを作成する場所です. 既にいくつか例があると思います. これから作成するファイルの名前を foo.mc とすると, sendmail.cf を求めているような形式に変換するには, 次のようにしてください. cd /usr/src/usr.sbin/sendmail/cf/cf make foo.cf cp foo.cf /etc/sendmail.cf 標準的な .mc ファイルは次のようになります. include(`../m4/cf.m4') VERSIONID(`Your version number') OSTYPE(bsd4.4) FEATURE(nodns) FEATURE(nocanonify) FEATURE(mailertable) define(`UUCP_RELAY', your.uucp.relay) define(`UUCP_MAX_SIZE', 200000) MAILER(local) MAILER(smtp) MAILER(uucp) Cw your.alias.host.name Cw youruucpnodename.UUCP nodns と nocanonify という指定をすることで, mail の配送に DNS を使用しなくなります. UUCP_RELAY という 行に関しては, ある理由から必要ですがそれは聞かないでください. .UUCPで終わる仮想ドメインを処理することのできるインターネット上での ホスト名をここに書いてください. 通常は, ISP の mail リレーホストを 書くことになると思います. これが終了したら, 次に /etc/mailertable というファイル が必要です. 標準的な例は次のとおりです. # # makemap hash /etc/mailertable.db < /etc/mailertable # horus.interface-business.de uucp-dom:horus .interface-business.de uucp-dom:if-bus interface-business.de uucp-dom:if-bus .heep.sax.de smtp8:%1 horus.UUCP uucp-dom:horus if-bus.UUCP uucp-dom:if-bus . uucp-dom:sax 見れば分かるように, これは実在する設定のファイルです. はじめの 3 行はドメイン名で指定されたメールが default の経路で配送されずに, ``近道'' するために UUCP で隣りのサイトに送るための特別な状況を 処理するものです. 次の行は Ethernet でつながっているローカルのドメインに対しては SMTP で送るための設定です. 最後に, UUCP での隣りのサイトが. UUCP で終わる仮想ドメインの書式で 指定されており, default の rule を ``uucp-neighbour!recipient'' で上書きするためのものです. 一番最後の行はいつもドットを一つ書きます. これは, ここまでの行でマッチしなかったすべてのホストにマッチし, このサイトから世界に向けて出ていくための mail gateway に UUCP で配送するためのものです. uucp-dom: に続けて書かれているノード名は, uuname コマンドで指定することによって UUCP で直接配送される正しいノード名でなければなりません. 最後に, このファイルは使用する前に DBM データベースのファイルに 変換する必要があります. これをおこなうコマンドラインは mailertable の最初のコメントに書いてあります. mailertable を変更した時には, 必ずこのコマンドを実行してください. 最後のヒントです: もし特定のメール配送がうまく作動するかどうか 確かめたい場合には, sendmail の オプションを 使用してください. このオプションによって sendmail は アドレステストモードで起動します. ``0 '' の後に 配送したいアドレスを書いてください. 最後の行に, 実際に使用される mail agent, この mail agent で送られる送信先のホスト, そして (多分変換されている) アドレスが表示されます. このモードを抜けるには Control-D を押してください. j@uriah 191% sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 0 foo@interface-business.de rewrite: ruleset 0 input: foo @ interface-business . de ... rewrite: ruleset 0 returns: $# uucp-dom $@ if-bus $: foo \ < @ interface-business . de > > ^D j@uriah 192% ダイアルアップでインターネットに接続する環境でメールをセットアップするにはどうやるの? 静的に IP アドレスが割り当てられる場合は, デフォルトの状態を 変更する必要はありません. 割り当てられた名前をホストネームと するだけで, sendmail が後のことを引き受けてくれます. ダイアルアップ ppp をインターネット接続に使用し, 動的に IP アドレスが割り当てられる場合は, インターネットサービスプロバイダ (ISP) のメールサーバにメールボックスがあるはずです. ISP のドメイン が myISP.com で, あなたのユーザ名が user だと仮定します. また, あなたが自分のマシンを bsd.home と呼んでおり, ISP が relay.myISP.com をメールリレーとして使用できると言っていると しましょう. メールボックスからメールを取ってくるためには, retrieval (回収) エージェントをインストールする必要があります. Fetchmail は 多種多様なプロトコルをサポートしているのでお勧めです. ISP が 使用しているのは大抵 POP3 プロトコルです. ユーザ ppp を使用している場合, /etc/ppp/ppp.linkup に以下のように記述すると, インターネットと 接続が完了した時点で自動的にメールを取得するようになります. MYADDR: !bg su user -c fetchmail non-local なアカウントにメールを配送するのに sendmail を使用している場合 (後述), 上に示したエントリの後に !bg su user -c "sendmail -q" を記述します. これはネットワーク接続が確立したらすぐに sendmail に溜っている mailqueue を強制的に処理させるようにします. この例では, user が bsd.home にアカウントを持ち, bsd.home 上の user のホームディレクトリに, 以下のような .fetchmailrc ファイルがつくられていることを想定しています. poll myISP.com protocol pop3 fetchall pass MySecret; 言うまでもなく, このファイルは user 以外のユーザが読むことが 出来ないようにしなくてはなりません. 内容にパスワード MySecret が 含まれているからです. 正しい from: ヘッダをつけてメールを送るためには, sendmail に user@bsd.home ではなく user@myISP.com を使用するよう教える 必要があります. メールをより早く転送するために, 全てのメールを relay.myISP.com へ送るように sendmail に指示しておくのも良い でしょう. 上の要件を満たすには, 以下のような .mc ファイルが適しています. VERSIONID(`bsd.home.mc version 1.0') OSTYPE(bsd4.4)dnl FEATURE(nouucp)dnl MAILER(local)dnl MAILER(smtp)dnl Cwlocalhost Cwbsd.home MASQUERADE_AS(`myISP.com')dnl FEATURE(allmasquerade)dnl FEATURE(masquerade_envelope)dnl FEATURE(nocanonify)dnl FEATURE(nodns)dnl define(SMART_HOST, `relay.myISP.com') Dmbsd.home define(`confDOMAIN_NAME',`bsd.home')dnl define(`confDELIVERY_MODE', `deferred')dnl .mc ファイルから sendmail.cf への変換方法については, 前のセクションを参照してください. sendmail.cf を更新した後に sendmail をリスタートするのもお忘れなく. しまった! root のパスワードを忘れてしまった! あわてないで下さい! 単にシステムを再起動し, シングルユーザモード に移るために Boot: と表示されるプロンプトで -s と入力してください. どのシェルを使うのかという質問には, ENTER キーを押してください. # プロンプトに移ることができるでしょう. mount -a と入力 して, root ファイルシステムを読み書きできるようにマウントし直した後, passwd root と入力して root のパスワードを設定し直して下さい. その後, exit と入力すれば, ブートが続けられます. Control-Alt-Delete でシステムがリブートしないようにするにはどうすればいい? コンソールで使っているキーマップを編集して, boot という キーワードを nop に置き換えて下さい. デフォルトキーマップは, /usr/share/syscons/keymaps/us.iso.kbd にあります. その 変更を反映させようとして, このキーマップのロードを明示的に行なう ために, /etc/rc.conf を実行すべきかもしれません. もちろん 他の国のキーマップを使っているのであれば, 代わりにそのキーマップ ファイルを編集して下さい. DOS のテキストファイルを UNIX のテキストファイルに整形するにはどうすればいい? 単に次の perl コマンドを実行してください: perl -i.bak -npe 's/\r\n/\n/g' file ... file の部分には処理するファイルを指定して下さい. 整形後のファイルは 元のファイル名で作成され, 整形前のファイルはバックアップとして元の ファイル名の末尾に拡張子 .bak のつけられた名前で作成されます. あるいは tr(1) コマンドを使うこともできます: tr -d '\r' < dos-text-file > unix-file dos-text-file は DOS 形式のテストファイル, unix-file には変換された出力が格納されます. perl を使うよりほんのちょっぴり速くなります. 名前で指定してプロセスにシグナルを送るにはどうすればいい? killall(1) を 使って下さい. su が not in root's ACL と言って私を悩ませるのはなぜ? Kerberos の認証システムからくるエラーです. この問題は致命的なもの ではなく, うっとおしいといったものです. su に -K オプションをつけて 起動するか, 次の質問で説明されている方法で Kerberos をアンインストール して下さい. Kerberos をアンインストールするにはどうすればいいの? システムから Kerberos を削除するには, あなたの動かしているリリースの bin ディストリビューションを再インストールして下さい. もし CDROM を 持っているのなら, その CDROM をマウント (マウントポイントは /cdrom と 仮定) して, 次のように入力して下さい. cd /cdrom/bin ./install.sh 疑似ターミナルを追加するには? telnet, ssh, X, screen をたくさん利用されている場合, 疑似ターミナルが足りなくなっている可能性があります. これを増やすには次のようにします: 次の行をカーネルコンフィグレーションファイルに追加して pseudo-device pty 256 新たにカーネルを作りインストールします. 次のコマンドを実行して # cd /dev # ./MAKEDEV pty{1,2,3,4,5,6,7} 新たなターミナル用の 256 個のデバイスノードを作ります. /etc/ttys を編集し 256 個のターミナルごとの定義を追加します. 既存のエントリーの形式にあわせる必要があるでしょう. 例えばこんな感じです. ttyqc none network 正規表現を使った指定は tty[pqrsPQRS][0-9a-v] となります. 新しいカーネルでシステムをリブートすると完了です. snd0 デバイスを作成することができません! 以下に示すコマンドでサウンドカード用のデバイスを作ることができます. # cd /dev # sh MAKEDEV snd0 ただし, このコマンドは /dev/snd0 という名前のデバイスファイルを作成するわけではなく, 代わりに mixer0, audio0, dsp0 などといった名前のデバイスファイルを作成します. 作成されるデバイス名は異なるのですが, サウンドデバイスを追加するためには, 依然として 上に示すコマンドの実行が必要です. リブートせずにもう一度 /etc/rc.conf を読み込んで /etc/rc を開始させるには? シングルユーザモードに移行して, マルチユーザモードに戻ってください. コンソールで次のように実行します: # 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 して, そのディレクトリで プロセスを実行すること(つまり, そのプロセスにとって "/" は システムの実際のルートディレクトリ "/" ではなく, chroot されたサブディレクトリを指す)です. 広く用いられているもう一つの方法があります. それは, 既に存在しているファイルシステムを 読み込み専用(read-only)でマウントし, その上に, あるプロセスに対して そのファイルシステムが書き込み可能であるように見せるような, もう一つのファイルシステムの層を用意するものです. すると, そのプロセスはファイルを書き込むことができると認識し, 実際に書き込むことができるのもその特定のプロセスだけ - システムにある他のプロセスは書き込めないのに対して - であるという状況を実現することができます. この種の砂場(sandbox)は, その非常に透過的な性質を使って, ユーザ(もしくは侵入者)が その事実に気付かないように実現されます. UNIX は, 内部的に二つの砂場(sandbox)を実装しています. 一つはプロセスレベルのもの, もう一つはユーザ ID レベルのものです. UNIX プロセスは全て, 他の UNIX プロセスから完全に隔離されています. どのプロセスも, 他のプロセスのアドレス空間を変更することはできません. これは, あるプロセスが他のプロセスのアドレス空間を上書きできるような, クラッシュにつながる行為が容易に実現できる Windows とは全く異なるものです. UNIX プロセスは, 特定のユーザ ID が所有します. もし, 実行者のユーザ ID が root ユーザのものでなければ, ユーザ ID は, 他のユーザが所有するプロセスから そのプロセスを守る機能を果たすわけです. また, そのユーザ ID は, ディスク上にあるデータを 保護するのにも使われています. X Window System と仮想コンソール 訳: 今野 元之 <motoyuki@jp.FreeBSD.ORG>.13 November 1997. X を動かしたいのですが, どうすればいいのですか? もっとも簡単な方法は (訳注: FreeBSD の) インストールの際に X を動かすことを指定するだけです. それから xf86config ツールのドキュメントを読んでこれに従ってください. このツールはあなたのグラフィックカードやマウスなどに合わせて XFree86(tm) の設定を行うのを助けてくれます. Xaccel サーバーについて調べてみるのもいいでしょう. 詳しくは か をご覧ください. 私のマウスはなぜ X で動かないのでしょうか? syscons (デフォルトのコンソールドライバ) を使っているのであれば, それぞれの仮想スクリーンでマウスポインターをサポートするように FreeBSD を設定できます. X でのマウスの衝突を避けるために, syscons は ``/dev/sysmouse'' という仮想デバイスをサポートしています. 本物のマウスデバイスから入力された全てのマウスのイベントは sysmouse デバイスへ MouseSystems プロトコルで出力されます. 一つ以上の仮想コンソールと X の 両方で マウスを使いたい場合, 以下のように設定することをお勧めします: /etc/rc.conf: moused_type=ps/2 # 実際のマウスのタイプ moused_port=/dev/psm0 # 実際のマウスポート moused_flags= /etc/XF86Config Section Pointer Protocol "MouseSystems" Device "/dev/sysmouse" ..... X で ``/dev/mouse'' を使うのを好む人もいます. この場合は, ``/dev/mouse'' を /dev/sysmouse にリンクしてください: # cd /dev # rm -f mouse # ln -s sysmouse mouse X のメニューやダイアログボックスがうまく動きません. Num Lock キーをオフにしてください. Num Lock キーがデフォルトでブート時にオンになる場合は, XF86Config ファイルの ``Keyboard'' セクションに 以下の行を加えてもいいでしょう. # Let the server do the NumLock processing. This should only be # required when using pre-R6 clients ServerNumLock 訳注: この問題は XFree86 3.2 以降では解決しています. 仮想コンソールとは何ですか? どうやったら使えますか? 仮想コンソールは, 簡単にいうと, ネットワークや X を動かすなどの複雑なことをおこなわずに, いくつかのセッションを 同時におこなうことを可能にします. システムのスタート時には, ブートメッセージが出た後に login プロンプトが表示されます. そこで login ネームとパスワードを 入力すると 1 番目の仮想コンソール上で仕事 (あるいは遊び) を 始めることができます. 他のセッションを始めたい場合もあるでしょう. それは動かしている プログラムのドキュメントを見たり, FTP の転送が終わるまで待つ間 メールを読もうとしたりすることかもしれません. Alt-F2 を押す (Alt キーを押しながら F2 キーを押す) と 2 番目の 「仮想コンソール」で login プロンプトが待機していることが わかります. 最初のセッションに戻りたいときは Alt-F1 を押します. 標準の FreeBSDインストールでは 3 枚の仮想コンソールが 有効になっていて, Alt-F1, Alt-F2, Alt-F3 で仮想コンソール間の 切替えをおこないます. より多くの仮想コンソールを有効にするには, /etc/ttys を編集して ``Virtual terminals'' のコメント行の後に ``ttyv4'' から ``ttyvc'' の手前までのエントリを加えます (以下の例は先頭には空白は入りません) : # /etc/ttys には ttyv3 がありますので # "off" を "on" に変更します. ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/libexec/getty Pc" cons25 on secure ttyv9 "/usr/libexec/getty Pc" cons25 on secure ttyva "/usr/libexec/getty Pc" cons25 on secure ttyvb "/usr/libexec/getty Pc" cons25 on secure 多くするか少なくするかはあなたの自由です. より多くの仮想 ターミナルを使うとより多くのリソースを使うことになります. 8MB 以下のメモリしかない場合はこれは重要な問題です. もし必要があれば ``secure'' を ``insecure'' に変更してください. 重要 X を使いたいのであれば, 最低一つの仮想ターミナル (のエントリ) を使わずに残しておくか, off にしておく必要があります. つまり, 12 個の Alt-ファンクションキー全てでログインプロンプトを 出したいのならば不運にも X は使えない, ということです. 同じマシンで X サーバーも動かしたいのならば 11 個しか使えません. 仮想コンソールを無効にするもっとも簡単な方法はコンソールを off にすることです. 例えば 12 個全てのターミナルを割り当てている 状態で X を動かしたいときは仮想ターミナル 12 を変更します: ttyvb "/usr/libexec/getty Pc" cons25 on secure これを次のように変更します: ttyvb "/usr/libexec/getty Pc" cons25 off secure キーボードにファンクションキーが 10 個しかないのであれば 次のように設定します. ttyv9 "/usr/libexec/getty Pc" cons25 off secure ttyva "/usr/libexec/getty Pc" cons25 off secure ttyvb "/usr/libexec/getty Pc" cons25 off secure (これらの行を消すだけでもいいです.) /etc/ttys を編集したら次は十分な数の仮想ターミナルデバイスを 作らなくてはなりません. もっとも簡単な方法を示します: # cd /dev # ./MAKEDEV vty12 # For 12 devices さて, 仮想コンソールを有効にするのにもっとも簡単 (そして確実) な方法はリブートすることです. しかし, リブートしたくない場合は, X ウィンドウシステムを終了させて次の内容を実行します (root 権限で) : kill -HUP 1 重要な点はこのコマンドを実行する前に X ウィンドウシステムを 完全に終了させておくことです. もしそうしないと kill コマンドを 実行した後にシステムはおそらくハングアップするでしょう. X から仮想コンソールに切替えるにはどうすればよいのですか? コンソールが X の表示をしている場合は, Ctrl-Alt-F1 などを使って 仮想コンソールの切替えをおこなうことができます. ただし, X から離れて仮想ターミナルへ移っている時は Alt-ファンクションキーを 使って他の仮想ターミナルへ切替えたり X へ戻ったりします. コントロールキーは押さないでください. Ctrl-Alt-ファンクションキーの 組合せは X から仮想ターミナルに移る時だけ利用してください. コントロールキーを押してしまうと ``control-lock'' モードになり テキストコンソールが止まってしまいます. コントロールキーを押して 回復させてください. 訳注: X に戻るには 3枚の仮想コンソールが有効になっている場合は Alt-F4 です. 有効な仮想コンソールの数 +1 のファンクションキーの 位置に X が割り当てられます. XDM をブート時に起動させるにはどうしますか? xdm の起動方法について, その考え方には二つの流派があります. ある流派では提供された例を使用して xdm を /etc/ttys から起動し, 他の流派では xdm を単に rc.local または /usr/local/etc/rc.d にある X.sh スクリプトから起動します. どちらも正しく, 片方が動作しない場合は, もう片方が動作するでしょう. どちらも場合でも結果は同じであり, X はグラフィカルな login: プロンプトを表示します. ttys を利用する方法の利点は, どの vty で X が起動したかの記録が 残せることと, ログアウト時に X サーバを再起動する責任を init に 押しつけることができることでしょう. rc.local からロードされる場合, xdm は引数を持たずに起動します. (すなわち, デーモンとして起動します.) xdm は getty が起動した後に ロードされなければなりません. そうでないと, xdm は getty と衝突し, コンソールをロックアウトしてしまいます. この問題に対処する最善の方法は 起動スクリプト(訳注: rc.local のこと)で 10秒ほどの sleepを実行させ, その後に xdm をロードすることです. 以前のバージョンの FAQ では /usr/X11R6/lib/X11/xdm/Xservers ファイルに X の使う vt を加えるように書いてあります. これは必要ありません: X は最初に見つけた利用可能な vt を使います. xconsole を動かそうとすると ``Couldn't open console'' とエラーが出ます. X を startx で起動しますと, /dev/console のパーミッションは 変更ができない ようになっていますので, xterm -C や xconsole は動きません. これはコンソールのパーミッションが標準ではそのように 設定されているからです. マルチユーザシステムでは, ユーザの誰もが システムコンソールに書き込むことが可能である必要は必ずしもありません. VTY を使い 直接マシンにログインするユーザのために, このような問題を解決するために fbtab というファイルがあります. 要点を述べると, 次のような形式の行を fbtab に加えます. /dev/ttyv0 0600 /dev/console そうすると, /dev/ttyv0 からログインしたユーザが コンソールを所有することになるでしょう. 私の PS/2 マウスは X ウィンドウシステム上でうまく動きません. あなたのマウスとマウスドライバがうまく同期していないからかも しれません. FreeBSD 2.2.5 までのバージョンでは, X から仮想ターミナルへ 切替えてまた X へ戻ると再同期するかもしれません. この問題がよく起きるようであれば, カーネルコンフィグレーション ファイルに次のオプションを書いてカーネルを再構成してみてください. options PSM_CHECKSYNC もし, カーネルの再構築をおこなったことがないのであれば のセクションを 見てください. このオプションにより, マウスとドライバの同期の問題の起きる 可能性は少なくなるでしょう. もしそれでもこの問題が起きるようならば, 再同期させるにはマウスを動かさないようにしておいて マウスボタンのどれかを押してください. このオプションは残念ながら, すべてのシステムで働くわけではなく また, PS/2 マウスポートにつながれているのが ``tap'' の特色を 持つ ALPS GlidePoint デバイスの場合, ``tap'' が無効となってしまいます. FreeBSD 2.2.6 以降のバージョンでは, 同期のチェック方法が少し改善 されたので標準で有効になっています. GlidePoint でもうまく働きます (同期チェックが標準の機能になったので PSM_CHECKSYNC オプションは これらのバージョンからは削除されました). しかしながら, 稀れに ドライバが間違って(訳注: 問題がないのに)同期に関して問題があると報告し, カーネルから psmintr: out of sync (xxxx != yyyy) というメッセージが出力されて, マウスが正しく動作していないように見える ことがあるかもしれません. もしこのようなことが起こる場合には, PS/2 マウスドライバのフラグに 0x100 を指定して同期チェックを無効にして下さい. システムの起動時に ``'' ブートオプションを与えて UserConfig に入ります. boot: -c UserConfig のコマンドラインで以下のように入力して下さい. > flags psm0 0x100 > quit MouseSystems の PS/2 マウスがうまく動きません. MouseSystems の PS/2 マウスのあるモデルは, 高解像度モードの場合 にのみ正しく動作するということが報告されています. それ以外のモードでは マウスカーソルがしょっちゅうスクリーン左上に行ってしまうかもしれません. 残念ながら FreeBSD 2.0.X や 2.1.X のバージョンではこの問題の解決する 方法はありません. 2.2 から 2.2.5 のバージョンでは以下のパッチを /sys/i386/isa/psm.c に適用しカーネルの再構築を行なって下さい. もし, カーネルの再構築をおこなったことがないのであれば のセクションを 見てください. diff -u psm.c.orig psm.c @@ -766,6 +766,8 @@ if (verbose >= 2) log(LOG_DEBUG, "psm%d: SET_DEFAULTS return code:%04x\n", unit, i); + set_mouse_resolution(sc->kbdc, PSMD_RES_HIGH); + #if 0 set_mouse_scaling(sc->kbdc); /* 1:1 scaling */ set_mouse_mode(sc->kbdc); /* stream mode */ FreeBSD 2.2.6 以降のバージョンでは, PS/2 マウスドライバのフラグに 0x04 を指定してマウスを高解像度モードにします. システムの起動時に ``'' ブートオプションを与えて UserConfig に入ります. boot: -c UserConfig のコマンドラインで以下のように入力して下さい. > flags psm0 0x04 > quit マウスに関する不具合の他の原因の可能性については直前のセクションも 見てみて下さい. X のアプリケーションを構築する時に, imake can't find Imake.tmpl となります. どこにあるのでしょうか? Imake.tmpl は X の標準アプリケーション構築ツールである Imake パッケージの一部です. Imake.tmpl は X アプリケーションの構築に必要な多くのヘッダファイルと 同様に, X のプログラムディストリビューションに含まれています. sysinstall を使うか手動で X のディストリビューションファイルから インストールすることができます. マウスのボタンを入れ替える方法はありますか? .xinitrc か .xsession で xmodmap -e "pointer = 3 2 1" というコマンドを実行してください. スプラッシュスクリーンのインストールはどうするのですか. どこで見つけることができますか? FreeBSD 3.1 のリリース直前に, ブートメッセージの表示期間に いわゆる "スプラッシュ" スクリーンを表示させることができる新しい 機能が追加されました. いまのところスプラッシュスクリーンは 256色のビットマップ (*.BMP) か ZSoft PCX (*.PCX) ファイルです. それに加えて, 標準のVGAアダプタでの動作させるには 320x200 以下の解像度である必要があります. カーネルに VESA サポート を追加すれば 1024x768 までのより大きいビットマップを使用できます. VESA サポートを有効化するにはまず, カーネルが VM86 カーネルオプションとともにコンパイルされている必要が あることに注意してください. VESA サポートそのものは VESA カーネルコンフィグオプション によって直接カーネル中にコンパイルするか, ブート時に VESA kld モジュールを読み込ませることができます. スプラッシュスクリーンを使うには, FreeBSDのブートプロセスを コントロールするスタートアップファイルを書き換える必要があります. これらのファイルは FreeBSD 3.2 のリリース以前に変更されましたので, 現在は, スプラッシュスクリーンを読み込む方法が二つあります: FreeBSD 3.1 の場合 まず最初のステップは, スプラッシュスクリーンのビットマップ版を 探してくることです. 3.1 リリースでは Windows のビットマップ形式 のスプラッシュスクリーンだけをサポートしています. お望みの スプラッシュスクリーンを見つけたなら, それを /boot/splash.bmp にコピーします. 次に, これらの行が書かれた /boot/loader.rc ファイルが必要です: 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 と読み換えて ください. そうではなくて, 新しいブート設定方法を使うのなら, 次の数行が書かれた /boot/loader.rc ファイル: include /boot/loader.4th start そして, 次の数行が含まれた /boot/loader.conf ファイルを作ることが必要です: splash_bmp_load="YES" bitmap_load="YES" この例では, スプラッシュスクリーンとして /boot/splash.bmp を使うことを想定しています. PCX 形式のファイルを使う場合には, そのファイルを /boot/splash.pcx にコピーして, 上で示したように /boot/loader.rc を作ります. そして, 次の内容の /boot/loader.conf というファイルを作ってください: splash_pcx_load="YES" bitmap_load="YES" bitmap_name="/boot/splash.pcx" さて, あとはスプラッシュスクリーンを用意するだけです. それには http://www.cslab.vt.edu/~jobaldwi/splash/ のギャラリーをサーフしてみてください. ネットワーキング 訳: 有村 光晴 <arimura@jp.FreeBSD.org> 広瀬 昌一 <shou@kt.rim.or.jp> にしか <nishika@cheerful.com> はらだ きろう <kiroh@jp.FreeBSD.org> . 4 October 1998. ``diskless boot'' に関する情報はどこで得られますか? ``diskless boot'' というのは, FreeBSD がネットワーク上で起動し, 必要なファイルを自分のハードディスクではなくてサーバから読み込むものです. 詳細については ハンドブックのディスクレスブートに関する節 を読んでください. FreeBSD をネットワークの router として使用することはできますか? インターネット標準やこれまでのよい経験によって指摘されている通り, FreeBSD は標準ではパケットを forward するように設定されていません. しかし, rc.conf の中で次の変数の値を YES とする事によってこの機能を有効にすることができます. gateway_enable=YES # Set to YES if this host will be a gateway このオプションによってsysctl の変数 net.inet.ip.forwarding が 1 になります. ほとんどの場合, router についての情報を同じネットワーク の他の計算機等に知らせるために, 経路制御のためのの process を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン である routed が付属していますが, より複雑な状況に対処するためには GaTeD (ftp.gated.Merit.EDU から FTP で手に入れることができます) を使用することもできます. 3_5Alpha7 において FreeBSD がサポートされています. 注意してほしいのは, FreeBSD をこのようにして使用している場合でも, router に関するインターネット標準の必要条件を完全には満たしていない ということです. しかし, 普通に使用する場合にはほとんど問題ありません. Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか? 通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では FreeBSD が, もう一台では Win95 が走っているような場合です. ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを 経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します. FreeBSDをPPP の Dialup ルータとして設定する方法については, 役に立つ文書があります. 注: これには, Windows の走っているマシンからどれだけの 作業を同時におこなうかによって, 最低 2 個, 場合によってはもっと多くの 固定した IP アドレスが必要です. もし固定した IP アドレスがない場合には, プライベートな IP アドレスを用いたサブネットを使用し, FreeBSD 上で SQUIDや TIS firewall ツールキット のような proxy を用いることによって実現することもできます. また, に関する節も参照してください. ISC からリリースされている BIND の最新版は compile できないんでしょうか? BIND の配布物と FreeBSD とでは ``cdefs.h'' というファイルの中で, データ型の矛盾があります. compat/include/sys/cdefs.h を削除してください. FreeBSD で SLIP と PPP は使えますか? 使えます. FreeBSD を用いて他のサイトに接続する場合には, slattach, sliplogin, pppd そして ppp のマニュアルページを見てください. pppd と ppp は PPP のサーバ, クライアント両方の 機能を持っています. sliplogin は SLIP のサーバ専用で, slattach は SLIP のクライアント専用です. これらのプログラムの解説が, ハンドブック の以下のセクションにあります. ハンドブックの SLIP (サーバ側) の節 ハンドブックの SLIP (クライアント側) の節 ハンドブックの PPP (kernel バージョン) の節 ハンドブックの PPP (user モードバージョン) の節 「シェルアカウント」を通じてのみインターネットへアクセス可能な場合, slirp package みたいなものが欲しくなるかもしれませんね. これを使えば, ローカルマシンから直接 ftp や http のようなサービスに (限定的ではありますが) アクセスすることができます. FreeBSD は NAT か IP マスカレードをサポートしていますか? ローカルなサブネット (一台以上のローカルマシン) を持っているが, インターネットプロバイダから 1 つしか IP アドレスの割り当てを 受けていない場合 (または IP アドレスを動的に割り当てられている場合でも), natd プログラムを使いたくなるかもしれませんね. Natd を使えば, 1 つしか IP アドレスを持っていない場合でも, サブネット全体をインターネットに接続させることができます. ppp も, 同様の機能を持っており, スイッチで有効にすることができます. どちらの場合も alias library が使われます. /dev/ed0 デバイスを作成することができません. Berkeley UNIX におけるネットワークの構成においては, ネットワーク のインタフェースは kernel のコードからのみ直接あつかうことが できます. より詳しく知りたい場合は, /etc/rc.network というファイルや, このファイルの中に書いてあるさまざまなプログラム についてのマニュアルページを見てください. それでもまだ分からない場合には, 他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう. ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0 や Ultrix と基本的に同じです. Ethernet アドレスのエイリアスはどのようにして設定できますか? ifconfig のコマンドラインに ``netmask 0xffffffff'' を追加して, 次のように書いてください. ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff 3C503 で他のネットワークの port を使用するにはどのようにすればよいですか? 他の port を使用したい場合には, ifconfig のコマンドラインにパラメータを 追加しなければなりません. default は ``link0'' が用いられるようになっています. BNC のかわりに AUI port を使用したい場合には ``link2'' というパラメータを 追加してください. これらのフラグは /etc/rc.conf. の using the ifconfig_* の変数を使って指定されるはずです. FreeBSD との間で NFS がうまくできません. PC 用のネットワークカードによっては NFS のようなネットワークを 酷使するアプリケーションにおいて問題を起こすものがあります. この点に関しては ハンドブックの NFS についての節 を見てください. 何故 Linux のディスクを NFS マウントできないのでしょうか? Linux の NFS のコードによっては許可されたportからの リクエストからしか受けつけないものがあります. 以下を試してみてください. mount -o -P linuxbox:/blah /mnt 何故 Sun のディスクを NFS マウントできないのでしょうか? SunOS 4.X が走っている Sun Workstation は許可された port からの mount のリクエストしか受けつけません. 以下を試してみてください. mount -o -P sunbox:/blah /mnt PPP で NeXTStep に接続する際に問題があるのですが. /etc/rc.conf の中で次の変数を NO にして, TCP extension を無効にしてみてください. tcp_extensions=NO Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう 場合にもこの変更を行ってください. IP multicast を有効にするには? 2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています. 現在使用している計算機を multicast の router として使用するには, MROUTING というオプションを定義したカーネルを作ったうえで, mrouted を走らせる必要があります. 2.2 かそれ以降の FreeBSD ならば, /etc/rc.conf でフラグ mrouted_enable を "YES" にセットして おくことで, ブート時に mrouted を起動できます. MBONE用のツールは ports 内の専用のカテゴリー mbone にあります. vic や vat といった会議用のツールを探している場合はこの場所を 見てください. 詳しい情報は Mbone Information Web にあります. DEC の PCI チップセットを用いている network カードにはどのような物がありますか? Glen Foster による一覧に, よりmodernな物を追加したものを 以下に示します. 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 Zynx ZX342 何故自分のサイトのホストに対して FQDN を使用する必要があるのですか? 実際にはそのホストは別のドメインにあるのではないですか. たとえば, foo.bar.edu というドメインの中から, bar.edu ドメインにある ``mumble'' というホストを指定したい場合には, ``mumble'' だけでは 駄目で, ``mumble.bar.edu'' という fully-qualified domain name で 指定しなければなりません. 伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが, FreeBSD に入っている bind の現在のバージョンでは, 自分以外のドメインに対して FQDN でない別名を自動的につけてくれるような事はありません. したがって mumble というホスト名は mumble.foo.bar.edu という名前か, もしくは root ドメイン内にある場合にしか適用されません. これは, mumble.bar.edu と mumble.edu ということなったドメイン名に対してホスト名のサーチがおこなわれていた 以前の振る舞いとは異なったものです. このような事が悪い例もしくは セキュリティホールとみなされる理由については RFC 1535 を見てください. /etc/resolv.conf の中で domain foo.bar.edu と書いてある行を search foo.bar.edu bar.edu のように書きかえることで, 上のような事ができます. しかし, RFC 1535 にあるように, search order が ``ローカルな管理と パブリックな管理の境界'' をまたがないようにしてください. すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが. IPFIREWALL オプションを付けてカーネルをコンパイルした場合には, 2.1-STABLE の開発の途中から変更になった 2.1.7R の標準的な方針として, 明示的に許可されていないすべてのパケットは落とされる設定 になっている事を覚えておいてください. もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる ようにするには, root でログインして次のコマンドを実行してください. ipfw add 65534 allow all from any to any /etc/rc.conf に "firewall_type='open'" を追加してもよい でしょう. FreeBSD のファイアウォールの設定についての情報は FreeBSD ハンドブック にあります. IPFW のオーバーヘッドはどのくらいでしょうか? この答えはあなたのルールセットとプロセッサのスピードによって ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ ているほどんどの場合には, その影響は無視できる程度です. 実 際の測定値を見ないと満足できない方々のために, 実際の測定結 果をお見せしましょう. 次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で 2.2.5-STABLE を使用しておこなわれました. IPFW は変更が加えられて, ip_fw_chk ルーチン内でかかる時間を 測定して 1000 パケット毎に結果をコンソールに表示するようになっています. それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが おこなわれました. ひとつ目のルールセットは最悪のケースを見るために ipfw add deny tcp from any to any 55555 というルールを繰り返したものです. パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに, 何度も実行される IPFW のパケットチェックルーチンによって, これは最悪のケースを示します. このルールを 999 個繰り返し並べた後に allow ip from any to anyが 書かれています. 2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです: ipfw add deny ip from 1.2.3.4 to 1.2.3.4 このルールでは, 発信元の IP アドレスがマッチしないのでチェックは すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは 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 のようしてパケット数の統計を取ることで, どのルールが最もよく使われているかを調べることができます. サービス要求を他のマシンにリダイレクトするには? FTP などのサービスのリクエストは, 'socket' パッケージを利用 してリダイレクトできます. 'socket' パッケージは ports の 'sysutils' カテゴリに含まれています. リダイレクトしたいサービ ス(/etc/inet.confのコマンド行をソケットを呼ぶように変 更してください. 変更例: ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp' はポートです. バンド幅の管理を行なえるツールはどこで手に入れられますか? FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる ALTQ と, Emerging Technologies から入手できる Bandwidth Manager という市販のものの 2 種類があります. なぜ ``/dev/bpf0: device not configured" が出るのでしょうか? バークレーパケットフィルタ(bpf) ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります. カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい. pseudo-device bpfilter # Berkeley Packet Filter そして再起動してから, 次にデバイスノードを作成する必要があります. これは, 次のように入力し, /dev を変更することで行ないます. # sh MAKEDEV bpf0 デバイスノードの作成の詳細は, FreeBSD ハンドブックのデバイスノードに関する節 を参照して下さい. PPP ppp が動きません. どこを間違えているのでしょう? まず ppp のマニュアルと, ハンドブックの ppp のセクションを読んでみましょう. 次に, set log Phase Chat Connect Carrier lcp ipcp ccp command という命令を ppp のコマンドプロンプトに対して打ち込むか, 設定ファイル /etc/ppp/ppp.conf に加えて (default セクションの先頭に加えるのが一番良いでしょう) ログを有効にしてみてください. その際, /etc/syslog.conf に !ppp *.* /var/log/ppp.log と書かれた行が含まれているか, また, /var/log/ppp.log が存在しているかどうか確かめておいてください. さて, これで 何が起きているのか突き止めるために, ログファイルからたくさんの 情報を得られるようになりました. ログに訳の分らない部分があっても 心配ご無用. あなたが助けを求めた誰かにとっては, その部分が 意味をなす場合があるのです. 訳注: ログの取得に syslog を使用するようになったのは 2.2.5 以降からです. 使用中の ppp のバージョンで "set log" 命令を解釈しない場合は, 最新版 をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます. ppp を実行するとハングします ホスト名の解決がうまくいっていないのでしょう. まず, リゾルバが /etc/hostsを参照するように, /etc/host.conf の最初の行に host と書き込んでください. つぎに, /etc/hostsに使用しているマシンのエントリを 書き加えます. ローカルでネットワークを使用していない場合は, localhost の行を以下のように変更してください: 127.0.0.1 foo.bar.com foo localhost 使用しているホストのエントリを追加してもかまいません. 詳細は関連するマンページを参照してください. ppp が -auto モードでダイアルしてくれない まず最初に, デフォルトルートが確立しているかどうかチェックして ください. netstat -rn を実行すると, 以下のような情報が表示されるはずです. Destination Gateway Flags Refs Use Netif Expire default 10.0.0.2 UGSc 0 0 tun0 10.0.0.2 10.0.0.1 UH 0 0 tun0 これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で 出てくるアドレスを使用していると仮定した場合の例です. デフォルトルートが確立していない場合, ppp.conf の中の HISADDR が理解できない, 古いバージョンの ppp が走っている可能性があります. FreeBSD 2.2.5 より前の バージョンに付属していた ppp を使用している場合, add 0 0 HISADDR と書かれた行を以下のように修正してください. add 0 0 10.0.0.2 netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ, /etc/rc.conf (2.2.2 より前のリリースでは /etc/sysconfig と呼ばれていました) の中でデフォルトの ルータを誤って設定し, ppp.conf から delete ALL の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの システムの最終設定 の項を読み直してください. "No route to host" とはどういう意味ですか? このエラーは通常, /etc/ppp/ppp.linkup に以下のような セクションが無い場合に起こります. MYADDR: delete ALL add 0 0 HISADDR これは動的 IP アドレスを使用している場合, またはゲートウェイの アドレスを知らない場合にのみ必要な設定です. インタラクティブモード を使用している場合, パケットモード に入った後で (プロンプトが PPP と大文字に変わったらパケットモードに入ったしるしです), 以下の命令を入力してください. delete ALL add 0 0 HISADDR 詳しい情報については, ハンドブックの PPP と動的 IP 設定 の項を参照してください. 3 分ほど経つと接続が切れてしまう ppp のタイムアウトは デフォルトでは 3 分です. これは set timeout NNN という命令によって調整することができます. NNN には 接続が切れるまでのアイドル時間が秒数で入ります. NNN が 0 の場合, タイムアウトによる切断は起こりません. このコマンドは ppp.conf に入れることも, インタラクティブモードでプロンプトから入力することも できます. ソケットを用いる telnet か pppctl を使用し, ppps サーバに接続することによって, 回線がアクティブな間に限定してタイムアウトの時間を調整することも 可能です. 訳注 pppctl は 2.2.5R からです. 詳しい情報は ppp のマニュアルを参照してください. 負荷が高いと接続が切れてしまう Link Quality Reporting (LQR) の設定を行っている場合, マシンと接続先の間で非常にたくさんの LQR パケットが失われている 可能性があります. 結果として ppp は回線の具合いが悪いと考え, 回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で 無効です. LQR は以下の命令で無効にすることができます. disable lqr 接続がランダムに切れてしまう 時々, ノイズの多い回線, あるいは待ち機能付きの回線では, モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう ことがあります. 大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか 設定で決めることができます. 例えば USR Sportster では, S10 レジスタ の値を 10 倍した秒数がその値になります. この場合, モデムをもっと のんびり屋さんにするには, dial 行に次のような文字列を加えると 良いでしょう. set dial "...... ATS10=10 OK ......" 詳しくはお使いのモデムのマニュアルをご覧ください. 接続が不規則にハングアップしてしまう たくさんの人が, 原因不明のハングアップを経験しています. 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか, ということです. 外部接続型モデムを利用しているなら, 単に ping を使うことで, データを送信するときに TD ランプが点灯するかどうかを確認することができます. もし, TD ランプが点灯して, RD ランプが点灯しなければ, 問題は回線の向こう側にあります. TD が点灯しなければ, 問題は回線のこちら側です. 内蔵型モデムの場合, ppp.conf ファイルに set server コマンドを入れる必要があるでしょう. 回線が切断されたとき, pppctl を使って ppp に接続してください. そのとき, ネットワーク接続が急に復旧(診断ソケットへのアクセスで, ppp が復活します)するか, もしくは接続自体が全くできない (ただし, ppp 起動時に set socket コマンドがちゃんと実行されているとします)としたら, 問題は回線のこちら側です. もし, 接続可能で, かつ状況が変化しなければ, set log local async を使ってローカル非同期ログ(async logging)を有効にし, ping を他のウィンドウかターミナルから使ってください. 非同期ログには, こちら側のリンクの送受信データが記録されます. もし, データが送信されたにもかかわらず返って来ていなければ, 問題は回線の向こう側にあることになります. 問題が回線のどちら側かにあることが分かったら, つぎの二つの可能性が考えられるでしょう. 回線の向こう側での反応がない これに対処できることはほとんどありません. 大部分の ISP は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう. ppp.conf ファイルの中に enable lqr を記述することで ppp が回線の向こう側で発生するハングアップを検出することができますが, この検出は比較的遅いため, あまり役に立ちません. また, あなたは user-ppp を利用していることを ISP に知られたくないと思うかも知れませんね. まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい. それには, 設定ファイルをつぎのようにします. disable pred1 deflate deflate24 protocomp acfcomp shortseq vj deny pred1 deflate deflate24 protocomp acfcomp shortseq vj そして再接続し, 変更前と同じように通信できることを確認します. もしこれによって状況が改善されるか, 完全に解決したら, (上の設定のうち)どの設定で状況が変化したのかを, 色々な組合せで試してみて下さい. これは, ISP に問い合わせを行なうときの有効な情報となります(ただし, あなたが Microsoft 社製品以外のものを利用していることも 明らかにしてしまいますが). ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして, 接続がハングアップするまで待って下さい. この作業は, 非常に多くのディスク空間を消費するかも知れません. 興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです. それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が 記載されている可能性があります. 回線の向こう側で通信ログを監視することは可能なはずですので, ハングアップが発生した時, ISP の対応が好意的ならば どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません. brian@Awfulhak.org まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません. ppp がハングアップする ベストな方法は, CFLAGS+=-g と STRIP= を ppp の Makefile に追加して, ppp を再構築し, そして make clean && make && make install を行なうことです. ppp がハングアップした時, ps ajxww | fgrep ppp を使って ppp のプロセス ID を調べ, gdb ppp PID を実行して下さい. gdb のプロンプトから, bt を使ってスタックをトレースすることができます. スタックトレースの結果は, brian@Awfulhak.org まで送って下さい. Login OK! のメッセージが出た後, 何も起こらない 2.2.5 より前のリリースの FreeBSD では, ppp はリンクが確立した後, 接続先が Line Control Protocol (LCP) を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを 自分からは起こさず, クライアントが起こすのを待っています. ppp に強制的に LCP を発信させるには, 次の命令を使います. set openmode active 注: 両方の側がネゴジェーションを起こしても, 大抵の場合は 何の問題もありません. ですから, 現在では openmode はデフォルトで active になっています. 次のセクションでこれが問題になる場合を 説明します. でもまだ "magic is the same" というエラーが出る 時折, 接続直後のログに "magic is the same" というメッセージが あらわれることがあります. このメッセージがあらわれても何も起きない 場合もありますし, どちらかの側が接続を切ってしまう場合もあります. ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと link が上がっている状態であっても, ppp が最終的にあきらめてしまい 接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた という通知が log ファイルに残ると思います. これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで getty が生きていて, ppp がログインスクリプトか, ログイン直後に 起動されたプログラムから実行されている場合に起こります. slirp を使用 している場合に同様の症状が見られたという報告もあります. 原因は getty の終了されるまでと, ppp が実行され, クライアント側の ppp が Line Control Protocol (LCP) を送り始めるまでのタイミングにあります. サーバ側のシリアルポートで ECHO が有効なままになっているので, クライアント側の ppp にパケットが「反射」してしまうのです. LCP ネゴジェーションの一部として, リンクの両サイドで magic number を定めて, 「反射」が起きていないかどうか確かめる作業があります. 規約では, 接続相手がこちらと同じ magic number を提示してきたら, NAK を送って新しい magic number を選択しなければならないと 定めています. この作業の間, サーバのシリアルポートの ECHO がずっと 有効になったままなので, クライアント側の ppp は LCP パケットを送り, パケットが反射して全く同じ magic number が送られてくるのを見つけ, それに対して NAK を送るのです. 一方 NAK 自体も (これは ppp が magic number を変更しなければいけないことを意味しています) 反射して くるので, 結果として magic number が数えきれないほど変更され, その全てがサーバの tty バッファの中に積み重なることになるのです. サーバでスタートした ppp はとすぐ magic number であふれかえってしまい, LCP のネゴジェーションを十分に行ったものと判断して, さっさと接続を 切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので 満足しますが, それもサーバが接続を切ったことを知るまでです. この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー ションを開始できるようにする事によって回避できます. set openmode passive これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして ください. set openmode active 3 これによって ppp は 3 秒間 passive モードを続けた後で LCP リク エストを送り始めます. この間に相手がリクエストを送り始めた場合には 3 秒間待たずにこのリクエストに即座に応答します. 接続が切れるまでLCPのnegotiationが続く. pppでは現在まだ, LCPやCCP, IPCPの返事が元のリクエストと 連携してくれる機能がきちんと実装されていません. その結果, ある pppが相手よりも6秒以上遅い場合には, LCP configurationのリ クエストをさらに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モードに設定 する, すなわち反対側がnegotiateを開始するまで待つようにする事です. これは, set openmode passive というコマンドでできます. このオプションは気を付けて使わないといけ ません. さらに set stopped N というコマンドを追加して, pppがnegotiationが開始するまで待つ 最大の時間を設定してください. もしくは, set openmode active N というコマンド(ここで, Nはnegotiationが始まるまで待つ時間です) を使うこともできます. 詳しくはmanual pageを見てください. ppp が接続直後に固まってしまう 2.2.5 より前のバージョンの FreeBSD では, ppp が Predictor1 圧縮 のネゴジェーションを誤って解釈して, 接続直後にリンクを無効にしている 可能性があります. これは両サイドが 異なる Compression Control Protocols (CCP) を使ってネゴジェーションを行った場合にのみ発生します. この問題は現在は解決していますが, あなたの走らせている ppp の バージョンが古い場合でも, 次の命令で解決することができます. disable pred1 ppp の内部でシェルを起動しようとすると固まってしまう shell あるいは ! コマンドを使用すると, ppp は シェルを起動し (何か引数を渡した場合は, ppp は引数も 実行します), コマンドが終了するまで処理を中断します. コマンドを 実行中に ppp のリンクを使おうとすると, リンクが固まっているように 見えますが, これは ppp がコマンドの終了を待っているからです. このような場合は, 代わりに !bg コマンドを使用してください. 与えられたコマンドがバックグラウンドで実行されるので, ppp は リンクに関するサービスを継続することができます. ヌルモデムケーブルを使用しているとき, ppp が終了しない ヌルモデムケーブルを使用して直接接続している場合, ppp は 自動的には接続の終了を知ることができません. これはヌルモデム シリアルケーブルの配線に起因しています. この種の接続形態を用いる 場合は, 以下の命令を用いて LQR を常に有効にする必要があります. enable lqr こうすると, 接続先がネゴシエーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. ppp を -auto モードで動かすと, 勝手にダイアルすることがある ppp が思いもしないときにダイアルを始める場合, その原因を 突き止め, 防止のために Dial filters (dfilters) をかけてやる 必要があります. 原因を突き止めるためには, 以下の命令を使用してください. set log +tcp/ip これで接続を通過する全てのトラヒックをログに残すことができるように なりました. 次に突然回線がつながったときのログのタイムスタンプを たどれば, 原因を突き止めることができるはずです. 原因がわかったら, 次に, このような状況ではダイヤルが起こらないように しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために 起こります. DNS による名前の解決によって, 接続が行われるのを防止する には, 次のような手段を用います (これは ppp の既に確立した接続 に関してパケットのフィルタリングをするものではありません). set dfilter 1 deny udp src eq 53 set dfilter 2 deny udp dst eq 53 set dfilter 3 permit 0/0 0/0 これはデマンドダイヤル機能に問題を生じさせるため, 常に適切であるとはかぎりません. ほとんどのプログラムは 他のネットワーク関連の処理をおこなう前に DNS への問い合わせ が必要になります. DNS の場合は, 何が実際にホスト名を検索しようとしているのかを 突き止めるべきでしょう. 大抵の場合は, sendmail が犯人です. 設定ファイルで sendmail が DNS に問い合わせないようになっているか確認すべきです. 自分用の設定ファイルを作成するための詳しい方法は の節をご覧ください. または, .mcファイルに次のような行を追加してもよいでしょう. define(`confDELIVERY_MODE', `d')dnl この行を追加すると, sendmailはメールキューを処理する (通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m'' というオプションを付けて起動されます) までか, または (多分ppp.linkupというファイルの中で) ``sendmail -q''というコマンドが実行されるまで, 全てのメールを キューに溜めるようになります． 訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して 終了します． CCP エラーとはどういう意味ですか ログファイル中の以下のエラーは, CCP: CcpSendConfigReq CCP: Received Terminate Ack (1) state = Req-Sent (6) ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが, 接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて こちら側でも Predictor1 圧縮を無効にすることで対応できます. disable pred1 ファイル転送の途中で, ppp が IO エラーを出して固まってしまう FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース の MTU のサイズより大きなパケットを受け取ることができないというバグが ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが 起こり, syslogd 経由で記録されるのです. ppp の仕様では, LCP のネゴジェーションを行う場合を含む どのような場合でも最低 1500 オクテットの Maximum Receive Unit (MRU) を受け入れる必要があります. ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく 1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない 機能にぶちあたって, リンクが固まるのを目にすることになるのです. FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく しないことで, この問題を回避することができます. どうして ppp は接続速度をログに残さないんでしょう? モデムとの「やり取り」全ての行をログに残すには, 以下のようにして接続速度のログの有効化を行ってください: set log +connect これは ppp に最後にくることが要求されている "expect" という文字列がくるま でのすべてのものをログに記録させます. 接続速度はログにとりたいけれど, PAP や CHAP を使っている (その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」 を行わない - "set login" スクリプトには何も書かない) のであれ ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる ようにしないといけません, 以下のようになります: 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''のような 特別なescape sequence (man pageを見てください)を見付けるために もう1回parseを行います. このようにparseは2回繰り返されま すので, 正しい回数だけescapeを行わないといけません. モデムにたとえば``\''のような文字を送りたい場合には, 次のように する必要があります: set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK" 実際にモデムに送られる文字列は次のようになります: ATZ OK AT\X OK 他の例ですと set phone 1234567 set dial "\"\" ATZ OK ATDT\\T" は次のようになります: ATZ OK ATDT1234567 ppp が segmentation fault になるのですが, ppp.core ファイルがありません ppp (や他のプログラム) はけして core を吐いてはいけません. ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム は ppp を終了させる前にディスクに core イメージを書き込みません. しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因 となるようなシグナルによって終了して おり, さらに 最新の バージョン (このセクションの始めを見てください) を使用している ならば, 次のようにしてください: $ 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 これで debug 可能なバージョンの ppp がインストールされます. root で ppp を実行し, 全ての特権が無効になっているようにする必要 があるでしょう. ppp を実行する時には, current directory が make した directory であるようにしてください. これで, ppp がセグメンテーション例外を受け取ったときには ppp.core という名前の core ファイルを吐くようになります. core が 吐かれたら次のようにしてください: $ su # gdb /usr/sbin/ppp ppp.core (gdb) bt ..... (gdb) f 0 ..... (gdb) i args ..... (gdb) l ..... 質問する際には, これら全ての情報を提供して, 問題点の分析ができ るようにしてください. gdb の使い方に慣れている場合には, 実際に dump の原因となった 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. auto mode でダイアルをするようなプロセスが接続されない これは ppp がローカル側の IP アドレスを, 動的に通信相手と交渉するように設定されている時に発生する 良く知られた障害でした. 最新のバージョンでは, この問題は修正されています. iface をマニュアルページから検索してみて下さい. これは, 最初のプログラムが connect(2) を呼び出した時, tun インターフェイスの IP アドレスが, ソケットの終端に割り当てられてしまうという問題です. カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます. そして ppp は, そのパケットを読み込んで接続を確立します. ppp は動的に IP アドレスを割り当てるため, もしインターフェイスのアドレスが変化してしまうと, 最初に割り当てられたソケット終端の IP アドレスは無効になってしまいます. そのため, それ以降相手に送られる全てのパケットは通常, 相手に届くことはないでしょう. もし仮に届いたとしても, 既にこちらの IP アドレスは変更されているので, どんな反応も最初のマシンには戻ってきません. この問題に対処する理論的な方法がいくつかあります. もし可能なら, 相手が再度, 同じ IP アドレスを割り当ててくれることが一番です :-) ppp の現在のバージョンはこれを行ないますが, 他のほとんどの実装はそういった動作をしません. 我々の側から対処できる最も簡単な方法は, tun インターフェイスの IP アドレスを固定する事です. またそのかわりに, 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP アドレスから, 交渉によって得られた IP アドレスに, 適宜書きかえる事によっても対処できます. こ これは, 基本的に ppp の最新バージョンにある iface-alias オプションが 行なっていることと同じです(libalias(3) および, ppp の スイッチにも関係します). それは, 以前の IP アドレスを全て管理し, それらを最後の交渉によって得られた IP アドレスの別名として扱えるようにします. もう 1 つの(おそらく最も信頼できる)方法は, bind された 全てのソケットの IP アドレスを, 異なるものに変更できるシステムコールを実装することです. pppは, 交渉によって新しい IP アドレスを得た時, このシステムコールを用いて実行されているプログラムにある, 全てのソケットを書きかえてやるわけです. 同じシステムコールが, DHCP クライアントが利用するソケットを 強制的に再 bind するのにも使うことができるでしょう. 3 つ目の方法は, IP アドレスを指定しないでインターフェイスを利用できるようにすることです. 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで, 255.255.255.255 という IP アドレス が与えられます. これによって. ソケットは常に bind することができます. pppに対して発信元 IP アドレスを変更させる事になりますが, もしそれが 255.255.255.255 になっていたら, IP アドレスと IP チェックサムだけ変更すれば良ければの話になります. この方法はちょっとした変更ですが, 他の機構が今までのように, IP アドレスを固定して利用する場合に, カーネルが 不適切に設定されたインターフェイスに向けて, 正常でないパケットを 送り出してしまう可能性があります. 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか? 訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます. NAT on iij-pppをご覧ください. libalias を使っている時にゲームなどの類のものが動作しない理由は, 外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な) UDP パケットを送信しようとしているからです. 内側のマシンにこれらのパケットを送るべきかについて, packet alias ソフトウェアは関知しません. うまく動かすためには, 実行中のものが問題の発生している ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化 (``set log +tcp/ip'') してください. 行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを 通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に, そのパケットは破棄されるでしょう (それが問題なのです). これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを 停止してください. これを数回繰り返して port 番号が常に同じであるかを確認してみてください. 同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると, そのソフトウェアは動作するようになるでしょう. alias port proto internalmachine:port port ここで ``proto'' は ``tcp'' か ``udp'' であり, ``internalmachine'' はパケットを送りたいマシン, そして ``port'' はパケットのディストネーションの port 番号です. 上記のコマンドを変更せずに他のマシン上でそのソフトウェアを 使用できるようにはしたくないかもしれません. そして 同時に二つの内部のマシン上でそのソフトウェアを実行することは この質問の範囲を超えています. 結局, 外側の世界からは 内部ネットワーク全体がただ一つのマシンとして見えるのです. port 番号が常に同じとは限らない場合, さらに三つのオプションがあります. 1)libalias でサポートするようにし, 結果を送り付ける. 特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります (alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み, 内部の計算機のある特定のポートへの接続を開始するような命令が 外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する, という作業が含まれます. これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが 複数の計算機で動くようにできます. 2)プロクシを使う. アプリケーションが, 例えば socks5 をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを 避けるためにあるオプションです. 3)''alias addr''を使ってなんでもかんでも内部の計算機に向けて 流してしまう. これはちょっと無理矢理な解決法です. 有用な port 番号のリストはありませんか? まだ出来ていません. しかし, これは(関心を持って頂けるならば,) そういったリストにしていく予定です. それぞれの例にある internal は, ゲームで遊ぶマシンの IP アドレスに置き換えて下さい. Quake alias port udp internal:6112 6112 このように設定する代わりに, www.battle.net で Quake のプロキシーがサポートされているか 調べてもいいでしょう. Quake 2 alias port udp internal:27901 27910 Red Alert alias port udp internal:8675 8675 alias port udp internal:5009 5009 Half Life alias port udp internal:27005 27015 PCAnywhere 8.0 alias port udp internal:5632 5632 alias port tcp internal:5631 5631 FCS エラーって何? FCS とは Frame Check Sequence (フレームチェック シーケンス) の略です. 個々の ppp パケットには, 送受信するデータ が正しいかを調べるためのチェックサムが含まれています. 受信した パケットの FCS が正しくない場合は, そのパケットは廃棄され, HDLC FCS カウントが増やされます. HDLC エラーの数 は, show hdlc コマンドを使って表示できます. リンクの品質が悪かったり, シリアルドライバがパケットを取り こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する 必要はありません. 外付けモデムを使っている場合は, ケーブルが ちゃんとシールドされているかを確認してください. そうでない場合, FCS エラーの原因となる場合があります. 接続直後からリンクがフリーズし, 大量の FCS エラーが発生する 場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ さい. どうしてもソフトウェアフロー制御を使わなければならない場 合は, set accmap 0x000a0000 コマンドを使用して, ppp に ^Q と ^S をエスケープさせてください リモートホストが PPP プロトコルを使用してない場合も, 大量の FCS エラーが発生します. この場合はログをとりながら非同期で 接続し, ログインプロンプトやシェルプロンプトが送られて来てい ないか確認してください. ログファイルにリンクを終了した原因となるような記録がない場合は, リモートホスト(プロバイダ?)の管理者に, セッションを終了された 理由を尋ねてください. どれにも当てはまらない! どうしたらいいの? これまでの全ての質問に当てはまらない場合, 設定ファイル, ppp の実行方法, ログファイルの該当部分と netstat -rn コマンドの出力 (接続前と接続後) を含む, あなたの持っている全ての情報を freebsd-questions@FreeBSD.org メーリングリストや comp.unix.bsd.freebsd.misc ニュースグループへ 送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう. シリアル接続 訳: 一宮 亮 <ryo@azusa.shinshu-u.ac.jp>.16 November 1997. このセクションでは, FreeBSD でシリアル接続をする時の一般的な質問に答えます. PPP および SLIP については, のセクションを参照してください. どうやったら FreeBSD がシリアルポートを認識したことを知る事ができますか? FreeBSD のカーネルがブートする時, カーネルはその設定にしたがって, システムのシリアルポートを検出します. 起動時に表示されるメッセージをよく観察するか, 起動後に次のコマンドを実行する事によって確認できます. dmesg | grep sio ここに上に挙げたコマンドの出力例を示します. 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 とポートアドレスの設定の二つのシリアルポートをサポートしています. これらの設定があなたのシステムに合わない場合, またはモデムカードを追加した場合やカーネルの設定以上にシリアルポートを持っている場合は, カーネルを再構築 (リコンフィグ) してください. 詳しくは, のセクションを参照してください. どうやったら FreeBSD がモデムカードを認識したことを知ることができますか? 前の質問を参照してください. 2.0.5 にアップグレードしたら tty0X が見つからなくなってしまったのですが 心配ありません. ttydX に統合されました. ただ, 古い設定ファイルのすべてを更新する必要があります. どうやったら FreeBSD でシリアルポートにアクセスできますか? 3番目のポート sio2 (DOS では, COM3 と呼ばれます.) には, ダイヤルアウトデバイスとしては /dev/cuaa2, ダイヤルインデバイスとして /dev/ttyd2 があります. それではこの両者にはどのような違いがあるのでしょうか? まず, ダイヤルインの時には ttydX を使います. /dev/ttydX をブロッキングモードでオープンすると, プロセスは対応する cuaaX デバイスがインアクティブになるのを待ちます. 次に CD ラインがアクティブになるのを待ちます. cuaaX デバイスをオープンすると, シリアルポートがttydX デバイスによってすでに使われていないかどうかを確認します. もしこのポートが使用可能であれば, ポートの使用権を ttydX から ``奪い取る'' のです. また, cuaXX デバイスは CD ラインを監視しません. この仕組みと自動応答モデムによって, リモートユーザーをログインさせたり, 同じモデムでダイヤルアウトしたりすることができ, システムのあらゆるトラブルの面倒を見ることができるでしょう. マルチポートシリアルカードをサポートさせるにはどうしたらよいのでしょうか? 繰り返しになりますが, のセクションでは, あなたのカーネルの設定についての情報が得られるでしょう. マルチポートシリアルカードを使用するためには, カーネルの設定ファイルに, カードの持つそれぞれのシリアルポートに対応する sio の行を記述する必要があります. しかし, irq とベクターは一つのエントリにのみ記述してください. カード上のすべてのポートは一つの irq を共有しなければなりません. 一貫性を持たせるためにも, 最後のシリアルポートの所で irq を指定してください. また, COM_MULTIPORT オプションも付けてください. 次に示す例は, AST の 4 ポートシリアルカードを irq 7 で設定したものです. 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 を使ってください. ポートにデフォルトのパラメータを設定する事は出来ますか? ttydX デバイス (または cuaaX デバイス) は, アプリケーションのためにオープンする標準的なデバイスです. プロセスがそのポートをオープンする時, プロセスはデフォルトの端末 I/O 設定を取得します. これらの設定は次のコマンドで確認することができます. stty -a -f /dev/ttyd1 このデバイスに対する設定を変更した場合, その設定はデバイスをクローズするまで有効です. デバイスを再オープンした場合, それらの設定はデフォルトに戻ってしまいます. デフォルトの設定に変更を加えるために, ``初期設定'' デバイスをオープンし, 設定を修正することができます. 例えば, CLOCAL モード, 8 ビット, XON/XOFF フロー制御という設定を ttyd5 のデフォルトにしたい場合, 次のようにおこなってください. stty -f /dev/ttyid5 clocal cs8 ixon ixoff この設定をおこなうためのコマンドを記述するのに適切なファイルは, /etc/rc.serial です. これでアプリケーションがttyd5 をオープンした時に, これらの設定をデフォルトで取得します. しかし, こういったリンクによる設定は変更可能です. ``設定固定'' デバイスを調整してやることによって, アプリケーションによる設定の変更を禁止することができます. 例えば, ttyd5 の通信速度を 57600 bps に固定するには, 次のように行ってください. stty -f /dev/ttyld5 57600 これにより, アプリケーションは ttyd5 をオープンし, ポートの通信速度を変更しようとしますが, 通信速度は 57600 bps のままになります. 当然のことながら, 初期設定デバイスおよび, 設定固定デバイスは root のみが書き込みできるようになっていなければなりません. しかし, MAKEDEV スクリプトはデバイスエントリを作成する時に, このような設定は行いません. どのようにしたら モデム経由でダイヤルアップログインができるのでしょうか? つまり, インターネットサービスプロバイダーになりたいのですね. それにはまず, 1 台ないし複数の自動応答モデムが必要です. モデムには, キャリアーを検出した時には CD信号を出力し, そうでない場合には出力しないことが必要とされます. また DTR 信号が on から off になった時には, 電話回線を切断し, モデム自身をリセットしなければなりません. おそらく, RTS/CTS フロー制御を使うか, ローカルフロー制御をまったく使わないかのどちらかでしょう. 最後に, コンピュータとモデムの間は固定速度でなければなりません. ただ, (ダイヤルアップの発呼者に対して親切であるためには) こちらのモデムと相手側のモデムの間の速度を, モデム間で自動調整できるようにすべきでしょう. 多くあるヘイズコマンド互換モデムに対して, 次のコマンドはこれらの設定をおこない, その設定を不揮発性メモリーに保存します. AT &C1 &D3 &K3 &Q6 S0=1 &W MS-DOS のターミナルプログラムに頼らずに AT コマンドを送出するには, のセクション以下を参照してください. 次に, モデム用のエントリを /etc/ttys に作成しましょう. このファイルには, オペレーティングシステムがログインを待っているすべてのポートが記述されています. 以下のような行を追加してください. ttyd1 "/usr/libexec/getty std.57600" dialup on insecure この行は, 2 番目のシリアルポート (/dev/ttyd1) には, 57600 bps の通信速度でノンパリティ (std.57600 : これは /etc/gettytabに記述されています.) のモデムが接続されていることを示しています. このポートの端末タイプは ``dialup'' です. またこのポートは, ``on'' すなわちログイン可能であり, ``insecure'' これは root がこのポートから直接ログインするのは, 許可されていないということを意味します. このようなダイヤルインポートに対しては, ttydX のエントリを使用してください. これが一般的な, ターミナルタイプとして ``dialup'' を使う方法です. 多くのユーザーは, .profile や .login で, login 時の端末タイプが dialup であった場合には, 実際の端末タイプをユーザーに問い合わせるように設定しています. この例は, ポートが ``insecure'' でした. このポートで root になるには, 一般ユーザーとしてログインし, それから ``su'' を使って root になってください. もし, ``secure'' を指定したならば, 直接 root がそのポートからログインできます. /etc/ttys に変更を加えた後は, hungup もしくはHUP シグナルを init プロセスに送る必要があります. kill -HUP 1 この操作は init プロセスに /etc/ttys を再読み込みさせます. これにより, init プロセスは getty プロセスを すべての ``on'' となっているポートに起動させます. 次のようにして, ポートがログイン可能かを知ることができます. ps -ax | grep '[t]tyd1' ログイン可能であれば, 次のような出力が得られるはずです. 747 ?? I 0:00.04 /usr/libexec/getty std.57600 ttyd1 ダムターミナルを FreeBSD マシンに接続するにはどうしたらよいのでしょうか? もし, 他のコンピューターを FreeBSD の端末として接続したいのならば, お互いのシリアルポート間をつなぐヌルモデムケーブル [訳注: リバースケーブルもしくはクロスケーブルとも呼ばれます.] を用意してください. もし, 既製の端末を使う場合は, 付属するマニュアルを参照してください. そして, /etc/ttys を上と同じように変更してください. 例えば, WYSE-50 という端末を 5 番目のポートに接続するならば, 次のようなエントリを使用してください. ttyd4 "/usr/libexec/getty std.38400" wyse50 on secure この例は, /dev/ttyd4 ポートにノンパリティー, 端末タイプが wyse50, 通信速度が 38400 bps (std.38400 : この設定は, /etc/gettytab に記述されています.) の端末が存在しており, root のログインが許可されている (secure) であることを示しています. どうして tip や cu が動かないのですか? おそらくあなたのシステムでは tip や cu は uucp ユーザーか, dialer グループによってのみ実行可能なのでしょう. dialer グループは, モデムやリモートシステムにアクセスするユーザーを管理するために, 使用することができます. それには, /etc/group ファイルの dialer グループにあなた自身を追加してください. そうする代わりに, 次のようにタイプすることにより, あなたのシステムの全ユーザーが tip や cu を実行できるようになります. # chmod 4511 /usr/bin/cu # chmod 4511 /usr/bin/tip 私の Hayes モデムはサポートされていないのですが, どうしたらいいのでしょうか. 実際, tip のオンラインマニュアルは古くなっています. すでに, Hayes ダイアラーが実装されています. /etc/remote ファイルで, ``at=hayes'' と指定してください. Hayes ドライバは, 最近のモデムの新しい機能である, BUSY, NO DIALTONE, CONNECT 115200 などのメッセージを認識できるほど賢くはなく, 単に混乱を起こすだけです. tip を使う場合には, (ATX0&Wとするなどして) これらのメッセージを表示させないようにしなくてはいけません. また, tip のダイヤルのタイムアウトは 60 秒です. モデムのタイムアウト設定はそれより短くすべきであり, そうしないと tip は通信に問題があると判断するでしょう. ATS7=45&W を実行してください. 実際, デフォルトの tip は Hayes の完全なサポートをしているわけではありません. 解決方法は /usr/src/usr.bin/tip/tip の下のtipconf.hを変更することです. もちろん, これにはソース配布ファイルが必要です. ``#define HAYES 0'' と記述されている行を ``#define HAYES1'' と変更し, そして ``make'' and ``make install'' を実行します. これでうまく動作するでしょう. これらの AT コマンドを入力するには? /etc/remote ファイルの中で ``direct'' エントリを作ります. たとえばモデムが 1番目のシリアルポートである /dev/cuaa0に接続されている場合, 次のようにします: cuaa0:dv=/dev/cuaa0:br#19200:pa=none モデムがサポートする最大の bps レートを br フィールドに使います. そして tip cuaa0 を実行すると, モデムが利用できるようになります. /dev/cuaa0がシステムに存在しない場合は, 次のようにします: # cd /dev # ./MAKEDEV cuaa0 または root になって以下のように cu コマンドを実行します: # cu -l``line'' -s``speed'' ``line'' にはシリアルポートを指定します (例えば /dev/cuaa0). そして ``speed'' には接続する速度を指定します (例えば 57600). その後 AT コマンドを実行したら, ~.と入力すれば終了します. pn 機能の @ 記号が使えません! 電話番号 (pn) 機能の中での @ 記号は, tip に /etc/phones にある電話番号を参照するように伝えます. しかし @ の文字は /etc/remote のような設定ファイルの中では特殊文字となります. そこで, バックスラッシュを使ってエスケープを行います: pn=\@ コマンドラインから電話番号を指定するには? ``generic'' エントリと呼ばれるものを /etc/remote に追加します. 例えば, 次のようにします: 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'' のように利用できます. tip より cu を使いたい場合, cu の generic エントリを使います: 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 フィールドに設定します. tip は 1200 bps が正しいデフォルト値であるとみなすので, ``tip1200'' エントリを参照します. もちろん 1200 bps を使わなければならないわけではありません. ターミナルサーバを経由して複数のホストへアクセスしたいのですが. 毎回接続されるのを待って ``CONNECT <host>'' と入力するかわりに, tip の cm 機能を使います. 例えば, /etc/remote に次のようなエントリを追加します: 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/cua02:br#38400:at=hayes:du:pa=none:pn=5551234: これで, ``tip pain'' や ``tip muffin'' と実行すると pain や muffin のホストに接続することができ, ``tip deep13'' を実行するとターミナルサーバに接続します. tip を使ってそれぞれのサイトの複数の回線に接続できますか? これは大学に電話回線がいくつかあって, 数千人の学生が接続しようとする場合によくある問題です. あなたの大学のエントリを /etc/remote ファイルに作成して, pn のフィールドには \@ を使います: big-university:\ :pn=\@:tc=dialout dialout:\ :dv=/dev/cuaa3:br#9600:at=courier:du:pa=none: そして /etc/phones ファイルに大学の電話番号の一覧を書きます: big-university 5551111 big-university 5551112 big-university 5551113 big-university 5551114 tip は一連の電話番号を上から順に試みて, 最終的に接続できなければあきらめます. リトライを続けさせたい場合は, tip を while ループに入れて実行します. CTRL+P を 1回送るために 2度押す必要があるのはなぜ? CTRL+P は通常 ``force (強制)'' 文字であり, tip に次の文字がリテラルデータであることを伝えます. force 文字は「変数の設定」を意味する ~s エスケープによって, 他の文字にすることができます. ``~sforce=<single-char>'' と入力して改行します. <single-char> は, 任意の 1 バイト文字です. <single-char> を省略すると NUL 文字になり, これは CTRL+2 や CTRL+SPACE を押しても入力できます. いくつかのターミナルサーバで使われているのを見ただけですが, <single-char> に SHIFT+CTRL+6 に割り当てるのもよいでしょう. $HOME/.tiprc に次のように定義することで, 任意の文字を force 文字として利用できます: force=<single-char> 打ち込んだ文字が突然すべて大文字になりました?? CTRL+A を押してしまい, caps-lock キーが壊れている場合のために設計された ``tip'' の ``raise character'' モードに入ったのでしょう. 既に述べた ~s を使って, ``raisechar'' をより適切な値に変更してください. もしこれら両方の機能を使用しないのであれば, force 文字と同じ設定にすることもできます. 以下は CTRL+2 や CTRL+A などを頻繁に使う必要のある Emacs ユーザにうってつけの .tiprc ファイルのサンプルです: force=^^ raisechar=^^ ^ は SHIFT+CTRL+6 です. tip でファイルを転送するには? もし他の UNIX のシステムと接続しているなら, ~p (送信) や ~t (受信) でファイルの送受信ができます. これらのコマンドは, 相手のシステムの上で cat や echo を実行することで送受信をします. 書式は以下のようになります: ~p <ローカルのファイル名> [<リモートのファイル名>] ~t <リモートのファイル名> [<ローカルのファイル名>] この方法ではエラーチェックを行いませんので, zmodem などの他のプロトコルを使った方がよいでしょう. tip から zmodem を実行するには? まず始めに, FreeBSD の ports コレクション (lrzszと rzsz との, 2つの通信カテゴリーのプログラムのどちらか) をインストールします. ファイルを受信するには, リモート側で送信プログラムを起動します. そして, エンターキーを押してから ``~C rz'' (lrzsz をインストールした場合, ``~C lrz'') と入力すると, ローカル側へのファイルの受信が始まります. ファイルを送信するには, リモート側で受信プログラムを起動します. そして, エンターキーを押してから ``~C sz <files>'' (lrzsz をインストールした場合, ``~C lsz <files>'') と入力すると, リモート側へのファイルの送信が始まります. 設定が正しいのにもかかわらず, FreeBSD がシリアルポートを見付けられません. マザーボードやシリアルカードが Acer の UART チップを使った物の場合, FreeBSD の sio ドライバでは正しく検出する事が出来ません. この問題を解決するためには, www.lemis.com からパッチを入手してください. その他の質問 訳: 内川 喜章 <yoshiaki@kt.rim.or.jp>, 杉村 貴士 <sugimura@jp.FreeBSD.org>, 福間 康弘 <yasuf@big.or.jp>. 10 November 1997 - 8 May 1999. FreeBSD は Linux より多くのスワップ領域を消費するのはなぜですか? FreeBSD は Linux よりもスワップを多く使っているように見えるだけです. 実際にはそうではありません. この点における FreeBSD と Linux の主な違いは, FreeBSD はより多くのメインメモリを有効利用できるように するため, 完全にアイドルになったものやメインメモリ上の使われなくなった ページをスワップにあらかじめ積極的に移動しているということです. Linux では最後の手段としてページをスワップに移動させるだけという 傾向があります. このスワップの使い方は, メインメモリをより効果的に 使用することによってバランスが保たれています. FreeBSD はこのような状況では先手策を取りますが, システムが 本当に空き状態の時に, 理由も無くページをスワップしようと決めることはない ということに注意してください. したがって, 夜中に使わずにおいたシステムが 朝起きたときにすべてページアウトされているということはないのです. FreeBSD の実行フォーマットの a.out はどのようなものですか, a.out を使う理由, ELFを使う理由は何でしょう? FreeBSD の a.outフォーマットを理解するためには, まず UNIXにおいて現在 「優勢」な 3種類の実行フォーマットについて いくらか知っておく必要があります: a.out 最も古く 「由緒正しい」 unix オブジェクトフォーマットです. マジックナンバを含む短くてコンパクトなヘッダが先頭にあり, これがフォーマットの特徴とされています (参照 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 に応じた情報を 書き加える ユーティリティを提供しています. brandelf のマニュアルページ を参照してください. より多くの情報があります. FreeBSD は伝統的な立場をとり, 数多くの世代の BSD のリリース で試され, 実証されてきた a.outフォーマットを伝統的に使用しています. いつかは FreeBSDシステムでネイティブ ELF バイナリを作り, 実行することができるようになるかもしれませんが, 初期の頃 FreeBSD では ELF をデフォルトのフォーマットに変更するという動きは ありませんでした. なぜでしょうか? ところで Linux においては, ELF への苦痛をともなった変更は, その時に 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 で変えられないのですか? この場合, ``'' か ``'' のどちらかのオプションを ``'' と同時に使う必要があります. chmod と symlink のマニュアルページにはもっと詳しい情報があります. 注意 ``'' オプションは 再帰的に chmod を実行します. ディレクトリやディレクトリへのシンボリックリンクを chmod する場合は気をつけてください. シンボリックリンクで 参照されている単一のディレクトリのパーミッションを変更したい場合は, chmod をオプションをつけずにシンボリックリンクの名前の後ろにスラッシュ (``/'') をつけて使います. 例えば, ``foo'' がディレクトリ ``bar'' へのシンボリックリンクである場合, ``foo'' (実際には ``bar'') のパーミッションを変更したい場合にはこのようにします: chmod 555 foo/ 後ろにスラッシュをつけると, chmod はシンボリックリンク ``foo'' を追いかけてディレクトリ ``bar'' のパーミッションを変更します. login 名がいまだに 8文字に制限されているのはなぜですか UT_NAMESIZEを変更して全体を作り直せば十分で, それだけで うまくいくだろうとあなたは考えるかもしれません. 残念ながら多くのアプリケーションやユーティリティ (システムツールも含めて) は小さな数値を構造体やバッファなどに 使っています ( 必ずしも "8" や "9" ではなく, "15" や "20" などの変った値を使うものもあります). (固定長のレコードを期待 するところで可変長レコードになるために) 台無しになった ログファイルを得ることになるということだけでなく, Sun の NIS の クライアントの場合は問題が起きますし, 他の UNIX システムとの関連 においてこれら以外の問題も起きる可能性があります. しかし, FreeBSD 3.0 以降では 16文字となり, 多くのユーティリティ のハードコードされた名前の長さの問題も解決されます. 実際には システムのあまりに多くの部分を修正するために, 3.0 になるまでは 変更が行われませんでした. それ以前のバージョンでは, これらの問題が起こった場合に, 問題 を自分自身で発見し, 解決できることに絶対的な自信がある場合は /usr/include/utmp.h を編集し, UT_NAMESIZE の変更にしたがって, 長いユーザ名を使うことができます. また, UT_NAMESIZE の変更と一致するように /usr/include/sys/param.h の MAXLOGNAME 更新しなくてはなりません. 最後に, ソースからビルドする場合は /usr/include を毎回 アップデートする必要があることを忘れないように! /usr/src/.. 上のファイルを変更しておいて置き換えましょう. FreeBSD 上で DOS のバイナリを動かすことはできますか? はい, 3.0 からは, 統合と改良が重ねられた BSDI の rundos DOS エミュレーションサブシステムを使ってできるようになりました. 今なお続けられているこの努力に興味を持って参加していただけるなら The FreeBSD emulation discussion list へメールを送ってください. 3.0 以前のシステムでは, pcemu という巧妙なユーティリティが ports コレクションにあり, 8088 のエミュレーションと DOS の テキストモードアプリケーションを動かすに十分な BIOS サービスをおこないます. これは X ウィンドウシステムが必要です (XFree86 として提供されています) ``sup'' とは何で, どのようにして使うものなのでしょうか? SUP とはソフトウェアアップデートプロトコル (Software Update Protocol) で CMU で開発ツリーの同期のために開発されました. 私たちの中心開発ツリーをリモートサイトで同期させるために 使っていました. SUP はバンド幅を浪費しますので, 今は使っていません. ソースコードの アップデートの現在のおすすめの方法は ハンドブックの CVSup の項 にあります. FreeBSD をクールに使うには? Q. FreeBSD を動かす時に温度測定をおこなった人はいますか? Linux は dos よりも温度が下がるということは知っていますが, FreeBSD についてはこのようなことに触れたものを見たことはありません. 実際熱くなっているように見えます. A. いいえ. 私たちは 250 マイクログラムの LSD-25 をあらかじめ 与えておいたボランティアに対する目隠し味覚テストを大量に おこなっています. 35% のボランティアは FreeBSD はオレンジのような味 がすると言っているのに対し Linux は紫煙のような味わいがある と言っている人もいます. 私の知る限り両方のグループとも温度の 不一致については触れていません. この調査で, 非常に多くの ボランティアがテストをおこなった部屋から不思議そうに出てきて, このようなおかしな結果を示したことに私たちは当惑させられました. 私は, ほとんどのボランティアは Apple にいて彼らの最新の 「引っかいて匂いをかぐ」 GUI を使っているのではないかと 考えています. 私たちは奇妙な古い仕事をしているのでしょう! 真面目に言うと, FreeBSD や Linux は共に ``HLT'' (停止) 命令をシステムのアイドル時に使い, エネルギーの消費を押えて いますので熱の発生も少なくなります. また, APM (automatic power management) を設定してあるなら FreeBSD は CPU をローパワーモード にすることができます. 誰かが私のメモリカードをひっかいているのですか?? Q. FreeBSDでカーネルのコンパイルをしている時にメモリから 引っかいているような奇妙な音が聞こえるようなことはあるのでしょうか? コンパイルをしている時 (あるいは起動時にフロッピドライブを 認識した後の短い間など), 奇妙な引っかくような音がメモリカードの あたりから聞こえてきます. A. その通りです. BSDのドキュメントでしばしば「デーモン」に ついて述べられている理由がわかるでしょう. しかし多くの人は本当の 事については触れていません. 非物質的な存在があなたのコンピュータ にあるのです. メモリからの引っかいたような音は, 実際に色々な システム管理タスクの扱いをいかに最善なものにするかという内容を交わす, デーモンたちのかん高いささやきなのです. 「雑音」があなたに DOS プログラムの ``fdisk /mbr'' を使ってうまくささやきを取り除かせようとしているように聞こえても, 彼らは逆にそうすることをやめさせようとしているのかもしれません. 本当は内蔵スピーカからのビル ゲイツの悪魔的な声が あなたに影響を与えているのかもしれません. 実行するのは止めましょう, そして振り返ってはいけません! BSD の守護神 (daemon) の力により, 繰り返しあなたのマシンを支配下に置こうとし, あなたの魂を 無限地獄に突き落そうとする DOSと Windows の双子の悪鬼 (demon) の 影響から自由になりましょう. 選択の機会は与えられました. 私自身はこの引っかくような音が 聞こえていたことを嬉しく思っています. 'MFC' とはどういう意味ですか MFC とは 'CURRENT との合流(Merged From -CURRENT.)'の 頭文字をとったものです. CVS ログで CURRENT から STABLE ブランチ への合流を示します. 'BSD' とはどういう意味ですか この言葉は, 仲間うちだけに分かる隠語で何とかという意味です. 文字どおりに訳すことはできませんが, BSD の訳は「F1 のレーシング チーム」か「ペンギンはおいしいスナック」, あるいは「俺たちゃ Linux より洒落は利いてるぜ」とかそのへんだと言っておけばおっけー でしょう. :-) 閑話休題. BSD とは, Berkeley CSRG (コンピュータシステム 評議会) が彼らの UNIX の配布形態の名前として当時選んだ 'Berkeley Software Distribution' の略です. ひとつの電球を取り替えるのに, 何人の 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人, パッチが 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人. 以下は Nik Clayton による追記: これには爆笑しました. それからわたしは考えました. 「ちょっと待てよ, この リストのどこかに『これを文書にまとめるのに 1人』というのが あってもいいんじゃないか?」 それからわたしは悟りを開いたのです :-) まじめな FreeBSD ハッカーだけの話題 訳: 岩崎 満 <iwasaki@jp.FreeBSD.org>.8 November 1997. SNAP とか RELEASE とかは何? 現在, FreeBSD の CVS リポジトリ には, 三つのアクティブ/準アクティブなブランチがあります. RELENG_2_2 通称 2.2-stable または "2.2 branch" RELENG_3 通称 3.x-stable または "3.0 branch" HEAD 通称 または 4.0-current HEAD は他の二つと違って実際のブランチ tag ではなく, 「current, 分岐していない開発本流」のための単なるシンボリック な定数です. 私たちはこれを と呼んでいます. 現在, は 4.0 の開発本流であり, 3.0-stable ブランチ, つまり RELENG_3 は 1999年1月に から分岐しています. 2.2-stable ブランチ, RELENG_2_2 は 1996年11月に -current から分岐しました. 2.1-stable ブランチ, RELENG_2_1_0 は 1994年9月に -current から分岐しました. このブランチは完全に保守されなくなっています. 自分用のカスタムリリースを構築するには? リリースを構築するには三つのことが必要です: まず, vn ドライバが組み込まれたカーネルを実行させている必要があります. 以下をカーネルコンフィグレーションファイルに追加し, カーネルを作り直してください: pseudo-device vn #Vnode driver (turns a file into a device) 次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには CVSUP が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります: *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 リポジトリ全体をコピーします... 最後に, ビルド用にかなりの空き領域を用意する必要があります. そのディレクトリを /some/big/filesystem として, 上の例で CVS リポジトリを /home/ncvs に置いたものとすると, 以下のようにしてリリースを構築します: setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs cd /usr/src/release make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release 処理が終了すると, リリース全体が /some/big/filesystem/release に構築され, 完全な FTP インストール用の配布物が /some/big/filesystem/release/R/ftp に作成されます. -current 以外の開発ブランチの SNAP を自分で構築したい場合は, RELEASETAG=SOMETAG を上の make release のコマンドラインに追加します. 例えば, RELEASETAG=RELENG_2_2 とすると最新の 2.2-STABLE snapshot が構築されます. カスタムのインストールディスクを作るにはどうすればいいのですか? /usr/src/release/Makefile のいろいろなターゲットとして インストールディスク, ソース, バイナリアーカイブを作る完全な処理を 自動的におこなうようになっています. Makefile に十分な情報があります. しかし, 実行には ``make world'' が必要で, 多くの時間とディスクの容量が必要です. ``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが. ええ, それが一般的な考え方です. 名前が示しているように ``make world'' はすべてのシステムのバイナリを一から作り直しますので, 結果としてクリーンで一貫性のある環境を得ることができます (これがそれだけ長い時間がかかる理由です). 環境変数 DESTDIR を ``make world'' や ``make install'' を実行する時に定義しておくと, 新しく作られたバイナリは ${DESTDIR}を root とみなした ディレクトリツリーにインストールされます. あるでたらめな共有ライブラリの変更やプログラムの再構築によって ``make world'' は失敗することもあります. システムブート時に ``(bus speed defaulted)'' とメッセージが出ます. アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に バスアクセス速度の設定をおこなうことができます. 以前のバージョンの 1542 ドライバは使用可能な最大の速度を求めてアダプタを その設定にしようとしました. これは特定のユーザのシステムでは 問題がある事がわかり, 現在ではカーネルコンフィグオプションに ``TUNE_1542'' が加えられています. これを使用すると, これが働くシステムではディスクが速くなりますが, データの衝突が起きて速くはならないシステムもあるでしょう. インターネットアクセスに制限があっても current を追いかけられますか? はい, CTM システム を 使って ソースツリー全体のダウンロードをおこなわずに追いかけることができます. どのようにして配布ファイルを 240kバイトに分割しているのですか? 比較的新しい BSDベースのシステムでは split に任意のバイト境界で 分割する ``'' オプションがあります. 以下は /usr/src/Makefile からの例です. bin-tarball: (cd ${DISTDIR}; \ tar cf - . \ gzip --no-name -9 -c | \ split -b 240640 - \ ${RELEASEDIR}/tarballs/bindist/bin_tgz.) 私はカーネルに拡張をおこないました. 誰に送ればいいですか? ハンドブックの「貢献の仕方 (Contributing to FreeBSD)」の章 を参照してください. あなたのアイディアに感謝します! PnP ISA カードの検出と初期化はどのようにおこなうのですか? 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 bits はいくらか過剰です. 下位の 32 bits はシリアル番号, イーサネットアドレスなどの ボードを特定するものです. ベンダは上位 32 bits が異なっていない のであれば下位 32 bits が同一である 2枚目のボードを製造することは ありません. したがって, 同じタイプの複数のボードをマシンに いれることができ, この場合でも 64 bits 全体ではユニークです. 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 は 3.0 スナップショット リリースが現在 ftp://ftp.freebsd.org/pub/FreeBSD/alpha から入手できます. ALPHA への移植版が現在動く機種は増えつつあり, その中には AlphaStation, AXPpci, PC164, Miata そして Multia といったモデルが含まれています. この ALPHA への移植版はまだ完全なリリースとはみなされていません. システムインストールツール一式や CDROM のインストールメディアの 配布が提供され, 適度な数の ports や packages が動くようになって からになるでしょう. 現在のところ FreeBSD/AXP はベータクオリティのソフトウェアと みなすべきです. 現状についての情報を得るには <freebsd-alpha@FreeBSD.ORG> に参加してください. その他に FreeBSD の SPARC アーキテクチャへの移植があります. プロジェクトへの参加に興味がある方は <freebsd-sparc@FreeBSD.ORG> に参加してください. 新しいアーキテクチャに関する一般的な議論については <freebsd-platforms@FreeBSD.ORG> へ参加してください. デバイスドライバを開発したので, メジャー番号が必要です. これは, 開発したドライバを公開するかどうかに依存します. 公開するのであれば, ドライバのソースコード, files.i386 の変更, コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する MAKEDEV のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの 問題により公開できない場合は, キャラクタメジャー番号 32 もしくは ブロックメジャー番号 8 が, このような目的のために予約されています. これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を <freebsd-hackers@FreeBSD.ORG> に流して頂けると助かります. 代替のディレクトリ配置ポリシー 現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い たものから全く変更されていません. 私は当初の配置ポリシーを, オリ ジナルの fast filesystem のために書き, まったく改定していません. このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき ましたが,お気づきの方もいる通り find の動作には不適切です. ほと んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます) によって作られたアーカイブからレストアして作成されます. この際, ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ 優先検索を行うには考え得る限り最悪の状態になります. もし作成する ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 / シリンダグループ数)個のディレクトリをシリンダグループごとにまと めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用 いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用 したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む という手順が使えるでしょう. とにかく私の結論は, そろそろ実験 を始めて見る時期だろうということです. カーネルパニックを最大限に利用する [この節は, freebsd-current に Bill Paul が投稿したメールを, Dag-Erling Coïdan Smørgrav が校正し,括弧内のコ メントを追加して引用したものです. ] From: Bill Paul <wpaul@skynet.ctr.columbia.edu> Subject: Re: the fs fun never stops To: ben@rosengart.com Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT) Cc: current@FreeBSD.ORG [<ben@rosengart.com> が以下のパニックメッセージを 投稿しました.] > 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 カーネルを使っているのであれば, 他の人間が問題の ある関数について追試をすることができますが, カスタマイズされたカー ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない のです. 何をすれば良いのでしょう？ 命令ポインタ値をメモします. 0x8: という部分は今回必 要ありません. 必要なのは 0xf0xxxxxx という部分です. システムがリブートしたら, 以下の操作を行います: % nm /kernel.that.caused.the.panic | grep f0xxxxxx ここで, f0xxxxxx は命令ポインタ値です. カーネルシンボルの テーブルは関数のエントリポイントを含み, 命令ポインタ値は, 関数内部のある点であり, 最初の点ではないため, この操作を行っても 完全に一致するものが表示されない場合もあります. この場合は, 最後の桁を省いてもういちどやってみてください. このようになりま す: % nm /kernel.that.caused.the.panic | grep f0xxxxx これでも一致しない場合は, 桁を減らしながら何らかの出力があるま で繰り返してください. 何か出力されたら, それがカーネルパニック を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける 正確な方法ではありませんが, 何もないよりましです. このようなパニックメッセージを投稿している人はよく見掛けますが, このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数 とつき合わせて調べている人はまれです. パニックの原因を突き止める最良の方法は, クラッシュダンプをとり, gdb(1) でスタックトレースを行うことです. もちろん -current で gdb(1) がちゃんと動いていればですが (私は動くことを保証 できません. ELF 化された gdb(1) はカーネルクラッシュダンプを 正しく扱えないと言っている人がいました. 3.0 がβテストを終える前, に調べなければいけません. さもないと CD 出荷後に大顰蹙を買うことに なります). どっちにしろ, 私は普通以下のようにします. カーネルコンフィグファイルを作ります. カーネルデバッガが 必要そうであれば options 'DDB' を加えても良いです(私は永久ルー プが起こっていそうな場合に, ブレークポイントを設定するのに使って います). config -g KERNELCONFIG としてビルドディレクトリを設 定します. cd /sys/compile/KERNELCONFIG; make カーネルのコンパイルが終了するのを待ちます. cp kernel kernel.debug strip -d kernel mv kernel /kernel.orig/ cp kernel / reboot [注: 現在 FreeBSD 3.x kernel はデフォルトで ELF 形式となっており, strip -d の代りに strip -g を使う必要があります. 何らかの理由でまだ a.out 形式の kernel を使っている場合は, strip -aout -d を使ってください. ] 全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は ありません. をつけてコンパイルされたカーネルは, 簡単に 10MB 近くの大きさになってしまいます. こんな大きなカーネル を実際にブートする必要はありません. この大きなカーネルイメージは 後でgdb(1)を使うときにのみ必要です(gdb(1) がシンボル テーブルを必要とするため). シンボルを含んだカーネルのコピーを保 存 しておき, strip -d を使ってシンボルを除いたカーネルを作 成して ブートします. 確実にクラッシュダンプをとるには, /etc/rc.conf を編 集して dumpdev を使用しているスワップパーティションに指定す る必 要があります. こうすると rc(8) スクリプトから dumpon(8) コマンドが実行されクラッシュダンプ機能が有効にな ります. 手動で dumpon(8) コマンドを実行してもかまいませ ん. パニックの後, クラッシュダンプは savecore(8) コマンドを 使用して取り出すこと ができます. dumpdev が /etc/rc.conf で設定されていれ ば, rc(8) スクリプト から savecore(8) が自動的に実行され, クラッシュダンプを /var/crash に保存します. 注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ シュ ダンプが生成されることになります. /var/crash に十 分な空き 容量があることを確認してください. 手動で savecore(8) を実行す れば, もっと空き容量のあるディレクトリ にクラッシュダンプを保存でき ます. options MAXMEM=(foo) と いう行をカーネルコンフィグファイ ルに追加することで, カーネルの メモリ使用量を制限できます. たとえば 128MB のメモリがある場合も, カーネルのメモリ使用量を 16MB に制限し クラッシュダンプのサイズ も 128MB ではなく 16MB にすることができます. クラッシュダンプを取り出せたら, 以下のように gdb(1) を使っ てスタックトレースをとります: % gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0 (gdb) where 必要な情報が 1 画面に収まらないことも多いので, できれば script(1) を使って出力を記録します. strip していないカーネ ル イメージを使うことで, 全てのデバッグシンボルが参照でき, パニッ ク の発生したカーネルのソースコードの行が表示されているはずです. 通常, 正確なクラッシュへの過程を追跡するには, 出力を最後の行から 逆方向に読まなければなりません. また gdb(1) を使って, 変数 や 構造体の内容を表示させ, クラッシュした時のシステムの状態を調 べられ ます. もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる 環境にあれば, gdb(1) をリモートデバッグに使うこともできます. リモートデバッグを使うと, あるコンピュータ上の gdb(1) を使っ て, 別のコンピュータのカーネルをデバッグできます. ブレークポイン トの設 定, カーネルコードのステップ実行など, ふつうのプログラム のデバッグ と変わりません. コンピュータを 2 台並べてデバッグする チャンスには, なかなか恵まれないので, 私はまだリモートデバッグを 試したことはあり ません. [Bill による注: DDB を有効にしていてカーネルがデバッガに 落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ クを 起こしクラッシュダンプさせることができます. パニックの途中 で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ ば, クラッシュダンプを最後まで実行させられます.] dlsym() が ELF 実行形式では動作しなくなります! ELF のツール類は, デフォルトでは実行形式の中に定義されている シンボルをダイナミックリンカから見えるようにはしません. このため, dlopen(NULL, flags) を呼び出して得られた ハンドルに対して dlsym() で探索を行っても, こういった シンボルを見つけられません. もし, あなたがプロセスの中心にあたる実行形式の中にある シンボルを探索したければ, ELF リンカ に オプションを 付けて実行形式をリンクする必要があります. カーネルアドレス空間を大きくしたり、小さくするにはどうしたら良いのですか? カーネルアドレス空間は, FreeBSD 3.x 上で 256MB, FreeBSD 4.x 上で 1GB がデフォルトになっています. 負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は, 256MB では足りないことに気付くかも知れません. では, アドレス空間を大きくするにはどうしたら良いのでしょうか? それには, 二つの段階を踏みます. まず, より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります. 次に, カーネルはアドレス空間の先頭にロードされるため, アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります. 最初の段階は, src/sys/i386/include/pmap.h にある NKPDE の値を増加させることで行ないます. ここに 1GB のアドレス空間にするために, どのようにすれば良いかを示します. #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 になります. そして, src/sys/i386/conf/Makefile.i386 にある LOAD_ADDRESS に, 今計算した値を入れます. また, 次のように src/sys/i386/conf/kernel.script のセクションの始めの方にある ロケーションカウンタにも同じ値を入れて下さい. 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 し直してカーネルを再構築して下さい. おそらく, ps(1), top(1) などに不具合が出るでしょう. それらを正常にするために, make world (もしくは, 変更した pmap.h を /usr/include/vm/ にコピーした後に, libkvm, ps および top を 手動で再構築すること)を行なうべきです. 注意: カーネルアドレス空間の大きさは, 4 メガバイトの倍数である必要があります. [David Greenman による補足: カーネルアドレス空間は 2 の乗数である必要があると思いますが, それが確かなことかどうかははっきりしていません. 昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため, 少なくとも 256MB の粒度であることが想定されていたと思います.] 謝辞 訳: こがよういちろう <y-koga@ccs.mt.nec.co.jp>.10 November 1997. この FAQ について問題を見つけたり, 何か登録したい場合は, <FAQ@FreeBSD.ORG> までメールを送ってください. フィードバック してくれるみなさんには感謝感謝なのです. みなさんに手伝ってもらわないとこの FAQ はよくなりませんから! FreeBSD Core Team Jordan Hubbard たまに起こす FAQ の並べ替えや更新の発作 Doug White freebsd-questions メーリングリストでの義務を超えたサービス Joerg Wunsch Usenet (NetNews) での義務を超えたサービス Garrett Wollman ネットワーク節の執筆と文書整形 Jim Lowe マルチキャストについて Peter da Silva FreeBSD FAQ タイピング機械奴隷 FreeBSD チーム 不平を言ったり, うめいたり, 情報提供してくれたり あと, 抜けてしまった他の方々に対して, 謝罪と心からの感謝を捧げます! FreeBSD FAQ 日本語化について FreeBSD 日本語ドキュメンテーションプロジェクトは, FreeBSD 関係の日本語 ドキュメントが少ないことを嘆いた数人の FreeBSD ユーザの提唱によって 1996年2月26日にスタートし, FreeBSD 日本語ハンドブックの作成をはじめとした 活動をおこなってきました. FreeBSD FAQ の日本語化については, オリジナルの翻訳作業だけでなく 日本国内に固有の話題についても広く情報を集め, 日本の FreeBSD ユーザにとって 真に有益なドキュメントを提供しようと考えています. オリジナルの FAQ は日毎に更新されており, 私たちもまた これに追い付くために作業を続けていきます. もちろん, 新しいメンバも大歓迎です. 日本語翻訳版について, 何かお気づきの点がありましたら, FreeBSD 日本語ドキュメンテーションプロジェクト <doc-jp@jp.FreeBSD.ORG> までご連絡ください. また, もし私たちの作業を手伝ってくれるなら, FreeBSD 日本語ドキュメンテーションプロジェクトのページ をご覧の上, 是非参加してください. 翻訳者 (五十音順) 有村 光晴 <arimura@jp.FreeBSD.org> 一宮 亮 <ryo@azusa.shinshu-u.ac.jp> 岩崎 満 <iwasaki@jp.FreeBSD.org> 内川 喜章 <yoshiaki@kt.rim.or.jp> くりやま <kuriyama@opt.phys.waseda.ac.jp> こがよういちろう <y-koga@ccs.mt.nec.co.jp> 今野 元之 <motoyuki@jp.FreeBSD.ORG> 杉村 貴士 <sugimura@jp.FreeBSD.org> 中井 幸博 <nakai@mlab.t.u-tokyo.ac.jp> にしか <nishika@cheerful.com> 花井 浩之 <hanai@jp.FreeBSD.org> はらだ きろう <kiroh@jp.FreeBSD.org> 広瀬 昌一 <shou@kt.rim.or.jp> 福間 康弘 <yasuf@big.or.jp> むらたしゅういちろう <mrt@mickey.ai.kyutech.ac.jp> 山下 淳 <junkun@esys.tsukuba.ac.jp> 査読者 (五十音順) 浅見 賢 <asami@FreeBSD.ORG> 岩崎 満 <iwasaki@jp.FreeBSD.org> 内川 喜章 <yoshiaki@kt.rim.or.jp> 大橋 健 <ohashi@mickey.ai.kyutech.ac.jp> くりやま <kuriyama@opt.phys.waseda.ac.jp> 今野 元之 <motoyuki@jp.FreeBSD.ORG> 佐伯 隆司 <saeki@jp.FreeBSD.org> 杉村 貴士 <sugimura@jp.FreeBSD.org> 花井 浩之 <hanai@jp.FreeBSD.org> 浜田 直樹 <nao@tom-yam.or.jp> はらだ きろう <kiroh@jp.FreeBSD.org> 日野 浩志 <hino@ccm.cl.nec.co.jp> 檜山 卓 <shiyama@intercity.or.jp> 広瀬 昌一 <shou@kt.rim.or.jp> むらたしゅういちろう <mrt@mickey.ai.kyutech.ac.jp> 若井 久史 <earth@hokuto7.or.jp> 作業環境整備 (五十音順) 一宮 亮 <ryo@azusa.shinshu-u.ac.jp> 岩崎 満 <iwasaki@jp.FreeBSD.org> 下川 英敏 <simokawa@jp.FreeBSD.org> 鈴木 秀幸 <hideyuki@jp.FreeBSD.org>