FreeBSDセットアップ「つまみぐい」その1 ハードウェアの設定と準備 メモしておくべき情報 ハードウェアの対応状況は http://www.jp.freebsd.org/www.FreeBSD.org/doc/ja_JP.eucJP/books/handbook/install-hw.html を参照すればよいが、そこそこメジャーな製品なら、発売直後とかでない限り、 たいてい対応しているはず。 モニタの対応周波数だけは設定をメモしておく必要があるが、ほとんどの場合 メーカーのウェブページで仕様が公開されているし、Windowsが入っている マシンなら、ファイル名を指定して実行＞DxDiag＞情報をすべて保存ボタン と選択すれば、詳細なハードウェア情報が得られる。 ネットワーク ルーターはぜひあった方がよい（セキュリティが段違いに向上する）。 LANカード（NIC）を複数インストールした場合には、どのカードに 何がつながっているのか覚えておく。 ディスクの領域確保に取り掛かる前に http://nobumasa-web.hp.infoseek.co.jp/boot_hdd.html http://plaza.across.or.jp/~kusunoki/Faq_main.htm http://www.h4.dion.ne.jp/~katsuwo/freebsd-install-4.9/man-b-07.html などを熟読してブートとパーティションについて十分理解し、好みのツールを入手する。 # 筆者は、MBMというブートローダーを愛用している。 # http://elm-chan.org/fsw/mbm/mbm.html バックアップが必要なファイルについては、適宜バックアップをすることを忘れない。 動きの怪しいハードディスクを使う場合、インストール予定の領域全体を、 いったん削除＞基本領域として確保＞完全に初期化 # Win9x系の起動ディスクからなら、 # A:\>fdisk /mbr＞Fdiskで空きスペースを作る＞一応リブート # Fdiskで基本領域確保＞リブート # A:\>format ドライブ名（ディスクが空でないとformat c: ができないことがある） # A:\>sys ドライブ名（これはあまり意味がないがおまじないのつもりで） したうえで、すでに動いているシステム（もしくは起動ディスクで 起動したDOSなど）から、きちんと認識されていて読み書きが可能であることを 確認しておく。その上で、すでに動いているシステムからスキャンディスクを 実行して、改めてFreeBSD用の領域確保を行う。 # できれば、FreeDosなり何なりを入れてみて、きちんと起動することを確認。 # MBRに手を入れていた場合、初期化されてしまうので忘れずに復旧しておく。 基本領域の確保とブート http://nobumasa-web.hp.infoseek.co.jp/multi_boot/other_os.html#freebsd http://hiiro-sou.hp.infoseek.co.jp/unix/freebsd/1-3.html なにはなくとも、まずはディスクスライス（基本領域）の確保が必要になる。 このスライスという仕組みは非常に優秀で、ほぼ何も考えずに「空いているところ」に 作成してしまってもほとんど問題は起きないし、他のパーティションにインストール されているOSの動作にもほとんど影響を与えない（ごく古いバージョンのものを除く）。 例外は「Linuxから認識可能な拡張領域がFreeBSDのスライスよりも前にある場合は、 Linuxの起動時にスライスを隠しておく必要がある」ことくらいではないかと思われる。 基本領域でさえあれば、第1ハードディスク以外であっても問題がない。 ブートについても、領域がアクティブになってさえいればほぼ問題なく起動できる。 ジオメトリの変化にも強く、IDEプライマリマスターに接続なしの状況で IDEプライマリスレーブのディスクにインストールした後、IDEプライマリマスターに ディスクを増設しても、何事もなかったかのように起動する。 # 上記は、FreeBSDにとってのデバイス名、つまりハードウェアの物理的な # 接続位置（IDEのプライマリスレーブとか）とディスク内でのスライスの番号が # 変わらなかった場合（詳しくはその3参照）。これが変わってしまうと、さすがに # boot -s （シングルユーザーモード）で起動してから/etc/fstabを # 書き換えてやらないとダメ（試したことはないが）。 デフォルトでブートローダーが付属しているが、特殊な仕様のものではないので、 別にこれを使わなくてはいけないわけではない。IBM-PC（というかMS-DOS）標準の ブートローダー（Windowsの起動ディスクからFdisk /MBR で入るもの）でも もちろん起動する（DOSのFdiskからはFreeBSDスライスのアクティブ属性を 変更できないので、マルチブートするならもう少し高性能なブートローダーが欲しいが） ようするに、必要条件は「（起動時に）アクティブな基本領域」であることのみで、 その他はまったくの自由、ただしLinuxとのマルチブートには少々注意、という ことになる。 パーティション パーティション構成については、インストーラーに任せっぱなしでも問題ない。 自動設定を使った場合、インストーラーのバージョンによって割り当て量が 異なる（新しいものほど、多めに容量を確保するようだ）が、/と/varと/tmpに 「たいていの環境で問題なく動く程度」の容量を、swapにメインメモリの2倍を 割り当てた後で、残りを/usrに割り当てる。 上記のパーティションに書き込まれるデータについて感覚的な説明をしておくと、 /：システムの中枢データ（パーティションを割り当てていないディレクトリすべて） swap：メインメモリから追い出されたデータ /var：頻繁に書き込むが、すぐ消すとは限らないデータ（ログとか受信メールとか） /tmp：書き込んだあとすぐ消してしまうデータ（インストール時の一時ファイルとか） /usr：システムの中枢と関係のないデータ全般（/usr/localやら/usr/homeやら） が入っている。 /にはOSの核の核であるカーネルが配置されているので、/にマウントする パーティションは、（少なくともデフォルトでは）速度は遅いが安全確実に 動くようにオプションが設定されいる。 が、/以下にはパーティションを割り当てなかったすべてのディレクトリが 配置されるので、/binやら/sbinやら/etcやら/bootやら/rootやらといった、 システムの中枢データが詰まったディレクトリ以外は、他のパーティションに 追い出しておくべきだ、ということになる（安全優先の設定なので、読み書きの 激しいファイルを置いてもパフォーマンスが上がらないし）。 ただし、シングルユーザーモードでログインした直後は/以外のパーティションが 見えないので、このときに必要になるディレクトリは追い出さない。 また「容量がどんどん増えていく（あるいは入れ替わる）データ」と 「一時的にしか利用しないデータ」は別にしておいた方が扱いが楽になる。 ということで、まず/varと/tmpを追い出した上で、/に置くべきでない データをまとめて/usrに詰め込んで別パーティションに追い出すことになる。 # ここまでが必須の設定。シンボリックリンクとディレクトリの関係を # よく理解していない場合、これ以上の設定はしない方が無難。 次いで/usr配下について考える。たいていは/usrで1つのパーティションでも 問題ないのだが、/usr/binや/usr/sbinなどが置いてあることもあり、極端に 読み書きが激しかったり容量を圧迫したりするデータは、別パーティションに 追い出しておいてもよい。 具体的には、ソフトウェアをバリバリインストールする人は/usr/local、portsを ガンガン更新する人は/usr/ports、ゲームをずんどこ入れ替える人は/usr/games/ あたりを追い出しておくとよいだろう。その他、Xメインで使うなら/usr/X11R6を 切り離しておくのも一案だし、spamなどでパンパンになる可能性のある/usr/mailを 隔離しておいたり、/usr/homeを分けておくのもよいだろう（マルチユーザーで 使うなら必須）。いずれにせよ、用途によって使い方が変わってくるので、 必要に応じて対応すればよい。 ただし、（スライス1つにつき）最大で8分割までしかできないので、すでに 分割の決まっている/と/varと/tmpと/usrの他には4つまでしか領域が 確保できないことになる。 # シンボリックリンクをうまく使えば、かなり細かく分けても8つあれば足りるが、 # あえて優先度の高いものを挙げるなら、/usr/homeと/var/mailだろうか。 # 基本領域を複数確保できるなら、16分割でも24分割でも可能。 ディスクの容量 /と/varと/tmpはインストーラーが自動設定してくれる量（おそらく合計で 1GB前後）で問題ない。心配性でかつディスク容量が余っている人なら、 自動設定量の2倍程度確保してしまえば鉄板。 /usrは、gnomeやKDEなどのヘビー級ソフトウェアを入れたとしても （/usr/home/以外で）5GBもあれば問題はなく、ディスクが余っているなら、 10GB程度用意してやれば（portsを全部インストール、などとやらない限り） ディスク容量の概念自体を忘れて利用できるだろう。 試しに、新規インストール直後にその2で紹介するソフトウェアと gmone2（とgnome2の依存環境全部と日本語環境）をportsで入れたら /usrの合計が1.5GBくらいだった。これにMozzilaだのOOoだのを突っ込んでも 2GBくらいだろう。 # 各パッケージは2004年秋時点での最新バージョン。 同様にKDE3をpkg_addで入れてみたところ、2GBくらいだった。さらにMozzilaと OOoとsambaとWineを突っ込んでみたら、ほぼ2.5GBだった（Kofficeなど、 必要のないソフトウェアをかなり入れてるので、実際はもう少し減らせる）。 最小構成インストールから、その4で紹介する手順でXまでを入れたところで500MB、 kde-liteと日本語環境まで入れて（その4で紹介する手順すべて）1GBくらい。 # 大物ソフトをソースからコンパイルする場合、瞬間的に上記よりも # （手抜きをすると最大で3GBくらい）容量をくう（後述）。 結局、ソフトウェアを自前でコンパイルしないなら、/usr/home/と/swap以外の合計で 5GBもあれば、デスクトップマシンとしてはほぼ問題なく動くはずだということになる （だいたい、WinNT5.x系のOSと似たような感覚だろう）。開発環境などを突っ込む人は 適当に/usrを増やしておいてやればよいし、ケチった構成にすれば2GB程度でも kde-liteが普通に動くはず（ソースからmakeしようと思うと面倒だが）。 # ただし、Windowsとはswap領域を共有できないので、Windows同士のマルチブートに # 比べてWindowsとFreeBSDのマルチブートの方が容量を食う。 swapは、ぶっちゃけ「なくても動きはする」ので、マシン構成や用途によっては ケチってもよいのかもしれない。 # 実際のところ、メインメモリを2GB積んでいたとして、4GBのswap領域を # 本当に使うか、と言われると大いに疑問（転送速度の問題もあるし）。 # メインメモリの2倍という考え方は、現代的ではないのかもしれない。 が、メインメモリとHDDの容量格差を考えたら、メインメモリの2倍程度の容量を わざわざケチる必要はない気もする。 /usr/homeについては、それこそ人によるので、好きに確保する。マルチブートの 場合は特に、FAT32のパーティションを別に用意して、そっちを使うようにするのも 一案。/usr/portsを別パーティションにする場合はかなり容量が必要になるので、 ディスクに余裕がない場合はやらない方がよい（ports自体は、cvsupでports-allを 指定した場合で150MB程度だが、ソースコードもローカルで持つ場合容量が膨れるし、 make時の作業ディレクトリもports/以下に作られるため：追記参照）。 # tarballでportsを更新する場合、シンボリックリンクである/usr/portsが # ディレクトリ/usr/ports/で上書きされないように注意が必要 # （tarの仕様が変わったそうなhttp://slashdot.jp/comments.pl?sid=199546&cid=599298） 追記： /usr/の容量を3GBにして最小構成でのクリーンインストール直後（opensslと portupgradeを入れたのでperlとrubyも入っている）にxorg6.8.2をportsから 入れようとしたところ、ディスクがあふれた。どうやらフォントの コンパイルで容量を使いすぎたようで、環境がプアな場合はpkg_addで フォントだけ先に入れておいた方がよい（コンパイルにもかなり時間が かかるし、portinstallに-Ccオプションをつけても依存関係を含めた すべてのパッケージがインストールされるまでmake clean されない）。 Xorgに引き続きKDE3.4.2も入れてみたが、丸ごとインストールするのは 完全に無理で、コンポーネントごとに個別にコンパイルしたところ kdepim以外は普通にコンパイルできた（開発環境などは入れていない）。 kdepimはどうしても容量で引っ掛かるのでpkg_addから入れようと思ったが、 packagesのkdepimはKDEパッチを当てないQT（qt-copyではなくqt）に 依存しているらしくインストールできなかった。 IDE接続で、古いHDDや大容量HDDを使う場合の注意 http://www.geocities.co.jp/SiliconValley-PaloAlto/4065/dame-lba.htm http://nobumasa-web.hp.infoseek.co.jp/hdd/8gb_limit.html http://www.linux.or.jp/JF/JFdocs/Large-Disk-HOWTO-7.html アクセス方法には、 CHS：HDDの自己申告情報（ジオメトリ情報）を使ってアクセス Large：HDD自己申告情報をBIOSが便利な形（bitを使いきれる）に翻訳 LBA：BIOSが翻訳しなくても、HDD自体が非常に便利な形（直線アドレス）を理解 がある（LBAはLinear Block Addressing ではなくLogical Block Addressing らしい） 最近のディスクなら、ほぼ間違いなくLBAでアクセスできる CHS方式だと最大容量が504MBになり実用的ではない このため、ディスクが対応していればLBA、対応していなければLargeという選択になる Largeは8GBまで、素のLBAは128GBまで、48bitLBA（BigLBA/BigDrive）なら2TBが 最大認識容量になるはず。 # BIOSやマザーボードによって、Largeで32GBまで見えたり、48bitLBAでも512GBまでしか # 見えなかったりするので、あくまで目安 BIOSがきちんとデータを読んでくれなくても、各ディスクメーカーが配布している ディスクユーティリティーを使えば、ディスクを認識させられることがある。 # 比較的大手のメーカーなら、たいていウェブページ上で配布しているはず ただし、BIOSの機能だけで素直に認識させた場合と比べて、動きに違いが出る場合も 考えられなくはない # 違いが出たからといってそれが不利益を生む違いだとは限らないが オマケ パーティションの種類（ファイルシステム） FreeBSDではUFSがデフォルトだが、UFSという名称については混乱が多い。 本家本元のUFSは4.3BSDに採用されていたもので、255文字までのファイル名、 ディスククォータ、シンボリックリンク、ファイルやフォルダのパーミッション といった機能を備える。さらに、FFS、FFFS、UFS2などの、微妙に拡張された ファイルシステムが複数あり、これらと本家UFSをまとめてUFSと言ってしまうことが 多いようだ。 # FAT12、FAT16、FAT32などをまとめてFATと呼ぶのと似たようなものだろう。 # Disklabel Editor の画面を見ても単にUFSとしか書かれていないし、 # ここでもこの書き方に倣うことにする。 http://x68000.q-e-d.net/~68user/unix/pickup?%A5%D5%A5%A1%A5%A4%A5%EB%A5%B7%A5%B9%A5%C6%A5%E0 FreeBSDでは、同期（sync）型と非同期（async）型が簡単に選択（/etc/fstabの Optionの項目）できる。 # sync型の場合、ファイルをひとつづつ書き込んでいくが、async型の場合 # いくつかまとめて書き込んでしまう（遅延書き込みをする）。前者の方が堅牢だが、 # 後者の方がパフォーマンスが高い（ディスクにデータを書き込んでいる間、他の # システムがボケっと待っている必要がない：反面、書き込み予定のファイルを # 抱えたままシステムがクラッシュすると困ったことになる）。いまどきのHDDは # 自前でバッファを持っており、わざわざOSで遅延書き込みをしてやることがどこまで # 有効なのかはよくわからない（ベンチ取るのも面倒だし）が、結構な差があるらしい。 Disklabel Editor の画面に話を戻すと、USFとだけ書いてあるパーティションと USF+Sと書いてあるパーティションがあるが、この+Sという表記は、Soft Updates を 使うということを示している。具体的にどういう機能なのか筆者にはわからないが、 どうやら、ディスクキャッシュを操作することでasync型でもsync型と同程度の 安全性を確保しようという仕組みらしい。アンマウントした状態であれば、 Soft Updates の有効無効も自由に変更できるため、シングルユーザーモードや CDブートを利用して切り替える。 http://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/configtuning-disk.html では、結局どのような設定にすればよいのかといえば、/はUFS、それ以外は UFS+S（つまり自動設定のまま）で問題ないことがほとんど。心配性な人は /etcもUFSにしておけばよいだろう。 # 筆者はよくわかっていないのだが、どうやら、ファイルシステムを上位下位の # 2レイヤーに分割するのがBSD流で、FFSの上にUFSとかLFSの上にUFSといった # 実装があり、上位に注目して言えばどちらもUFSだし、下位に注目すれば # 前者がFFSで後者がLFSと呼ばれることになる（FreeBSDのデフォルトは # UFS/FFFSだったが、バージョン5くらいから64bitのUFS2に入れ替わった）。 また、変わり種として、メモリ上にファイルシステムを作成するMFS（5.x系では mdに統合されたらしい）や、AFSという分散ファイルシステムから派生した ArlaやCodaなどといったファイルシステムもあるらしい。 http://coral.neic.nsk.su/ja/projects/#filesystem 以前OpenBSDで採用されていたSFS（暗号化機能を備えたファイルシステムらしく、 ライセンス問題で削除された?）など、先進的なファイルシステムもたくさんある （が、ここでは扱わない）。 FreeBSD上では、Dosが採用しているFATの読み書きが可能で、WinNT系が採用している NTFSは読み込みのみ可能（書き込みはまだかなり危険らしい）、Macが採用している HFSにも対応予定らしい。 # Dosパーティション（FAT）の読み書きについては、その3で再度触れる。 ディレクトリ構造 とくにこうしなければならないという決まりはないのだが、目安として Filesystem Hierarchy Standard（FHS）という標準がある。 http://www.pathname.com/fhs/ 2007年5月時点での最新版であるFHS 2.3によると http://www.pathname.com/fhs/pub/fhs-2.3.html /bin：必要不可欠なユーザーコマンドのバイナリ（全ユーザが使用） /boot：ブートローダーの静的ファイル /dev：デバイスファイル /etc：そのホストに固有のシステム設定 /home：ユーザのホームディレクトリ（オプション） /lib：必要不可欠な共有ライブラリとカーネルモジュール /mnt：一時的にマウントするファイルシステム用のマウントポイント /opt：アドオンのアプリケーションソフトウェアパッケージ /root：root用のホームディレクトリ（オプション） /sbin：システム用バイナリ /srv：システムが提供するサービス用のデータ /tmp：一時ファイル /usr：共有可能なリードオンリーのデータ /usr/X11R6：X Window System, Version 11 Release 6（オプション） /usr/bin：ユーザコマンドの大部分 /usr/include：標準的なインクルードファイル /usr/lib：プログラミングとパッケージのためのライブラリ /usr/lib：フォーマットの異なるライブラリ（オプション） /usr/local：ローカルディレクトリ /usr/sbin：必要不可欠でない標準的なシステムバイナリ /usr/share：アーキテクチャー非依存ファイル /usr/source：ソースコード（オプション） /var：スプール、ログ、一時ファイルなど /var/account：プロセスアカウントログ（オプション） /var/cache：アプリケーションキャッシュデータ /var/crash：システムのクラッシュダンプ（オプション） /var/games：各種ゲームデータ（オプション） /var/lib：各種ステータス情報（state infomation） /var/lock：ロックファイル /var/log：ログファイルとログディレクトリ /var/mail：ユーザのメールボックスファイル（オプション） /var/opt：/optディレクトリのプログラムが使う各種データ /var/run：今回起動中（run-time）の各種情報 /var/spool：アプリケーション用スプールデータ /var/tmp：システムリブート時に削除しない一時ファイル /var/yp：NIS用データベースファイル（オプション） プログラムのバイナリはまずユーザーコマンド（bin）とシステムコマンド（sbin）と ライブラリ（lib）に分け、シングルユーザーモードでの起動に必須なものを/直下に、 それ以外を/usr直下にインストールする。/usr/localは「ローカルなソフトウェア」の インストール用だが、これは「システムソフトウェアのアップデートにより上書き されない」という意味。/tmpのファイルはリブート時に削除することを 前提としている。最新のXorgは/usr/X11R6ではなく/usr/localにインストールされる （まあ、もうVersion 11 Release 6じゃないから当然といえば当然）。 /var/runの「今回起動中の各種情報」というのは、前回起動してから現在までの 状況に関する情報という意味。 オマケ もしCUIでの操作を主にするなら、誤操作や誤作動の心配が少ないものを選びたい。 もちろんスクリプトなどでの予防はするのが当然だが、たとえば > rm *.bak とやろうとして > rm * のところでリターンキーが誤入力されたら、大変困ったことになる。 シリアル接続（PS/2の前に主流だった規格）はともかく、21世紀に入っても PS/2接続のキーボードが絶滅しないのは、この辺の事情も影響している。