この前、FreeBSD 5-STABLEをファイルサーバにして、CentOS 5.0をネットワークブートさせようとしてて、どうしてもダメだったメモ。
こんな感じで、お膳立てをして、玉砕した。
- CentOSを動かしたいディスクレスクライアントは、PXEブートできる
- DHCPサーバは、FreeBSD 6.2-STABLEで、isc-dhcpd
- ブートローダ（pxelinux）やカーネルなどのファイルは、FreeBSD 6.2-STABLEなマシンから、tftpでダウンロード
- ルートファイルシステムは、FreeBSD 5.5-STABLEをNFSサーバとして、NFSマウントさせる。initrdは使わない
- FreeBSD 6.2-STABLEと5.5-STABLEと、２台使っているけど、単にディスクがあまってるマシンが、5.5-STABLEのマシンだったからという理由
- pxelinuxは、昔、debianやFedora Core 4などをネットワークインストールしたときのがあるので、それをそのまま使う
- とりあえず、HDDにCentOSをインストールしておいてから、ファイルをすべて、FreeBSDのファイルサーバ上へdump ＆ restoreしてコピー。/dev/などがコピーされてなくて、実はまずかったんだけど、ディスクレスなlinuxマシンが、そこらをアクセスするようになる以前の段階でエラーになっているため、とりあえず無視
- Linuxカーネルを再構築して、ROOT_NFSという機能が組み込んだ。また、ネットワーク（NIC）のデバイスドライバも、モジュールにせずに、カーネルに組み込んだ
- Linuxカーネルのブート中のログを見てると、DHCPでアドレスなどの情報を取得には成功しているが、ルートファイルシステムをマウントできずpanic。
- NFSサーバ側で、showmountしてみると、マウントした痕跡は残っていた
☆
tcpdumpしてみた。
Linuxが、ルートファイルシステムをNFSマウントしようとしてるところ。
MOUNTは成功している。
そのあとに、STATFSというのを実行しようとしている。
STATFSのリクエスト
STATFSのリプライ。
replyは、denied。AUTH_ERRORとなっている。
リクエストに入ってた、AUTH_NULLというのが（詳しい意味はわかんないけど）、FreeBSD 5.5-STABEのNFSサーバで未対応なのではないか？という感じがする。
そう思った理由というのが、ファイルサーバを、CentOS 5.0なマシンに変更したところ、STATFSも成功しているから。
MOUNTして、STATFSしているところ。
STATFSのリクエスト
STATFSのリプライ。
RPC executed successfullyとなってるし、ファイルシステムの情報（Block Sizeなど）が、NFSサーバから返ってきている。
というわけで、どうやら、ディスクレスなリナックスをブートさせるためには、NFSサーバを選ぶらしい・・・と。
もしかすると、FreeBSDでも、バージョン6系列とか7系列とかだと、うまくいくかもしれない？！
また、linux kernelのバージョンによっても、挙動がかなり違うらしい。
☆
Cent OSをファイルサーバにすれば、ネットワーク・ブートできたのか？っていうと、実は、うまくいってない。
diskless clientで、initなどの実行がはじまり、root filesystemをread write mountし、あれこれ/var/以下にファイルを書き込もうとしているときに、root権限でファイルを作成できず、nobodyにされてしまうため。
もちろん、NFSサーバ側では、no_root_squashをつけてexportしているし、別のNFSクライアントで、root権限で書き込みができることは確認済み。
以下は、diskless clientが、root権限でファイルを書き込めていない様子。
とりあえず、ムリヤリに、single userでブートさせておいてから、/tmp以下に、testという名前のファイルを作成しようとしたところ。
CREATEのリクエスト。
CREATEするとき、なぜか、uidやgidが指定されていない。なんか、もうここからしてダメっぽい。・・・NFSプロトコルについてよく知らないので、本当にそういう意味なのかどうかはよくわかんないけど。
CREATEのリプライ。
一応成功はしているが、uidが65534になっている。
つまり、root権限で書き込めていない。というか、NFS client側が、そもそも、rootで書き込む気がない、ってかんじ。
こういう挙動から、どうやら、kernelに組み込まれるROOT_NFSのNFS clientとしての機能は、実は、かなりウソくさい実装になっているんじゃないか？っていう感じがしてくる。
ためしに、single user modeのときに、NFS clientとして動作するのに必要なデーモン類（portmapや、rpc.nfsdかな）を、手動で実行し、NFSマウントしてみると、ちゃんとroot権限で書き込みができた。
というわけで、root filesystemを read write modeでremountする前に、NFS client用のデーモンを一通り実行して、ROOT_NFSではなく、本物のNFS clientとして動作させておかないとダメなんじゃないかな、って気がする。
そういうことをするinitrdを作っておけば、そもそもROOT_NFSなんかも使う必要がないわけで、カーネル再構築も不要。initrdでなんとかガンバル、というのが、実は正しいアプローチな気がする。