rita.karing.jp(www.karing.jp)は、2013年3月にOSをVine Linux 4.2からVine Linux 6.1に一新しました。以下は、そのときの記録、およびtipsです。ここでは、サポート外である486機でVine 6.1を動作させる方法を紹介します。内容・各テーマに関しては前回のVine 4.1のインストールと重なる部分もありますので併せてご参考くだされば幸いです。rita.karing.jpに関する技術情報 486機でVine Linux 4.1

サーバー等の設定に関しては基本的に以前と変わっていませんので、そちらに興味のある方は旧版の技術情報をご参照ください。rita.karing.jpに関する技術情報

1. はじめに
2. インストールの概要
3. システム構成
4. RPM packages rebuild for i486
5. kernel configuration
6. upgrade
7. その他
8. 動作状況
9. まとめ


六年ぶりにメインサーバ・rita.karing.jpのOSをメジャーアップデートすることにしました。OSではなく486機自体をアップデート・リプレイスするのが正道なのでしょうが、色々と悩んだ挙句、今回もOSのアップデートで済ませることにしました。前回のOSアップデートでは自分なりの意義はあったものの、前回でさえ世間的には道化・酔狂の類だったのに、あれからさらに六年も経って、なお、この486機にこだわるのは、もはや宿痾でしかありません。諦めたら楽になれると何度思ったことか…、しかし、なんとか、踏みとどまりました。

2013年の今では秋葉原でさえローエンドのジャンクはPentium4なので、次期メインサーバとして待機しているFROLA 270EX(Pentium III 500MHz)を実戦投入してもジャンク者の面目は保たれるであろうとは思ったのですが、結局、Pentium IIIでは何のネタにもならないのでFROLA 270EXはPentium IIIがネタ化するまで封印の予定です。

ここで対象となる実機は以下のHITACHI FLORA 3010CTです。以前、HITACHIのサイトでこの機体がバッテリーレスであることを確認したので、かつてはこの機体のページもあったはずなのですが、現在、HITACHIのサイトでは見つからないという幻の機体です。このFLORA 3010CTは、前述の通り、ACアダプタオンリーのバッテリーレス設計になっており、現在では絶滅した狭義のラップトップ機です。またSCSIコネクタにはPC98用とも言えるアンフェノールハーフピッチが、BIOSのバッテリーには通常のボタン電池ではなく、MacのPRAM用として知られるER3Sが使われており、PC/AT黎明期の息遣いを感じさせてくれます。しかし、買った当時でさえ十分にジャンクだったのに、あれから十年以上も不眠不休で動作し続けるとはまったく思いもしませんでした。壊れたら晴れて解放されるのに…。

HITACHI　FLORA　3010CT

CPU	Intel 486DX4/75MHz
RAM	32MB
HDD	IBM IC25N020ATCS04-0 20003MB
on board video chip	WD90Cxx
LCD	9.8inch TFT 256色
on board sound	ESS688
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

さて、実は我がLANには486機がもう一台存在しています。FROLA 3010CTは我がLANのメインサーバゆえ簡単には止めることができません。よって、新環境の構築・検証には別な486機が必要です。その機体は、今は亡きCOMPAQ DESKPRO XE4100で、今回のOSアップデートに際し、事実上の対象となった以下の機体です。BIOSの設定はDOS上で実行するという変わり者です。

COMPAQ DESKPRO XE4100

CPU	Intel 486DX4/100MHz
RAM	32MB
HDD	実験機のため不定(IDEx1)
on board video chip	COMPAQ AVGA VRAM 1MB
CD-ROM	NEC CD-ROM DRIVE:28B
on board sound	Windows Sound System
SCSI	adaptec aha1510A
ethernet card	3Com 3c509TP
modem	Microcom V34.ES II

インストールするOSはVine Linux 6.1です。Vine 6.1は、バイナリがi686に最適化されており、486機では動作しません。その他、メモリ量、インストールメディアの問題で486機には通常のインストールもできません。よって、動作・インストール可能な他機でインストールし、そこでi486の環境を整え、完成したハードディスクを対象の486機に移し替えることになります。

実際では、qemu上に通常のインストールを行い、486用のRPMに入れかえていき、入れ替わったところでqemuをISAオンリー・CPU=i486の設定で動かし、調整した後、実験機の486機(COMPAQ DESKPRO XE4100)に移し替え、さらに調整し、最後に実機(HITACHI FROLA 3010CT)に移し替えて最終調整、完了となりました。

この過程における最大の問題は、大量のRPMパッケージをi486用にリビルドすることです。Vine 4.1の時は、glibc、kernelなど極少数の限定された重要パッケージのみのリビルドですみましたが、Vine 6.1では使用するRPMパッケージすべてをリビルドする必要があります。実際のリビルドではスクリプトで回すだけなので時間はかかってもそう大変ではないのですが、数がたくさんあるとその中にリビルドできるはずなのにリビルドできないパッケージも出てきます。現実的・具体的にはそれらに対する対応が最大の問題となります。この詳細については後述します。

なお、前回、Vine 4.1の486機へのインストールで最も苦労したのはrpm-4.4.2がi486にとって不正な命令(rdtsc)を発してしまうことでしたが、Vine 6.1のrpm-4.8.1では時間の計測にはrdtscからgettimeofday()を使うように変更されており、ソースを修正する必要がなくなりました。


Vine 6.1を486機で動作させるには使用するRPMパッケージすべてをi486用にリビルドしなくてはなりません。このリビルドの手間を最小化させるため不必要なパッケージはインストールしないようにします。そのためVine6.1のインストール時には最小構成を選択しましたが、それでも700MBを越えてしまう上、自分が想定していた必須パッケージがかなり入っておらず、落ち着くまで意外に手間取りました。

この機体はサーバなので基本的にはその関係パッケージのみインストールすれば良いのですが、一連の開発パッケージもインストールしてあります。原則としてリビルドはパワーのある他機で行なっているとはいえ、実機上でのリビルドも何かの保険として必要でしょう。というわけで、インストールパッケージが芋づる式に増えています。

以下が、rpm -qaの結果です。現在、493パッケージがインストールされています。前回、Vine 4.xでは375パッケージだったので30%強の増量、前回は開発パッケージがほとんどインストールされていなかったことを考えると微妙に少ない印象です。

rpm_qa.txt


ここではVine 6.1のRPMパッケージをi486用にリビルドします。対象のRPMパッケージは前項で取り上げたものになります。kernelについては次項で、別途、言及します。リビルドはパワーのある他機(Vine 6.1)で実行していますが、場合によっては実機でも行っています。新たにリビルドされるパッケージの命名規則は、specファイル等の修正が何もない場合は、i686.rpmがi486.rpmに変わるだけ(rpmbuildの生成に従うだけ)で、SRPMに何らかの修正が加えられている場合は、リリース(vl6)の後に何らかの値が付加されます。

apt-get source XXX
rpm -i XXX-x.x.x-xvl6.src.rpm
rpmbuild --target i486 -ba rpm/SPEC/XXX-vl.spec

最初は、すべてのRPMパッケージをi486用にリビルドし、それに入れ替えたインストールメディアを作成する予定だったのですが、specファイルの修正等では単純にリビルドできないもの(libproxy, hplip, etc.)がいくつかあり、断念しました。ここで方針を転換、必要なものだけをリビルドすることにし、リビルドできないというリスクを軽減、その問題を回避しました。以下、問題と解決法です。

　リビルドできない

　illegal instructionで実行不能
　その他

　未インストールパッケージ


ここでは、現時点(2013-03-27)での最新版、kernel-3.0.68-1vl6.src.rpmが対象です。

kernelに関しては、CPUタイプを486に変更して再構築したものが問題なく使えれば、その後の最適化・軽量化も容易なのですが、Vine 6.1のkernelでは新しいIDE・ATAドライバが当該の環境に対応しておらず、結果、この単純な設定変更で再構築したkernelでは/をmountをできずにkernel panicになります。kernelのDocument的には、新しいIDE・ATAドライバはISAには対応してない、ということではなく、厳密にはチップセットの問題のようなのですが、いずれにせよ、この環境では新しいドライバでハードディスクを認識させることができませんでした。というわけで、新しいIDE・ATAドライバはあきらめ、古いIDE・ATAドライバを有効にし、genericなドライバを組み込みにして対応しています。

最適化・軽量化については、不要と思われる機能、負荷の大きい機能は無効化する方向で、ドライバ関連も不要なものは無効化し、必要なものも極力moduleにすることとしました。最終的にkernelは1.1MB弱に収まり、目標だったboot diskの作成も可能となりました。なお、この最適化・軽量化の過程において無効化で問題が生じた設定は、Support for large (2TB+) block devices and files (LBDAF)、Dnotify support (DNOTIFY)、Inotify support (INOTIFY)でした。LBDAFを無効にするとext4がread-onlyでしかmountできなくなり、DNOTIFYの機能にはNFSが依存しており、INOTIFYの機能にはudevが依存しています。

486用のconfigファイル

また、linux-2.6.36以降には、i82365(ISA PCMCIA)の動作に問題(カードを正常に認識できない)があり、この不具合を回避するためにパッチをあてています。詳細は省きますが、この不具合はドライバの問題ではなく、1MB以下のメモリを割り当てることができなくなっているためとのことで、このパッチはその制限を解除しています。副作用については不明ですが、現状、問題なく動作しています。ただし、この解決策はPCIバスが無効化されているときにのみ有効で、PCIバスを有効にすると対象箇所を削除していてもその不具合が再発します。

linux-3.0.68-isapcmcia.patch

最後に、それらのことを踏まえてkernelをRPMパッケージにします。新たに用意するファイルは前述の二つで、486用のconfigファイルは1行目にARCHを設定しておきます(# i386)。後はspecファイル・kernel-vl.specを修正し、i486でもリビルド可能にします(kernel-vl.spec.diff参照)。これにより、ターゲットをi486に設定して生成されるパッケージは、kernel-3.0.68-1vl6g1.i486.rpmとなります。

kernel-vl.spec.diff


現時点で最新のkernel-3.0.68-1vl6は、この企画がほぼ完了していた3月の下旬にアップされました。なので、この企画で実際の対象となっていたkernelはその前のバージョンの3.0.60-2vl6でした。この二つに大きな差はありませんが、kernel-3.0.60-2vl6.src.rpmにはPCIをはずすとmakeできないという不具合がありました。原因はarch/x86/kernel/setup.cのsnb_gfx_workaround_needed(void)がPCIバスの無効化に対応していないからで、当初は、PCIバスが無効化された時はこの関数のPCIに関する部分を無効化するような以下のパッチをあてていました。この不具合は、kernel-3.0.68-1vl6.src.rpmでは修正されています。

linux-3.0.60-nopci.patch


Vine 6.1のRPMパッケージはi686に最適化されているため、この486機には直接インストールできません。つまり、aptによるパッケージのアップデートができないので、なんらかの対策が必要です。

ここでは、アップデート可能なパッケージの選出とそのリビルドまでをスクリプトで自動化し、インストールは確認しながら手作業で行うこととしました。前述したように、リビルドは必ずしも問題のないパッケージを生成するわけでないので、rpmbuildがエラーを出さなくても単純にインストールするのは躊躇われます。また、リビルドをパワーのない実機で行うのは非現実的なのでリビルドまでは別機で行います。以下が、そのスクリプトです。

apt-upgrade.sh

使用法は、まず、実機で全インストールパッケージを下記のコマンドでリスト化し、
$ rpm --qf %{NAME}:%{VERSION}-%{RELEASE}\\n -qa |grep -v gpg-pubkey >rpm.list

リビルド機にて、そのリストで当該のスクリプトを実行します。
$ apt-upgrade.sh rpm.list

最終的な結果は次のような出力になり、UPDATEはアップグレードするべきパッケージは存在するが、リビルドに問題が予想され、保留されていることを意味し、BUILD O.K.はリビルドでrpmbuildがエラーを出さなかったことを意味し、O.K.は486機用にリビルドされたアップグレードパッケージがすでに存在することを意味します。

2013-02-15 Fri 12:39
BUILD START
UPDATE kernel-headers:3.0.50-1vl6a:3.0.60-2vl6:kernel
BUILD O.K. libxml2-devel:2.7.8-5vl6:2.7.8-6vl6:libxml2
UPDATE kernel:3.0.50-1vl6g:3.0.60-2vl6:kernel
O.K. libxml2-python:2.7.8-5vl6:2.7.8-6vl6:libxml2
O.K. libxml2:2.7.8-5vl6:2.7.8-6vl6:libxml2
BUILD O.K. libtiff:3.9.5-4vl6:3.9.5-8vl6:libtiff

実際の運用では、一週間に一度、自動実行しています。メインサーバである486機で全パッケージのリスト(NFSによる共有ファイル)を作成した後、WOLでリビルド機を起動させ、cronによるこのスクリプトの実行を待ちます。実行完了後、その結果はメールで私のケイタイに送られます。この時点でログインユーザが存在しなければ、スクリプトは自機をshutdownし、ログインユーザが存在するならば何もせずに終了します。


ここでは、これまで詳述しなかったその他の関連事項について記述します。

・QUEM
この企画の試行錯誤において最大の活躍をしたのはquem(0.11.0)です。何度もHDDを取り替えたり、再起動を繰り返したりを実機で行うのは非常に面倒です。とくに正常にbootできるkernelができるまでは、仮想環境を使わない限り、HDDに試作のkernelをコピーするには内蔵のHDDを取り外して、外付けするくらいしかありません。これらを仮想環境で行えると作業効率が格段に向上します。

正常にbootできるkernelを作成するため、qemuのマシンタイプはISAPC(PCIのない環境)にCPUは486に設定し、実機をエミュレーションさせました。しかし、この環境下で動作するkernelを作成し、i486用の環境を整え、そのHDDを実機に移してみるとgrubが正常に動作せず、bootできませんでした。bootをクリアした後も、qemu上では問題がなかったのに実機上ではillegal instructionが出まくりました。kernelのconfigurationで一番苦労したIDE・ATA周りではqemuのISAPC設定は期待・想定した動作をしてくれたのですが、qemuのCPU設定は命令セットをエミュレートするものではないようです。

前回のOSアップデートの時もqemuは大活躍し、その時は特別な設定なしに使えていたと記憶しているのですが、今回はそのままではネットワークが使えませんでした。新しいqemuでネットワークを使用するには、ネットワークに関する権限が必要で、rootで実行するか、/dev/net/tunおよびqemu-ifupに適切なパーミッションを設定した上でネットワークに関する権限を付与されたqemuを実行する必要があります。具体的には

# setcap cap_net_admin=ep /usr/bin/qemu

でネットワークに関する権限を付与します。いわゆる、capabilityというkernelの新しい機能です。


・リビルド機
再三再四登場してきたリビルド機ですが、ここで我が最新のジャンク集合体に言及します。マザーボードは、EPSON Endeavor Pro3500の抜き取りマザーで秋葉原のGENOにて1,000円で購入。この板は、ASUSTeK P5WDG2 WSの廉価版OEMでIntel 975X+ICH7で構成されています。CPUは、Pentium4 651 3.4GHz、じゃんぱらで200円でした。他のパーツは部屋に転がっていた物が適当に使われています。200円のCPUながら当LAN内における最新ハイパワーマシンです。

momo.karing.jp

CPU	Pentium4 651 3.4GHz
RAM	DDR2 2048MB
マザーボード	EPSON Endeavor Pro3500
on board sound	Intel HD Audio
on board NIC	Marvell 88E8053
Video Card	Radeon HD 2400 PRO
SATA HDD	WDC WD2500JD-19H 250GB
SATA HDD	WDC WD10EADS-00L 1TB
DVD-RAM	MATSHITA DVD-RAM SW-9581
ケース	DELL DIMENSION XPS D300

・boot disk
最近は、フロッピーディスクを持たない環境が標準化し、kernelも肥大化、boot loaderもgrubが主流になるなど、ハード・ソフト両面からboot diskの存在自体が忘れ去られていますが、kernelを1.1MB程度にすることができたので懐古趣味からboot diskを作成してみました。

現在、boot loaderとしてはgrubが一般的ですが、grubは高機能のため大きく、それだけでフロッピーディスクがいっぱいになってしまいます。なので、ここでは、boot loaderにはliloを使います。Vine 6.1にはliloは用意されていないので野良ビルドしました。個人的には、現在でもboot loaderはliloで十分で、grubは非常用ツールの意味・価値しかないと思っています。日常作業としてのbootでは、技術的に高機能なgrubを使うよりも、現状、より柔軟な起動画面設定が可能なliloで多彩な起動画面を表示する方が文化的に豊かだと思います。

作成の手順としては、フロッピーディスク上にファイルシステムを作り、それをmountし、kernelと必要なデバイスファイルをコピーし、lilo.confを書き、mountポイントを/にして、/sbin/lilo -r /mount/pointで以前は上手くいっていたはずなのですが、liloを実行するとDevice busyで上手くいきません。仕方がないのでフロッピーディスクの仮想イメージ上にboot diskを作成し、それをddで実デバイスに書き戻してやることにしました。
 
# dd if=/dev/fd0 of=bootdisk.img
# mkfs.ext4 bootdisk.img
# mount bootdisk.img mnt
# mkdir mnt/boot
# mkdir mnt/etc
# mkdir mnt/dev
# cp /boot/vmlinuz mnt/boot
# cp -a /dev/loop0 mnt/dev
# cp -a /dev/hda2 mnt/dev
# cat >mnt/etc/lilo.conf <<EOF
boot=/dev/loop0
disk=/dev/loop0
bios=0x00
sectors=18
heads=2      
cylinders=80
timeout=50
prompt
image=/boot/vmlinuz
        label=linux
        root=/dev/hda2
EOF
# lilo -r mnt
# umount mnt
# dd if=bootdisk.img of=/dev/fd0

lilo.confの/dev/loop0、およびroot=/dev/hda2は環境によって値が異なりますので注意してください。いまさら、こんなことをやってみる人はいないと思いますが…。


パーティション構成は、20GBのうち128MBが/dev/hda1に割り当てられ、/bootにmountされています。いわゆる1024シリンダの壁に対する処置です。残りの容量はすべて/dev/hda2に割り当てられ、これが/になります。また、/tmpには、/tmp.imgという128MBのイメージファイルをループバックでmountしています。これは、ディスクアクセスの軽減を目的に読み出し時のatime更新を行わないようにしてあるのですが、/tmpに関してはtmpwatchがatimeを参照するので/tmpだけは別パーティションにしてnoatimeの設定をはずすためです。swapは、/swap.imgという128MBのswapファイルで対応しています。

# df

Filesystem	1K-blocks	Used	Available	Use%	Mounted on
rootfs	19101832	7421960	10709548	41%	/
/dev/root	19101832	7421960	10709548	41%	/
devtmpfs	14508	76	14432	1%	/dev
none	14620	0	14620	0%	/dev/shm
/dev/hda1	124427	23147	94856	20%	/boot
/dev/loop0	126931	5666	114712	5%	/tmp

以下は、telnetでloginして何か作業をしているときのメモリ使用状況です。負荷が低いときは実メモリに収まるのでSwapを使いすぎなんじゃないのか？と思わないでもないのですが、Swapが設定してあれば、kernelはどうしてもSwapを使いがちになってしまうのは仕方のないところです。かといって、この状況下でSwapなしで運用するのも躊躇われますが、Vine 2.6の時は、Swapは下手の長糸と見得を切り、堂々とSwapなしだったことを思うといささか小心になったと思います。

# free

	total	used	free	shared	buffers	cached
Mem:	29704	28648	1056	0	1828	7632
-/+ buffers/cache:		19188	10516
Swap:	131068	26388	104680

以下は平凡なcpuinfoです。bogomipsは36.86でリビルド機(Pentium4 651 3.4GHz)のbogomips(6798.98)と比較すると誤差でしかないですね。

# cat /proc/cpuinfo
processor    : 0
vendor_id    : GenuineIntel
cpu family    : 4
model        : 8
model name    : 486 DX/4
stepping    : 0
cache size    : 0 KB
fdiv_bug    : no
hlt_bug        : no
f00f_bug    : no
coma_bug    : no
fpu        : yes
fpu_exception    : yes
cpuid level    : 1
wp        : yes
flags        : fpu vme
bogomips    : 36.86
clflush size    : 32
cache_alignment    : 32
address sizes    : 32 bits physical, 32 bits virtual
power management:


こう文章にしてみると、何か、サラッと書いてあり、そんなに大変だったようには感じませんが、なんだかんだで大変でした。「ここはあくまで技術情報なので感情的なことは避ける」という建前は、精神衛生上、非常に良くない…、と思い悩むこともしばしば…。まぁ、とにもかくにも、正月休みから始まったこの騒動もまる三ヶ月で終了です。最近は少し忙しく、なかなか時間が取れなかったものの、なんとかこのサイトの年度単位規約に収まってホッとしています。喉奥に刺さった小骨のように残っていた我がLAN唯一のEUC-JP環境もついになくなりました。

しかし、まるでRPGでした。ストーリーを進めるごとに様々な態様で現れる不具合という敵、そしてそれに用意された多彩な解決策…。特にkernelのボスキャラ戦では、小ボス、中ボス、ラスボスのPCIをめぐる相互関係にはシビレましたね。脚本は誰だ！とつい叫びたくなったものです。この物語のクライマックスは、486用のVine 6.1が実験機上で完成し、そのHDDをついに実機に移したときでした。なんと、ISAのpcmciaがバグっていて使えないことが完成目前で判明したのです！最後の最後でここまでやってきたことが全て無駄になるかもしれない恐ろしい事態です！まさにラスボスに相応しいkernelのバグでした。

なにはともあれ、これはRPGなので回避策は用意されており、一つはバグのないVine 6.0の一番最初のkernel-2.6.35を使うことで、もう一つはこのバグ用のパッチをあてることでした。しかし、最初のkernelを使い続けるなんてことは世界の半分で我慢するようなものだし…、とはいえ、このパッチはISAバスオンリーでないと効果がないのに、対象のkernel-3.0.60-2vl6にはISAバスオンリーにする（=PCIをはずす）とmakeできない不具合が…。実際は、PCIをはずすとmakeできない不具合はすでに対処済みだったのでそんなにハマらなかったのですが、振り返ってみるとホント良くできたシナリオだったと感心してしまいました。

というわけで、このサーバはVineの偶数バージョンを使用する慣例なので次回はVine 8の予定なワケですが、正直、VineのSRPMのリビルドにはいろいろな意味で疲れました。今後のことは未定ですが、OS云々より本当はハードの方が問題なんでしょうね。次期メインサーバとして待機しているFROLA 270EX(Pentium III 500MHz)、そして次次期メインサーバとして待機しているFROLA 270W(PentiumM 1.73GHz)、彼女たちの活躍の日はいつ訪れるのでしょうか。ちなみに、ここでは、フローラ、フローラ言ってますが、もちろん、フローラではなくビアンカを選んでいます。

2013-03-27 Wed 12:22