FreeBSDをNFSサーバにしてdiskless Linuxのブート ・・・ できなかったメモ

この前、FreeBSD 5-STABLEをファイルサーバにして、CentOS 5.0をネットワークブートさせようとしてて、どうしてもダメだったメモ。

• http://nhh.mo-blog.jp/ttt/2007/07/post_68d2.html

こんな感じで、お膳立てをして、玉砕した。

• 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でなんとかガンバル、というのが、実は正しいアプローチな気がする。