ページ

2016年4月30日土曜日

Buffalo LS-H640GL に搭載されていた HDD はゴミでした

電源ユニットを修理したことによって、起動することに成功していた LS-HGL (LS-H640GL)ですが、念の為、ハードディスク(SAMSUNG HD642JJ)を取り出して、単体での検査を行いました。その結果、使用不可能な故障品であることが判明しました。

ハードディスク検査中のサムスン製 HD642JJ です。

ハードディスクの検査状況

HGST DriveFitnessTest
我が家でハードディスクの検査でよく使用している HGST 製の DriveFitnessTest では、SMART Self Test のところで停止したまま、検査が終了しませんでした。検査開始より8時間を経過したところで中断しました。

SAMSUNG ESTOOL
サムスン製 の ESTOOL では、途中でセクタ・エラーとなり、全然進捗しない状況となってしまいました。そのため検査を中断しました。

ESTOOL での検査状況

HDAT2
不良セクタの検査で定評のある HDAT2 でも検査を行いましたが、不良セクタが大量発生しており、これもハードディスク全体の検査を終えるに長い時間を必要とするため中断しました。

HDAT2 での検査状況

ハードディスクの消去

不良セクタが大量発生している状況のため、ハードディスク全体をゼロで書き尽く方法で消去を行おうとしましたが、ESTOOL や HDAT2 の他、Active@KillDisk で消去を行おうとしましたが、途中で動作が明示的にエラーで停止したり、消去動作が進捗しなくなってしまいました。

結論

以上のことから、本ハードディスク(SAMSUNG HD642JJ)は、故障だと判断しました。個人的には、サムスン製のハードディスクの故障率の高さは数多く体験してきましたが、今回も期待を裏切ることはありませんでした(笑)。

故障していたサムスン製ハードディスク(HD642JJ)です。


2016年4月29日金曜日

Buffalo LS-HGL を入手

インターネット・オークションにて、バッファローの NAS 製品の LS-H640GL(以下 LS-HGL と記します)を入手しました。

今回入手したバッファロー LS-HGL です。

経緯

今までプロセッサに POWERPC 搭載の「玄箱」を中心にして NAS 製品をインターネット・オークションにて落札してきました。そろそろ目新しいものが欲しくなり、たまたま落札できたのが LS-HGL です。
ただし入手したものは、出品時より「電源が入らない故障品」として入手したものです。最悪は、保守用部品取りのマシンとなってしまう可能性のあるものでした。

動作確認

LAN ケーブルを接続して電源を投入すると、電源のランプは点灯しませんでした。しかし LAN のランプのみが、マルチキャストのパケットに反応して時折点滅する状態でした。さらに内部に残されていたハードディスクも動作していないようでした。明らかに故障状態でした。

動作確認中のランプの様子です。
電源ランプが点灯しませんでした。

分解

故障している状況が判明しましたので、早速分解することとしました。搬送にレターパック・プラスを使用していたことと、ほとんど緩衝材が入っていないこともあって、分解途中で、内部を固定する爪の破片がポロポロと落ちてきました。故障していることを前提とした簡易発送であったのですが、もっと他の発送方法を選べばよかったと反省しているところです。

分解した LS-HGL です。
ハードディスクは運悪くサムスン製 HD642JJ でした(涙)

故障原因の発見・修理

分解すると、すぐに故障の原因が判明しました。電源ユニットの電解コンデンサ(SAMXON 2200μF/10V)が破裂していました。

電解コンデンサが破裂していた電源ユニットです。

ちょうど手元に新品の電解コンデンサ(ニッケミ KMG 2200μF/10V)があったため、これと交換することとしました。

RTV ゴムで固定されていた電解コンデンサを取り外して、新しい電解コンデンサに交換するところです。
新しい電解コンデンサへ置き換えた電源ユニットです。
この状態で電源電圧が正常に出力されることを確認しました。

掃除

せっかく分解したこともあり、筐体を水洗いしておきました。今回は電解コンデンサの電解液と思われる汚れも付着しており、プラスチック部品はレンジ周り用アルカリ洗剤でしっかりと洗浄しておきました。

洗浄中の LS-HGL のプラスチック部品です。

動作確認

電源ユニット単体の状態で出力コネクタの部分に 5 ボルトと 12 ボルトが出力されていることを確認しました。その後、金属フレームへ電源ユニットやハードディスクなどを取り付けて動作確認を行いました。正常に動作を開始したようで、パソコンから LS-HGL のディスクへアクセスすることができました。

電源ユニットの修理の後に動作確認を行っているところです。

今後の予定

ハードディスク単体の試験などを行う他、LS-HGL のボードへシリアルコンソールのピンヘッダの取り付けなどを予定しています。そして Debian Jessie をインストールしたいと思っています。ARM 系のインストールは初めてのことなので、いろいろ事前調査を行って作業をしたいと思っています。


FreeBSD 9.3 の p40 (ntp) アップデート

FreeBSD 9.3 へ p40 アップデート(ntp)が到着しました。今回は ntp でした。何度か ntp のアップデートが行われましたが、まだまだセキュリティ上の問題が残っていたようです。
FreeBSD-SA-16:16.ntp
Multiple vulnerabilities of ntp
https://www.freebsd.org/security/advisories/FreeBSD-SA-16:16.ntp.asc

/usr/src/UPDATING の内容

20150429        p40     FreeBSD-SA-16:16.ntp

        Fix multiple vulnerabilities of ntp.

ソースツリーの更新

subversion でソースツリーを更新しました。ntp 関係だけで 189 行におよぶ更新がありました。
# svn update /usr/src
Updating '/usr/src':
G    /usr/src/UPDATING
U    /usr/src/contrib/ntp/ChangeLog
U    /usr/src/contrib/ntp/libntp/work_thread.c
U    /usr/src/contrib/ntp/ntpd/invoke-ntpd.texi
U    /usr/src/contrib/ntp/libntp/Makefile.in
U    /usr/src/contrib/ntp/libntp/authkeys.c
U    /usr/src/contrib/ntp/libntp/is_ip_address.c
     ↓
     ↓
U    /usr/src/usr.sbin/ntp/config.h
U    /usr/src/usr.sbin/ntp/doc/ntpd.8
U    /usr/src/usr.sbin/ntp/libntp/Makefile
Updated to revision 298783.

カーネルとユーザランドの再ビルド

今回のアップデートでは、ユーザランドの再ビルドが必要です。
# cd /usr/src
# make buildworld

ユーザランドのインストール

# make installworld

マシンの再起動

# reboot

2016年4月28日木曜日

NTT FT-STU-Bng を入手

NTT の USB 型無線 LAN アダプタの FT-STU-Bng を入手しました。

今回入手した NTT FT-STU-Bng です。

概要

親指先ほどの大きさの USB 型無線 LAN アダプタです。
無線 LAN の特性は、2.4GHz 帯の IEEE 802.11 b/g/n 対応となっています。内部のチップには Ralink 社の RT2870 が使用されている模様です。

NTT FT-STU-Bng の背面表記の様子です。

デバイス ID を追加してビルド

Debian Jessie が稼働しているパソコンへ本機(FT-STU-Bng)を装着してみたところ、なんの反応もありませんでした。デバイス ID (0411:0192)が登録されていない模様でした。そこでデバイス ID (0411:0192)を rt2800usb ドライバ・モジュールへ追加してビルドすることとしました。なおデバイス ID のベンダーコードの "0411" を見てのとおり、バッファローが製造委託された製品のようです。また lsusb コマンドでも Buffalo の名前が読み取れます。

動作確認

FT-STU-Bng のデバイス ID を追加してビルドし直した rt2800usb.ko をカーネル・モジュールとしてインストールした後、動作確認を行いました。ちゃんと認識をして rt2800usb.ko ドライバ・モジュールで稼働しました。

稼働中は、本体先端の内側から青色の LED ランプが点灯していました。

動作中の NTT FT-STU-Bng のランプの点灯状況です。

ダウンロード

今回ビルドしたドライバ・モジュールを「Debian 用ドライバ保管庫」へアップロードしています。自由にダウンロードして使用してください。ただし自己責任でお願いいたします。

該当する Debian バージョンのホルダの中にあるドライバ・モジュールの rt2800usb.ko をダウンロードするか、私がビルドしたドライバ・モジュールを一纏めにした圧縮ファイル(tar.gz)をダウンロードして使用してください。このドライバ・ モジュールを一纏めにした圧縮ファイルのダウンロードをお奨めします。

ドライバ・モジュールを一纏めにした圧縮ファイルの場合、解凍後、ドライバ・モジュールのインストール・スクリプト modules-update.sh を特権ユーザで実行させると、自動的にドライバ・モジュールをインストールしてくれます。
$ tar zxvf Jessie-wifi-modules_pack.tar.gz
$ su
# ./modules-update.sh


Debian Firefox 46.0 へアップグレード

mozilla.debian.net で配布している Debian 用 Firefox が 46.0 へアップグレードしました。
Firefox リリースノート
バージョン 46.0 — 2016/04/26 リリース

https://www.mozilla.jp/firefox/46.0/releasenotes/

Firefox 46.0 へのアップグレード通知
Firefox 46.0 のクレジット表示

この他、一般の Debian 配布の Iceweasel は 38.8.0esr へアップデートしました。


2016年4月27日水曜日

NEC Lavie LL370/E へ Debian Jessie を再インストール

メモリカード不良が発生していた NEC LaVie LL370/E へ Debian Jessie の Xfce4 をインストールしました。

経緯

メモリ異常のためか個人ファイルだけでなく、システムファイルにも障害が発生していました。復旧を試みましたが、なかなか思うように復旧が進みませんでした。日頃使っていないパソコンということもあり、新規にインストールし直すこととしました。

Debian Jessie の再インストール

再インストールに当たって、デスクトップ環境は前回パフォーマンスの良かった Xfce4 としました。インストールそのものは順調に終了しました。

Debian Jessie の Xfce4 デスクトップをインストールした LaVie LL370/E です。

サウンド関係のトラブル

いろいろと個人的な環境を設定を終えたころ、音声(サウンド)が出力されないことに気づきました。

以前のインストール記事を参照してみると、Gnome3 の環境で Pulseaudio のコントローラで、「アナログヘッドホン(アンプなし)」で動作していました。
NEC LaVie LL370/E へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2015/05/nec-lavie-ll370e-debian-jessie.html

そこで早速同じ設定をしようとしたところ、Alsamixer は存在しましたが、Pulseaudio のコントローラは見当たりませんでした。そこで Pulseaudio のコントローラである pavucontrol をインストールしました。
# aptitude update
# aptitude install pavucontrol

すると [アプリケーション]-[マルチメディア]-[PulseAudio  音量調整] としてインストールされました。

これで Gnome3 の時と同様に「アナログヘッドホン(アンプなし)」を選択してみましたが、音声は出力されませんでした。

PulseAudio のコントローラ

問題点対策

認識されている関連チップとしては SiS SI7012 (AD1981B) ということで、カーネル・モジュールは、snd_intel8x0 が使用されていました。この snd_intel8x0 カーネル・モジュールは、過去にも他機種のパソコンでスピーカとヘッドホンの入れ替えを行ったことのあるチップです。メーカの設計によって様々なバリエーションが存在しているようです。そのため多くのオプション設定ができるようになっています。このオプション設定のうち、音声アンプ回路のオン・オフする部分を負論理にする "ac97_quirk=inv_eapd" が適応しました。上記のとおり、Gnome3 の時に「アンプなし」で音声が出力されたことからも合致します。なおこの設定を行った時には「アナログヘッドホン/アンプ」を選択します。

オプションの設定は以下の通りとしました。音声アンプ回路のスイッチの設定の他、電話回線のモデムも使用しないことからモデム用のカーネル・モジュール(snd_intel8x0m)をブラックリストへ追加して読み込まないようにしました。なお今回の設定ファイルの名前は ll370e.conf としました。そして設定を反映させるためにマシンを再起動させました。
# vi /etc/modprobe.d/ll370e.conf
options snd-intel8x0 ac97_quirk=inv_eapd
blacklist snd_intel8x0m

以上により、音声(サウンド)が出力されるようになりました。

音声が出力されるようになった LaVie LL370/E です。

その他 Alsamixer の [スイッチ] の中の [Headphone Jack Sense] の項目にチェックを入れると音声が出力されなくなりました。音声が出力されないときには、この部分もチェックが必要です。

[Headphone Jack Sense] の項目にチェックを入れない



FreeBSD Asterisk のアップデート

FreeBSD の ports へ Asterisk のアップデート(1.8.32.3_6 から 1.8.32.3_7 へ)が到着しました。

portmaster でビルドを行ったところエラーが発生して、インストールが中断してしまいました。
tcptls.o: In function `__ssl_setup.part.3':
tcptls.c:(.text+0xc59): undefined reference to `SSLv3_client_method'
collect2: error: ld returned 1 exit status
Makefile:183: recipe for target 'asterisk' failed
gmake[1]: *** [asterisk] Error 1

なお、今まで気づかなかったのですが、すでに Asterisk 1.8 系は、昨年 2015-10-21 に開発終了(EOF)となっていました。FreeBSD の ports も 2016-04-30 以降に削除予定となっていました。
Asterisk 1.8 reached EOL on 2015-10-21.

It is scheduled to be removed on or after 2016-04-30.

そこで、上記のエラーの回避を考えるのではなく、新しくAsterisk の 11 系か 13 系へ移行を予定しています。


Debian OpenJava と MySQL のアップデート

Debian Jessie へ OpenJava と MySQL のアップデートが到着しました。



2016年4月26日火曜日

Debian Vivaldi ブラウザのアップデート&フラッシュプレーヤ・プラグイン

いつものように Debian Jessie のリポジトリを更新したところ、なんと! Vivaldi (ヴィヴァルディ)ブラウザのアップデートの通知がありました。リポジトリ情報を確認すると Vivaldi ブラウザのリポジトリが追加されていました。どうも Vivaldi ブラウザのインストーラによって自動的にリポジトリ情報(/etc/apt/sources.list.d/vivaldi.list)が追加された模様です。
# cat /etc/apt/sources.list.d/vivaldi.list

### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
deb http://repo.vivaldi.com/stable/deb/ stable main

更新

Vivaldi ブラウザのアップデート通知


フラッシュプレーヤ(Flashplayer)

初めて Vivaldi ブラウザをインストールしたときには、フラッシュプレーヤが動作しませんでした。その後、フラッシュプレーヤのプラグインの種類が違いことが判明しました。次の "pepperflashplugin-nonfree" プラグインのインストールで、 Vivaldi ブラウザ上でもフラッシュプレーヤが動作しました。
# aptitude install pepperflashplugin-nonfree

追記:2016-05-16

フラッシュプレーヤのプラグインは 64 ビットのものが提供されています。32 ビットのものは終了した模様です。

プラグインのインストール時に以下のような公開鍵のエラーが発生した場合
ERROR: failed to retrieve status information from google : W: 以下の鍵 ID に対して利用可能な公開鍵がありません:
1397BC53640DB551
More information might be available at:
   http://wiki.debian.org/PepperFlashPlayer

一般ユーザの状態で次のように公開鍵のインストールを行ってください。この処理には、コマンドの sudo が必要です。事前にインストールを行ってください。
$ gpg --keyserver pgp.mit.edu --recv-keys 1397BC53640DB551
$ gpg --export --armor 1397BC53640DB551 | sudo sh -c 'cat >> /usr/lib/pepperflashplugin-nonfree/pubkey-google.txt'

2016年4月25日月曜日

A-DATA のメモリカードの修理(失敗)

先日、動作異常で NEC LaVie LL370/E から取り外した A-DATA の DDR メモリの修理を試みてみました。
NEC LaVie LL370/E のメモリカードの異常
http://near-unix.blogspot.jp/2016/04/nec-lavie-ll370e.html

修理を試みたのは、今回取り外したメモリカードの他、一年ほど前に取り外した同じメーカのメモリカードも一緒に行いました。

今回修理を試みた A-DATA のメモリカードです。

再ハンダ付け

修理方法は EDO-RAM などで何度も行ったメモリチップのリードへの再ハンダ付けです。通常の表面実装の左右にリードが飛び出した形状のため、私も再ハンダ付けができる状況でした。再ハンダ付けと言うよりは、ハンダを盛りつけては、ハンダの吸い取り線で余分なハンダを吸い出す作業の繰り返しでした。この作業で精根尽き果てました(笑)

ルーペを使って再ハンダ付け作業です。
上段が未加工のメモリカード、
下段が再ハンダ付けを行ったものです。

動作確認

最悪でした(涙)。
メモリカードを装着したパソコンが起動不良となってしまいました。LaVie LL370/E をはじめ、ThinkPad T30、ThinkPad R40 などなど・・・。正常なメモリカードに交換して、何度か電源の入り切りを繰り返すと再び息を吹き返すという状況となってしまいました。

何度かハンダ不良と思われる箇所を修正して、ようやく ThinkPad R40 でだけ、動作確認ができる状況となりました。しかし 512MB の容量のはずなのですが、256MB しか認識してくれませんでした。またメモリカードのベンダ情報などを取得しようとしましたが、何故かできませんでした。

まだ予想の範疇ですが、メモリチップのリードのハンダ割れなどによる接触不良が発生したのではなく、メモリコントローラのチップが破損しているのではないかと思われました。二枚のメモリカードも同様の状況のため、たまたま故障したというよりか、製造上の問題で早期に寿命を迎えてしまったのではないかと想像しているところです。

もうこのメモリカードを装着するとパソコンが起動不良となってしまう状況のため、修理するのを諦めました。メモリカードの上に載っているメモリチップは再利用可能と思われますので、将来必要なときに備えて「使用不可」で保管しておきたいと思います。



2016年4月24日日曜日

Debian タイムゾーンのアップデート

Debian Jessie と Wheezy にタイムゾーンのアップデートが到着しました。

今回興味を引くのは、いつものようにタイムゾーンに新しい地域データが追加されたり、変更されたという内容ではなく、「バグ修正更新」であったことです。どんなバグかは不明ですが、早めの更新が必要のようです。

タイムゾーンのアップデート通知


2016年4月23日土曜日

NEC LaVie LL370/E のメモリカードの異常

以前入手していた NEC LaVie LL370/E のメモリカード(512MB/PC2700)に異常が発生しました。

今回故障したメモリカードです。

経緯

元々入手した当時に搭載されていた二枚のメモリのうち、一枚は異常が発生していました。そこで一度は二枚とも交換をしていたのですが、そのうち正常に動作していたメモリを元に戻して使用していました。
NEC LaVie LL370/E を入手しました。
http://near-unix.blogspot.jp/2015/05/nec-lavie-ll370e.html

しかしパソコンの電源投入時にファンだけが回転をして、起動をしない状況が発生するようになりました。しかし毎回起動不良が発生する状況ではありませんでした。

そこで memtest86+ でメモリ試験を行ったところ、メモリの異常を発見しました。メモリカードが温まると異常が発生するという典型的なパターンのようです。

memtest86+ でメモリ試験を行ったところです。

対策

不良となった A-DATA ブランドのメモリカードを取り外して、別のメモリカードへ交換しました。

再び memtest86+ で動作試験を行いました。2サイクルほど動作させましたが、問題なく動作しているようです。これでしばらく経過観察をしてみたいと思っています。

メモリカードを交換した後に行った memtest86+ の動作試験です。


2016年4月22日金曜日

玄箱 Debian Jessie の rsyslog の警告問題

今まで気にしていなかったのですが、/var/log/messagesrsyslog の警告が大量に発生していました。

状況

我が家の場合次のような内容で記録が残っていました。
Apr 22 12:50:58 kurobox rsyslogd-2007: action 'action 17' suspended, next retry is Fri Apr 22 12:52:28 2016 [try http://www.rsyslog.com/e/2007 ]

対策

ネット上を検索してみると、ずばりの事例を発見しました。
rsyslogd-2007: action 'action 18' suspended が出る場合の対策
https://www.netfort.gr.jp/~tosihisa/notebook/doku.php/raspberrypi/log20151101_rsyslogd-2007

上記のブログのとおり、/etc/rsyslog.conf の最後の四行を無効化(# によるコメントアウト)して問題が解決しました。
vi /etc/rsyslog.conf
#daemon.*;mail.*;\
#       news.err;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

弊ブログにて配布をしている Debian Jessie をインストールしている読者さんは、是非修正をお願いいたします。なお修正をしなくても、大量に記録が残ること以外に問題は発生しません。

2016年4月20日水曜日

Debian xscreensaver のアップデート

ここしばらくのところ、Xfce4 のデスクトップのスクリーンセーバ(xscreensaver)が「警告 大変古いバージョンです。アップグレードしなさい!」と警告が表示されていました。


何事も安定性重視の Debian ですので、ようやくスクリーンセーバのアップデート(5.30-1+deb8u1 から 5.30-1+deb8u2 へ)が到着しました。

これでようやく、スクリーンセーバの警告表示を見なくてすみます。

なお gnome3 のデスクトップのスクリーンセーバとは異なっているようです。Gnome3 の場合には、アップデートはありませんでした。

FreeBSD MySQL 5.5.49 へアップグレード

FreeBSD の poers へ MySQL のサーバとクライアントにアップグレード(5.5.46 から 5.5.49 へ)が到着しました。

mysql55-server-5.5.49 のビルドオプション


2016年4月19日火曜日

ThinkPad R50e で CMOS 電池トラブル

久しぶりに ThinkPad R50e を立ち上げてみました。すると CMOS 用の電池が消耗していたようで、日付などが初期化(リセット)されていました。

CMOS 用電池のトラブルが発生した ThinkPad R50e です。
起動画面から BIOS 画面へ自動で切り替わってしまいました。
日付の項目を表示させると初期化されていました。

この ThinkPad R50e は以前に銅箔テープ法で CMOS 用電池を交換していました。消耗するには、早いようにも感じました。本体のバッテリパックが存在していないので、CMOS 回路用の電力を一手に引き受けていることもあり、消耗が早かったのかもしれません。

そこで筐体を分解して CMOS 用電池の交換をすることとしました。ThinkPad R50e の CMOS 用電池はパームレスト部分の下に隠れています。

現在我が家で標準としている銅箔テープ法です。

CMOS 用電池の絶縁をしていたテープを剥がして電圧を計測してみました。なんと 3.2 ボルトありました。どうも電池の消耗ではなく、接触不良だったようです。

そこで継続して電池の表面と銅箔が接触を継続できるようにスポンジテープを貼り付けてみました。これで筐体の蓋で常に押さえつけられている状態となり、接触不良も改善されると考えました。

スポンジテープで電池と銅箔の接触を改善してみました。

再び接触不良が発生するかどうか経過観察をしてみたいと思っています。

FreeBSD Perl 5.20.3_12 へアップデート

FreeBSD の ports へ Perl のアップデート(5.20.3_11 から 5.20.3_12 へ)が到着しました。

perl5-5.20.3_12 のビルドオプション


Corega 無線 LAN アダプタ CG-WLCB54AGM を入手

コレガの無線 LAN アダプタ CG-WLCB54AGM をインターネット・オークションにて入手しました。

今回入手したコレガ CG-WLCB54AGM です。

概要

カードバス形式の無線 LAN アダプタです。コレガの製品によく見られるアンテナ部分が薄型の製品で、上下の PC スロットと干渉し難くなっているのが外観上の特徴です。

コレガ CG-WLCB54AGM の外観です。

無線 LAN 部分については、2.4GHz 帯と 5GHz 帯の IEEE 802.11a/b/g 対応となっています。さらに MIMO による 108Gbps 通信にも対応となっていました。

内部には Ralink 社の RT2600 が使用されている模様で、lspci コマンドでその内容が読み取れます。Debian Jessie におけるドライバは rt61pci という今まで見かけたことのないものが適合しました。

動作確認

Debian Jessie が稼働しているノートパソコンの PC カードスロットへ装着すると自動で rt61pci ドライバ・モジュールが読み込まれました。そして CG-WLCB54AGM の内部で使用するファームウェア(firmware-ralink)を事前にインストールしておくと、すぐに動作を開始しました。2.4GHz 帯も 5GHz 帯も問題なく動作していました。ただし MIMO としての動作は、機材がないため、確認することができませんでした。
# aptitude update
# aptitude install firmware-ralink
rt61pci - Debian Wiki
https://wiki.debian.org/rt61pci

ただし、gnome3 のデスクトップを使用していると、周辺にある無線 LAN アクセスポイントを探し出すところまで動作するのですが、何故か接続できませんでした。Xfce4 のデスクトップの場合には問題なく動作しました。同じネットワーク・マネージャを使用しているはずなのに、どうしてこのような差異が出てしまうのかは不明です。

動作中の CG-WLCB564AGM は二個の LED ランプが点灯していました。Link/Act のランプは無線 LAN 通信の状況に応じて点滅を繰り返していました。

CG-WLCB54AGM の LED ランプの点灯状況


2016年4月18日月曜日

シリアル - USB 変換モジュール FTDI232 が Debian Jessie で動作しました

メーカ不詳の シリアル - USB 変換モジュール FTDI232 が Debian Jessie で動作しました。

Debian Jessie で動作することが確認できた FTDI232 です。

経緯

以前、弊ブログにて紹介しました FTDI232 は、Windows XP や Puppy Linux 5.7.1 JP で動作することが確認出来ていました。しかし肝心な Debian Jessie では、受信のみの動作だけで、送信の動作ができない状態でした。さらに調べてみると Debian Wheezy でも同様の状況でした。
メーカ不詳 シリアル - USB 変換モジュール FTDI232
http://near-unix.blogspot.jp/2016/04/usb-ftdi232.html

その後、FTDI232 の中に使われているチップ(FT232RL)を動作させている ftdi_sio.ko のソースコードを調査してみました。問題の FTDI 社が行った偽物の対策が、Linux カーネルモジュールにも影響を与えているか?についてです。私が理解した範疇では、Windows 用ドライバによってデバイス ID を "0403:0000" に書き換えられたチップを "BRICKED" と認識して、何も動作しないように 2014 年ごろに変更が加えられているだけで、Linux のドライバ・モジュールが積極的に動作を制限することはないものと判断しました。

そうすると、余計に Debian Jessie でデータの送信が出来ない理由が解りません。

screen コマンドで動作

そこでネット上を「debian ft232rl」などといろいろと検索してみました。しかし送信だけが出来ない事例を見つけることができませんでした。チップそのものを認識出来ないなどの問題だけが発見できました。その他、多くは Debian 上での使用方法についての解説できした。そこで気づいたことは、このようなシリアル・ポートを使用するときによく使う cu コマンドを使用する事例が何故か見当たりませんでした。その代わり screen を使うものばかりでした。そこで screen コマンドで試しに FTDI232 と通信させてみました。

 すると相手先に送信していることを示す LED ランプがチカチカ点灯しているのを発見しました。急遽、玄箱のシリアルコンソールの外部端子へ接続して確認すると、ちゃんと送受信ができているのを確認しました。

中央部にある二個の LED ランプが送信と受信に対応して点滅しました。

これから判断できることは、ドライバ・モジュールの ftdi_sio.ko は正常に動作しており、何らかの理由で cu コマンドからの送信データを出力出来ない状況にあるようです。

screen で操作事例

screen での通信開始時のコマンドは次の通りです。通信速度は、玄箱用に 57600bps の事例で表記しています。一般ユーザから操作することができます。
$ screen /dev/ttyUSB0 57600
screen の終了は "Ctrl + A" の後、"\(バックスラッシュ)" です。

以下は、玄箱を制御中の端末画面のスクリーンショットを取得したものです。

玄箱起動時の様子です。
玄箱が起動してログインできる状況となりました。
従来であれば、ここで何も出来なくなっていました。
パソコンからのデータが玄箱へ届いてログインできました。
シリアル通信を終了するときには Ctrl+A と \(バックスラッシュ) です。

これでようやく Debian Jessie のマシンから FTDI232 を操作することができるようになりました。Debian Jessie で操作できないことが判明した後、ずっとモヤモヤがありましたが、これですっきりと晴れました!

2016年4月16日土曜日

Debian OpenSSH のアップデート

Debian Jessie と Wheezy に OpenSSH のアップデートが到着しました。


OpenSSH のアップデート通知



2016年4月15日金曜日

玄人志向 玄箱へ SATA-HDD to IDE 変換アダプタを組み込む

自宅玄関で監視カメラセットとして稼働中の玄箱(正確にはケースだけ HD-HLAN )へ、先日紹介したノーブランドの SATA-HDD to IDE 変換を行うアダプタを取り付けました。

玄箱による監視カメラセットの共鳴音対策を行いました。

経緯

玄箱へ組み込んでいた 3.5 インチのハードディスクの振動が玄関部分で共鳴をして、ブーンという耳障りな音が発生していました。家族も変な音が聞こえると訴える始末です(笑)。 そこで 3.5 インチのハードディスクからノートパソコン用の 2.5 インチのハードディスクへ交換して、振動を少なくすることにより共鳴音を低減するを目的としました。

ここで 44 ピンから 40 ピンの IDE 変換アダプタで接続する方法もあるのですが、先日紹介した SATA-HDD to IDE 変換アダプタを使用してみることとしました。
とある SATA-HDD to IDE 変換アダプタ
http://near-unix.blogspot.jp/2016/04/sata-hdd-to-ide.html
今回使用した SATA-HDD to IDE 変換アダプタです。

取り外しと掃除

前回 CF ディスクから 3.5 インチのハードディスクへ交換して一週間ほどの時間が経過しましたが、何と連日の黄砂の影響で、筐体の上部にはしっかりと黄砂が積もっていました。指で触るとザラザラします。筐体を開いて内部のボードなどを観察するとここにも黄砂が入り込んでいました。恐るべし!黄砂! 掃除機や雑巾で綺麗にしておきました。

筐体内部まで黄砂が侵入していました。

ハードディスクのコピー

現在使用している 3.5 インチのハードディスクから 2.5 インチのハードディスクへデータのコピーを行いました。

fdisk コマンドで 3.5 インチのハードディスクのパーティション情報を読み取ると、使用している第3パーティションの最後尾は 15662303 ブロックであることが判明しました。そこでハードディスク全体をコピーするのではなく、この必要最初限度の部分を dd コマンドでコピーしました。

なお今回の事例では、コピー元の 3.5 インチのハードディスクが /dev/sdb 、コピー先の 2.5 インチハードディスクが /dev/sdc として認識されていました。またコピーするブロック数も、きっちりの値ではなく、若干大きめの値を設定して確実にコピーしました。
dd if=/dev/sdb of=/dev/sdc count=15662400
ハードディスクのコピーの様子です。
3.5 IDE ハードディスクから 2.5 SATA ハードディスクへコピーしました。

動作確認

SATA-HDD to IDE 変換アダプタを装着して、パソコンの IDE ケーブルへ接続して正常に動作していることを確認しました。

動作確認中の SATA ハードディスクと変換アダプタです。

組み込み

組み込みには少し注意が必要でした。
まずハードディスクは、2.5 インチのハードディスク用のネジ一本で固定しました。二本以上で固定したいところですが、簡単な作業ではこれで精一杯でした。金属のマウンタは、ハードディスクの熱を逃がすための放熱板としての役目のあるため、しっかりと密着していることが必要です。

マウンタへ取り付けた 2.5 インチのハードディスクです。
マウンタへの固定は写真の丸印の一箇所のネジで固定しています。

このマウンタに取り付けたハードディスクから、一旦 SATA-HDD to IDE 変換アダプタを取り外します。この変換アダプタへ IDE ケーブルと電源ケーブルを取り付けた後、筐体へ組み込む途中で変換アダプタをハードディスクへ装着することとなります。この作業手順は、特に強度が少なくなっている電源コネクタ部分への圧力の負担を減らす目的があります。

最終確認

筐体の蓋を閉める直前の状態で全体の動作確認をしました。特にコピーしたハードディスクで正常に起動をして、さらに motion による動体検知動作を行うか確認を行いました。問題なく動作していることを確認した上で、筐体を組み立て、元の場所へ設置しました。

最終確認中の玄箱の様子です。

共鳴音の状態

やはり振動の少ない 2.5 インチのハードディスクを使用したこともあって、共鳴音はなくなりました。

初めて使用する SATA-HDD to IDE 変換アダプタの動作状況を含めて、しばらく経過観察をしたいと思っています。