TOP
Ĥ뤿ˤΥڡ
■ 帰京。数年前までは実家でそれなりに休めたが、甥や姪ができてからは、気が抜けない。結構疲れた。今日だけは誰もおらずお休み。
■ 仕事から帰ったら、喉が痛い。風邪引いたかも。そろそろ気が緩んできたか。
mail/p5-Mail-SpamAssassinを更新。途中でsa-updateも実行。その後、変更された設定ファイルなどをcvsで管理するために、
cvs -n updateで調べると、
cvs update: Updating mail/spamassassinと出る。
? mail/spamassassin/sa-update-keys
(以下略)
このディレクトリは以前から存在したはず。ただ、中のファイルは管理の必要がないので、そのディレクトリ中で.cvsignoreファイルを設定することで無視させていた。それなのに、今度は親ディレクトリが「不明」なファイルになっている。
どうも、mail/p5-Mail-SpamAssassinの更新の際、"sa-update-keys"のディレクトリごと削除されるらしい(中には既にCVSディレクトリが作成されていたはずだが、これも含めて親ディレクトリごと削除)。その結果、cvsから見たら管理ディレクトリの無い不明なディレクトリが存在する、ということのようである。mail/p5-Mail-SpamAssassinの更新のたびにこんなことが起こってはたまらない。
そこで、mail/spamassassinで.cvsignoreにこのディレクトリを追加して、ディレクトリごと無視させようとした。.cvsignoreを作成し、cvs commitすると、
% cvs add .cvsignoreだとか。
cvs add: scheduling file `.cvsignore' for addition
cvs add: use 'cvs commit' to add this file permanently
% cvs commit
cvs commit: Examining .
cvs commit: Examining sa-update-keys
cvs commit: in directory sa-update-keys:
cvs [commit aborted]: there is no version here; do 'cvs checkout' first
で、CVS/Entriesを見ると、
D/sa-update-keys////が残っていた。このディレクトリが管理対象であることになったままなので、.cvsignoreの設定に関係なく管理しようとして、以下にCVSディレクトリが無い、というエラーとなるらしい。この行を消して、無事解決。
そもそもcvsで管理するディレクトリを実際の設定ファイルが存在するディレクトリにするべきでないことは重々承知しているのだが...めんどくさいので。
年末に白菜を漬けた。ちょっと塩が足りなかったみたいで、帰省から戻ってきても、あまり水が上がっていない。3%では少ないのかも。
で、漬物容器に入らなかった一部はステンレスのボウルに入れて漬けていたのだが、漬け直してボウルをあけてみると、見慣れない変色が...洗ってもとれない。触るとちょっと凹凸がある。そういえば、以前も鍋で煮物を放っておいたときに同じような状態になった。
金属を腐蝕するような細菌が身近に居るのか？と、ちょっと驚く。
2011.12.25に書いた問題は自分だけではないらしい。依然としてうまく動かないまま。
で、javascriptのデバッグを有効にすると、エラーでまくり。200以上のエラーがでる。どうしようもない。
stunnelをサービスに登録し、メール送信に使っているが、ちょっとトラブル。
まず、実行中のサービスを、タスクトレイから停止。で、v4.44を、v4.51をインストーラでインストール。その後、サービスのパネルから実行したのだが...タイムアウト、だとかで実行できない。どうも、Norton AntiVirusが、stunnel.exeが疑わしい挙動を行っているとして、削除してしまうらしい。こうなったら再起動するしかないが、それでも何度も削除される。「疑わしい動きをしている」と、「ほとんど使われていない」が原因らしい。
仕方ないので、これを検索対象から除外するしかない。サービスからも削除されたので、再度インストール。"stunnel -service -install c:\path\to\stunnel.conf"でサービスの登録。
しかし、これを実行すると、設定ファイルがきちんと読み込まれない。stunnelのウィンドウが開き、設定ファイルのエラーはない、と表示されるのだが、現実にはなぜかエラーになっている。"Cannot read configuration"だとか。直前には設定ファイルをきちんと読んでいるようなのに、なぜなのか。
そこで、コマンドラインから(サービスではなく)実行してみると、まず、"service=stunnel"という行が気に入らない、ということだったので、削除。その後はきちんと起動する。しかし、サービスから起動すると、うまくいかない。サービスとは何かオプションが違うのか？
昨日の問題は、単に引数の誤りだった、ということらしい。2009.4.11に書いたのには誤りがあり、最後の設定ファイルのパスは" "で括ってはならない。これが無ければ、きちんと動作する。ということは、空白を含むパスは指定できないことになる。実際、うまくいかなかった(エスケープなどは無理らしい)。エスケープなど一切無しだと何とかなるのかもしれない。
では、なぜうまくいかないのか？空白を含まないパスを指定し、" "があるときとないときで、stunnelの表示するメッセージを比べると、設定ファイルのパスが" "で括られるかどうかに反映されている。つまり、引数の" "を含め、stunnelにわたっているということ(それでいいのか...?)。で、stunnel側でCreateFile()を実行して、エラーになっているらしい。この前にパス名をUnicodeに変換しているようだが、これが関係あるのかどうだか。ちなみに、FreeBSDで同じように" "を付けて設定ファイルを指定しても、きちんと起動した。この場合は、stunnelのメッセージにも" "は現れない。普通はOSが消してくれると思うので、これが普通だと思うのだが...なぜかWindowsでは駄目らしい。以前からこうだった？
なお、なぜかコマンドプロンプトからサービスとして実行しようとすると、「StartServiceCtrlDispatcher: error 1063: サービス プロセスをサービス コントローラに接続できませんでした。」というエラーがでる。原因不明。
SHARPのLC-24K5というテレビには、USB HDDを追加して録画が出来る(チューナーはテレビとの排他利用)。3ヶ月ほど前に(HDDがタイの洪水で値上がりする直前に)買ったHDDとUSB用ケースは、実質的にほとんど使っていないので、転用することに。
で、その前に、ちょっとお遊び。このHDDはどのようになっているのか？USBでFreeBSDのPCに繋ぎ、様子を見る。接続時はこんな感じ：
Jan 13 14:04:09 h120 kernel: ugen1.2: <ASMedia> at usbus1
Jan 13 14:04:09 h120 kernel: umass0: <ASMedia AS2105, class 0/0, rev 2.10/1.00, addr 2> on usbus1
Jan 13 14:04:10 h120 kernel: da0 at umass-sim0 bus 0 scbus4 target 0 lun 0
Jan 13 14:04:10 h120 kernel: da0: <WDC WD15 EARX-00PASB0 51.0> Fixed Direct Access SCSI-0 device
Jan 13 14:04:10 h120 kernel: da0: 40.000MB/s transfers
Jan 13 14:04:10 h120 kernel: da0: 1430799MB (2930277168 512 byte sectors: 255H 63S/T 182401C)
sysutils/testdiskのtestdiskコマンドで確認すると、
% testdisk /list /dev/da0となり、どうもファイルシステムはxfsらしい。
TestDisk 6.12, Data Recovery Utility, May 2011
(略)
Disk /dev/da0 - 1500 GB / 1397 GiB - CHS 182401 255 63, sector size=512
Disk /dev/da0 - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition Start End Size in sectors
1 P MS Data 2048 2930276351 2930274304 [primary]
% testdisk /list /dev/da0p1
TestDisk 6.12, Data Recovery Utility, May 2011
(略)
Disk /dev/da0p1 - 1500 GB / 1397 GiB - CHS 182401 255 63, sector size=512
Disk /dev/da0p1 - 1500 GB / 1397 GiB - CHS 182401 255 63
Partition Start End Size in sectors
P XFS 4 0 0 1 182401 35 34 2930274304
そこで、カーネルモジュールxfs.koを読み込んでマウントすると、
% kldload /boot/kernel/xfs.koとなった。
% mount -t xfs -o ro /dev/da0p1 /mnt
% ls -la
total 12721862
drwxr-xr-x 2 root wheel 114 12月 7 14:34 .
drwxr-xr-x 30 root wheel 1024 1月 6 09:54 ..
-rw-r--r-- 1 root wheel 4 1月 12 12:05 .AquosMediaInfo
-rw------- 1 root wheel 13024755712 10月 19 01:41 20111018185956001.tts
-rw-r--r-- 1 root wheel 1206272 1月 12 13:28 AquosDB.edb
-rw------- 1 root wheel 1206272 1月 12 13:32 AquosDB.edb.bkup
---------- 1 root wheel 4096 10月 18 17:03 aquos.conf
録画済番組は1つだけなので、一番大きなファイルがそうなのだろう。これらのファイルのうち、fileコマンドでファイルタイプがきちんと分かったものはなかった。一番小さいファイルは、0x00000001とだけ書かれていた。
フォーマットは難しいが、xfsをきちんと扱えるOSがあれば、ファイルシステムのパーティショニングなどが出来るのか。また、上記のファイルをうまくコピーすれば、別のxfsなディスクもそのまま認識できるのか。これらはよくわからない。
ところで、デバイス名の/dev/da0p1ってどういう意味？/dev/da0s1などの表記は見慣れているが、pってのはなんなのだろうか。GPTのコト？
[追記]なお、このパーティションをumountしたら、カーネルがパニックした...これはFreeBSDのxfsサポートの未熟のせいだろう、きっと。
Windows7とFreeBSDをインストールしたPCのHDDの様子がおかしい。このHDDはFreeBSDからはデータ置き場としてしか使っておらず、とくに問題なく使用できているが、SMARTのエラーがでている。とくに、pending sectorが1000近くに増えてしまった。それに関連して、Win7が起動しなくなった。ブート途中で電源が落ちてしまう。Win7のDVDで起動しても同じ。Win7のシステムが入っているので、仕方ないか。
そこで、元のHDD(1TB)を、テレビに繋いで録画用に使っていた(1.5TB)に変えることに。PCのHDDを入れ替え、まずWin7のインストーラで既存のパーティションを削除、パーティション作成、インストール。今回はブートパーティションの作成を甘受したので、この時点で2つのパーティションが出来ているはず。次いで、FreeBSDを起動し、パーティションを作成しようと、fdiskコマンドでパーティションを確認し、同じコマンドで作成した。ここまでは問題ない。ところが、デバイスファイルが出来ない。そのため、作成したパーティションにbsdlabelを作成しようとした時点で、エラーになった。sysinstallでパーティションを切りなおそうとするが、こちらではパーティションの存在が認識されず、全て未使用領域となってしまう。OSにはパーティションの存在が認識されていないのか(だからデバイスファイルが出来ない)。fdiskの認識と矛盾している。
仕方ないので、"gpart show"でディスクの情報を拾うと、GPTなディスクとなっている。そしてパーティションは存在しないことになっている。これで困るわけではないはずだが、なぜかFreeBSDから認識できないので、やっぱり困る。MBRの部分にはきちんと情報が書き込まれない、ということか(たしかGPTでは単一パーティションであるかのように書き込まれる仕様だったような...)。一方、FreeBSDでは、GPTでもMBR部分に各パーティションの情報を書き込むことになっていたように思う。この相違が原因なのだろう。
仕方ないので、FreeBSDで一からパーティションを作成しなおし、Win7を再インストールする羽目に。MBRだけ書き換えても良かったのだが...
昨日の問題で、FreeBSDでパーティションを作成しても、やっぱり駄目だった。症状は全く同じ。"gpart show ada1"はMBRではなくGPTだと表示する。しかも、fdiskコマンドはMBRの情報を反映しているが、GPTパーティションだと認識された時点でこの情報自体がOSに使われていないらしい。OSの認識と、その提供するツールの返す情報が異なるのは、非常に不可解。
最初は、fdiskコマンドでMBRを書き換えてみたが、無駄。
仕方ないので、Win7のインストーラで、diskpartコマンドから完全にディスク情報を消してみた。
diskpartただしディスク番号は慎重に確認しなければ怖い。
select disk 0
clean
これで完全に消えたらしく、あとはWindowsのインストーラでパーティションを作成しても、MBRパーティションになった。ということで、無事に使用可能。
なお、そもそもGPTが残ったのは、最初に利用したSHARPのテレビがGPTでパーティションを切ったらしい。この情報が「どこか」に残っていたのだろう(どこか、ってどこだ？)。
調子の悪いHDDから、データを取り出す。
まず、USBのHDDケースに繋ぎ、FreeBSDで使っていた領域をマウントして、paxコマンドで安全なHDDにコピー。最初は順調だったが、途中からエラーが。
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11654086656, length=114688)]error = 5などと、延々と出る。
Jan 14 22:41:45 h116 kernel: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 11 5b 51 90 0 0 40 0
Jan 14 22:41:45 h116 kernel: (da0:umass-sim0:0:0:0): CAM status: SCSI Status Error
Jan 14 22:41:45 h116 kernel: (da0:umass-sim0:0:0:0): SCSI status: Check Condition
Jan 14 22:41:45 h116 kernel: (da0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present)
Jan 14 22:41:45 h116 kernel: (da0:umass-sim0:0:0:0): Invalidating pack
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11654119424, length=81920)]error = 5
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11654594560, length=131072)]error = 5
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11654086656, length=32768)]error = 6
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11653431296, length=65536)]error = 6
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11653496832, length=49152)]error = 6
Jan 14 22:41:45 h116 kernel: g_vfs_done():da0s2d[READ(offset=11748360192, length=65536)]error = 6
こうなると、稀にpaxコマンドが
pax: File log-20110324a4.gz changed size during copy to /path/to/log-20110324a4.gzのようなメッセージを出して終了してしまうことがあり、なぜか元のディレクトリ以下のファイルが一切見えなくなった...なんとも恐ろしい。ただし、アンマウントして再度マウントしなおすと、なぜかきちんとファイルが存在する。また、同じディレクトリについて同じコマンドを実行しても、エラーにならないこともあり、本当にエラーなのかが疑わしくなってきた。
ということで、今度はSATAで繋いで同じ事を行ってみた。ところが、やはり
Jan 15 14:48:16 h116 kernel: ad2: FAILURE - READ_DMA48 status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=1799597776と、先と同じくg_vfs_done()のエラーが続く...うーん、これは本当にまずい。今回は、paxコマンドを何度繰り返しても、cpでコピーしようとしても、同じファイルでエラーが出た。
Jan 15 14:48:16 h116 kernel: g_vfs_done():ad2s4d[READ(offset=240641736704, length=131072)]error = 5
Jan 15 14:48:41 h116 kernel: ad2: FAILURE - READ_DMA48 status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=1800356944
Jan 15 14:48:41 h116 kernel: g_vfs_done():ad2s4d[READ(offset=241030430720, length=131072)]error = 5
Jan 15 14:48:45 h116 kernel: ad2: FAILURE - READ_DMA48 status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=1800356976
Jan 15 14:48:45 h116 kernel: g_vfs_done():ad2s4d[READ(offset=241030447104, length=131072)]error = 5
Jan 15 14:48:49 h116 kernel: ad2: FAILURE - READ_DMA48 status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=1800356976
Jan 15 14:48:49 h116 kernel: g_vfs_done():ad2s4d[READ(offset=241030447104, length=65536)]error = 5
都合、20個くらいのファイルを諦める羽目に。計算結果なので、必要なら再計算すれば数日で同じものが得られるので、もうこれ以上は深追いしないことに。
先日、Windows 7の再インストールを行ったPCで、HDDの認識順が以前とは逆になっていることに気づいた。以前は、ディスク0がFreeBSDしかないHDD、ディスク1がFreeBSDのデータ用とWindows7本体の入ったパーティションがあるHDDだったのだが、再インストール後はなぜか逆になっている。BIOS設定の起動順はFreeBSDだけのディスクが先で、FreeBSDで実際にAHCIのディスクとして認識されるのもFreeBSDだけのほうがada0、Windows7との混在のほうがada1の順。
なんだか気持ち悪いが、BIOSとは関係ないだろうから、Windows7がどういう順で認識しているかを知らない以上、手が出せない。
なお、物理ディスクの順なんて関係ない、という気がするが、boot0を使っているためにWindowsからブートセクタを書き換えたくなるとき、これが効いてくる。
最近のMLで、pkg_libchkなるものを知った。sysutils/bsdadminscriptsでインストールされるらしい。
で、早速調べてみると、かなりのエラーが出る。原因不明。
なぜこれが気になったかというと、x11/xcb-utilが最近分割されたらしく、このために250個近いportsを再ビルドする必要が生じたため。単に分割されただけなら(依存性を正しく記録できないことを無視すれば)放っておけばいいのだが、本当にそれで良いのか気になる。そこで、これで調べてみたら、xcb-utilに関係ないのもたくさん見つかった。
なお、xcb-utilの分割は完全ではない気がする。既にPRされている問題もあるし、まだの問題もありそう。
■ どうやら朝から風邪の症状。喉が痛い。ひたすら安静。
■ 体調は回復せず。全身が痛いから、きっとインフルエンザだろう。一昨日の時点で病院に行っておけばよかった...その時点ならタミフル効いたかも知れないのに。仕事は休ませてもらう。採点の仕事だけを何とか済ませたが、宅急便は集荷を頼んだ。
■ 何とか動けるようになったので、午後からの授業を行う。うつったらごめんなさい。
■ ようやく、ほぼ回復といえるくらいに元気になった。
2011.8.26にも書いたように、x11-toolkits/gtk30がビルドできない。これは既にこのときにsend-prしてあり(PR ports/160224)、一向に解決しない。
どうも、GNU sedでは改行が出力されるらしく、おそらくGNU sedをインストール済みの環境でビルドしてもエラーにならないのだろう。勝手にsedのルールを曲げ、しかもそれを普通のsedでも使えるのが当たり前だと思っている(であろう)gtk関係者の設計思想が恐ろしい。
そうそう、GNU sedといえば、先日、FreeBSD-users-jpのMLで、japanese/ebnetdのインストールが出来ない、というのがあった。GNU sed(testproc/gsed)がインストールされていて、環境変数LANG等がja_JP.eucJPになっていると、インストール時に実行されるsedコマンドが「刺さって」しまうことがあるらしい。こちらでビルドした際に作成されたファイルに対しては、刺さることは無かったが、問題のファイルで実行すると、確かに動作しなくなった。ファイルの特定の場所を読み込んだ時点でおかしくなっているので、バグといえると思うのだが、よくわからない。ともかく、ロケールによってビルドできないのはおかしい(以前にもtrコマンド使用時の問題は修正された)ので、japanese/ebnetdの修正を行うべきかも。
lang/ruby18をWITH_ONIGURUMA=1つきでビルドしたい。
で、すでにdevel/onigurumaの作業ディレクトリが展開されていれば、問題はない。それが無ければ、展開するまでなのだが、既にdevel/oniguruma4がインストールされていれば、展開が出来ない。従来はdevel/oniguruma4はインストールしていなかったので問題なかったが、今はconverters/php5-mbstringがこれに依存しているらしく、インストールされてしまっている。
oniguruma4は必要、onigurumaは作業ディレクトリだけ必要なのだから、CONFLICTSでは無いはずなのに、CONFLICTS指定をすると、展開すら出来なくなってしまう。これはおかしい。CONFLICTSは本来、インストール時にチェックすれば十分だと思うのだが、そうはなっていないのはなぜか。
こういうときには、CONFLICTS_INSTALLを使うべきだと思うのだが。というより、他のportsもほとんどはこちらを使うべきで、インストール前のビルドの時点では問題ないことが多いはず(インストール済みのヘッダファイルやライブラリが問題となるケースを除く)。
ちょっと気になったので、cupsの設定を行ってみた。
まず、print/cupsをインストール。既にインストールされていたものとあわせ、cups-base, cups-client等がインストールされた。ここで
% /etc/rc.d/lpd stopで既存のlpdプリンタスプーラをストップ。
次いで、
% /usr/local/etc/rc.d/cupsd forcestartを実行。
設定を行うため、同じサーバでvncserverを起動して、ブラウザでhttp://localhost:631/にアクセスし、rootのユーザ名とパスワードを入力して、ログイン(ここは本当にシステムのrootのパスワードであることに驚く)。
あとは、トップメニューからプリンタの追加を行い、LAN上のEPSON LP-1900(N)を見つける。ドライバは見つからないので、http://openprinting.org/printer/Epson/Epson-LP-1900からPPDファイルをもらって、適当な場所に設置し、そのファイルを指定。後は解像度の設定などを行い、終了。
試しに、FreeBSD上に置いたPDFファイルをacroread9(最近更新済みだがバージョンは9.4.2と古い)で開き、プリント画面を出すと、きちんと追加したプリンタがリストされる。そのまま印刷すると、lprとしてlpdシステムのものが使われてエラーになるので、/usr/bin/lprの名前を別のものに変えておくと、無事に印刷された。日本語を含む少し複雑な文書だったが、問題はなかった。
あまり印刷の需要は無いのでこれ以上は追及しないが、使い勝手はいいのだろうか？