ここ数日気分が滅入っていた。
お腹の調子が悪かったと言うのもあるが、Debian lenny なマシンで perl から csv ファイルを扱いたいからって Perl モジュールを aptitude でインストールしようと試みたのだ。
で、なにやらやたらといつもの事だけど依存関係でいろんなパッケージがアップグレードされていくし、なぜかカーネルのバージョンアップもされたりする。
しかし、失敗する。
目的のパッケージがインストールできさえすればいいんだけど、今回は目的のパッケージがインストールされないばかりかシステムに必須と思えるようなコマンドまで消えてしまっている。
嗚呼、さんざん警告を無視し続けてだましだまし使い続けてきたが、もうさすがに限界なのか、X Window System も使えなくなってしまった。かなりまずい。
いろいろ aptitude を試してみたけど駄目だなぁと。というか aptitude が機能しない。
きっと再起動したら正常に起動しなくなっているんだろうなと思いつつも、現状を打開したいので再起動。
嗚呼、やっぱりまともに起動しなくなっていた。
とりあえず initramfs な環境でどうしようかなぁと・・・。どうしようもないから別のカーネルで起動。するとなんとか起動はした。新しいカーネルでは起動できなくなっていたようだ。
そうか、ソフトウェアRAIDで設定したRAID1のディスクが認識できていないようだ。LVMも微妙な感じだ。
嗚呼、困った。再起動前の状態を事前に記録しておけば良かった。元に戻すにしても元がどうなっていたんだっけ？
まぁ、いいや。深く考えない。
とにかく initrd の再作成が必要なようだ。で initrd を再作成したんだけど、そうしたら今度は古いほうのカーネルでも起動しなくなってしまった・・・。嗚呼、困った。
つまり、lenny から squeeze へのバージョンアップがいつの間にか進んでいて、あまりアップグレードしたくなかったんだけど、面倒な事になるから。だけど、使っているうちにどんどん依存関係上アップグレードが進行してしまい、カーネルのバージョンアップが必要なわけで、しかしなぜか失敗しているので困った。
/var/cache/apt/archive あたりに保存されていた新しいカーネルを dpkg で手動でインストールしようとしたら原因が分かった。root filesystem が容量不足だ。/lib にモジュールが入れられない。
ということで、以前も /usr が容量不足だったときに /home をソフトウェアRAIDでRAID1構成にした新しいハードディスク上に置いて、/home に使っていたLVMボリュームを /usr に割り当てていたのだ。その /usr として使っていたのは容量が中途半端だからって放置していたんだけど、/ で容量不足なら昔の /usr を割り当てれば良いではないかと考え debian の install CD から rescue モードで起動して root filesystem の中身を以前の usr に移して fstab を書き換えたいんだけど /usr/bin/vi が見つからないのは何故？しかたないので LVM のラベル名を変更して fstab そのままでも良いようにした。
しかし、それでもまだ問題は解決しない。
/ の容量に余裕ができたから aptitude でカーネルやらなにやらをどんどんアップグレードしていくけれど、古いカーネル用の initrd を再作成したら古いカーネルでも起動しなくなったじゃないか。
嗚呼、困った、でもオプションで all を指定しなかったから古くも新しくも無い中くらいのカーネルで起動できた。どうやら lenny から squeeze へのアップグレードの際の注意点をよく読めという話のようだ。
なにしろ起動するたびにソフトウェアRAIDのディスクを手動で認識させ、LVMを手動でACTIVEにしないと/homeが見つからないから大変。なんか udev の挙動が変。/dev/shm も消えているし。udev は最新のカーネルパッケージを要求しているのにカーネルがインストールできなかったので "/" ファイルシステムの容量を大きくしてインストールできるようにして、やっとカーネルのアップグレードができたと思ったんだけど、やっぱり最新のカーネルでは起動できない。
嗚呼、どうやらGRUBを最新にしないと mdadm で作ったRAIDは見えなかったらしい。その他いろいろやってようやく一番新しいカーネルでも起動できるようになった。
それで xorg も再設定。NVIDIAカーネルも入れて X も立ち上がるところまで修復できた。それで日常の業務を行うスクリプトを走らせるとなんか止まる。
mysqldump がエラー出してる。
ええい面倒だということで mysql 関連パッケージをアップグレード。
そしたら今度は mysql サーバー自体が動かなくなってしまった・・・。
嗚呼、困った。本当に困った。
で、結局 my.cnf の中身が不正なんじゃないかということが分かってきたので試しに my.cnf をリネームして /etc/init.d/mysql start とかしてみるとすんなり起動した。
今までの my.cnf のメモリーの取り方は間違っていたみたいだ。やたらとパフォーマンスが悪くていろいろ試していたのが今回のバージョンアップで引っかかってしまった。
そうしてようやくやっと、ほぼ元の状態と同じ程度に使えるようになった。
でも、リモートホストからのMySQLの接続が失敗する。GRANTで許可するネットワークのサブネットを指定しても接続元のホスト名で拒否されてしまう。どうやらIPアドレスの範囲で許可したつもりでも名前解決を行いホスト名で判断されてしまう。
困った。GRANTで許可するホスト名を指定しないと駄目なのかも。
とりあえず使えるようにはなった。多少変更が必要そうだけど大丈夫そうだ。まあこんなものだ。ときどきバージョンアップせざるを得なくなって苦労するんだ。
ここ数日、自分用のサーバーが使い物にならなくなっていたので気分が悪かった。いわゆる基幹サーバーとかだったらもっと気分が悪いのだろう。自分はもっと小規模なホームサーバーちっくな自分しか使っていないようなサーバーだからあんまり困らなかったけど、自分は困るけど。何日か使えなくなってもあまり深刻にならないで済む。とはいえ月末だから月が変わる前に直しておかないと毎月のデータ抽出に支障が出る。つまり１週間以内に直さなくてはいけなかったのだ。間に合ってよかった。
