ThinkPad 560 で BasicLinux を使う

以前ハードディスクを取り出して debian sarge をインストールしていた ThinkPad 560 ですが、その後 進展がありませんでした。システムのインストールでハードディスクを取り出して、他のマシンへ取り付けて作業を行っていたこともあり、この取り外しの作業にうんざりしていました。そこで何かよい方法がないものかと考えていました。

以前からフロッピーディスクで起動させる BG-Rescue Linux を使うことを考えていましたが、これを上手く使いこなすことができませんでした。バージョン 2.0.0 で USB に大々的に対応したのはよいのですが、ThinkPad 560 には USB 端子がありません。そればかりか pcmcia に非対応になってしまってまったく使いものになりませんでした。ずっと古いバージョンの 1.0.0 を使って有線 LAN 経由でデータの受け渡しをしながらシステムのインストールが出来ないものかと考えていました。

この BG-Rescue Linux でいろいろと検索しているとあの懐かしい Keroppy Linux などのことを思いだしましたが、何故かダウンロードサイトへデータがなく動作の検証もすることもできなくなっていました。

そんな中、発見したのが BasicLinux 3.5 です。BG-Rescue Linux と似ていて、二枚のフロッピーディスクで起動をします。BG-Rescue Linux のカーネルが 2.4 系列という古いものですが、BasicLinux はもっと古い 2.2.26 です。古い ThinkPad を操作するのに相応しい古さです(笑)。そこでシステムのインストールなどで使い物になるのか検証してみました。

BasicLinux 公式ウェブサイト
 http://distro.ibiblio.org/baslinux/

一番の心配ごとは pcmcia に対応して有線 LAN で通信ができるかどうかです。その部分を重点的に検証してみました。

まず BasicLinux 3.5 を二枚のフロッピーディスクへインストールします。BasicLinux の公式ウェブサイトからフロッピーバージョンのものをダウンロードします。解凍して得られたイメージデータのうち、DISK1.IMG を dd コマンドを使ってフロッピーディスクへイメージコピーします。そして DISK2.TGZ を通常の FAT フォーマットしたフロッピーディスクへ単純にコピーしてインストール終了です。

BasicLinux の DISK1 を ThinkPad 560 のフロッピードライブへ挿入して電源を投入します。何の問い合わせもなくどんどん起動してゆきます。そして DISK2 を挿入するように求められますので、そこで DISK1 と DISK2 を入れ替えてリターンキーを押して起動を継続します。最終的に下記のような画面で起動を完了します。

CUI モードでも十分に操作できますが、X も用意されていることから X を起動させて GUI で操作することとしました。起動方法は今ではすっかり忘れ去れてしまった感じとなってしまった startx です。すぐに起動オプションの問い合わせがあります。ThinkPad 560 で大切なことは 800x640x15 で起動しても異常な状態となるため、640×480 (default VGA) を選択して起動する必要があります。他にも設定方法があるのかもしれませんが、標準の選択肢のなかから選べるのはこの一つだけです。他の ThinkPad では 800x640x15 でちゃんと X が起動できるため、この ThinkPad 560 の固有の問題のようです。

pcmcia の有線 LAN を使用するためには pcmcia 関連のモジュールを別途読み込む必要がありました。標準ではサポートされていません。
端末上から次の順番で三つのモジュールを insmod コマンドで読み込みました。

/ insmod pcmcia_core
/ insmod i82365
/ insmod ds

補足:/ は BasicLinux のプロンプト表示です。

モジュールがちゃんと読み込めたか lsmod コマンドで確認してみましょう。

これで pcmcia が使用できるはずです。次にカードマネージャーを起動させます。

/ cardmgr

すると PC スロットへ挿入済みの NE2000 互換の有線 LAN アダプタを認識して使用可能な状態にしてくれます。BasicLinux では NE2000 互換の有線 LAN アダプタしか対応していないようです。

次にネットワークの設定を DHCP 機能を使って設定します。ルーターなどがあれば自動的に設定データを受け取ってネットワークの設定を行ってくれます。使用するコマンドは dhclient ではなく、簡易型の udhcpc コマンドです。

/ udhcpc

設定されたホストアドレスや DNS アドレスなどが表示されるはずです。ここで ping コマンドで通信が開通しているか確認をしてみましょう。

ここまでのことが BG-Rescue Linux で出来なかったところです。私の予想では BG-Rescue Linux は CardBus を装備したノートパソコン以降に対応しているのではないかと思っています。

さて有線 LAN で通信が開通したところでデータの受け渡しを実際に行ってみました。

しかし ftp などメジャーなものが使えません。ftpput という簡易型の ftp クライアントがあるくらいでした。トンネル動作も出来ないようで dd コマンドと組み合わせてハードディスクのイメージデータを転送するなどといった技が使えないようです。その他には wget があるぐらいです。

丹念にコマンドを各ディレクトリ(/bin , /sbin , /usr/bin , /usr/sbin など)を探してゆくと nc (netcat) を発見しました。nc は超単純なデータ転送コマンドですがとても強力なものです。これで ThinkPad 560 のハードディスクのイメージデータをサーバーへ転送実験をしてみることとしました。

コマンドは単純なため、操作するのにちょっとしたコツも必要です。まずイメージデータを受け取るサーバー側でも nc コマンドで待ち受けます。以下のように仮想端末上でコマンド実行して、ThinkPad 560 側からデータが送りつけられてくるのを待ちます。

$ nc -l -p 7000 > thinkpad560-hdd.img

(コマンド解説)nc を待ち受けモードとして、ポート番号は7000番にするものです。そしてパイプを使って thinkpad560-hdd.img というファイル名でデータを保管するという内容です。

サーバー側のマシンの準備が終了したら ThinkPad 560 から nc を使ってハードディスクのイメージデータを発信します。

/ dd if=/dev/hda | nc 192.168.24.2 7000

(コマンド解説)dd コマンドでハードディスク(/dev/hda)の全体のデータをイメージデータとして吸いだします。それをパイプを使って nc へ受け渡します。nc 側ではサーバーマシンの IP アドレス(192.168.24.2)へポート7000番で送り出す内容となっています。

このコマンドを実行すると有線 LAN を経由してサーバーマシンへ ThinkPad 560 のハードディスクのイメージデータが転送されて、thinkpad560-hdd.img のファイルとして保存されます。

10 BASE-T の有線 LAN アダプタを使っていることもあって一時間以上もの時間を必要としましたが無事データの転送が終了しました。この転送が完全なものであるか検証するために md5sum コマンドを使用しました。

サーバーマシン側
$ md5sum thinkpad560-hdd.img

ThinkPad 560 側
/ md5sum /dev/hda

この両者の計算値(ハッシュ)が同一であれば両者のデータが同一であると証明されます。違っていた場合には転送過程で何らかの障害があったものと想像できます。原因を追求して再度転送をしなおす必要があります。

これでデータの転送に時間が掛かってしまいますが、ThinkPad 560 の分解をしないでシステムのインストールの道が開けました。ThinkPad 365X でも BasicLinux 3.5 を使用して同様のデータ転送が出来ることを確認していますので、意外と多くの古いパソコンでこの技が使用出来ると思います。古いノートパソコンではハードディスクの交換が容易ではないものが多いため、BasicLinux を使った nc 転送の技は汎用性が高いものと思っています。

最後に参考として検証したハードディスクのイメージデータを再度 ThinkPad 560 へ書き戻すコマンド例を提示しておきます。

まず最初に ThinkPad 560 側をリッスンモードで立ち上げておきます。

/ nc -l -p 7000 | dd of=/dev/hda

ThinkPad 560 の準備が終了したらサーバーマシンから nc を使ってデータを送り返します。

$ nc 192.168.24.3 7000 < thinkpad560-hdd.img

ThinkPad 560 の IP アドレスが 192.168.24.3 であった時の事例です。ifconfig コマンドで ThinkPad 560 へ設定されている IP アドレスを確認してください。

IBM 10/100 EtherJet CardBus Adapter

ThinkPad 愛好家として、IBM ブルーのストライプの絵柄を見てついうっかりインターネット・オークションで落札してしまいました(笑)。

届いた商品をよく眺めると Xircom と色違いの同様のカプラーケーブルが付属していました。スリットの部分に二個の LED が埋め込まれているのも同様です。

Puppy Linux 4.3.1 (2012) で認識させてみると、xircom_cb という先日の Xircom RBEM56G-100 と同じドライバを読み込んでいました。そして lspci -v で PC カード情報を読み取ってみたところ下記のとおり Xircom 社の製品であることが判明しました。どうやら IBM 社へ対する相手先生産(OEM生産)のもののようです。

Ethernet controller: Xircom Cardbus Ethernet 10/100 (rev 03)
Subsystem: IBM 10/100 EtherJet Cardbus Adapter

そしてカプラーケーブルのプラグ部分は今までに見たことのない形式のものでした。プラグの接点を保護する金属製のフレームの形状が大きくしっかりしたものとなっていました。これであれば今まで数多く遭遇した接触不良にならないのではないかと期待しました。しかし何とカプラーケーブルの先端にある LED がケーブルの角度などによって点滅をする状態となっていました。どうやらこのプラグの形式でも接触不良が発生することを確認しました。このプラグの接点も針先などを使って起こしてやれば接触が改善される可能性がありますが、いかんせん小さい接点ですので躊躇しているところです。

中古で購入した有線 LAN アダプタのうち、カプラーケーブル方式のものが一様に接触不良となってしまうのはどうしたものでしょうか?販売されて10年以上の時間が経過した製品ですので、プラグを構成するプラスチック樹脂が変形をしてしまって接触不良に至ってしまったのでしょうか?それとも長年接触したまま保管をしていると、接点の金属(金メッキをした燐青銅か?)が変形を記憶してしてしまって電気的接触を維持出来なくなっているのでしょうか?何となく接点の金属が変形してしまったとすると、バネの性質を生かしたまま保管するにはプラグを抜いて、PC カード本体とカプラーケーブルを分離する必要があるのかもしれません。しかし保管方法が悪ければ PC カード本体とカプラーケーブルが別々に行方不明になってしまう危険も付き纏います。ちょっと悩ましいところです。

debian squeeze マイナーアップグレード

久しぶりに大量のアップデートが到着していたと思っていたところ、debian squeeze が 6.0.6 から 6.0.7 へマイナーアップグレードをしていました。

アップグレードの前後で特に変わったところは感じられませんでした。そこがマイナーアップグレードの良さなのですが…

これから手持ちの debian squeeze がインストールされているマシンを次々にアップグレードします。

MITEL 5330 電話機

もう半年ほど前にインターネット・オークションで入手していたものです。電源が PoE だけしか方法がなく、PoE アダプタ(インジェクタ)を入手するのに時間が掛かってしまって、なかなか動作確認ができませんでした。今回非純正品(I/0 DATA POE-PS)ながら PoE アダプタを入手することができたため、設定や動作確認を行ってみました。

電話機の背面の様子は LAN ケーブルと受話器へのケーブルの二本だけしか出ていません。

ネット上を検索すると MITEL の電話機を日本で使用してブログなどに掲載している人は少ないようで、主に海外のブログなどを参考にさせてもらいました。

電話機の設定が SIP 方式となっていないため、まず最初に SIP 方式へモード変更しました。そして電話機に設定した IP アドレスへ直接ブラウザでアクセスを行って細かな設定を行いました。いつも asterisk を操作している人であれば設定できる内容です。特に注意点もありませんでした。

asterisk 経由で内線電話との間で通話試験を行いました。とりあえず問題なく動作してくれました。

MITEL 5330 の使用感ですが、受話器を強く握ってもギシギシと音がすることもなく上質な感じで、音質も大変良いものと感じました。またスピーカーによる音声も聞き取りやすい音質のように感じました。スピーカー使用時のハウリングも比較的抑制されている方だと感じます。

そして着信時には着信音だけでなく、右肩の部分にある LED が赤く点滅して知らせてくれます。

着信音のムービーです。

比較的良好な MITEL 5330 ですが、いくつか気になる点もあります。一つは、電源投入時の起動時間です。およそ三分程度かかります。電源を切っていてすぐに使用しようとした場合、まったく対応ができません。常時電源を入れておけば解決なのですが、電源が入っている状態では正面中央部にある液晶パネルが常に点灯している状態となっています。時間が経過すると明るさが一段暗くなりますが、まったく消灯することはないようです。この液晶パネルが常時点灯していることが気にならない人は常時電源を入れたままでもよいのかもしれません。

とりあえず簡単に使用できるまでに設定したのですが、実は多くの設定項目があり、いろいろな情報を液晶パネルへ表示できるのだそうです。しかしまだそのような設定をするまでには至っていません。そのうち時間が出来たときにでも設定してみようと思っています。

Xircom RBEM56G-100 有線 LAN + モデム アダプタ

Xircom 社の RBEM56G-100 という有線 LAN とモデムのコンボ・アダプタをインターネット・オークションで入手しました。先日も Xircom CEM56-100 有線 LAN とモデムのコンボ・アダプタを入手したばかりですが、今回のものはカプラーケーブルのないタイプ(Dangle-less)のものです。

PC カードの Type 3 という最も厚さのある形状をしていて、よく見かける Type 2 のスロットしか用意されていないノートパソコンでは使用することが出来ない形状となっています。

写真は ThinkPad A22e の PC カードスロットへ挿入したときの様子です。PC カード・スロットの大きさいっぱいのサイズとなっていることが判ると思います。ただこの形状のおかげで LAN ケーブルのソケット部分も PC カード本体の中に装備することが出来るようになったことから、ノート・パソコンからはみ出す部分が無くなっています。これは大きなメリットで、このはみ出しの無さからこの RBEM56G-100 を入手した人も多かったのではないかと想像しています。

ThinkPad A22e で Puppy Linux 4.3.1(2012) と Puppy Linux 5.2.8 で動作確認を行ってみました。
どちらの Puppy Linux でも有線 LAN の部分は xircom_cb というドライバが読み込まれました。先日の Xircom CEM56-100 のものとは違ったドライバでした。ドライバ名の最後にある _cb の文字から CardBus 用のドライバと思われます。このドライバで問題なく通信ができました。ただ Pyppy Linux 4.3.1(2012) も Puppy Linux 5.2.8 の両方において、パソコンを再起動させたところ有線 LAN の自動認識が行われませんでした。なぜか dhclient が上手く動作しないようで、通信不可の状態で立ち上がってしまいます。一度有線 LAN アダプタを抜いて、再度差し直すとちゃんと動作してくれます。原因がどこにあるのか不明ですが常用するにはちょっと不便な有線 LAN アダプタになりそうです。

次にモデム部分の確認を行ってみました。なぜか Puppy Linux 4.3.1(2012) も Puppy Linux 5.2.8 の両方ともモデムの検出の時点でシステム停止(ストール)となってしまいました。そしてアダプタを抜くとシステムは復帰して動作を開始しました。モデム部分は上手く認識をしてくれないようです。先日の Xircom CEM56-100 においてもモデムが上手く動作しなかったことから、Xircom のモデムを動作させるのは難しいかもしれないと感じています。

モデム部分を動作させることを今後の課題としたいと思います。

Laneed LD-CDS 有線 LAN アダプタ

また一つ増えてしまいました(笑)。今回もインターネット・オークションで入手しました。Laneed 社の LD-CDS は 10BASE-T の遅い速度の有線 LAN アダプタとなります。
 
外観は PC カード本体 にカプラーケーブルが附属する構造となっています。このカプラーケーブルのプラグ部分はトラブルが多いので少し心配をしています。

そして表面に貼り付けられている製品シールが表と裏が大変似通っているためどちらが表なのか判りにくいように感じました。

早速 Puppy Linux 5.2.8 上で動作確認をしてみました。通信用のチップは不明ですが NE2000 互換製品のようで pcnet_cs のドライバが読み込まれました。一見問題なく動作しているように見えましたが、次のような bogus packet (異常パケット)を受信していました。原因がこの LD-CDS にあるのかどうかは不明です。

eth5: bogus packet: status=0x80 nxpg=0x53 size=1456

2013-02-23 追加
やはりカプラーケーブルのプラグ部分の接触不良は本機においても発生しました。写真のようにケーブルが水平状態だと接触を保っていますが、ケーブルを持ち上げたり、垂れ下がった状態となると接触不良となり、通信リンクが切れました。残念ながらこの種類のプラグはどれも接触不良となってしまうようです。