rita.karing.jp(www.karing.jp)は、2007年3月にOSをVine Linux 2.6r1からVine Linux 4.1に一新しました。以下は、
そのときの記録、およびtipsです。ここでは、サポート外である486機にVine 4.1を
インストールする方法を紹介します。おそらく、最近のrpm系ディストリビューションでも
応用が効くはずです。
サーバー等の設定に関しては基本的に以前と変わっていませんのでそちらに興味のある方は旧版
の技術情報を参照ください。→
rita.karing.jpに関する技術情報
1. はじめに
2. インストールの概要
3. 486用のkernel
4. 486用のrpm
5. 486用のglibc
6. インストール
7. pcmciaの設定
8. 486における諸問題
9. まとめ
いまさら無理をしてまで486機を使い続けることにメリットはあるのか、と問われると答えに窮するの
ですが、かと言って個人のサーバー程度では十分に使用できるものを簡単に捨ててしまうのも気が
ひけます。また、この486ラップトップ機は、スペックでは劣っても、SCSI内蔵のその拡張性はなかなか
他のノート機では代替が効かないのでまだまだ使い続けることにしました。
巷では、昨今の肥大化したシステムでは486機は実用に堪えないのではないかと思っている方も多いかと
思われますが、肥大化の最大の原因はおもにGUIデスクトップのためであり、サーバー機としてならば、
バージョンアップ、世代交替による肥大化はさほどではありません。むしろ低スペックのマシンでこそ、
バージョンアップ、世代交替による進化洗練を実感できます。この486機では、Vine 2.6r1からVine 4.1に
アップデートし、CGIの実行速度が二倍以上になり、以前には処理が不安定だったCDクオリティ
のWAVファイルがスムーズに再生されるようになりました。
ここで対象となる実機は以下のHITACHI FLORA 3010CTです。HITACHIのサイトには見当たら
ない幻の機体です。当時としてはハイエンドのラップトップ機だと思われるのですが、なにゆえ
記録から消されているのか不思議です。
ちなみにこの機体はAC駆動オンリーのバッテリーレス設計になっており、現在では絶滅した
狭義のラップトップ機です。またSCSIコネクタにはPC98用とも言えるアンフェノールハーフピッチ
が、BIOSのバッテリーには通常のボタン電池ではなく、MacのPRAM用として知られるER3Sが使わ
れており、PC/AT黎明期の息遣いを感じさせてくれます。
HITACHI FLORA 3010CT
| CPU |
486DX4/75MHz |
| RAM |
32MB |
| HDD |
FUJITSU MHD2032AT 3253MB |
| Video chip |
WD90Cxx |
| LCD |
9.8inch TFT 256色 |
| on board Sound |
Soundbraster Pro 互換 |
| on board SCSI |
aha1510 (no pcmcia) |
| pcmcia |
Vadem VGｰ468 |
| Ethernet PCカード |
Fujitsu FMV-J182A |
| Ethernet PCカード |
Toshiba Advanced Network 10/100 |
外部SCSI機器
| SCSI DVD-RAM |
Panasonic LF-D200 |
| SCA HDD |
Seagate Cheetah 18GB |
| SCSI Scanner |
CANON CanoScan 300 |
| SCSI CD-R |
MATSHITA CW-7502 |
Vine 4.1は486機どころか公式にはISAバスさえサポートしていません。また、Vine 4.1のインストール
には最低96MBのメモリが必要で、それを満たす486機は極めて稀でしょう。それよりなにより、
そもそもインストーラのrpmは486機では動作しません。よって、486機にVine 4.1をインストールする
には、Vine 4.1をインストール可能な別機でインストールしてからそのHDDを移しかえるか、
もしくはVine 3.2からaptでアップグレードすることになります。
しかし、どちらもそれだけでは済みません。なぜなら、Vine 4.1には486機では正常に動作しない
パッケージがいくつかあるからです。とりあえず、クリティカルなものとしてkernel、rpm、glibcが
挙げられ、それぞれ486機用にビルドしたものをインストールする必要があります。
簡便のため以下よりおもに3.2からのaptによるアップグレードについて詳述します。おおまかな
流れは、まず必要な486用のパッケージを用意し、その後Vine 3.2をインストール、最新の状態にした
後、sources.listを4.1用に変更、aptをアップグレードします。ここでrpmがVine 4.1のrpm-4.4.2に
アップグレードされるのですが、このrpm-4.4.2は486機では動作しないので、それ以上インストール
作業を進めることができなくなります。ここで486用にリビルドしたrpmをインストールし、
さらに486用にリビルドしたkernelをインストール、このkernelでbootするように設定します。
その後、dist-upgradeを実行し、終了です。
先に486機では動作しないパッケージとしてglibcをあげましたが、Vine 4.1のglibcにはサポート対象
のi586、i686以外にもi386のパッケージが用意してあり、486機上で行うアップグレードの場合に
はi386用のglibcがインストールされるため特段の処置は不要です。ただし、別機で通常のインストール
を実行し、HDDを交換する場合は、通常、386用のglibcはインストールされないので注意する必要が
あります。
主題の実例では、PCIサポート、フレームバッファをはずし、ルートファイルシステムをmountするのに
必要なIDEドライバやファイルシステム(ext2,iso9660)のみをkernelに組み込み、その他、実機で必要な
ドライバのみをモジュール化しています。これらの最適化によってkernelを1MB弱に収めることができ、
昔懐かしいフロッピーのboot diskも作れるようになりました。なにかと制限の多い486機ではフロッピー
を活用できるのとできないのとでは大違いです。
もっとも、対象の環境に合わせ不要な機能を削ぎ落としていくことは意味のあることとはいえ、kernelのconfigは
一筋縄ではいかないそれだけで大きなテーマですので、ここで悩むよりインストール完了後に落ち着いて
手をつける方が合理的とも言えます。確実な策をとるならば、出来合いのconfigファイルのProcesser familyを
486機に変更する(CONFIG_M486=y)だけですますのも一つの方法です。
適当なconfigファイルができたら、kernel-2.6.16-0vl68.src.rpmを展開し、
# rpm -i kernel-2.6.16-0vl68.src.rpm
先に作成したconfigファイルをrpm/SOURCEにkernel-2.6.16-i486.configとしてコピーします。そしてその一行目を
# i386
に書き換えます。この値はスペックファイルのスクリプトがアーキテクチャを決定するために用いられます。
次に rpm/SPECS/kernel-2.6-vl.specを編集します。
i386 i586 i686 athlon
となっているすべての箇所にi486を加え、
i386 i486 i586 i686 athlon
とします。終わったら、--target i486でリビルドします。
#rpmbuild -bb --target i486 rpm/SPEC/kernel-2.6-vl.spec
出来上がったkernel-2.6.16-0vl68.i486.rpm、kernel-devel-2.6.16-0vl68.i486.rpmは実機での
インストールに備え適当なところに保存しておいてください。また、rpm実行時に依存関係
を解消するため、procps-3.2.6-0vl3.i386.rpm
nfs-utils-1.0.9-0vl3.i386.rpm modutils-3.2.2-0vl3.i386.rpm
libevent-1.1b-0vl1.i386.rpm openldap-2.3.27-0vl2.3.i386.rpm
libnfsidmap-0.16-0vl3.i386.rpmが必要なので合わせて準備しておきます。
kernelまでrpm化の手間をとらなくても良さそうな
ものですが、rpmのデータベースにkernelが入っていないと依存関係のためインストールされない
パッケージ(pcmciautilsなど)があるので何らかの方策が必要です。
Vine 4.1を486機にインストールしてみようと思い立ち、何が一番大変だったかと言えば、すでにrpmが486を
サポートしていなかったことです。時代の流れからもはや486機がサポートから外されるのは自然なことで、
そのことに関しては特に思うこともないのですが、とにかく困ったのはこのサポート外であることの情報が
まったく見つからないことでした
現行のrpmは、486には存在しないrdtsc命令を何のラッパーにも包まないかたちで直接発行しているため、486機
では不正終了してしまいます。この明確な仕様変更に関し、失敗談、成功談、その他まったく情報がないと
いうことは、つまり、誰も486機で試した人がいないということなのだと思われます。
ここは、一応、技術情報と銘打っている手前、あまり感情的なことは避けたいのですが、自分と同じ試み考え
を持った人がどこにも見つからなかったという冷厳な事実には失望しました。いや、孤独こそ我が友人、
これまでの己の人生を振り返る良い機会になりました。というわけで、このページを読む人も極めてマレで
しょう。今、これを読んでいるあなたは相当の奇人です。
なにはともあれ、このままではrpmは動かないのでpatchをあてます。ここではVine 4.1が対象ですの
で、Vine 4.1のrpm-4.4.2-0vl16.src.rpmにpatchをあてi486でリビルドします。当然ですが、リビルド
にはVine 4.1の(もしくはそれと同等の)別環境が必要です。なお、このpatchはtargetをi486にしたとき
のみ有効になります。
rpm-4.4.2-fake-rdtsc.patch
rpm-vl.spec(s1)
rpm -i rpm-4.4.2-0vl16.src.rpm
cp rpm-4.4.2-fake-rdtsc.patch rpm/SOURCE
cp rpm-vl.spec rpm/SPEC
rpmbuild --target i486 -bb rpm/SPEC/rpm-vl.spec
このビルドで以下のパッケージが生成されます。
popt-1.10.2-0vl16.s1.i486.rpm rpm-4.4.2-0vl16.s1.i486.rpm
rpm-build-4.4.2-0vl16.s1.i486.rpm rpm-devel-4.4.2-0vl16.s1.i486.rpm
rpm-libs-4.4.2-0vl16.s1.i486.rpm rpm-python-4.4.2-0vl16.s1.i486.rpm
出来上がったら実機でのインストールに備え、適当なところに保存しておいてください。
このpatchは、rdtscの擬似値を
作るものなのですが、実は、rdtscの実値がなくてもrpmは適当に動作してくれ
ます。rpm-4.0の頃には不要だったわけですし、同様の命令が存在しないIA32以外のプラットホームのことも考慮され
ているからです。
つまり、問題なのは486にとって不正な命令であるrdtsc命令を発行
してしまうことで、擬似値を与えるなどという回りくどいことをせずとも、rdtsc命令を出せないよう
に、rpm-4.4.2/rpmio/rpmsw.cにあるrdtsc命令を含むわずか一行を削除してしまえば486機上でも動作するよう
になります。擬似値を用いるにしろ、値そのものを無視するにしろ、いずれにせよはずれた道ですので、
トラブルシュートの経験則としてはより単純な方がお薦めです。ここで、わざわざ複雑な解決策をとって
いるのは単に検証のためです。
また、このpatchを有効にするとrpmの実行速度は著しく低下します。通常のrpmとこのpatchを有効にしたrpmをAthlon64 3200+上で動作比較してみたところ、ほぼ二倍の速度差がありました。rdtsc命令を
使うrpmのライブラリ関数はなんとrpm一度の実行につき少なくとも100回弱、多いときは数百回も呼び出さ
れるため、ほんのわずかなオーバーヘッドもたちまち積もり積み重なってしまうのです。そういうヘビーロード
な関数において、ベタ書きのrdtsc命令という言わばもっともオーバーヘッドの小さな手段がとられているのは
たいへん合理的なことです。そういう事情では486が無視されるのも仕方がないことと納得がいきます。
前述したように、glibcに関してはi386でビルドされたパッケージがVine 4.1にも用意されていますので、
別機でインストールしたなどでi586やi686のglibcがインストールされている場合はi386のglibcと入れ換えて
ください。486機上でVine 3.2からアップグレードする場合はi386のglibcがインストールされる
ので特別な操作は不要です。
この項ではaptによるアップグレードについて
詳述します。この作業は486機のパワーでは丸一日以上かかりますので、けっこう大変です。前述したよう
に486用のrpmには大きなオーバーヘッドがあります。486機のパワーではrpmのデータベース更新だけで
数時間を要したりするので気長に待ってください。可能ならば、aptによるアップグレードインストールは
避け、別機でインストールし、そこで486用の環境(kernel rpm glibc)を整え、HDDを交換する方がはるかに
簡単です。
また、
インストール法にかかわらず、486機の頃は昔懐かしい1024シリンダ問題がありますので、/bootは500MB以下
の第一パーティションに割り当てておくのが安全です。
Vine 3.2のインストールが終わったら、再起動し、aptで3.2を最新の状態にします。この例では3.2は
フルインストールされています。
# apt-get update
# apt-get upgrade
そして、これからVine 4.1へのaptによるアップグレードインストールを行うわけですが、まず、
先に用意した486用のパッケージを準備しておきます。また、このアップグレードの途中ではrpmが
使えなくなってしまうので、そのときrpmを486用のrpmに入れ換える手段を用意しなければなり
ません。このために、3.2のrpmを退避させておき、それで486用のrpmの入れ換えを行います。
# cp -a /bin/rpm /root/bin/
# cp -a /usr/lib/librpm* /usr/local/lib
これにより、librpm-4.0.4.so librpmdb-4.0.4.so librpmbuild-4.0.4.so librpmio-4.0.4.soが/usr/local/libに
退避させられます。なお、Vine 3.2のデフォルトでは/usr/local/libにはリンカのパスが通っていない
ので、/etc/ld.confに/usr/local/libを加え、ldconfigを実行しておいてください。
一通りの準備が整ったら、/etc/apt/sources.listをVine 4.1のsources.listで上書きし、aptを更新します。
# apt-get update
# apt-get install apt
このとき、アンインストールされるgcc glib-devel build-essential gcc-c++はアップグレード終了後
に入れ直します。
aptの更新が終了したらこの時点で486機ではrpmが使えなくなっているので、退避させておいた3.2のrpmで486用のrpmに
入れ換えます。
# /root/bin/rpm -Uvh rpm-4.4.2-0vl16.s1.i486.rpm rpm-libs-4.4.2-0vl16.s1.i486.rpm \
rpm-python-4.4.2-0vl16.s1.i486.rpm popt-1.10.2-0vl16.s1.i486.rpm rpm-build-4.4.2-0vl16.s1.i486.rpm
くわえて、486用のkernel 2.6でブートできるように設定します。先に用意した486用のkernelと依存関係を
解消するためのパッケージをインストールします。
# rpm -Uvh kernel-2.6.16-0vl68.1.i486.rpm kernel-devel-2.6.16-0vl68.1.i486.rpm procps-3.2.6-0vl3.i386.rpm\
nfs-utils-1.0.9-0vl3.i386.rpm modutils-3.2.2-0vl3.i386.rpm libevent-1.1b-0vl1.i386.rpm\
openldap-2.3.27-0vl2.3.i386.rpm libnfsidmap-0.16-0vl3.i386.rpm
そして、lilo.confを編集後、liloを実行してください。
終わったらdist-upgradeですが、その前にdist-upgrade実行中に生じる一時的なライブラリの不整合を
避けるため、先にlibxsltをインストールします。この一時的なライブラリの不整合は、aptが決定する
インストールオーダーの不正確さに起因するもので、rpmの%postスクリプトから実行されるscrollkeeper-updateを一時的に
セグメンテーションフォルトさせます。実際にはライブラリの不整合が解消された後、後続する
パッケージのインストールで手順にscrollkeeper-updateが再実行されるため実害はないのですが、気分が
よくないので対処しておきます。続いてdist-upgradeを実行します。
# apt-get install libxslt
# apt-get dist-upgrade
再起動後、アップグレードの過程でアンインストールされたgcc glib-devel build-essential gcc-c++を
再インストールします(gccはdist-upgradeで再インストールされているかもしれません)。
# apt-get install gcc glib-devel build-essential gcc-c++
また、Vine 3.2に存在しないためdist-upgradeではインストールされない
差分(grubなど)、逆にVine 4.1には不要な差分(Cannaなど)がありますが、それらも、適宜、
追加削除してください。これでVine 4.1へのaptによるアップグレードインストールは終了です。
kernel 2.6からデバイスの認識はおもにudevに任されるようになりました。しかしながら、ISA、それもPnPでは
ないデバイスとなるとudevからは見えないので自動的に認識されることがありません。つまり、486機時代の
古いpcmciaは自分で設定することになります。
とは言っても、単に既知のモジュールをロードしてやるだけなので特に難しいことはありません。
ただ、kernel 2.6のシステムではudevによるデバイス認識が前提なので、起動時のudevによるデバイス認識終了後、
できるだけ早くドライバをロードしてやるのが正攻法と思われます。よって起動スクリプトの一つにして
その一番最初に実行させることにしました。一旦、ドライバがロードされてしまえば後はudevが適当に管理して
くれます。
以下は、実機で使用中のスクリプトです。起動スクリプトの書式に従っているため少々冗長になっています
が、やっていることは、「modprobe i82365」だけです。
#!/bin/sh
# Startup script for ISA no-pnp pcmcia socket driver
#
# chkconfig: - 9 91
# description: for ISA no-pnp pcmcia socket driver.
. /etc/rc.d/init.d/functions
case "$1" in
start)
echo -n $"Starting pcmcia: "
modprobe i82365;RETVAL=$?
if [ $RETVAL = 0 ];then
echo_success
else
echo_failure
fi
echo
;;
stop)
echo -n $"Stopping pcmcia: "
echo_success
echo
;;
restart) /etc/rc.d/init.d/pcmcia stop
/etc/rc.d/init.d/pcmcia start
;;
*)
echo -n "Such options are not implemented: "
echo_failure
echo
exit 1
;;
esac
exit 0
上記を適当な名前で/etc/init.dにコピーします。仮りにpcmciaという名前にした場合、
# chkconfig pcmcia on
とし、各rcディレクトリにリンクをはります。 ntsysvで設定してもほぼ同じですが、ntsysvの場合、
実行しているrunlevelのみに設定されるので注意が必要です。
Vine 4.1は486をサポートしていないので、rpmのような不具合がどこに潜んでいてもおかしくありません。
現在、これまで挙げたパッケージの他、sash-3.7-6vl1が正常動作しないことを確認しています(sashは単純に
実機でリビルドすることで動作可能でした)。ただ、大概のものは、-march=i386でコンパイルされて
おり、OS上での整合性はともかく、単体のバイナリとしては486機でも
動作するのが建前です。Vine 4.1をサポート外の486機で使うというこの企画はその建前に依拠しています。
しかし、中にはrpmのようにその建前が通用しないものも存在します。今のところrpm以外の重要
パッケージでは見つけていませんが、その可能性には常に留意する必要があります。この労力こそが
サポート外の動作をさせるこの企画の最大のコストでしょう。
なお、そのようなパッケージに対応したら、不用意にVineオリジナルのパッケージに入れ換えてしまわ
ないよう、aptでHoldの設定をしておくのが賢明です。とりあえず、rpmを不用意にVineオリジナル
のrpmに入れ換えてしまうと大変苦労することになるので、まずはapt.confのRPMの項でrpmをHoldの
設定にしておきます。
RPM
{
Hold { "^rpm" ;}
}
さて、ここまで、486というCPUの観点から議論を進めてきましたが、古い機体へのインストール作業で
直面する問題は、CPUに起因するものだけではありません。とくにkernel 2.6からはデバイス自動認識の
ためudevが標準採用され、システムにPCIバスがあることを暗黙のうちに期待しており、ISAバスオンリー
のシステムではその恩恵を受けられないのみならず、想定外のトラブルを引き起こします。
また、kernel 2.6ではサウンド回りがOSSからALSAへ移行したわけですが、ALSAのサポートが十分
でなくOSSが手放せない古い環境では、ALSAデフォルトの各種設定には何かと悩ませられることでしょう。
残念ながら、開発者たちにとってそれらの問題を解決することはもはや費用対効果に見合いません。もし、
なんらかの不具合が出た場合は自己解決するしかなく、ここでの主旨としてはその対処法について
議論したいところなのですが、古い機体の問題解決に労力を費すよりも潔くあきらめるという選択肢の方
がはるかに合理的かつ合目的的である、というのが、この項における最終的結論です。
というわけで、486機であるrita.karing.jp(www.karing.jp)もOSをVine 4.1にアップデートし、なんとか
再稼働しはじめました。調子はボチボチです。cgiの実行は早くなったし、kernelの最適化も以前より
シビアに実行したし、今回のOSアップデートには概ね満足しています。
唯一不満なのはsambaが3.x系になって重くなったことでしょうか。sambaの負荷の状態によってsmbmountが
タイムアウトするようになりました。いままではそんなことなかったのに…。apacheが2.x系になって軽快に
なったのとは対照的です。起動時、netfsによるsmbmountが失敗しても再実行するようにはしてあるので今
のところ問題は出ていないのですが、自動運転の機体ではシステム全体に影響を与えるクリティカルな
部分を共有していたりするので、あまり頻繁に失敗するようならば、LAN内のファイル共有はNFSにしよう
かなとも思案中です。でも、事実上Windowsを使っていない身としては、世間様との接点を保つため
にもsambaにはこだわりたいんですよね。
ちなみにサーバーなどの設定はVine 4.1の流儀にあわせ、inetdからxinetdに変えたくらいで、ほぼ変わって
いません。今回のOSアップデートにおけるrita.karing.jp最大の変更点は、64MBのswapです。以前はswapなし
のRAM32MBのみで動かしていたのですが、多少、日和ました。実際には、kernelは厳しく減量して
以前使っていたkernel 2.4より小さくなっているし、仮想コンソールの数を三個から二個に減らしたり、
それなりの対策は講じたのでrita.karing.jpの実メモリ消費は以前とさほど変わらず、現在は、
使用中 17MB、バッファ/キャッシュ 12MB、swap 13MBくらいの内訳で、これなら、swapなしでも
なんとか行けそうなのですが、誰も褒めてくれないし、無理してもしょうがないと少し大人になってみました。
とにもかくにも、Vine 4.1を486機で動かすのはけっこう大変でした。ここにたどり着くまで様々な
紆余曲折がありましたが、とにかく情報がまったくないことには滅入りました。おそらく現行のrpm系
ディストリビューションを486機にインストールする情報が書いてあるページはジョーダン抜きで世界で
ここだけなのではないかと思います。もはや、希少価値と言うより、誰にも必要とされていない情報なの
でしょう。現行のrpm系ディストリビューションを486機で使っているのは世界で自分一人だけなのではないか、
インターネット上で動作しているサーバはこのrita.karing.jpだけなのではないか、と孤独な笑みを夕日にさらして背中で泣いてる男の美学…、
世の中、洒落のわからん奴らばっかだな、てな気分です。