特急のアルバイトの仕事でLinux PCが必要になった。

初代のWebサーバーに使っていたPCが埃を被ったままだったので、立ち上げてみた。

SegateのHDDを使っいる、昔からやたらとエラーが出るのだが、最近F/Wに問題があるということで大騒ぎになっているらしい。かつてはIBMのHDDも似たようなF/Wのインチキで事業売却ということになったのだがSegate大丈夫か。かつてIBMで問題を起こしたF/W開発者がSegateに渡り歩いて同じ問題を起こしたとかないだろうね？

HDDのF/W開発者経験者なんて世界中でも数える程しかいない希少絶滅危惧種だけに引っ張りだこなのかもしれない。

話をもとに戻そう。

Linux PCにはディスプレイをつないでいなかったがどうやら立ち上がっている気配が見えない。

仕方がないのでVGAのケーブルの尻尾を手元のDELLの19インチ液晶の使っていないVGA端子に接続。

VGAを選択して切り替えると、BIOS起動画面でCMOSのチェックサムエラーで止まっているではないか。

電池切れぽい。

まずは時刻を設定しようとBIOS設定画面を出したら1999年だった。

日付と時刻を設定しなおし、設定を保存して再起動。

Linuxが立ち上がったこのころの安定版カーネルは2.4.27だ。大丈夫か？

次ぎに仕事で使うソースアーカイブをFTPで転送してLinux上で展開。

インストールスクリプトを起動してごにょごにょ。

ツールをインストールするディレクトリの確認を求められる。

デフォルト値でやったら怒られた。

なのでインストールスクリプトを起動し直して今度はユーザーホームディレクトリを指定したらOK

次ぎにツールを起動してソースからビルドするのだが、ここでいくつか必須パッケージがインストールされていないと怒られる。

apt-getで足らないパッケージをインストールすればいいかとやってみたが、パッケージサーバー(ftp.debian.or.jp)とかにつながらない。

最初/etc/apt/sources.listが古いのかと思って調べてblogとかで紹介されている内容を追加してみたが同じ。どれも接続できないと出る。

ネームサーバーの問題か？

/etc/resolve.confを見ると、Webサーバー時代の設定になっていた、HDDの壊れた玄箱でDNSを運用していた時代の代物だった。

そこを直して、ようやく外につながるようになった。やれやれ。

sudo apt-get install 足らないパッケージ名

をやってみたがエラーが出る。

使用しているaptが古いかもと思って、apt-get updateをやってみるもこれもうまくいかない。

仕方がないのでapt-get upgradeを実行すると、依存関係でエラーが出て止まる。

思い切って断腸の思いでapt-get -f upgradeで強制アップグレードを実行。

うまく行っている、古いパッケージが新しいのにリプレースされる他になんかいろいろ知らないetchとかいうサフィックスのついたパッケージも追加されている。セキュリティ関係でパッケージシステムに変更が入ったのかな。

正常に終わったので、再びsudo apt-get install 足らないパッケージ名
をやってみた。

パッケージ名が違っていたらしく、正しいパッケージ名を指定するとインストールされた。

もともとソースがRedhat上で使うことを前提としているので、使用しているパッケージ名もRedhat独自のものになっている。これがRedhat系とDebian系での仲の悪さ。

Redhat系で開発されたソースなので、必要なツールとかはソースRPMからビルドしているらしい。なのでrpmパッケージがインストールされていないとどうにもならない。Debianではrpmに代わるパッケージシステムを標準にしているので障害となった。一応rpmパッケージも提供されているのでapt-getでインストール済み。

再びソースからのビルドを試みると今度は進んだみたいだ。

しかし１時間ほどしてPasswordを入力するプロンプトが出てきた。

慌てて入力したが、なんか失敗したらしい。

もう一度やり直しか...orz

インストール失敗の原因を調べたところ、Linux 2.4の頃にはEXPERIMENTALだったmutexシステムコールをアプリケーションが利用できることを前提としているためだった。

結局Linux 2.4ベースではだめだということじゃん。

仕方がないので、最新のDebian 5.0をインストールすることに。

インストール自体は問題ないのだが、間違って標準で選択されているデスクトップ環境を導入したのでえらいことに。

Gnomeデスクトップが256MBのPCで立ち上がりはじめた。

なんかSeagateのHDDからやたらエラーが出る。

あげくのはて、パッケージ構成を変更しようとしたらファイルが書けない。

rootファイルシステムがエラー時リードオンリになるらしい。

ライトプロテクトがかかって書けないという。

なんだよそれ。

仕方がないので、もう一度インストールし直し。今度はデスクトップは選択しないでファイルサーバーとウェブサーバーにプリンタシステムを追加してサーバーとしてインストール。

ソフト開発関連のパッケージはまったく入っていないので、それを後からaptで追加。

ようやく振り出しに戻った。

ツールのインストールを開始。

今度もしばらくしてエラー終了。

見るとなんかおかしい。スクリプトが出しているメッセージがおかしいのである。

見るとPerlで書かれたスクリプトだがかなり古いバージョンのPerlを前提としているようだ。Perlは最新の5.8とかだから、不整合が生じているかもともとバグなのか。

とりあえず問題ないのに誤動作している条件判定部分をスキップするようにスクリプトを変更してようやく順調に導入が進むようになった。

しかしこのツール、全部ソースからリビルドするのか。まあ、使用される環境毎にバイナリを用意してダウンロード配布することは余計な手間だからしないというわけね。

まだ終わらない。しばらくかかるらしい。

なにかというとLtibというオープンソースな組み込みLinuxビルド用ツールでした。多様な組み込みCPUをカバーできるのでこれひとつで足りるといえば足りるのだが、もっと早く試しておくべきだった。大分時間が取られた。

LtibがDebian GNU/Linux 4.0だとスムーズに導入できた。といっても足らないパッケージを追加導入するひつようがあったが。

また止まったかと思ったらコンフィグレーションメニューが画面が表示されていた。

そのまま抜けてオリジナルのままビルドしてみたら正常に終わった。

あっけなかった。

前任者は１ヶ月かけてさじを投げたらしい。なんともはや。

やはりあれだ、同じように使えるといっても古いボロコンAMD-K6-IIマシンと最新のデスクトップPCでLinuxカーネルのビルド時間を比べたら雲泥の差がある。

１時間で終わるのが４時間かかるとかなり体力的にも精神的にもつらいものがある。

組み込みLinuxをクロスビルドするマシンを新調したいけど、先立つものが無い。

とほほ

やはり古いAMDK6-IIの500MHzのPCよりは中古でも2.4GHzでメモリを沢山積んだサーバー機の方がクロスコンパイルは早いだろうということになり、中古を入手。

NEC Express5800のラックマウントタイプで、2コアのXeonが２つ搭載されているので4コアということになる。メモリは２GB搭載と文句無し。更に元々raidが組んであったらしいUltra SCSIのディスクアレイが内蔵されている。5スピンドルで４つをraid 5に、残りひとつをboot用にしていたと思われる。

当然ながら元々使われていたWindows 2000 Serverは消されている。

これにDebian系のLinuxをタワー型のExpress5800機と同様にインストールして使うつもりで購入。

とりあえずものが届いたのでディスプレイとキーボードを接続して電源を入れてみた。BIOSの画面が立ち上がり問題なさそう。

手持ちで容易したDebianのnetinst CDを入れて立ち上げようとしたがどうもCDから立ち上がってくれない。

これには悩んだ。同じ機種でCDが読めないとかいう出品もあったので、これも読めないのかと諦めかけたが、古いKnoppix 3.7のCDを入れたら立ち上がってペンギンが４匹現れた。なんだ読めるじゃないか。

ということは読み損ねているのかと、CDのリードヘッドの部分を綿棒で擦ってみたら真っ黒になった。汚れていただけだった。

以降は快調に読めるようになり、あとはどれをインストールするか。

Debianでもいいけど、Ubuntuもいいらしい。同じDebianベースだし。

早速インストールしてみた。が、どうもディスクアクセスが遅い。

raid 5で組んでいるので遅いとは言えるが、なんか変だ。仮想コンソールを切り替えて、ログを見ると、ディスクエラーらしきログが頻繁に流れている。ディスクへの書き込みのタイミングと同期しているので間違いない。

むう、ディスクもだめか。

それだけでなく、時々CPUから謎のNMIが発生してカーネルがpanicして止まることがある。むう、CPUも怪しいか？

それでも最後までインストールできそうなのだが、肝心のブートローダーをインストールする段階で失敗する。

ちゃんとraidディスクアレイは認識されているのに何故ブートローダーがインストールできんのだ。

ちょっと調べると、どうやらUbuntuのインストーラースクリプトに問題があるらしい。最近のLinuxのデバイスファイルは少々小難しいことになっていて、デバイスファイルノード名以外に、UUIDとか様々な識別方法がサポートされている。しかしサーバー機特有のraidドライブに関しては十分対応していないくさい。

そうなるとraidコントローラーを介してわざわざ使うのは障害になるということなので、オンボードのUltra SCSIコントローラーのコネクタにディスクアレイからのscsiケーブルを接続して、そちらで通常のSCSIドライブとして扱うことにした。これなら昔からサポートされているはず。

するとディスクエラーはまったく出なくなった。しかしNMIは相変わらず出て時々panicする。

どうも２枚もraidコントローラー(Mylex AcceleRaid 160)が刺さっているのが気になるので、２枚とも抜いてみた。

するとNMIも発生しなくなった。こいつが原因か？

このサーバー機は無駄にカードが刺さっている。オンボードのUltra SCSIの他にスロットにUltra SCSIのカードが刺さっている。たぶんバックアップ用のストリーマーテープドライブ用だろう。

ようやくインストール完了かと思ったが、今度はブートしてもrootファイルシステムが見つからないといってinitramfsシェルに落ちてしまう。

これは原因がしばらくわからなかったけどシェルに落ちた時点では、ちゃんとrootファイルシステムの入ったドライブのブロックデバイスノードが出来ている。おかしいなとかなり悩んだが、同様の症状を訴えていたUbuntuフォーラムの記事を見つけて、rootdelay=を指定しないといけないということが判明した。

デフォルトでカーネル立ち上がり時のログは表示されないようになっているのだけども、そのオプションを消して立ち上げると、まだSCSIドライブを認識するずっと前でinitramfsシェルに落ちてしまっていることが確認できた。

結局rootdelay=60を追記して起動から60秒ぐらい時間猶予を与えると、ようやくrootファイルシステムがマウントできるようになって立ち上がるようになった。なんと、SCSIのドライバがバスリセットに３０秒もかけているのと、一台一台認識に時間を要していたので15秒とか待てば良いはなしではなかった。

Ubuntuのnetinstall CDのレスキューモードであれこれ修復を試みたりしたので、rootファイルシステムには最小構成しか入ってなかった。

とりあえず、/etc/apt/source.lstを書き直して外からパッケージを拾ってこれるようにして、必要なパッケージをインストール。

ようやく使える環境ができた。

しかもカーネルのビルドとか早い。今まで500MHzで２時間かかっていたのが、１０分もかからない。

これにアルバイト用の作業環境を整えていくことにしよう。

なにげに最新のDebian/Lennyのnetinst CDはデスクトップPCにインストールしやすくなっている。

CDを挿入するとWindows用インストーラーが立ち上がってインストールの段取りをしてくれる。

我が家のPCはCDからの起動を優先しているので、立ち上げなおすとCDから立ち上がってしまうが、そこでinstallを実行してもちゃんと空き領域にインストールすることができる。

まっさらなHDDにインストールするのと違って少しやっかいだけど空き領域全部を使えば簡単にインストールできる。

全部使うのはもったいないので、一旦rootパーティションを削除して少ないサイズのものを作り直してインストールを決行。

最後にGrubブートローダーをインストールする段階でWindowsが既に入っているのを認識してくれて、そちらにGrubをインストールしデュアルブートにしてくれた。

立ち上げ直すと、Grubメニューが出てデフォルトでDebianが起動。

こちらの方がWindows XPより立ち上げ時間が短いし、Norton先生もいないのですぐ作業ができる。

今度からこっちをメインにしよう。

アルミニウムは精錬に大量の電力を必要とすることから電気の缶詰と称される。

ソフトウェアはそうした観点から見ると、さしずめ時間の缶詰だろう。

ソフトウェアを精錬（開発）するには膨大な年月の積み重ねが必要とする。

既存のソフトウェアやそのソースコードはまさにそれを作った人達が費やした時間の固まりでもある。

ready madeなソースコードを流用することで、ゼロから新規に開発するよりも時間を節約することができるのはそのためである。

実際には流用するにも、それを理解するための最低限の時間を費やす必要がある。それが短い時間で済むか永遠と終わらないかは、それまでにその分野でどれだけ知識を獲得するのに本人が時間を割いてきたかによって１０倍も１００倍も違うのは当然である。

先日入手したNEC Expressサーバー機のSCSIドライブがどうも怪しい。

時々立ち上げた直後にビルドとかファイル操作を行う時にたまに回復不能なディスクエラーが生じて代替処理が行われる所為でコマンドプロンプトが長い時間返らなくなることが度々あった。

大抵は何事も無いが、読み込み時に代替処理が発生すると、以前あった内容が失われるので、そのファイルは壊れてしまう。

それがビルドの際に使われる実行ファイルの事が良くある。ldとかがsegment faultで異常終了する。

仕方がないのでツールのツリーをばっさり削除するかリネームして再度ツールが再インストールされるようにすると解消していた。

しかしこのままにしていると、通常のソースファイルやビルド済みのバイナリファイルが壊れたりすると怖い。

どうりで入手したときのraid構成から最初のドライブが外されていた訳である。

このドライブを使い続けるのは怖いので、別のドライブにOSから全部インストールし直すことにした。

最初にSCSIコントローラーのBIOSメニューで別のドライブのバッドブロック検査を行って１個代替え処理されたぐらいなのでそれを使うことにする。

ちょっとCD-ROMドライブがCD-Rの種類によっては全然読み込みが出来なくて難儀したが、CD-RWメディアだとスムーズに読み込めてインストールも完了。ユーザファイルは前のドライブをマウントしてコピーしてお終い。

今のところエラーは起きていなさそうだ。

暇が出来たらraidコントローラーを挿して余っているドライブでraid構成を試してみたい。それ以前にraid構成のドライブにgrubとかがインストールできない問題があったのでだめかもしれない。

起動時にBIOSが古くて実装されているXeonプロセッサーが新しすぎて対応するuCodeが無いとかいうエラーが出るのでBIOSがアップデートできないかと思っていた。

暇になったので検索したら出てきた。

Express 5800 120Re bios updateか本体に張ってあるシールにある型番 N8100-817 bios updateで検索すると見つかった。

NECのExpress 5800のサポートはさすがだ。ちゃんとBIOSとBMSのファームウェアアップデートがダウンロードできるようになっている。

ダウンロードした自己解凍ファイルはBIOSとBMSの二つのサブディレクトリを展開する。

READMEに書かれている方法によるとExpress 5800に付属のbuilder CD-ROMが必要になるが、どうやらこれはアップデート用FloppyにMS-DOSシステムを書き込むために必要なだけらしい。当然builder CD-ROMなど失われているので、手持ちのPC用MS-DOSのブートディスク（おそらく起動用に作成したFloppyでも良いかも）を立ち上げて、その後でそれぞれ展開されたBIOSとBMSのディレクトリの内容をコピーしたFloppyに差し換えてautoexecを起動すれば良いはず。

やってみたら、問題なくアップデートが出来た。

やっと起動時の赤いメッセージも出なくなった。ちゃんとプロセッサーのリビジョンをサポートしているBIOSになったということに。

もともとこの個体はN8100-817という型番からして1.8GHzのXeonが一機搭載されたモデルのはずだが、Xeon 2.4GHzが二機搭載されたN8100-818形にアップグレードされている。最新の型名のはIDEがSATAになっていてBIOSもPhenix BIOSとまるで違う構成になっているので注意が必要だ。

BIOSをupdateしたExpress 5800を立ち上げ直す際に、BIOS update用に接続していたVGAディスプレイにどっかで長年見覚えのある

Loading, please wait...

が表示されっぱなしになっていた。

GRUBブートローダーがブート用のlinuxシステムをロードして立ち上げている最中なのだけれども、デバイスが認識されてドライバがロードされるまでに相当時間がかかるらしい。手元のExpress 5800ではそれほど待たされないけれども、環境によっては２０分もこの状態が続くこともあるらしい。