debootstrapでRAMベースネットワークブートシステムを作るアイディア
RAMベースネットワークブート=ルートファイルシステムをサーバーから取ってきて、RAMに全部展開してブートする。今勝手に命名:p
RAMに全部展開すると何が嬉しいかというと、まずネットワークを落としても問題ない。これは嬉しい。VIVERでもそうだけど、ネットワークに常に接続していないといけないタイプだと、初期ブートプロセス（たぶんinitramfs内）でネットワークの設定を全部やらないといけない。これだとネットワークの設定が面倒になる。（もちろんできないわけではない）
あとミスってネットワークを落としても、システムは落ちない。シャットダウンする途中でネットワークを落としてしまっても、ちゃんと終了できる。
それから、/にunionfsやaufs、cowloopなどのCopy-on-Writeなにやらを使わなくてもいい。これらは歴史が浅いので、安定性に不安（でもaufsにはかなーり期待）。それから、/にunionfsやらを使ってしまうと、/のアンマウント（or Read-onlyでリマウント）が難しくなる（そりゃできなくはないだろうけども！やってくれー）。そうすると、正常終了できなくなる。sync;sync;sync;halt -i -p -d -f;prayみたいな。
さらにさらに、initramfsを環境に合わせて作り込まなくてもよくなる。あるいは大量のブートパラメータを渡さなくても済む。一発initramfsを作ってしまえば、いろいろ流用可能。逆にルートファイルシステム側を作り込まないといけなくなるけど、これはinitramfsのようなヘンな環境ではないので、難しくない。普通にOSをセットアップするのと同じ。
開発者的に美味しいのは、initramfsでHDDを触らないで良くなる。これはスバラシイ。NTFSなんてっ
というわけで、initramfsとCopy-on-Writeでがんばるより、RAMに展開してしまった方がとてもとてもおいしい。
でも逆においしくないのは、起動するだけでRAMの使用量がトンでもないことになること。これは悲しい。従って、ルートファイルシステムのサイズは極限まで小さくしないといけない。200MBくらいにまで落とせれば嬉しい。
サイズに限りがある時点で、XやらKDEやらの重量級は入れられないことは明白。フツーのデスクトップ用途には使えないですな…なんとかならんですかねぇ…。
で、最初から超小型サイズ（かつ実用的）なルートファイルシステムを作るのは難しいので、まずはdebootstrapでやってみる。
initramfsの実装方針は以下。
- /procと/sysをマウント
- ブートパラメータをパース
- /sysrootにtmpfsをガッツリマウント
- PCI自動検出＋モジュールをロード
- 引数に応じてネットワークを起動
- ブートパラメータで指定されたURL（HTTPとかFTPとか）をダウンロードしつつ、パイプでgunzipにつないで/sysrootに展開
- /sysrootにswitch_root
ネットワークを起動するためのブートパラメータの指定方法が、とても迷う。で、閃くに、ブートパラメータに"ifconfig %i[0] 192.168.0.2; route add default gw 192.168.0.1; dns 192.168.0.1"とかとか、コマンド名をそのまま渡してもらえばいいんじゃないか。長くなるけど分かりやすい。DHCPの場合も、"dhcp %i[0]"みたいな。
これのいいところは、initramfs側でNICの数に応じて処理を別けなくていいこと。NICの数くらい分かるでしょと。VIVERはこのあたりの実装が既にカオス！カオス良くない。ハックできない。
逆に問題は、NICが複数ある時に、番号が不定だということ。コレ、Linuxの実装がどうなっているのやら。でも思うに、モジュールのロード順で決まる。と言うことは、PCI自動検出で検出される順番で決まる。PCI自動検出は/sys/devices/pci*で判断するので、PCIのバスIDの順番で決まる。これなら問題ない？例外はNICが3以上あって、PCIのバスIDで最初と最後のNICが同じモジュールで動くとき。でもNIC３枚などというリッチな環境なら、そちらで何とかしてくれるでしょう！
ちょっと心配なのは、ブートパラメータの文字数制限。それから既存のブートパラメータ名と衝突しないかということ。「ブートパラメータジェネレータ」みたいなものを作って、ブートパラメータを圧縮してbase64にするか!? 短いテキストに特化した圧縮アルゴリズムなんてあるのかな。zlibでいい？
