さくらVPSでPlan 9

いろいろ動かないなぁと探っていたんだけど、何のことはないパーティションIDをMINIXからPlan 9に変えるのを忘れていて、9loadがパーティションを見つけられなかったというオチで、結局MINIX3と同じアプローチでPlan 9をさくらVPSで動かすことができた。GrubからちゃんとチェインロードでPlan 9をブートできることを確認できたのは収穫だった。回り道したけど、今まで気にすることがなかったブート周りの仕組みがわかったので、合わせてメモを残しておく。

方法は「さくらVPSでMINIX3」とまったく同じで、スワップパーティションにddでPlan 9のディスクイメージを書き込む。fdiskでスワップパーティションのパーティションIDを0x39 (Plan 9)に変更することを忘れないように。

次のスクリーンショットがさくらVPSでPlan 9を起動したところの図。

ただしネットワークインタフェース（Intel e1000）の認識に失敗している。/dev/kmesgには次のようなメッセージが。キャッシュラインサイズレジスタの読み込みに失敗しているらしい。これは今後の課題。ネットワークが使えないと全然うれしくないからね。

igbe: unusable CLS - 0
igbe: unusable CLS - 0

さてx86においてHDDから起動する場合は次のようなブートシーケンスになる。(1) BIOS、(2) MBR、(2) PBS、(3) 9load、(4)カーネル。BIOSはHDDの先頭セクタを読み込み実行する*1。このセクタをMBR (Master Boot Record)と呼び、今回のケースではGrubがインストールされているので、Plan 9の/386/mbrは使わない。ちなみにmbrが実行されると「MBR...」とメッセージが表示される。続いて、GrubのメニュからPlan 9を選択してチェインロードする場合、Plan 9パーティションの先頭セクタであるPBS (Partition Boot Sector)がロード、実行される。このパーティションが（Plan 9の呼び方では）sdC0となる。PBSにはCHS版のpbsとLBA版のpbslbaが存在する。CHSとLBAはセクタアドレッシング方法で、前者のアクセス範囲には8GBの壁が存在する。今回、Plan 9パーティションは8GBよりも後ろに存在するので、pbslbaを使う必要がある（最近はデフォルトでpbslbaになっているはずである）。「PBS2...」とメッセージが表示される。ちなみにpbsのメッセージは「PBS1...」である。pbs(lba)はsdC0!9fatから9loadを探し、ロードする。9loadの実行は「Plan 9 from Bell Labs」のメッセージから始まる。9loadはブートの可能性のあるデバイスからplan9.iniを読み込み、「boot from:」プロンプトを表示する。あとは（カーネルの選択はplan9.ini依存になるが）デフォルトのカーネルはsdC0!9fat!9pcfになっているので、このカーネルが9loadからロードされて、ようやくカーネルが立ち上がる。カーネルの実行は「Plan 9」というメッセージから始まる。

最初、9loadがsdC0を認識できていないのかと思ったのだが、9loadがロードできているからディスクの認識自体はうまくいっているはずで、パーティションが見つけられていないのだと言うことにさっさと気がつくべきだった。ちなみにpbs自体はパーティションIDはチェックしないようで、Plan 9のID 0x39になってなくても9loadを見つけてくれたのだが、9loadはちゃんとIDをチェックするので、sdC0!9fatが見つからないとなる。また、9loadはUSBブート機能に対応しているのだが、KVMから起動する場合はその機能が有効になっているとsdC0を見つけてくれない。9loadnousbを使う必要がある。この点はいろいろ実験しようと思ってはまってしまったポイントである。

*1:MBR周りの話は「なぜx86ではMBRが"0x7C00"にロードされるのか？(完全版)」が面白い。