ただのにっき
2000-07-04(火) [長年日記]
■ mph
slocateとか、けっこう使ってるツールがerattaに上がっている。いちいちパッケージをftpしてきてもいいんだけど、そろそろmphで自動upgradeに挑戦してもいい頃。自宅のマシンはいいとしても、職場のマシンは誰にクラックされるかわかったもんじゃないし。それに職場にはKondaraのmirrorサイトがある。これを利用しない手はない。
mph自体は自動的にインストールされているので、まず、/etc/mph.confを自分の環境に合わせて書き換える。デフォルトではスナップショットを持ってくるという実にKondaraらしいというか、恐ろしい設定になっているので、ここは以前、ぱぱんださんの日記で読んだのを参考にして、Kondara1.1/eratta以下だけを対象にするようにしよう。こんな感じ:
$DIRS = [ 'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/bugfixes/i586', 'ftp://ftp.hogehohe.co.jp/Linux/kondara/Kondara-1.1/errata/bugfixes/noarch', 'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/security/i586', 'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/security/noarch', 'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/updates/i586', 'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/updates/noarch' ]
■ 上の方にある、ftpのパスワードを、自分のメールアドレスに変えるのも忘れずに。続いて、データーベースを更新:
$ sudo mph-get update
■ ……と思ったらmph-get(その実体はRubyスクリプト)自体がコケる。正規表現のparseエラーだ。Ruby 1.4.5の非互換だな、これ。こないだ自作のスクリプトもこれにやられた。ちょこちょこと直して再実行。これでそれぞれのディレクトリに関する*.mphファイルを取得してくるので、その内容に基づいてアップグレードできるようになる。さて、アップグレードしてみよう。
$ sudo mph-get upgrade
■ アップグレード対象になっているパッケージの一覧がずらずらと表示され、そのファイルサイズ(初めてなので30MBほど。とても自宅でやりたい作業ではないね)が出て、更新するかどうか聞いてくる。「y」と答えるとftpからrpmファイルをGETしてくる……はずなんだけど、よくわからない理由でGETできんとかぬかしてくる。をいっ。
なんとなくftpのライブラリがくさい。現在のRubyはnet/ftpを使うことを推奨してるけど、このmph-getは古いftplibを使っている。そこで、スナップショットから最新のmph-0.9.6-17を持ってきてインストール……と、またreadlineが依存してるとか言われたので、src.rpmの方を再GETして--rebuildしてから再インストール。手慣れてきたな(笑)。
新しい/etc/mph.confを編集して($DIRが$asDIRに変わってたりするので注意)、再度update、upgradeを行う。こんどはいけてる。全ファイルの取得が終わると、rpm -Uvhがかかるのだ……が(こればっか)、なんとRubyのupgradeに失敗していると出た。あんた、今入ってるのは最新の1.4.5なのに、なんで1.4.4を入れようとするの。しかもruby-ebが依存してるからダメとか言うし。たぶん、mphファイルに書かれている方が優先されちゃうんだな。
■ 仕方がないので、ruby-ebをいったんアンインストールしてから、再度upgradeを実行。さっきダウンロードしたファイルはキャッシュされているので、すぐにrpmが動いて、こんどは成功。でもRubyが1.4.4に戻っちゃったので、改めてこないだ作ったRuby 1.4.5と、RubyEBを入れ直す。その前に、eb.soが入る/usr/lib/ruby/1.4/i586-linux-gnuというディレクトリを削除して、i586-linuxを指すシンボリックリンクに変えておく。これで素直に入るようになった。泥縄だけど(笑)。
でもこれだけだと、次回のupgradeでまた同じことが起きるような……。仕方がない、当面の処置としてeratta/updates/i586(Rubyが入っているディレクトリ)だけ、更新対象からはずしておこう。ローカルに自作のパッケージを入れたディレクトリを作ってmphファイルを生成しておけば、それを見に行くようにできる気もするけど、いかんせん、mphファイルの書き方がわからない(笑)。ま、これはいずれ。
■ Kondara 1.2
そういえば、Kondara自体の最新版もShizuka(1.1)からAyaka(1.2)になってるんだよなぁ。まぁ、特に不都合はないからしばらく1.2にする必要はないんだけど。つーか、ダイヤルアップユーザとしては、箱になるまで入手できないんだけどな(会社でCD-Rに焼くという手はあるけど、これは最後の手段)。そもそも、OSなんてものは年に何回もバージョンアップするものではない。次はKernelが2.4になるタイミングでしょう。
■ ディスク増設
続いて、週末に買ってきたハードディスクの取り付け。MP3ファイルで手狭になってきたQuantum Fireball SE 4GBに変えて、IBM DTLA-30502 20GBにするのだ。まずはIBMをセカンダリ・スレーブに取り付けて、以前の増設の手順を見ながら領域確保〜フォーマット〜mountまで順調に進める。日記ってすばらしい(笑)。それから取り外す予定のQuantumから、全ファイルをコピー。なんか、やたらとCPUを食うような。しかも遅い。変だな。
この時点ではあまり気にせず、Quantumを外して空いたプライマリ・スレーブにIBMをつなぎ替え。/etc/fstabを適当に修正して、載せ替え完了。ふっふっふー、楽勝じゃ。
でも、さっきの遅さが気になる。いずれ/homeをこっちに移動しちゃおうと思ってるだけに、あまり遅いのは困るだろ。dmesgを見てみると、プライマリ・マスターにつないであるもう1つのQuantumには「UDMA」の文字が出ているのに、今日増設したIBMには出ていない。UltraDMA66のディスクだから? どうもハードウェアのことになるとからきしだからなぁ、おれ。
hdparmというコマンドが記憶にあったので、rootになって使ってみる。DMAは-dで見えるらしい。なるほど、Quantumは1(on)なのに、IBMの方は0(off)だ。だから遅い? いやいやしかし。-tでちょっとしたベンチマークを取ってみると、どっちのディスクも3MB/secくらいしか出ていないことが判明(爆)。こんな遅いディスクで満足してたんか、おれは(笑)。
Webを調べてみると、DMAよりも-cオプション、つまりI/Oモードを32bitにする方が効果があるみたいだ。実際、IBMの方に-d 1を指定してDMAをonにしたら、ディスクが正しく読めなくなっちまった(汗)。試しに両者を比較してみると……
# hdparm -c 0 -t /dev/hdb /dev/hdb: setting 32-bit I/O support flag to 0 I/O support = 0 (default 16-bit) Timing buffered disk reads: 64 MB in 17.45 seconds = 3.67 MB/sec # hdparm -c 1 -t /dev/hdb /dev/hdb: setting 32-bit I/O support flag to 1 I/O support = 1 (32-bit) Timing buffered disk reads: 64 MB in 10.29 seconds = 6.22 MB/sec
■ おおー、およそ倍。これなら文句ないだろ。いや、もしかするともっと速くなるかも知れないけど、おれって以前からSCSI2の5MB/secで満足だった人だから。これだけ出てれば十分でないの。いやホント。不満なのはDMA転送を使えないとCPU負荷が高いことだよなぁ。どうしたもんか……。
などと考えつつ、試しにリブートしてみたら、見事に設定を忘れてくれてるし。いちおう-kオプションもつけてみたんだけど、無意味だったか。仕方がないので、/etc/rc.d/rc.localの末尾に/sbin/hdparm -c1 /dev/hda /dev/hdbというのを追加しておいた。ちょっと不満だが、ま、いいだろ。