debian lenny openofficeのアップデート

debian lenny へ openoffice 関連のアップデートが大量に届いていました。

アップデートマネージャーで処理しました。

FreeBSD php5-5.3.3_1 へアップグレード

FreeBSD の ports へ php5 のアップデートが入っていました。一緒に extension もアップデートが入っていたので、全部まとめて portupgrade -a で処理しました。

　php5-5.3.3 < needs updating (port has 5.3.3_1)

10年前に書き込んだCD-Rが読み出せません

以前から気になってはいたのですが、CD-Rの読み出し不良が大発生しています。

写真フィルムをスキャニングしたデータをせっせとCD-Rへ焼いて保存していたのは10年以上前のことです。最近古いCD-Rを引き出して中身を見ようとすると読み出し不良が発生することが目立ってきました。いわゆるCRCエラーです。

ここで一念発起してファイルサーバーへこれらのCD-Rのデータを移管させることを決意しました。しかしいきなり連続して何枚ものCD-RがCRCエラーで読み取れなくなっていて途方に暮れています。

いやはやどうしたものかと。実のところ5年前ぐらいからヤバいと感じていたのですが、なかなか重い腰を上げることが出来なかったもので。。。

エラーが多く発生しているのは台湾製のARITA(RiTEK)の12倍速のものです。パッケージがオレンジ色でえぐい模様が描かれているものです。ネット上を検索すると初期のフタロシアニンを使用したもののようです。

傾向として外周部でのエラーが急増しているようです。そのため700MBのうち半分程度しか書き込んでいないものはエラーなくコピーが完了します。しかし75%を越えるものは一様にコピーの終わり頃にエラーが発生しています。特に外周部いっぱいまで書き込んだものは100%エラーが発生します。



とりあえずコピーできる部分だけでも救おうとコピーを始めています。

そしてエラーの出たCD-Rにはマークをつけて再度吸いだしに挑戦しています。

取り合えずCD-Rを冷凍庫で冷やして読み出す方法も試してみましたが、ダメでした。エラーで停止した後、CD-Rをドライブから取り出すとほっかほかの状態でした。冷やすと効果があるというのは本当なのでしょうか？都市伝説？

ddrescueを使ってエラーブロックの再読み込みなどの方法で出来るだけデータを回収することでこれからの段取りを考えていますが、これが効率が悪くてどうしようかと悩んでいます。

このCD-Rのデータ回収については、随時報告をしたいと思っています。

FreeBSD sqlite3 の ports 再び

sqlite3 に不具合があったのでしょうか？再び ports へ sqlite3 のアップデートが入っていました。

その他のアップデートと一緒に portupgrade で処理しました。

p5-BerkeleyDB-0.41 < needs updating (port has 0.42)
p5-HTML-Parser-3.66 < needs updating (port has 3.67)
sqlite3-3.6.23.1_2 < needs updating (port has 3.6.23.1_3)

FreeBSD 再びghostscript のアップデート

ghostscript などのアップデートが ports へやってきました。

特に考えることなく portupgrade で処理しました。

ghostscript8-nox11-8.71_4 < needs updating (port has 8.71_5)
ruby+nopthreads-1.8.7.248_2,1 < needs updating (port has 1.8.7.248_3,1)
sqlite3-3.6.23.1_1 < needs updating (port has 3.6.23.1_2)

ブラザーのフック部品

故障したブラザーの MFC-830CLN のフック部品を調べたときに写真を撮影しておいたものです。

フック部分は使用頻度が高いものですので、電気的なスイッチを使用することは少なく、写真のように光学的な方法でオン・オフをするものが多いようです。



フックが下がっているときには黒いプラスチックでLEDとフォトトランジスタ（フォトダイオード）の間を遮蔽してオフの状態にしています。この付近かと思ってこの素子をアルコールで洗浄してみましたが症状は改善しませんでした。



もうこれ以上深追いすることなく、元の状態に組み立て直しておきました。

ブラザー MFC-695CDN が届きました

もう5年ほど前に購入したブラザーの MFC-830CLN が8月14日に壊れてしまいました。

壊れ方が少し珍しく電気的にフックが上がったままの状態になってしまいました。いわゆる受話器が外れている状態です。そのため電話を掛けてもらってもいつも通話中の状態になっていました。
もちろん物理的にはちゃんとフックは下がっています。受話器が物理的に取り外せるようになっていますが、この連結部分も点検してみましたが症状は変わりませんでした。

ブラザーへ修理に出そうかと迷いましたが、結局新しい後継機種(MFC-695CDN)を購入しました。

再びブラザーを選んだのはもちろんLinuxへの対応がよかったからです。もちろん置き換えの意味もあったので、置き換えてすぐに学習なしで使えるというのもポイントが高いところです。デザインは違いますが、ボタンの配置も似ているのですぐにファクシミリなどが使えました。

以下は開梱の様子を撮影したものです。

通信販売で購入したため宅配便で到着しました。到着した外観の様子です。



これは蓋を開いたところです。いわゆるプラスチック素材のクッション材は見当たりませんでした。この頃のエコロジー梱包の流れのようです。




灼熱の夏の太陽の中、シール材を剥いだり、受話器部分の組み立てを行いました。



そして古い MFC-830CLN と並べてみたところです。若干サイズが大きくなっているようです。ペーパートレイなどが二段になるなどの改良が行われていることから若干大きくなったようです。



メインで使用している WindowsXP のマシンでは一旦古いソフトウェアをすべて削除して新しくソフトウェアを入れ直しました。似たような機能のソフトに重ねてインストールするのはいろいろと問題が発生した経験があったためでした。面倒でも一旦削除するのがよい結果が得られることが多いようです。

パソコンとの接続はLANケーブルで接続しました。すでに以前の MFC-830CLN で使用していたものをそのまま使いました。なんと本体にあるケーブルを通す溝の寸法も同じだったので以前のケーブルについている曲がり癖がそのまま填まっていました。

WindowsXP マシンを設定した後、その他の Linux マシンでも使用できるようにLPRとCUPSドライバーをインストールして印刷が出来るようにしておきました。これで新しいプリンタ複合機がいままでどおりに使用できるようになりました。

debian lenny カーネル・アップデート

debian lenny へ kernel のアップデートがやってきました。

linux-image-2.6.26-2-686 2.6.26-24 ＞ linux-image-2.6.26-2-686_2.6.26-24lenny1_i386.deb

その他 ghostscpript 関連のアップデートもありました。

ghostscript ghostscript-x gs-common gs-esp libgs8

いつものようにアップデート・マネージャーで処理しました。

FreeBSD bison のアップデート

bison のアップデートが ports へやってきていました。

いつものように portupgrade で処理しました。

bison-2.4.1_1,1 < needs updating (port has 2.4.3,1)

デスクトップ・パソコンのハードディスク交換

昨日購入したハードディスクを使って、まず最初にデスクトップ・パソコンのハードディスク交換をしました。

このパソコンは2003年7月に組み立てたもので、調子もよくずっと使っています。ハードディスクは適宜交換と増量を図ってきました。CPUのファンなどもガタガタうるさくなったついでに静音で冷却能力の高いものに交換するなどメンテナンスは比較的しっかり行ってきたつもりです。



現在はマザーボード(intel D865GBF)にあるSATAコネクタへ500GBのハードディスクを接続しています。これを新しいものに交換します。ちょうど倍の1TBにして毎日のように溜まるデジタルカメラのデータの保存や活用に使用します。

ハードディスクには使用開始した日付を書き込むようにしているので前回の交換日が判りました。2008-02-27だそうで2年6ヶ月ぶりの交換になります。（写真の左が古いもの、右が新しいもの）



なおハードディスクの不調を示す前兆現象などはまったくありませんでした。この状態で交換してこそ意味があると思っています。

ハードディスク上の OS は WindowsXP なので NTFS 5.1も扱える最新の GParted Live CD を使用することとしました。

新しいハードディスクへパーティションのコピーを行います。このハードディスクは Cドライブと Dドライブ として二つのパーティションに分割してあるので、それぞれを同じ順番でコピーをします。

Cドライブは60GBに設定してあり、コピー時間はおよそ15分程度でした。しかし残りすべての容量がある Dドライブは2時間程度の時間が必要でした。

Dドライブのパーティションのコピーが終了したところで、後ろの部分に残っている空き領域いっぱいをDドライブにするように拡張コマンドで容量を拡大しました。

この一連のコピーで新しいハードディスクへデータが移行できました。最後に Cドライブの部分へ boot フラグの設定も忘れずに行っておきました。これがないと立ち上がりませんから。

この写真はデータ移行作業をしている様子です。所定の場所に新しいハードディスクを取り付け、古いハードディスクは取り出してケーブルで接続している状況で作業をしました。

ハードディスクを購入

パソコンのハードディスクは消耗品のため定期的な交換が必要なものです。

我が家のパソコンのハードディスクを交換することとしました。

一般的な作業をしているデスクトップ・パソコンへ1台、そして自宅サーバーへ2台のハードディスクを購入しました。



3台とも1TBのハードディスクを選択しました。デスクトップ・パソコンには現在500GBのハードディスクを搭載しています。そしてサーバーには RAID 1 (ミラーリング) の構成で320GBのハードディスクが2台搭載しています。

これらの古いハードディスクを一気に交換して、故障の原因を取り除き、そして保存容量も一気に増やそうという魂胆です。

パソコンショップで手頃な値段で販売されていた日立の1TBを購入しましたが、以前のようにバルク品として裸で売られているものは少なく、多くはパッケージされたリテール品になっているようです。これも時代の変化なのでしょうか？

バルク品は本当にハードディスクの本体しかありませんが、パッケージされたリテール品は説明書や取り付けネジまで付属する親切ぶりです。結構ネジって落としてどっかに行ってしまうこともあり、いくら有っても邪魔にはならないものです。

明日からいよいよハードディスクの交換に取りかかります。

partimage-server で、まさかのバージョン違い

debian lenny がインストールされているパソコン同士で partimage と partimage-server の間でパーティション・データの保存を繰り返していました。

そこで SystemRescueCD に入っている partimage を使って、データの保存ができるか確かめることとしました。

昔焼いて使っていた SystemRescueCD 1.2.3 を使って partimage-server へアクセスしようとしましたが、アクセス出来ません。
外部サーバーへアクセスする項目の下に「SSL&login disabled at compile time (コンパイルの時からSSLとログインは無効にしている) 」とあるので、当然かと。

そこで最新の SystemRescueCD 1.5.8 を試してみることとしました。この中に入っている partimage は外部サーバーへ接続できるようになっていました。喜び勇んでデータのバックアップを開始しようとしました。

ログイン画面でユーザー名とパスワードを入力して OK をクリックしたら、「Connexion refused by server Version mismatch」と表示されて停止してしまいました。

バージョンがミスマッチ（不一致）とはどういうこと？と思いつつ partimage のバージョンを調べてみました。

　　debian lenny の partimage & partimage-server は 0.6.7 でした。
　　SystemRescueCD 1.5.8 の partimage は 0.6.8 でした。

この僅かなバージョン違いも許されないほどプロトコルや保存されるデータの形式が違ってしまっているのでしょうか？

手っ取り早く、debian lenny の partimage を squeeze のものから借用する方法もありますが、もうムキになってバージョン合わせをしてまでサーバーで保存する気持ちもなかったので、今回はバージョンが合わないと接続してもらえないことが判っただけでも勉強になったと思って次の機会に回すこととしました。

debian partimage-server のインストール

partimage のネットワーク・サーバーとなる partimage-server を debian lenny で稼働しているファイルサーバーにインストールしました。

もちろん目的はパーティション・イメージ・ファイルをいちいちファイル・サーバーへ転送するよりは、直接転送してしまった方が便利だと思ったからです。

インストールは aptitude を使ってさっくり完了しました。

　# aptitude install partimage-server

早速、他のパソコンから WindowsXP がインストールされているパーティションをバックアップしてみました。

動作させる上で注意点はイメージ・ファイルの名前にディレクトリの指定が出来ないことです。単純に「WindowsXP.img」のように指定します。これはサーバー側で指定されたディレクトリに一括して保管されるためです。

ただ最初はどこに保管されるのか分からず戸惑ってしまいました。ここにありました。

　/var/lib/partimaged/

これではいろいろ不都合なこともあるので保存場所を変更することとしました。設定ファイルが /etc/default/partimaged にあります。

初期値（デフォルト）のディレクトリをコメントアウトして、新しいディレクトリをしていしました。TARGET= で指定します。

　# TARGET=/var/lib/partimaged/
　TARGET=/home/partimaged/

新しい保存先となるディレクトリは次のようにオーナーなどを設定しておきました。

　# chowm partimag:partimag /home/partimaged/
　# chmod 750 /home/partimaged/
　# ls -l
　drwxr-x--- 2 partimag partimag 4096 2010-08-08 03:13 partimaged

なお設定を変更した後は partimaged を再起動させておきます。

　# /etc/init.d/partimaged restart

debian wget のアップデート

debian lenny に wget のアップデートが到着していました。

アップデートマネージャーでアップデートさせておきました。

wget 1.11.4-2+lenny1 ＞ wget_1.11.4-2+lenny2

FreeBSD 再びghostscript のアップデート

先日アップデートがあったばかりの ghostscript ですが、再びアップデートが来ていました。

portupgrade でアップデート処理を開始すると、jbig2dec をインストールし始めました。
PNG画像の処理を含めるかどうかのビルドオプションの問い合わせがありました。デフォルト値はPNGを含めるとなっていたのでそのままビルドさせることとしました。

JBIG2 ってなんだろうと検索してみると、「joint bi-level image experts group 2」ということで画像圧縮形式の一つのようです。

ghostscript8-nox11-8.71_3 < needs updating (port has 8.71_4)

debian avahi 関連のアップデート

debian lenny へ avahi 関連のアップデートがやってきていました。

いつものアップデートマネージャーで対応しました。

libavahi-common-data 0.6.23-3lenny1 を (.../libavahi-common-data_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-common-data を展開し、置換しています...

libavahi-common3 0.6.23-3lenny1 を (.../libavahi-common3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-common3 を展開し、置換しています...

libavahi-core5 0.6.23-3lenny1 を (.../libavahi-core5_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-core5 を展開し、置換しています...

avahi-daemon 0.6.23-3lenny1 を (.../avahi-daemon_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

Stopping Avahi mDNS/DNS-SD Daemon: avahi-daemon.
avahi-daemon を展開し、置換しています...

libavahi-client3 0.6.23-3lenny1 を (.../libavahi-client3_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-client3 を展開し、置換しています...

libavahi-compat-libdnssd1 0.6.23-3lenny1 を (.../libavahi-compat-libdnssd1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-compat-libdnssd1 を展開し、置換しています...

libavahi-glib1 0.6.23-3lenny1 を (.../libavahi-glib1_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-glib1 を展開し、置換しています...

libavahi-gobject0 0.6.23-3lenny1 を (.../libavahi-gobject0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-gobject0 を展開し、置換しています...

libavahi-ui0 0.6.23-3lenny1 を (.../libavahi-ui0_0.6.23-3lenny2_i386.deb で) 置換するための準備をしています ...

libavahi-ui0 を展開し、置換しています...
libtiff4 3.8.2-11.2 を (.../libtiff4_3.8.2-11.3_i386.deb で) 置換するための準備をしています ...

libtiff4 を展開し、置換しています...

FreeBSD ghostscript のアップデート

先日アップデートしたばかりの ghostscript が再びアップデートです。

いつものように portupgrade で対応しました。

ghostscript8-nox11-8.71_2 < needs updating (port has 8.71_3)

debian ghostscript 関連のアップデート

debian lenny に ghostscript 関連のアップデートがありました。

いつものようにアップデートマネージャーでアップデートさせておきました。

ghostscript 8.62.dfsg.1-3.2lenny1 を (.../ghostscript_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換

libgs8 8.62.dfsg.1-3.2lenny1 を (.../libgs8_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換

gs-common 8.62.dfsg.1-3.2lenny1 を (.../gs-common_8.62.dfsg.1-3.2lenny4_all.deb で) 置換

ghostscript-x 8.62.dfsg.1-3.2lenny1 を (.../ghostscript-x_8.62.dfsg.1-3.2lenny4_i386.deb で) 置換

gs-esp 8.62.dfsg.1-3.2lenny1 を (.../gs-esp_8.62.dfsg.1-3.2lenny4_all.deb で) 置換