| 2024年11月23日 | ノート定期点検 |
| 2024年1月22日 | セゾンゴールドアメックスカードの変化 |
| 2024年11月20日 | DS-C480W購入 |
| 2024年11月18日 | EOS R7ファームウエアアップデート |
| 2024年11月17日 | PX-M730Fのシアンインク交換 |
| 2024年10月19日 | 腕時計のファームウエア |
| 2024年10月5日 | RF-S 10-18mm F4.5-6.3 IS STM購入 |
| 2024年10月3日 | 三菱UFJニコスカード到着 |
| 2024年9月28日 | 三菱UFJニコスカード申込 |
| 2024年9月23日 | 第10世代iPad購入 |
部品寄せ集め4号がたびたび落ちるようになったので、 機能を統合して6号とマージした。 しかし、ケースの都合でDDSドライブが入らない。 これは別のマシンに仕込んでリモートでバックアップをとるか…… ちなみに作業は以下の通り。
5インチベイ×4、3.5インチベイ×2、3.5インチシャドウベイ×7、 350W電源というフルタワーケースを購入し、 7号に入れてあったDDSドライブ共々ひとつにまとめる。 Pentium4、Athlon対応というふれこみだが、8cm角のファンが2個、 あらかじめつけてあるのがいかにもサーバー向け。 で、シャドウベイにも8cm角のファンをつけられる構造になっている。 一番発熱の激しい、7200r.p.m.のHDがある部分に取り付けたら、 全然熱くならない。 やはり、ファンの効果はたいしたものがある。 RAID用に3台固まっている部分にも、ファンをつけようかなあ。
ついでに、7号に組み込んであった128MBのDIMMメモリも、6号に移植。 これで、メモリが256MBになった。 7号には、余っているSIMMで128MB実装する予定。
なぜか、DDSでのバックアップがこける。 それも、/homeのパーティションをバックアップしているときに限って。 電源は300Wから350Wになっているから足りないはずはないしなあ。 OSの再インストールかも。
raid-5を構成していたHDがひとつ死んだ。 これ幸いと、 HDの交換がてらマザーボードをP6B40D-A5からPDB-Rに変更する。 ついでにSCSIインターフェイスとDDS-2ドライブも組み込む。 さらに、 もうひとつのケースファンもHDを冷却するように配置しなおした。 symとsaをサポートするようにカーネルを再コンパイルし、 ちゃんとdumpできることを確認。
次の問題はraid-5の再構築である。 ハードウェア的にはケーブルセレクトにしたドライブを入れ替えるだけ。 ソフトウェアの方は、disklabelに慣れていないので苦戦。 /stand/sysinstallはcore dumpで止まるし。とりあえず、
fdisk -BI ad4
disklabel -w -B ad4s1 auto
disklabel -e ad4s1
でeパーティションをvinum用に確保。 ad4s1ではなくad4と指定するとoperation deniedと言われてしまって悩んだ。 マニュアルはよく見るものである。
この状態でvinum startを実行すると、 交換したドライブが壊れていると表示される。 で、vinum rebuildparity raid5.p0とすると、 plexが壊れているとのたまう。 じゃあvinum init raid5.p0.s2かというと、今度はI/Oエラー。 しばらく悩んだあげく、
vinum detach raid5.p0.s2
vinum stop
vinum start
vinum rebuildparity raid5.p0
で再構築が始まった。 2～3時間ほどかかったようである。 しかし結局のところうまく復旧できなかった。 これではraid-5の意味がない。 ストライプを組んで、 必要なところだけをバックアップしておく方がよさそうだ。
FreeBSDのDNSリゾルバにバグが見つかった。 4.6-releaseでもダメで、最新の4.6-stableにする必要がある。 久しぶりに、stable-supfileでcvsupを行う。 いやー、ソースコード丸ごとだと時間がかかることかかること。この後、
が控えているのだが、かなりかかりそう。
とりあえず、バージョンアップはなんとか終わった。 しかし、HDの認識がおかしい。 拡張ボードに接続したはずのHDが、 オンボードのIDE RAIDチップにつながっていると報告される。
そこで配線を替え、 オンボードIDE RAIDチップでストライピングを行うようにした。 これにつながるのは4台のHD。 で、さらにもう1台をvinumcでひとつにまとめようと思ったのだが、 うまくいかなかった。 しかたがないので、 ar0たるハードウェアストライピングHDをビデオ作業用に、 残りの1台を共有のファイル置き場としてマウントした。 40GBのHDの下に160GBのHDをマウントしたので、 Windowsから見るとさぞかし発狂しそうなファイルシステムに見えることだろう。
知り合いから預かった20GBのHDもハードウェア的には組み込んだが、 マウントして運用するのは明日以降にしよう。
この1週間ほど、 3:01の定期チェックを実行するとマシンが反応しなくなる。 topを実行しておくと画面表示は書き変わるのだが、 apacheやsshでの反応がない。 それらしいエラーログもないので悩んでいたが、 富士通製のMPG3409ATという、 例の壊れやすいらしいHDが入っているではないか。 さっそく交換した。
ついでに、余っていたIBMのDTLA-307045も組み込んで、 ccdでひとつのパーティションにしてみた。手順としては、
といったところか。 後はsambaで共有したときに読み書きできるよう、 パーミッションを設定して終わり。
これで落ちなくなるといいのだが。
昨日作成したパーティションだが、 soft updateを有効にするのを忘れていた。 shutdownでシングルユーザーモードになり、 アンマウントした後tunefs -n enable /dev/ccd0cで有効にする。 マウントし直して、マルチユーザーモードに戻って終わり。 なお、今日は落ちていないようだ。
依然として、3:00のスクリプトを実行すると落ちる。 次に交換すべきは、 システムをインストールしてあるad0(Maxtor 51536U3)か？ 容量が15GBという点からして、 そろそろ寿命がきてもおかしくはない代物。 とはいえ、ログに何も残さず落ちてしまうというのは困ったもんだ。 壊れかけのHDだと、 たいていRead ErrorとかWrite Errorwがでるもんなんだが。
システムをインストールしてあるHDを、 ウェスタンデジタルのWD400EBに交換した。 シングルユーザーモードでテープにバックアップをとって、 一から再インストール。 オートマチックにパーティションを切ったら、 スワップが1776Mだそうな。 実メモリの2倍くらいが一番効率いい、 とハンドブックで読んだような気もする。 portsでいろいろインストールして、 バックアップしてあったデータを書き戻した。 これで止まらなくなればいいのだが。
しばらく/dev/ccd0のソフトアップデートを止めて快調に動いていたが、 /dev/ad1cが読み取りエラーを報告してきた。 これが原因だったのかもしれない。