rita.karing.jpに関する技術情報
486機でVine Linux 6.1

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. まとめ


1. はじめに

六年ぶりにメインサーバ・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


2. インストールの概要

インストールする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()を使うように変更されており、ソースを修正する必要がなくなりました。


3. システム構成

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

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

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

rpm_qa.txt


4. RPM packages rebuild for i486

ここでは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.)がいくつかあり、断念しました。ここで方針を転換、必要なものだけをリビルドすることにし、リビルドできないというリスクを軽減、その問題を回避しました。以下、問題と解決法です。

 リビルドできない
・udev-154-7vl6.src.rpm
udevが依存しているvideodev.hがVine 6.1に存在しないため、リビルドに失敗します。videodev.hはkernel-headersに含まれるのですが、3.0.xにはvideodev2.hしかありません。というわけで、Vine 5.2(kernel-headers-2.6.27-76vl5)から持ってきてリビルドしました。

・nss-3.12.10-1vl6.src.rpm
kernel-3.0.x用のファイル(mozilla/security/coreconf/Linux3.0.mk)が欠けており、kernelが3.0.xであるVine 6.1上ではリビルドに失敗します。Vine 6.0の最初のkernelは2.6.35でしたが、kernelに合わせてその後の適切な更新が行わなれていないためと思われます。正しいか否かは不明ですが、makeの前、Linux2.6.mkにシンボリックリンクをはるようにして対処しました。今のところ問題は出ていません。

・sane-1.0.21-1vl6.src.rpm
sane-1.0.21-1vl6.src.rpmのリビルドではドキュメントの生成で失敗しており、この原因は、Vine 6.1のlatex2htmlが、./sane.texという「.」が前置されたファイル名を受け付けないというものでした。この問題は、specファイルでdoc/Makefileの該当箇所を書き換えるようにして対処しました。ちなみにlatex2htmlが「.」が前置されたファイル名を受けつける環境は、Vine 5.xです。

 illegal instructionで実行不能
・net-tools-1.60-15vl6.src.rpm
・ntp-4.2.6p3-2vl6.src.rpm
・dev86-0.16.17-3vl6.src.rpm
illegal instructionで実行不能というのはi486用にリビルドされていないということです。rpmbuildの--targetでi486を指定しても、specファイル内でそれを理解する仕組みがないと無意味です。通常はoptflagsマクロが解決してくれるのですが、まれにこのマクロを使っていないものがあります。それが、net-tools-1.60-15vl6.src.rpmとntp-4.2.6p3-2vl6.src.rpmおよびdev86-0.16.17-3vl6.src.rpmです。解決法としてはi486の実機上でリビルドするか、specファイルでリビルドの際、-march=i486を有効化することです。

・grub-0.97-4vl6.src.rpm
486機用に整備したHDDに入れ替え、bootさせてみると再起動を繰り返すだけでbootできませんでした。これは、grubのstage2がi486用にコンパイルされていないからです。specファイルを見ると、optflagsマクロが有効になっておらず、加えて、glibcが静的にリンクされています。よって解決法は、i486の実機上でリビルドするか、specファイルでoptflagsマクロを有効にし、i486用のglibc-staticがインストールされている環境でリビルドすることです。

・module-init-tools-3.12-2vl6.src.rpm
bootが成功し、最初に驚いたのはkernelがmoduleをloadできないことでした。おかげでエラーを出しまくりました。これは、静的にリンクされているzlibのgzreadが問題で、configure --enable-zlib-dynamicでzlibを動的にリンクするか、i486用のzlibがインストールされている実機上でリビルドすると解決します。

・gcc-4.4.5-6vl6.src.rpm
gccの場合は、なぜかoptflagsマクロ内の-march=ix86オプションが削除されるようになっているので、それを修正してリビルドします。最適化オプションをわざわざ削除するのは何か理由があるはずですが、実機上でリビルドするにはgccは大きすぎてどれだけ時間がかかるか見当がつかない(486機とリビルド機ではbogomipsで150倍以上の差がある)ので、それは無視してspecファイルの修正で対応しました。

・glibc-2.11.1-10vl6.src.rpm
glibcは、glibc自体に問題はないのですが、glibcインストール時の自己設定ユーティリティ(build-locale-archive, tzdata-update)のコンパイルにoptflagsマクロを使っておらず(ただし、x86のみ)、rpmの%postスクリプトが正常に実行できません。したがって、この二つのユーティリティが-march=i486でリビルドされるようにspecファイルの該当箇所を修正します。おそらく、これもi486の実機上でリビルドすれば大丈夫だと思うのですが、gcc同様、面倒なので試していません。

・libcap-2.16-3vl6.src.rpm
ftp(proftpd)接続においてlogin認証をクリアした後、プロンプトが返ってこないという不具合に遭遇。いろいろ検証した結果、proftpdのmod_capがstallしているようでした。しかし、illegal instructionのエラーがどこにも確認できず、加えて、libcapにリンクしたproftpd以外のアプリケーションでは不具合が見つからな かったため、原因の特定にかなり手間取りました。最終的に、getcap(libcapのコマンドラインツール)の実行でillegal instructionを確認しました。

原因は、specファイル内でoptflagsマクロを代入している変数COPTFLAGがMakefile(Make.Rules)内で未定義だからです。対策はspecファイル内%buildにおけるmakeの引数を調整するか、実機でのリビルドですが、specファイルの修正は色々あってどうもキレイにならないので実機でのリビルドで対応しました。

・apr-util-1.3.9-8vl6.src.rpm
一見、正常に動作していたapacheですが、htaccessを使用する とログにillegal instructionのエラーを残し、接続が切断されてしまいます。ライブラリのリンク先をたどってみるとエラーの元はapr-utilと判明しました。このパッケージのリビルドでは、optflagsマクロ(-march=i486)は有効になっているものの、一部、-marchの代わりに-mtuneが使われているところがあり、そこではoptflagsマクロの設定が無効化しているのが原因と思われます。それほど大きいパッケージではないので細かくオプションを調整するよりも単純に実機でのリビルドで対処しました。

・vim-7.3.206-1vl6.src.rpm
・mdadm-2.6.9-3vl6.src.rpm
・dmraid-1.0.0.rc16-1vl6.src.rpm
リビルド機は基本的にi686の環境であるため、リビルド機でリビルドした静的リンクの実行ファイルはi486の環境下ではどうしてもillegal instructionを出しがちです。調べてみると静的リンクの実行ファイルはそんなに多くはなかったので、これらは、安全策、工程の簡素化策として実機でリビルドすることにしました。

静的リンクの実行ファイルは、リビルドに問題があると先述したSRPMから生成される物を除いて、vim.tiny(vim-7.3.206-1vl6.src.rpm)、mdadm.static mdassemble.static(mdadm-2.6.9-3vl6.src.rpm)、dmraid.static(dmraid-1.0.0.rc16-1vl6.src.rpm)で、これらは全てillegal instructionのエラーを出しました。vimは個人的に不要だし、この486機でRAIDを組む予定もないので、これらのパッケージをアンインストールすることも考えたのですが、結局、依存の問題から断念しました。

ちなみにvimの実機でのリビルドには80時間強(3日半)かかりました。リビルドの速度だけを優先するならば、リビルド機上の486仮想環境qemuでリビルドした方が三倍近く速いのですが、実践による動作確認の意味もあるので遅くても実機を動かしています。

 その他

・upstart-1.2-1vl6.src.rpm
upstartはinitなどを含む基本的重要パッケージです。一見、正常に動作しているように見えたのですが、glibcのインストール時、glibc_post_upgradeから実行されるtelinitがエラーを出して不正終了します。これは、前項のような単純なillegal instructionによるエラーではなく、原因不明です。解決法は、i486ではなく、i386でリビルドすることで、雰囲気的に何かのバグっぽいです。

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

・libproxy-0.4.6-1vl6.src.rpm
・hplip-3.11.5-3vl6.src.rpm
当初は、インストールメディアのすべてのRPMパッケージをi486用にリビルドし、それに差し替えたVine 6.1のインストールメデイアを作成する予定でしたが、それを阻んだのがlibproxyでした。他にもリビルドできないパッケージはあったのですが、依存するパッケージの多さでlibproxyが致命傷となりました。

リビルドできなかった原因は、Vine 6.xのxulrunner-devel-2.0.1-2vl6で、Vine 5.xの1.9.1.16-1vl5ならエラーにならなかったのでした。また、hplip-3.11.5-3vl6.src.rpmのリビルドもVine 5.xのファイル構成に依存しており、Vine 5.x上でないと素直にリビルドできなかったりと、Vine 6.xのビルド環境は良くわかりません。もっとも、Vine 6.xのパッケージをVine 6.xでリビルドするということは鶏と卵の関係に陥ることでもあるので、Vine 6.xのパッケージのリビルドでVine 5.xが出てくるのは、ある意味、当然と言えば当然なのですが、例えば、そのリビルド環境を簡単に知ることができるような仕組みがあればいろいろ悩まずに済んだのにと思います。


5. kernel configuration

ここでは、現時点(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


6. upgrade

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し、ログインユーザが存在するならば何もせずに終了します。


7. その他

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

・QUEM
この企画の試行錯誤において最大の活躍をしたのはquemです。何度も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は環境によって値が異なりますので注意してください。いまさら、こんなことをやってみる人はいないと思いますが…。


8. 動作状況

パーティション構成は、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:


9. まとめ

こう文章にしてみると、何か、サラッと書いてあり、そんなに大変だったようには感じませんが、なんだかんだで大変でした。「ここはあくまで技術情報なので感情的なことは避ける」という建前は、精神衛生上、非常に良くない…、と思い悩むこともしばしば…。まぁ、とにもかくにも、正月休みから始まったこの騒動もまる三ヶ月で終了です。最近は少し忙しく、なかなか時間が取れなかったものの、なんとかこのサイトの年度単位規約に収まってホッとしています。喉奥に刺さった小骨のように残っていた我が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 よしのぶ
yoshino@rita.karing.jp
index.html 一つ戻る
2013-03-27 Wed 12:22