FreeBSDをアップグレード

　FreeBSD 8.0 がリリースされました。そこで我が家のサーバーをようやくバージョン 6.4 から 7.2 へ引き上げることとしました。

　取り合えずcsupのsupfileの設定を変更してcvsupを実行します。新しいバージョンへ置き換えることからいつもより時間がかかっていました。

　build中に問題が発生しないように/usr/objをディレクトリを綺麗さっぱりと消去してbuildworldから作業を開始しました。

２種類のマシンでworldをbuildする処理時間です。

pentium3 1GHzのマシンで3時間33分の作業時間となりました。
　11102.251u 1055.167s 3:33:02.19 95.1% -1334+1469k 43480+5261io 3429pf+0w

pentium2 530MHzのマシンで8時間15分ぐらいです。
　25318.128u 2794.628s 8:15:44.54 94.5% -606+212k 69681+5128io 34758pf+24w

pentium3 800MHzのマシンで5時間9分ぐらいです。
　16177.483u 1772.411s 5:09:45.76 96.5% 750+-153k 67228+5256io 28690pf+24w

pentium4 2.2GHzのマシンで1時間53分ぐらいです。
　5776.975u 577.756s 1:53:05.84 93.6% -1080+-1811k 38889+5448io 5038pf+0w


これからじっくりとカーネルをビルドします。


ついでのkernelのbuildも終了しましたので処理時間の報告を。

pentium3 1GHzのマシンで1時間10分の時間となりました。
　3708.510u 313.423s 1:10:51.49 94.6% -4852+2707k 15682+8064io 156pf+0w

pentium2 530MHzのマシンで2時間45分ぐらいです。
　8614.701u 846.911s 2:45:45.34 95.1% 1065+-2012k 26676+8027io 570pf+0w

pentium4 2.2GHzのマシンで0時間30分ぐらいです。
　1527.591u 127.273s 29:52.21 92.3% 5938+2340k 12133+1622io 15pf+0w

pentium3 800MHzのマシンで1時間24分ぐらいです。
　4530.692u 417.570s 1:24:49.60 97.2% -2924+2295k 18384+1590io 310pf+0w

そしてinstallkernelを実行すると" file isn't dynamically-linked "と大量に表示されて驚かされます。バージョン6系から7系へアップグレードする時の通過儀礼らしいです。そしてそのままrebootして再度ログインするとちゃんとカーネルは 7.2 へとアップグレードされていました。

　Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
　 The Regents of the University of California. All rights reserved.
　
　FreeBSD 7.2-RELEASE-p4 (GENERIC) #0: Sun Nov 29 17:39:34 JST 2009
　
　Welcome to FreeBSD!

このあとinstallworldを行って、mergemasterを実行します。mergemasterの実行の前に必ず"/etc"をバックアップしておきます。ついつい忘れがちなものです。
　# cd /usr/src
　# make installworld
　# cp -Rp /etc /etc_back
　# mergemaster -Ui　------注1
　# reboot

"portupgrade -af"でインストールしてあるソフトのすべてを再ビルドとインストールする。このときruby関係でトラブルが発生しやすいので、rubyの部分だけ先にビルドしておくことが吉！

再度マシンを立ち上げ直した後、古いライブラリなどを削除しておく。ただし全てのソフトが正常に稼働することを確認しておくことが必要です。これでライブラリを削除してしまうので、アップグレードが完了する前に行うとportupgradeをするとライブラリ不足で悩まされることとなります。
　# cd /usr/src
　# make delete-old　---------注2
　# make delete-old-libs　----注2
　# reboot

再度のマシン立ち上げ直しで無事ログイン出来て、各部の動作に問題なければシステムまわりのアップグレードは終了です。

注1：mergemasterでの問い合わせで一番多いのでは、どれを残してどれをインストールするかです。"-Ui"オプションでは、定型的な変化のものを自動的にインストールしてくれて、判断がつかないものを問いあわせてくれます。本当に必要か不要かの判断ができない場合、"d"を押してインストールしない選択にしましょう。passwordやgroupなどの間違っても新しいファイルをインストールしてはいけないものがインストールされる心配がありません。

注2：問い合わせが半端無く多いです。面倒なので以下の方法で一括して"yes"と返事しましょう。
　# yes | make delete-old
　# yes | make delete-old-libs

Willcom WX310K で PPP 接続 (3)

　Willcom WX310K で PPP 接続が出来るようになって、ブラウザで各種のウェブサイトを閲覧して回ってみていることでしょう。しかし異常な通信の遅さに驚いていませんか？私も驚きました。Willcom WX310K 本体だとここまで遅くないからです。

　原因はもちろん基本的な通信速度の遅さ（32kbps or 64kbps）なのですが、さらにパケットの応答の遅さも原因となっています。

　さらに DNS の名前解決でも通信の反応が遅くなっているようです。ブラウザの通信ステータスの部分を観察していると「アドレス解決をしています」の文字が頻繁に、それも数秒間にも渡って見られます。

IPv6対策
　IPv6の接続でも DNS の名前解決で時間がかかることがあることが知られていますが、debian-lennyでは ppp 接続では問題はないようです。
　がしかし、念のためにIPv6の動作を停止させておきました。WX310Kで通信をするノートパソコンなどでは当分 IPv6 は必要ないと思われるからです。

/etc/modprobe.d/aliases の中の "alias net-pf-10 ipv6" の項目を "alias net-pf-10 off"に変更します。これでOSを再起動させれば IPv6 が無効になっているはずです。試しにスーパーユーザーになって ifconfig のコマンドを実行すると LAN の eth0 の項目にあった IPv6 アドレスなどが表示されなくなっているはずです。

mdns4(マルチキャストDNS)対策
　それから DNS の名前解決で時間がかかっている理由にmdns4(マルチキャストDNS)も悪さをしているようです。/etc/nsswitch.conf を修正して mdns4 を利用しないようにします。

/etc/nsswitch.conf を以下のように修正します。これで hosts などの files を検索した後、resolv.conf にある DNS を検索するようになります。

hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
　　　　↓
hosts: files dns

以上の対策で随分と通信が速くなったように感じます。しかし ping コマンドを IP ではなくドメイン名で行うとパケットロスが異常に発生していることが判ります。

以下は一例です。

IP で ping を実行した場合
# ping 125.1.152.139
PING 125.1.152.139 (125.1.152.139) 56(84) bytes of data.
64 bytes from 125.1.152.139: icmp_seq=1 ttl=51 time=562 ms
64 bytes from 125.1.152.139: icmp_seq=2 ttl=51 time=237 ms
64 bytes from 125.1.152.139: icmp_seq=3 ttl=51 time=233 ms
64 bytes from 125.1.152.139: icmp_seq=4 ttl=51 time=228 ms
64 bytes from 125.1.152.139: icmp_seq=5 ttl=51 time=226 ms
^C
--- 125.1.152.139 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4016ms
rtt min/avg/max/mdev = 226.181/297.635/562.011/132.243 ms

ドメイン名で ping を実行した場合
# ping tatsuya.dnsalias.com
PING tatsuya.dnsalias.com (125.1.152.139) 56(84) bytes of data.
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=2 ttl=51 time=238 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=4 ttl=51 time=239 ms
64 bytes from nthrsm091139.hrsm.nt.ftth4.ppp.infoweb.ne.jp (125.1.152.139): icmp_seq=6 ttl=51 time=219 ms
^C
--- tatsuya.dnsalias.com ping statistics ---
8 packets transmitted, 3 received, 62% packet loss, time 21796ms
rtt min/avg/max/mdev = 219.281/232.374/239.428/9.267 ms

なんとドメイン名で ping を実行した場合には、一つおきにしかパケットが返ってきませんでした。"icmp_seq=" の文字のところの数字が何番目の通信かを示しています。この例では 2,4,6,と偶数番目のパケットしか返ってこなかったわけです。
この状態では上手く通信ができません。パケットロスが大発生している状況だからです。これは DNS の名前解決の応答に時間がかかっているためです。検証には "ping -n ドメイン名" のコマンドで調べることができます。IP で ping を実行した場合と同様の結果が得られます。

応答時間の問題からくる DNS の名前解決の問題対策
この応答時間の問題からくる DNS の名前解決の問題対策は簡単です。単純に DNS の名前解決をキャッシュしておけばよいことなのです。一般的な Linux ディストリビューションでは、通信の度に DNS の名前解決を行っています。この DNS の名前解決をキャッシュで行ってしまえば、レスポンスが改善されるはずです。

DNS の名前解決をキャッシュすることとして、ネット上では "dnsmasq" を使う方法と "NSCD" を使う方法が紹介されています。両方を確かめたところ、NSCD の方が設定などの面で楽だと判断しました。ここでは NSCD による方法を紹介します。

NSCD は aptitude でインストールしました。

# aptitude install nscd

NSCD がインストールされると、各種設定ファイルなども一緒にインストールされます。この中で、"/etc/nscd.conf" の中にある "hosts" の項目が "no" になっているのを "yes" に変更しておきます。

これで DNS の名前解決で得られた IP がキャッシュされることとなり、何度も DNS へ問い合わせを行って無駄な時間を使ってレスポンスが低下するのを防ぎます。

NSCD の設定を変更したら、NSCD のデーモンを再起動させておきます。

# /etc/init.d/nscd restar

この状態で無駄な DNS の問い合わせがなくなり、通信がかなり改善されていると思います。
Willcom の端末を使って通信をしている人で通信速度に不満のある人は試してみては如何でしょうか？

Willcom WX310K で PPP 接続 (2)

　Willcom の WX310K で PPP 接続が前回までに出来るようになりましたが、接続後2分で接続が切れてしまいます。今回はこの対策を行います。

/etc/ppp/options の "lcp-echo-failure" の項目を "0" に変更します。なおファイルの変更はスーパーユーザーになって行います。

lcp-echo-failure 0

ここはモデムの通信が生きているかどうかを判定するものですが、これを無効にします。これで2分を越えて接続が出来れば大丈夫です。なおモデムの通信が途絶えても検知することができません。通信が停止したと思ったらWX310Kの画面で接続の有無を確認することとなります。

Willcom WX310K で PPP 接続 (1)

Puppy Linux で Willcom の WX310K を使用して PPP 接続をしていましたが、debian linux (lenny) でも PPP 接続をしてみました。ここでは接続までの手順を備忘録として書きました。debian linux で PPP 接続をするときの参考にしてください。

pppd を直接コマンドラインで打ち込むのもせっかくのデスクトップがもったいないので、gnome-ppp をインストールしました。インストールはいつものaptitudeを使って一発導入です。gnome-ppp と一緒に ppp も一緒にインストールされると思います。

gnome-ppp を起動させて、初期設定を行います。

まずは基本的なユーザー名やパスワード、アクセスポイントの電話番号の入力です。アクセスポイントの電話番号の前には "DT" をお忘れ無く。

次に "Setup" のボタンを押して各種の設定を行います。


まず WX310K を USB ケーブルでパソコンと接続しておきます。次に "Detect"(検出) のボタンを押して WX310K を USB モデムとして認識しているか確認します。通常は /dev/ttyACM0 として認識されます。そして "Analog Modem" と認識しますが、ここで "ISDN Modem" に変更しておきます。
"Init Strings" は "Init 2 ATZ" , "Init 3 ATS0=0" としておきます。


次に "Networking" のタブを開きます。ここではIPやDNSの設定を行いますが、プロバイダから指定されたものを設定します。


次に "Options" のタブを開きます。"Check defaut route" と "Ignore terminal strings(stupid mode)" へチェックを入れます。

これで gnome-ppp での設定は終了です。このまま "Connect"（接続）のボタンを押しても各種のエラー表示が出て、接続出来ないものと思います。それは pppd が一般ユーザーに開放されていないからです。
本当はセキュリティ上問題があると思われますが、以下の方法で pppd や pppd が使うファイルの属性を変更して、一般ユーザーからも使用できるようにします。

pppdの属性変更
属性変更はスーパーユーザーとなって行います。

# ls -l /usr/sbin/pppd
-rwsr-xr-- 1 root dip 269156 2008-11-29 02:48 /usr/sbin/pppd
# chmod o+x /usr/sbin/pppd
# ls -l /usr/sbin/pppd
-rwsr-xr-x 1 root dip 269156 2008-11-29 02:48 /usr/sbin/pppd

pap-secrets , chap-secrets , peers のファイルやディレクトリの属性変更

# chmod 666 /etc/ppp/pap-secrets
# chmod 666 /etc/ppp/chap-secrets
# chmod 777 /etc/ppp/peers

これで gnome-ppp の "Connect" ボタンを押して接続を確認してください。接続が出来れば終了です。
もちろんのことですが、この接続の前に LAN が接続されているならば、この LAN を解除しておく必要があります。一番手軽で確実なのは LAN ケーブルを抜くことです。ケーブルを抜かなくても標準的な gnome でデスクトップを使用しているならば、右上にあるパソコンが二台重なったような LAN のアイコンを右クリックして "ネットワークの有効化" のチェックマークを外すと LAN 接続が解除されます。

CD/DVDドライブ交換の悪影響

先日交換したCD/DVDドライブですが、インストール当時からハードディスクの認識に変な悪影響を与えていました。とうとう普通に使っていたところ、突然ハードディスクが認識されなくなって、パソコンがフリーズする現象が頻発するようになりました。

最初は、ハードディスクが寿命を迎えたものだと思っていました。慌ててハードディスクの内容をバックアップするなどの対応に追われました。しかし他のパソコンに問題のハードディスクを接続しても突然死することもなく順調に動いています。そこで元のIBM S50 (8183-DGJ ) に接続して、CD/DVDドライブを外すと、やはり調子良く動きます。これでCD/DVDドライブが悪影響をしていると判断しました。

CD/DVDがないと毎月訪れるCDを大量に焼き付ける作業のとき、焼き付けるパソコン不足になってしまいます。どうしてもCD/DVDが使えるようにしたいと思いました。しかし新しいドライブを買う予算もないため、現状のドライブを使いこなすことを検討しました。


そこで考えたのが、SATAをraidでサポートするPCIカードを使って、このカードからハードディスクにアクセスすることでした。手元に玄人志向の SATARAID-PCI ( SiI3512 ) を使うこととしました。早速パソコンのIBM S50 (8183-DGJ ) の拡張PCIコネクタに取り付けてみました。電源を入れるといつもよりBIOSの起動に時間が掛かってドライブカードのバス・コンフリクト（バスの衝突）だと表示されて、パソコンが起動しなくなりました。二ヶ所あるPCIコネクタをそれぞれ取り付けて試してみましたが同様の結果となりました。


次に CD/DVD を EIDE-raidカード (Iwill raid100) からアクセスする方法に切り替えました。こっちは何故かBIOSの起動も問題なく、無事OSの立ち上げに成功しました。立ち上がったdebian-lennyからCD/DVDドライブが認識することができました。またCDへの書き込みも出来ました。

しかし問題は、このCD/DVDドライブからパソコンの起動が出来ないことでした。1CD-Linuxなどの確認で起動出来ることが望ましいことですが、他のパソコンでも確認が出来るため、CDブートは諦めることとしました。debian-lennyの更新はネットから行うことが出来るのでCDブートは必須条項でもないので、余程のことがなれば問題はないと思っています。

意外なことでしたが、IDEドライブとSATAドライブの相性がこれほど悪いパソコンがあることを初めて知りました（苦笑い）

popfile のアップグレード

popfile-1.0.1 ---> popfile-1.1.1 へアップデート

少し前まで sed コマンドの使い方の間違いで ports のアップデートが出来ない状況でした。メンテナンスさんのご尽力によって今回無事アップデートが完了しました。

なお今回は sqlite3 のインストールも行われていましたが、これって以前から popfile で使用されていましたっけ？

p5-DBD-SQLite-1.25
sqlite3-3.6.14.2
popfile-1.1.1

CD/DVDドライブの交換

IBM S50 の CD/DVD ドライブが故障しました。ISO データを焼いて、書き込んだ内容をチェックするため、元の ISO データと dd コマンドで読み出した CD のデータの md5sum 値が異なっていました。

最初はたまたま何かの間違えでもあるのかと思って、２枚目も md5sum が違っていました。それも１枚目とも md5sum 値が違うのです。もうこの時点でおかしいのは解っていましたが、もう１枚焼いて確信への変わりました。

一年ほど前に買っておいた CD/DVD ドライブがあったので、これを使うこととしました。もともと違うパソコンで使用することを前提に考えていたものであったので、ベゼル部分がクリーム色となっていて、IBM パソコン特有の黒色のボディーと華麗なほどのアンマッチとなってしまいました。

しかし新しく取り付けた CD/DVD ドライブは調子よく、書き込んだデータの md5sum 値が異なることもありませんでした。

なお新しいドライブ('Optiarc' 'DVD RW AD-7200A')を IBM S50 (8183-DQJ) を取り付ける上でちょっとトラブルがありました。

元々取り付けてあったドライブ('HL-DT-ST' 'RW/DVD GCC-4481B')はCSのポジションで、P-IDEのプライマリ／マスター側に接続してありました。そしてハードディスクはS-ATAのマスター側に接続してありました。

これをそのまま新しいドライブに交換しましたが、S-ATAのハードディスクを認識しなくなりました。そこでコネクタの位置やケーブルセッティングを変更してうまく動作することが出来たのが以下の条件でした。

CD/DVDドライブのケーブルセッティングをCS->Masterにして、P-ATAケーブルのプライマリ／マスター（先端側）のコネクタにつなぐ方法でした。

なおケーブルセッティングがケーブルセレクトのCSポジションで動作不良となる理由は不明です。同じ条件でお困りの読者さんがいらっしゃればご参考にしてください。

平和記念公園から無線LAN

数週間前からwillcomの携帯電話からインターネットへ接続することを散々してきましたが、意外な盲点があることを知りました。灯台下暗しの喩えはあるんですね！

平和記念公園では一般来場者のために広島市が無線LANを公開していました。それも無料で！太っ腹！　そして取材をしてインターネットに接続したかった場所はまさしく平和記念公園内にある国際会議場でした。携帯電話などを使うより無線LANの方が安定性も良さそうなので期待も膨らむばかりです。


さて無線LANはIEEE 802.11のbとgに対応しているようです。早速、平和記念公園に出かけて接続の確認をしてみました。


いつものようにThinkPad 235 と無線LANカードとしPLANEX GW-NS54CW (IEEE 802.11 b/g) と CISCO AIRONET 340 series AIR-PCM340 (IEEE 802.11 b)の二枚を念のために持って行きました。速度は IEEE 802.11 b なので遅めですが消費電力で優位なCISCOのカードを使用したいと思っていました。もともと速度も ThinkPad 235 では速いカードでも動作は遅くなってしまいますから。


平和記念公園に到着してパソコンを起動させて無線LANの状況をスキャンしてみました。ありました「peace_memorial_park」の文字が！　このアクセスポイントを選択して接続を試してみました。


接続設定も順調に行き、ブラウザを立ち上げてどこか適当なところにアクセスすると平和記念公園の無線LANの管理ページにリダイレクトされました。ここで利用者登録やログインをするようになっていました。


利用者登録を済ませ、ログインも完了するとログインページが表示され、ログアウトのボタンも表示されていました。

このページを残したまま、新しいタブを開いてgoogleやyahooのトップページにアクセスをしてみました。無事表示することもできました。

しかしここからが問題でした。どうもアクセス制限がかなり厳しい模様で、このブログにさえアクセスすることが出来ないのです。もう特定のページしかアクセスできない感じでした。結局使えない無線LANでした。

しかしこの広島市の無線LANは、11月8日から始まる世界最大級のインターネット技術会議（第76回IETF広島会議）が開催されるのに合わせ、インターネットが無料で利用できるエリアを平和記念公園から平和大通りにも拡大したそうですが、この会議で使用できるしろものでは到底なさそうでした。一体何のための無線LANなのかと思ってしまうところでした。やはり行政のやることは「お役所仕事」というところでしょうか？実態はともあれ、実施したという実績だけが大切なのでしょう。とほほ。

dvgrab でキャプチャ

ビデオ編集ソフトの kino のキャプチャ機能でビデオカメラから動画を取り込もうとしていましたが、どうしてもキャプチャ機能が正常に動作しない状況です。具体的には、最初の一回目の再生は動画も音声も綺麗に取りこめるのですが、一度でもストップをした後、再度再生スタートするともう音声がブツ切れの状況になってしまうのです。

そこで dvgrab というキャプチャソフトを使ってビデオカメラの動画を取り込んでみました。こっちは音声がブツ切れになることもなくスムーズに取り込むことができました。やはり問題は kino にあったようです。

取り合えずこの dvgrab のインストールなどの様子です。

debian-lenny なので、私がいつも使っている aptitude でインストールをしました。

# aptitude install dvgrab

取り合えず一般ユーザーでコマンドを入力して動作を試みましたが、ビデオカメラが見つからないというメッセージを吐いて止まってしまいました。

$ dvgrab capture
rom1394_0 warning: read failed: 0x0000fffff0000418
rom1394_0 warning: read failed: 0x0000fffff000041c
rom1394_0 warning: read failed: 0x0000fffff0000420
rom1394_0 warning: read failed: 0x0000fffff0000424
Error: no camera exists

こんな時には、意外とスーパーユーザーだとうまく行く場合があるので試してみました。するとすんなりと動作しました。

# dvgrab capture
Found AV/C device with GUID 0x000085000014acb4
Capture Started
^C"capture003.dv": 553.78 MiB 4839 frames timecode 00:45:11.17 date 2009.10.16 19:19:45
Capture Stopped

これでコマンドを実行しているカレント・ディレクトリにcapture001.dvという動画を取り込んだファイルが出来ます。続けて同じコマンドを実行するとcapture002.dvと末尾の数字が一つずつ大きくなるファイル名で保存されます。

後は kino でこの動画ファイルを開いて編集すれば大丈夫でした。ただキャプチャした動画ファイルの所有者がrootになっているので、キャプチャが終了したらユーザーの変更を行っておくと後が楽になります。

# chown user:user *.dv ---- userの部分は実際のユーザー名ですよ！

kino でビデオキャプチャ

今までビデオ編集をするために、ビデオカメラで撮影した動画を一旦ハードディスク・レコーダーに記録をして、DVDに焼くかLANでmpeg2データとして編集用パソコンに取り込んで編集を行っていました。

もう10年前ぐらいに購入していたIO DATA の GV-DVC2/PCI という ieee1394(firewire) のPCIカードがあったので、これをパソコンに装着して、直接ビデオカメラの動画を取り込もうとしてみました。

とりあえず日頃使っている IBM S50 (P4-3GHz , Mem-1GB , OS:debian-lenny) のパソコンに取り付けてみましたが、どうも相性が悪いようでうまくビデオカメラと通信が出来ませんでした。

そこで IBM M34 (P3-1GHz , Mem-512MB, OS:debian-lenny) のパソコンに同じieee1394のカードを取り付けたところ、通信は出来るようになりました。今回はこの取り付け作業の報告です。

これが取り付けるieee1394のカードのGV-DVC2/PCIです。ミニ4ピンのコネクタが2個設置してあるものです。

そしてこれがieee1394のカードを取り付けるパソコンの IBM M34 です。

パソコンの蓋は1本のネジで固定されていますので、このネジを取り外して内部を開きます。PCIカード部分はマザーボードからライザカードとして取り付けるようになっています。PCIカードが2枚まで装着出来るようになっていますが、残念ながらパソコンの底の方に当たるPCIコネクタにieee1394のカードを取り付けると、他の部品と干渉して取り付けることができませんでした。そこで外側の方のPCIコネクタにieee1394のカードを取り付けました。

ieee1394のカードを取り付けた後、逆の順番でパソコンを組み立てます。そしてパソコンの操作が出来るようにようにセットアップを行います。

パソコンを立ち上げたら、ieee1394カードが正しく装着されていることを確認します。

　# lspci -v
　01:09.0 FireWire (IEEE 1394): NEC Corporation Firewarden (rev 02) (prog-if 10 [OHCI])
　　Subsystem: I-O Data Device, Inc. Device c030
　　Flags: bus master, medium devsel, latency 32, IRQ 19
　　Memory at febff000 (32-bit, non-prefetchable) [size=4K]
　　Capabilities: [60] Power Management version 1
　　Kernel driver in use: ohci1394
　　Kernel modules: ohci1394

そしてモジュール類が組み込まれているのかを確認します。2種類のモジュールが組み込まれているのがわかります。

　# lsmod | grep 1394
　ohci1394 24976 0
　ieee1394 75832 1 ohci1394

ビデオ編集ソフトの kino は raw1394 を経由してビデオカメラとアクセスするので、このモジュールを手動で組み込みます。今回は確認のために恒久的に組み込みません。そしてraw1394のノードを一般ユーザーでも使用出来るように変更を行っておきます。

　# modprobe raw1394
　# chmod 666 /dev/raw1394
　# ls -l /dev/raw1394
crw-rw-rw- 1 root disk 171, 0 2009-10-19 13:55 /dev/raw1394

raw1394 のモジュールを組み込むと dmesg に以下のような記録が残ります。

　[ 380.998413] ieee1394: raw1394: /dev/raw1394 device initialized

この状態でパソコンとビデオカメラをieee1394のケーブルを接続します。
するとビデオカメラ側でも接続して通信が出来る状態となります。使用しているビデオカメラの場合には、モニター液晶画面の右下に「DV入力」の文字が表示されます。一つ前に確認した IBM S50 の場合、モジュール類の組み込みは正常に行えたのですが、なぜか通信が出来なくて、DV入力の文字が点滅する状態となっていました。またdmesgで確認してもビデオカメラを認識していませんでした。

正常に認識すると以下のような dmesg が記録されます。

　[ 916.112342] ieee1394: Node added: ID:BUS[0-00:1023] GUID[000085000014acb4]
　[ 916.113739] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
　[ 916.256042] IEEE 1394 device has ROM CRC error
　[ 916.434821] NOTE: The dv1394 driver is unsupported and may be removed in a future Linux release. Use raw1394 instead.

これで kino からビデオキャプチャを行うと動画の取り込みができました。しかししばらくキャプチャをしていると音声がブツブツと切れたようになってしまいます。上記の dmesg にも「IEEE 1394 device has ROM CRC error」の表示があることから、まだieee1394カードが完全に動作をしていないようです。今後、この部分を詰めて行く予定です。

php5 のアップデート

php5 を 5.2.11 から 5.2.11_1 へ portupgrade を使ってアップデートしました。特に問題はないようです。

昨日の失敗を踏まえて

今日も外出先からブログの更新を試みています。

以前にも成功したThinkPad 235 + Puppy Linux 4.12 + Nikon D2H の組合せです。
実際に何度もノートパソコンを持ち出して更新を重ねるごとに作業の要領もよくなっているようです。

今日はさらに TinkPad 235 に Puppy Linux 4.30 もインストールしているので、こちらでも動作確認をしておくこととしました。

今日の更新場所は広島市の横川駅前からです。

ここからは Puppy Linux 4.30 からの更新です。
無事ネットへの接続も更新も可能でした。
しかし昨日問題となったメモリースティックとPCMCIAカードの読み取り、認識ができないのは一緒です。どうもハードウェア側に問題があるのでしょうか？

事前の確認が大切

今日もノートパソコンの ThinkPad 235 を持ち出して、屋外からブログの更新をしようと思っていました。いろいろと写真を撮影してノートパソコンに写真を取り込もうとしたのですが、メモリカード（メモリースティック）が認識されないため大変困ってしまいました。結局ブログの更新は、なんやかんや手間が掛かったおかげで電池低下となり断念してしまいました。なお本日使用したデジカメはソニーのDSC-F55Kという古い200万画素のものです。


写真のようにソニー純正のメモリスティックをPCMCIAに変換するカードを使用しました。実は出かける前に ThinkPad 235 ではなく、兄弟機種の ThinkPad 535x で同様の読み込み操作をして動作することを確認していたのでした。それも使用しているOSは Puppy Linux 4.12 の同じバージョンを使用していました。何が悲しくてこんなことになってしまったのか私にはまだ原因がつかめていません。

今日の教訓は、実際に使用する機材で本当に行いたい操作を行って動作が出来ることを事前に確認しなければならないということでした。

Puppy Linux 430 JPRC をインストール

Puppy Linux の最新のバージョンが公開されたため、早速インストールをしてみました。
なおカーネルの違いなどによって三種類のisoイメージが公開されていますが、今回使用したのは、最新のkernelを持っている 430 JPRC ( kernel 2.6.30.5 ) です。

alpha版とbeta版を試しに使っていたので、同じ要領でインストールなどを完了させました。

起動動作はますます機敏になった感じがしました。その他の部分もブラッシュアップが図られているようです。

詳しくはこれから実際に使って確認してゆく予定です。

namazu2 のアップデート

検索エンジンの namazu2 のアップデートを行いました。

namazu2-2.0.19 --> namazu2-2.0.20

FreeBSD のアップデート

久しぶりにカーネルのセキュリティー・アップデートがありました。ウェブサーバーとルーターのアップデートを行いました。

毎度、セキュリティー・パッチだけを当てるのではなく、カーネールを再構築しています。


FreeBSD 6.4-RELEASE-p7 (MYKERNEL) #9: Wed Oct 7 01:33:20 JST 2009

恥ずかしながらカーネル名はMYKERNELです。

プリンタのインク交換

ブラザーの複合プリンタのMFC-830CLNのインク交換をしました。

以前から純正インクではなく、互換インクを使用していました。
何種類かを試していましたが、現在使用している互換インクは空気抜きの穴からインクが漏れてしまうものでした。しかたがなくティッシュを空気穴のところに置いて、こぼれたインクを吸い取らせていました。このインク交換のときに漏れ具合を確認することとなるのですが、写真のようにびっしょりの状況でした。
やはり安いには理由があると実感する場面でした。


新しい互換インクに交換した後、再度ティッシュを置いて液漏れに対応することとしました。スキャナーをかねた蓋がしっかり締まらないのがちょっと辛い感じでした。

w3m からの投稿

これは、テキストブラウザの w3m を使っての投稿のテストです。
Firefox や SeaMonkey などの本格的なブラウザを使わなくても、このテキストブラウザから投稿できることを確認してみました。
ターミナル端末上での操作のため、とても軽快です。昔はこうして掲示板に投稿をしていたことを思い出しました。

屋外からのブログ更新

今月末に大きな取材が控えていることもあって、手持ちの機材で屋外からブログの更新ができるのかを確認するために、ノートパソコンを持ち歩いて、実際にブログを更新してみました。

現在は自宅を出て、広島駅南口の噴水の前にいます。ここからwillcomの回線を使って通信をしています。ノートパソコンが古いIBM ThinkPad 235 というPentium-mmx 230MHz のものです。回線が遅いのかパソコンが遅いのかよくわからない状況の中での更新となります。こんなイライラ感と一緒に作業ができるのかを確かめるのが今回の目的です。

とりあえず現場でノートパソコンの写真を撮り、写真も縮小加工をしてアップロードしてみました。

ここまでの作業で待ち時間も合わせておよそ30分もの時間がかかってしまいました。バッテリーの残量も100%から58%へ減少していました。回線の遅さはどうしようもありませんが、ノートパソコンについては、もっと速度の速い機種を選ばないと実際の作業として難しい感じがしました。


ThinkPad 235 には Puppy Linux 4.12 と MS-DOS 6.2がインストールされています。ブログなどのネット接続では linux を使用しています。

それぞれのGRUBによるマルチブート化の実験（puppy のインストール）

新しく領域（パーテーション）を設けて puppy をインストールします。

GParted を使用してpuppy をインストールする領域を設けました。

現状は以下のような領域となっています。

• sda1 - debian
• sda5 - debian
• sda6 - debian
• sda7 - swap
• sda8 - debian
• sda9 - debian
• sda10 <-- ubuntu がインストール済みです。
• sda11 <-- ここに puppy をインストールします。

puppy はまず通常どおりにlive-CDから起動させて frugal インストールを行いました。このpuppy が正常にインストールされたことを確認するために、puppy のブートコードを ubuntu の GRUB の menu.lst へ追加して、起動や動作をすることを確認しました。

次にいよいよ実験の GRUB のインストールとなります。

puppy のメニューから「スタート」＞「システム」＞「Grub - ブートローダの設定」を選択します。

「simple」と「expert」の二種類のいずれかを選択することとなりますが、ここでは「simple」を選択します。（下図参照）

次にフレームバッファの設定画面となりますが、通常のテキストの「standard」を選択します。

次にGRUBをおくパーテーションの設定ですが、今回の例では「sda11」に puppy をインストールするので「/dev/sda11」とします。ここでこのまま進むと GRUB のインストーラーが停止してしまいます。事前に sda11 の中に /boot のディレクトリを作成しておけば、インストーラーは次の画面に進むことができます。（下図参照）

次はGRUBの本体を置く場所の設定となります。通常のインストールではハードディスクの先端部分の MBR に置くことが定石となっています。この puppy の GRUB のインストーラーではなぜか「多分危険」と表示されています。今回はこの MBR にはインストールせず、puppy をインストールした領域のスーパーブロックの部分へとインストールをします。実のところ、私は散々 linux などのインストールを行ってきましたが、すべて MBR ばかりだったので、これが初めての経験となりました。（下図参照）

GRUB のインストールが終了すると、下記のような表示が出ます。

早速、sda11 の中の /boot/grub のディレクトリを確認すると、GRUB の各種のファイルがインストールされていました。そして menu.lst を開いて内容を確認してみました。なんと frugal インストールしたのですが、full install したときの設定のブートコードとなっていました。それも現在あるすべての領域からブートが可能なような？コードとなっています。そこで frugal install に適合したブートコードを先頭部分に挿入することとしました。下図のグレーに選択された部分が挿入されたブートコードです。

これが実際に挿入したブートコードです。これは frugal install したときに参考で puppy 自身が作ってくれるものです。

title Puppy Linux 420 frugal
rootnoverify (hd0,10)
kernel /puppy420/vmlinuz pmedia=atahd psubdir=puppy420 nosmp
initrd /puppy420/initrd.gz


これで puppy 側の設定は終了しました。ubuntu 側の GRUB の変更をします。

sda10 の中の /boot/grub/menu.lst に以下の内容のブートコードを末尾に追加しました。chainloader を使って puppy の GRUB を起動させようとするものです。

title Puppy chainloader
root (hd0,10)
chainloader +1

ubuntu の GRUB の設定変更が終わったところで、パソコンを再起動させてみます。

最初に ubuntu の GRUB のメニューが表示されます。最下段に今回追加した chainloader によるブートコードが表示されます。これを選択して puppy の GRUB を起動させます。

引き続き puppy の GRUB が起動され、 puppy の GRUB のメニューが表示されました。この中の一番上の Puppy Linux 420 frugal を選択して puppy を起動させます。

これで puppy が起動することができました。
今後 debian の GRUB から ubuntu の GRUBと puppy の GRUB を呼び出す変更をしたいと思っています。

それぞれのGRUBによるマルチブート化の実験

私はメインのディストリビューションに debian を選択しています。もう長い付き合いなので、今後も debian をメインにおいて使用してゆくつもりです。

しかし数多くの中のディストリビューションの栄枯盛衰も激しいもので、昨今では ubuntu の成長が著しく、パソコンなどにプリインストールされることも多いものです。このように数多くのディストリビューションを無視することも出来ないので、いろいろなディストリビューションをライブCDや実際にインストールして状況を確認しています。

使わなくなった古いパソコンのハードディスクに実際にインストールして確かめることが多かったのですが、さすがに ubuntu などの本格的なディストリビューションでは動作が鈍くなって本来の性能を確認出来ないことも多くなっています。そこでやむなくCPUの速いパソコンにインストールするのですが、マルチブートなどでいろいろと苦労しているのが現状です。

debian がインストールされたパソコンに空き領域を設けて ubuntu 9.04 をインストールをした場合、標準的なインストールでは ubuntu の GRUB がインストールされて、ubuntu が管理する menu.lst を参照するようになります。（下図参照）　ubuntu のmenu.lst には debian を起動させるコードも自動的に付加してくれるのですが、今後 debian のアップデートやアップグレードで必要なカーネルが立ち上がらなくなってしまう可能性もあります。

現状の ubuntu の GRUB の状況です。

元々は実験的にインストールした ubuntu なので ubuntu の領域を消去して、再度何らかの方法(※1)で debian の GRUB を復活させる予定だったのですが、ubuntu の調子もよく、このまま残しておきたい気持ちとなってきました。
※1：GRUB のインストールコマンドでubuntu のインストールされている領域にある menu.lst から debian がインストールされている領域にある menu.lst に変更するだけなのですが。

そこで本格的に両方のディストリビューションを使うために、GRUB の設定の見直しをすることとしました。

今までは ubuntu の GRUB が起動して、この ubuntu の GRUB から debian のカーネルを直接呼び出す方法となっていたものを、debian の GRUB を最初に起動させ、ubuntu が必要な場合には debian の GRUB から ubuntu の GRUB を呼び出した上で最終的に ubuntu の各カーネルを起動させる方法にしたいと思っています。二段階に GRUB を起動させて、最終的に OS を起動させる方法です。

最初に debian の GURB を起動させるのは、やはりメインとして使用したいのは debian だからです。

いきなり GRUB まわりの設定を変更して取り返しのつかないことになっても嫌なので、さらにpuppy linux をインストールして、実験的に ubuntu の GRUB から puppy の GRUB を呼び出す実験をすることとしました。実験は成功しましたので、新しい項目でその設定の様子を説明いたします。

ThinkPad X20 の壁紙を変更しました

先日Puppy Linux 4.20 をインストールした ThinkPad X20 の壁紙を変更してみました。

画像のように IBM のパソコンに入っている世界地図のものを設定しました。これでいかにも ThinkPad を使っているという雰囲気が溢れてきました。

私個人としては、青色系統のクールな壁紙が基本的に好みです。

Flash の透過化のトラブル

Puppy Linux だけの問題かと思っていた Flash の透過（透明）化のトラブルは他のディストリビューションでも発生していました。

それは OpenSUSE 11.1 Release でした。確認したブラウザは Firefox 3.0.4 ですが、やはり Flash の透過部分を真っ黒に塗りつぶしていました。

原因の切り分けをしようと思っていたのですが、だんだんと深みにはまってゆく感じがします。

こうしてみると、今まで何の認識もなく使っていた debian や ubuntu は結構優秀であったことがよくわかります。

平成21年消費者向け電子商取引実態調査

このブログの趣旨から少し外れますが、ちょっとおもしろいネタを

経済産業省が毎年行う商業統計調査などの一環だと思われますが、今年は「平成21年消費者向け電子商取引実態調査」というものが届きました。今年から調査の外部委託が出来るようになったということで企業情報を取り扱う帝国データバンクが業務委託を行っていました。そのため調査票の返送先は帝国データバンクとなっていました。

私が行っている事業の柱は正しく電子商取引によっていますので、ぴったりの調査のようにも感じました。



これは調査票の１ページ目です。企業名や住所などはあらかじめ印刷済みとなっていました。資本金や従業員数などの基本情報を入力するようになっていました。

そして赤字で「報告された調査票は統計作成の目的以外には使用されません。また調査の事務に従事する者が調査の内容を他に漏らすことは法律により固く禁じられております。」とも書いてありました。
ここで気になるのは「他に漏らす」という部分で、帝国データバンクから外部ではなく、内部同士で情報が流れて行かないものなのだろうか？ということでした。帝国データバンクとしては、経費をかけずに企業情報を集められる立場にあることがとても気になりました。「他に漏らす」が帝国データバンクの内部であっても、この調査業務以外に流用されないことを信じるしかないようです。



肝心の調査ですが、やはり通信販売などを念頭に置いた調査のようで、この部分には細かく調査項目が設定されていました。私の会社が扱うデジタルコンテンツの販売については最終の3番めの項目で小さい取扱いの調査でした。デジタルコンテンツはまだまだ市場規模が小さいのか、こんな扱いとなっているようです。画像の中のオレンジの部分です。零細企業の多くは「その他」の項目にほとんどまとまってしまう感じでした。私個人としては、この部分こそ将来日本が世界に売り込める部分だと思うだけに、もうちょっと掘り進んだ調査をして欲しいところでした。

firefox 2.0.0.7をインストールしてトラブル

Flashplayer のトラブル対策のために一時的にインストールした Firefox ですが、その後 SeaMonkey でユニクロのサイトを閲覧すると ssl 通信で問題発生と表示が出るようになりました。

もともと兄弟関係の Firefox と SeaMonkey を同居させたことが問題のようで、一部のファイルを共通して使用するようです。そのため問題が発生した模様です。

とりあえず Firefox をアンインストールしてみましたが、同じ問題が発生し続けるようです。そこで SeaMonkey を起動させていない状態（停止状態）で設定データの入っている /root/.mozilla を丸ごと消去しました。再度 SeaMonkey を立ち上げると、自動的に .mozilla のディレクトリは再作成されて、正常に閲覧が出来るようになりました。なお注意として、この .mozilla のディレクトリを消去するとブックマークや各種の設定がすべて消えてしまいます。覚悟をして消去してください。

SeaMonkey と Firefox を同居させるときには注意が必要のようです。

Puppy Linux flashplayerのトラブル

Puppy Linux において、衣料品のユニクロのサイトで各商品の詳細な説明がなされているページで flashplayer のトラブルが発生します。バージョン4以降の各バージョンで確認をすることができました。

内容は、商品を表示してある部分へ flash が被せてある形となっていて、通常は商品が見えるように透明になるところが、黒色に塗りつぶされてしまって表示出来ないというものです。上記の画像の通りです。
なお Windows や debian , ubuntu などで firefox を使って閲覧すると正常に表示が出来るものなので、ユニクロのサイトの問題ではないようです。

また flashplayer が表示させる画面はちゃんと表示をするようです。このことから、透明化するところを黒色に塗りつぶしていることが今回の問題となります。下の画像は flash の画像を表示させているところです。


とりあえず問題の切り分けのために、flashplayer を削除して様子を観察してみました。
問題の flashplayer は /root/.usr/lib/mozilla/plugins/libflashplayer.so です。この libflashplayer.so を /root のディレクトリへ一時移動させて、plugins のディレクトリからなくしました。そして seamonkey を立ち上げてみました。


ご覧のようにちゃんと商品の画像が表示されました。もちろん flash の部分がなくなったため、画像の切り替えのアイコンなどは表示されなくなりました。

ここで pet化されているブラウザを調べて見ると、公式 pet に firefox 2.0.0.7 がありました。そこでこの firefox をインストールして様子を観察してみます。インストールの前に flashplayer のプラグインを元のディレクトリに戻しての挑戦となります。


ご覧のように firefox でも同じ現象が発生していました。単純に seamonkey 固有の問題ではないようです。

それから flash 上でマウスを右クリックして表示される flashplayer のメニューで、「設定」を選択するとフリーズしてしまいます。やはり何か問題があるようです。なお現在調査しているPuppy Linux 4.30 beta では、flashplayer バージョンは　10.0 r32 と現時点で最新のものとなっています。

今日はここまで調査した時点で終了しました。後日、継続調査をしたいと思っています。

Puppy Linux seamonkey でカーソル飛びの対策

Puppy Linux の seamonkey でカーソルが飛んでしまうことの原因が判りました。seamonkeyの機能でした。

対策方法はメニューの「編集」＞「設定」を開いて。「詳細」の中の「キーボード　ナビゲーション」で設定します。
この中の「タイプ検索(Find As You Type)」の「打った文字と同じ部分を自動的に探す機能」のチェックボックスからチェックを外します。これで対策終了です。

このオプションをオンにしておくと、例えば「カーソル」と文字入力すると、「アカウント情報」の「カ」の文字にカーソルが飛んでいました。このような機能を必要とする人は世の中には存在していると思いますが、一般的には必要ないのではないかと思いました。デフォルトでオフにしてもらって欲しい機能でした。

Puppy Linux 4.30 beta にはいろいろ問題があるようで

ブログを更新するときに上手く文字入力ができないことに気づいたのですが、その後ワープロソフトのabiwordで文字入力を試してみました。

ワープロ上ではカーソルが飛んでしまうこともなく、日本語の入力ができました。しかしAnthyを止めて英数字を入力しようとすると、キーマップが変な感じで変わってしまうようで、"abcde"と入力しても違う文字が表示される状況でした。

一見正常に動作しているように見えるPuppy Linux 4.30 beta ですが、まだまだ問題は山積みのようでした。