Diary

1. Caldera OpenLinux 1.3
   コイツをいじってると、2.2.1カーネルや glibc2を入れたくなる衝動に駆られて止まない。
   ただそのまま入れるだけじゃ無意味で、wcsmbsパッチ等を入手しておかないとダメだし、それに glibc2を入れるとなると binutilsも更新しなくちゃ......恒例の芋蔓式。
   で、思い止まる。

2. Linux (つづき)
   で、glibc2や 2.2.1カーネルを入れたら、次はシステムまるごとサーバーにコピーして、Network Bootするんだいッとか考えてる。
   サーバー機は Linux Emulationで、Celeron機(クライアント)は Network Bootして、Linux用バイナリを共有。
   良さげ。

1. doscmd
   FreeBSD用の doscmdをちょっと動かしてみた。
   え? キーボード入力処理はまだ全然触ってないから押したキーと入力される文字がぐちゃぐちゃかと思いきや、結構使える。
   が、どうしても '='(イコール)が入力できないことに気付く.....。
   (PC/AT系は、テンキーに'='(イコール)は付いていない)

2. Linux emulation
   Linuxの Networkが動かないため Caldera OpenLinuxのパーティション(ext2fs)を FreeBSDから mount。
   徐に /(ext2fs mountディレクトリ)/usr/bin/makeを動かしてみる。
   『make: *** No targets. Stop.』と表示される。動いてる!
   取り敢えず make, as86, ld86だけをコピーする。
   試しに etherbootパッケージ(Linux用)を構築してみた。
   多少 Makefileをいぢったら、ちゃんとできた。
   ちょっとだけ感激。

3. doscmd(続き)
   doscmd内から、sysコマンドを使って作った floppyは起動できるのか実験しようと、サーバー機で floppyを formatし、次に doscmdを立ち上げて sysコマンドでシステムを転送。
   さあ実験だッと右手で floppyを抜こうとしたその瞬間、中指第 2関節がサーバー機の電源スイッチに触れる。
   『ひゅーん』という表現がぴったりの音とともに、いくばくの静寂が訪れる。

   その後の fsckでも問題は無かったけど、悲し(;_;)

/compat/linux/usr/bin/makeは、やはり壊れていると思う。
elf headerに記述されたアドレスが、一部 /compat/linux/usr/bin/gccのものと異なるから。
そのヘッダに書かれた中のあるアドレスが ld-linux.so.1をロードしようとする先を指しているものだから、ld-linux.so.1をロードせずにエラーとして処理していたのであった。...あとでちゃんとバグレポしよ。

そこで、楽しい楽しいカ〜ネルデバッグ〜♪

1. /compat/linux/usr/bin/makeが動かない。
   imgact_elf.c+568にブレークポイントを張ってみる。
   何度か遊んでいると VM(仮想メモリ)部分がエラーを返しているのがわかった。
   ある特定の条件で ld-linux.so.1が Loadできないみたい。でもちゃんと Loadできる時もある。
   /compat/linux/usr/bin/gccなんかはちゃんと動くので (同じ ld-linux.so.1を使ってるのに) 手動でならちゃんと compileできるんだけど.....
   ちょっと手動で compileしてみたけど、as86も ELF interpreter...と表示して実行できないので、もうデバッグしないと無理だということが判明。
   どこかに FreeBSDの VM構造のドキュメントって転がってないかなあ?
   ......traceしていくうちに、なんとなく構造が掴めてきた。
   既に 0x8000000...(ZEROって何個だっけ?)以降の数ページのメモリが既に確保されていた場合に、エラーチェックに引っかかっていたのであった。
   んで、どうして既にメモリが確保されているのか、その原因を調査中。

2. SCSIタイムアウト。
   どうやら BusLogicの probeルーチンが原因のようだ。いじってみたらちょっとだけ症状が替わった。けど、よく見ると、いじる前にも何度か起きていた症状だった.....

NetNewsを読みたいなと思ったけど、うちのプロバイダはサービスしてない。
気前よく Celeronを 300Aに交換してくれたおぢさん(@OCNエコノミー)に gatewayを頼もうかな。
もちろんおぢさんに NetNewsの gateway設定を頼めるわけでもなく (それは苛酷な試練というものだ B-)、僕が設定するんだけど。
delegateにしよッかな?

cd焼き焼き環境を構築するため、mkhybridを入れて遊んでみようと思う。
CD-RWだから、失敗しても恐くない!

etherbootに対する FreeBSD/elf対応 patchや、netbootに対する packet driver patch...などなど、楽しめる材料を一杯 Netから拾ってきた。
まず dos packet driver環境で network bootする floppyを作成する。
その時 config.sysで network interfaceを選べる(もしくは全部組み込む!)ようにすれば、floppy 1枚でどこからでも network bootできるようになる。
現状だと netbootは packet driverに対応できるけど aout formatの kernelしか bootできない。
かと言って etherbootは elf formatに対応できるものの packet driverには対応していないようだ。
材料はあるけど、実現するのは大変だぁ〜!

その後、無事 network boot (いや、正確には NFS root)できることを確認。次は本来の目的である Aptivaで network bootしないとね。
ちなみに FreeBSDの GNATSデータベースを覗いたんだけど、netbootに対する patchで packet driverに対応する差分があるそうだ。あとは elf formatに対応させれば、ほとんどのネットワークカードで network bootが可能になる!? ちょっといじって試したい気分になってきた。どーしよーかなー??

いま NFS rootのまましばらく使ってるんだけど、NFS server not respondingのメッセージがまったく出ません。どうなってるんだ? こりゃ。
debugモードでコンパイルされた kernelなので速度が落ちているせいかなあ?
それから NFSの負荷を掛けるために NFSマウント先の directoryで kernelの再コンパイルしてみたんだけど、なんと超高速で正常終了しました。以前は全然おかしくて make dependの段階でコケてたのに。
あ! ということは、原因は amd経由で mountしてたから!? (今回は fstabに書いて直接 mount...)

もひとつ感想。
rlogin使ってるより、その rlogin使った先のマシンから kterm起動させた方がキーの反応が速いのはなぜだ?
とても快適だぜッ!

で、今までなんで悩んでいたのかと言うと、
1. handbookに書いている手順は、一部順序が逆だッ。
   まず targetの consoleから gdb<RET>、s<RET>として待ち受けさせておいて、次に remote側から kgdb) target remote /dev/cuaa0としなければならなかった。

2. これが原因かどうかはまだ詳しく調べてないんだけど、私の用意したクロスのシリアルケーブルが、中途半端なヤツだった。(sttyを使って clocalと設定しなければならないヤツ。)
   んで、カーネルドライバの初期化部分に手を加えた。
   (その後の調査で、クロスケーブルは全然関係なかったみたい。なんせ、sio初期化ルーチンに突入する以前でも gdb remote chatが行なえたからだ。)

field type 4
hostname
field type 15

netbootの設定を見直した際 bootparamdを起動させたりもしたけど、...全く無駄だった。
こりゃ、本気で source読みながら debugしないとダメみたい。

はーしんどい。
kernelの方は、結局 comconsoleの probeルーチンを利用して、sioに flagsが設定されている時には (comconsole用の)clocal設定処理が実行されるようにしてみた。
今は動作確認以前にサーバーの環境設定で戸惑っているところだ(汗)。

1. staticに決め打ちされているポートじゃ無いとダメなような。
   PnPや、PCMCIAのポートは扱えないような感じかな。(注:根拠なし)

2. 初期化せずにいきなり siocnputc/siocngetcを呼んでいるようなので、設定が初期値のまま。
   clocalの設定は、どこで行なえば良いのかな!?
   やっぱ DDBから gdbと入力した時でしょう。(自己レス)

その時の行動記録 (要するに下の続き)
1. target(celeron機)が DDBに落ちた。
   celeron機で gdbと入力し、remote chatに反応するよう指示する。
   サーバー機の gdb)プロンプトで target remote /dev/cuaa0と入力。
   Ignoring packet error, continuing...と返ってくる。これは、通信できていないという事か!?

2. 仕方なくクロスケーブルの動作確認。
   celeron機を通常の kernelで再起動させ、ttyd0に対して gettyを立ち上げる。
   サーバー機から tip+を使用し、クロスケーブル経由の remote loginに挑戦する。
   が、なにも返ってこない。やはり stty clocalと設定しないとダメみたいだ。

3. ちょっと趣を替えて、/etc/gettytabで clocalの設定を試してみる。
   すると Loginプロンプトが返ってきているようだ。
   ようだと言うのは、文字が化けててよく判別できないから。
   試行錯誤の結果、stty -ignparと設定しないとダメみたい。これで文字化けが無くなり、正常に Loginすることができた。

4. さて、これから何をするんだっけ?
   トラブルに遭遇するとこんな感じで芋蔓(イモヅル)式にまたトラブルに見舞われることがしょっちゅう。だから、よく何が目的だったか忘れてしまうのだった。
   ...そうだ、次は kernelの GDB_REMOTE_CHAT部分を操作して、壊れたクロスケーブル(と呼ぶことにする)に対応する改造をやるんだった。

行動記録
1. 640MB MOの扱いがおかしい。
   DOS formatされた 640MB MOが読めない。また、昔の 3.0-currentで ufs formatした 640MB MOが読めない。
   od-driver-2.2.6Rや 3.0-RELEASEで formatした 640MB MOは読めるのに。
   ということで、手始めに od-driver-2.2.6Rを参照して ufs/msdosfsの改造を試みる。

2. 改造後、MOが接続されている celeron機で kernel compile & reboot。
   すると、昔の 3.0-currentで ufs formatした 640MB MOが読み込めるようになった。しかし、まだ dos formatの 640MB MOは読めない。

3. そこで、どこが原因か突き止めるため kernel debugの準備を始める。
   (ついでに NFSとか SCSIの調子が悪いのも debugできたらいいなーなどと思ったりする)
   debugのためには、2台のマシンのシリアルポートをクロスケーブルで接続しないといけない。(別にクロスケーブルじゃなくても、2台の MODEMを使って TA折り返しで接続するという方法もあるにはあるけど、ここでは置いておく)
   でも、サーバー機の内蔵シリアルポートは MODEMと TAで既に塞がってる。あと内蔵 MODEMカードが刺さってるけど、これは使えない。他に増設シリアルカードがあるけど、これにも別の TAが繋がってる。要するに、全部のシリアルポートが使用中。
   そこで、シリアルポートを空けるのが面倒なので Aptivaを使おうと考えた。
   でも Aptivaには FreeBSDが入っていない。(唯一 Winが起動できる環境なので、消すわけにはいかない)

4. というわけで netbootしようと試みる。
   が、予定通り(汗) netbootは失敗した。原因は kernel object形式が elfだからだ。ここで elfだと netboot、dosbootが一切できない事を知る。
   aoutで Aptiva用 kernelを compile。

5. 再び netboot。
   で kernelを読み込み device probeは順調に進んでくれたのだが、案の定 panic。NFS root部分でコケてるみたい。確か以前も同じ症状だったよな。
   チンケな俺には設定がヘンなのか、バグなのかわからないのであった。むはー。

6. ここで発送の転換。celeron機から Aptivaの kernelを debugしようと試みる。
   Aptiva用 kernelに debugオプションを付けて再コンパイル & netboot。
   再び panicするので kernel debuggerのプロンプトから gdbと入力する。これで Aptiva側の準備は整った。

7. celeron機で debug。
   Aptiva用 kernelのコンパイルディレクトリで gdb -k kernelと入力してみた。
   ところが、gdbに File format not recognized.と言われる。ああ、そうか、kernelは aout formatだったよな。
   気を取り直して env OBJFORMAT=aout gdb -k kernelしてみた。
   が、今度は aout/gdbが実行できないと言ってくる。
   むはー。/usr/libexec/elf/gdbは存在するのだが、/usr/libexec/aout/gdbが無い。なんと object形式が aoutだと、一切 debugできない!? (あ、2.2系から拾ってくればいいのか)

8. 疲れた。
   ………素直にサーバーのシリアルポートを空ければ celeron機で kernel debugできるし、ついでに netbootというか NFS root部分のデバッグも楽しめるのに(汗)。

またまた SCSIバスの調子が悪いようなのだ。一度カードを抜き差ししただけなのに、ほぼ毎回異常が発生するようになった。
は! もしかしたらこれが Win98が起動しない原因………って、抜いた時にも例外発生してたから全然関係ないや。気のせいだ。
良く考えたら CPUが速くなってからだ。266(400)の頃は大丈夫だったハズ。
メッセージによると FreeBSDの SCSI device probeでタイムアウトが発生するようだ。困ったな。ちょっと kernelをいじるしかなさそう。

え〜ん(涙)、やっぱ俺の HDD運(IBM製 IDEに限る)は悪いみたいだ。
make in HUNGARYの DTTA-351010の音が非常に軽くて静かだったのだ。それに比べると俺のヤツは重くて響く。ショックだ。しかも向こうは 1年保証付き。こっちは 1週間の初期不良交換のみ(そんなのとっくに切れてる)。やっぱ値段に釣られて買う店を間違ったな。今度から気をつけよう。

それから、相変わらず FreeBSDの NFSの調子が最悪。もう、やんなってきた。
今の状態では Celeron機がまったく役に立たない。Winは起動しないし、NFSが厳しい状態では Voodoo2ドライバ移植もやる気が起きない。原因はハードじゃなくて全部ソフト側の問題なのに。
まずは頑張って NFSデバッグか...
ところがサーバー機はシリアルポートが全部埋まってるので kernelのリモートデバッグができん。rbootができれば Aptivaを活用してデバッグもできるんだが、wide-dhcpとは相性が悪いのか、どのマシンでも一度たりとも正常に稼働したことが無い。起動だけなら 9821As2で確認したけど、idle状態に突入した途端 kernel panicするし、まともに使えたことが無い。ぶ〜 :-(。

さあこれからどうする!? FreeBSD独立運用計画発動か?
だが、Linux/FreeBSD等の PC-UNIXや BeOSには課題が山のようにある。一部抜粋してみたが、現段階ではどれも難しいものばかりだ。

個人的に Win以外の OSに必要な機能。(一部抜粋)
1. DVD再生環境。MPEG2が再生したい。コピープロテクションのかかっている DVDソフトをだ! これは無理なのか!?
2. Voodoo2等、3D Accelerator活用環境。これは所々で話を目にするので、おそらく時間の問題で解決されるはず。
3. MultiSession CD Writing環境。既にフリーソフトとしてのソースが手元にある。一部改造が必要かもしれないが、少し努力すれば実現可能だ。さらに、実現できればこちらの方が汎用性があり便利なハズ。
4. USB経由じゃ無くてもいいから、KODAK DC260 Zoomと画像のやりとりがしたい。
5. FlashPix形式の画像を jpeg等の他の形式に変換したい。……は! そもそも FlashPix仕様って一般公開されていないんじゃ!?