2009年12月1日火曜日

print/cups-base の更新がうまくいかない…

portupgrade -a をちょっとやってみたのですが、 print/cups-base のアップグレード (cups-base-1.3.9_3 から 1.4.2 へ)に失敗してしまいました。


cc -L../cgi-bin -L../cups -L../filter -L../ppdc -L../scheduler -L/usr/local/lib/ -L/usr/local/lib -Wl,-R/usr/local/lib -pie -fPIE -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -o cupsd auth.o banners.o cert.o classes.o client.o conf.o dirsvc.o env.o main.o ipp.o listen.o job.o log.o network.o policy.o printers.o process.o quotas.o removefile.o select.o server.o statbuf.o subscriptions.o sysman.o -L. -lcupsmime \
-lz -L/usr/local/lib -lgnutls -lldap -lpam \
-lpaper -L/usr/local/lib -ldbus-1 -lcups -L/usr/local/lib -lgnutls -pthread -lm -lcrypt \

client.o(.text+0x233a): In function `encrypt_client':
/usr/ports/print/cups-base/work/cups-1.4.2/scheduler/client.c:3217: undefined reference to `_httpReadGNUTLS'
client.o(.text+0x234e):/usr/ports/print/cups-base/work/cups-1.4.2/scheduler/client.c:3218: undefined reference to `_httpWriteGNUTLS'
gmake[1]: *** [cupsd] エラー 1
gmake[1]: ディレクトリ `/usr/ports/print/cups-base/work/cups-1.4.2/scheduler' から出ます
gmake: *** [all] エラー 1
*** Error code 1

Stop in /usr/ports/print/cups-base.
*** Error code 1

Stop in /usr/ports/print/cups-base.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade20091130-71145-r2vh1l-0 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=cups-base-1.3.9_3 UPGRADE_PORT_VER=1.3.9_3 make
** Fix the problem and try again.
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! print/cups-base (cups-base-1.3.9_3) (linker error)


他にも同様の問題が報告されていたり、既にsend-prされている(ports/141014)みたいなので、しばらく動向を見守るなり、対策が思いつく方はcommitしてみて下さい。どうもDBUSへの対応を切るといいみたいなんですが、それはgnomeで使うときに問題にならないんだろうか……?

で、終わっとく予定だったんですが、ついかっとなって調べた。正直おなかが空いている。

引っかかっている原因は、どうも
/usr/ports/print/cups-base/work/cups-1.4.2/cups/http.c
のコンパイルが行われていないせいなのではないか? という気がします。

というのは、上記ソースに _httpReadGNUTLS() が含まれているのですが、
/usr/ports/print/cups-base/ で make して止まったとき、
/usr/ports/print/cups-base/work/cups-1.4.2/cups/lib*
には _httpReadGNUTLS() が含まれていないのです。だからリンク時エラーが出てるんですね。

で、script を使って make 時のログを見てみたんですが、どうも http.c がコンパイルされていないようなんです。(何故?)

エラーで止まった状態で
/usr/ports/print/cups-base/work/cups-1.4.2/cups
まで下がり、 make testhttp を実行した後だと、
# grep _httpReadGNUTLS lib*
Binary file libcups.a matches
で無事 _httpReadGNUTLS() が含まれるようになります。このときのログにはちゃんと、

echo Compiling http.c...
Compiling http.c...
cc -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/
usr/local/include/avahi-compat-libdns_sd/ -I/usr/local/include -I/usr/local/incl
ude/avahi-compat-libdns_sd/ -O2 -fno-strict-aliasing -pipe -DLDAP_DEPRECATED -I
/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -DDBUS_API_S
UBJECT_TO_CHANGE -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_THREAD_SAFE -D_REENTRANT -c http.c
echo Compiling http-addr.c...
Compiling http-addr.c...
cc -Wall -Wno-format-y2k -fPIC -Os -g -fstack-protector -I.. -D_CUPS_SOURCE -I/
usr/local/include/avahi-compat-libdns_sd/ -I/usr/local/include -I/usr/local/incl
ude/avahi-compat-libdns_sd/ -O2 -fno-strict-aliasing -pipe -DLDAP_DEPRECATED -I
/usr/local/include/dbus-1.0 -I/usr/local/include/dbus-1.0/include -DDBUS_API_S
UBJECT_TO_CHANGE -I/usr/local/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_THREAD_SAFE -D_REENTRANT -c http-addr.c

といったようなログが残っています。ところが、ports で make したときにはこれが無い。

多分Makefileの違いなのだろうと思うんですが……なんでだろう?

追記:とりあえず解決? Makefileのほうで置き換えをしていたようです。こんな感じになおすとmakeが通るようになりました。


# diff -u print/cups-base/Makefile.orig print/cups-base/Makefile
--- print/cups-base/Makefile.orig 2009-12-01 22:53:29.000000000 +0900
+++ print/cups-base/Makefile 2009-12-01 22:56:09.000000000 +0900
@@ -261,7 +261,7 @@
${WRKSRC}/Makefile
.else
@${REINPLACE_CMD} \
- -e 's|cups filter backend|backend|' \
+ -e 's|cups filter backend|cups backend|' \
-e 's|$$.INSTALL_SCRIPT. cups-config|echo skip: cups-config|' \
-e 's|/usr/share|${PREFIX}/share|g' \
-e 's|installhdrs$$||' \


本家にも報告しておいたけど、合ってるのかな……?

2009年10月9日金曜日

page fault while in kernel mode ??


ハードディスクの全セクタ検査をやっている間、VMware Workstation で実験環境を作ってみたのですが、gmirrorしたディスクの上でzfsを動かすと、何故かリブートの度に gm0 のrebuildが走ってしまい、起動時にzfsプロセスがpage fault を起こす、という、GEOMなのかzfsなのかVMware Workstationなのか原因がはっきりしないトラブルに見舞われました。とりあえず記録。あやしいことをやっていることは確かなのです(^^;

環境:VMware Workstation 6.5.3 build-185404
ホストOS: Microsoft Windows Server 'Longhorn' Business 6.0.6002, Service Pack 2 (32bit)
ゲストOS: FreeBSD/amd64 8.0-RC1 (64bit)

やったこと:
仮想メモリ1536MBの仮想PCを作成。それに30GBの仮想ドライブを2台(da0, da1)作成し接続。
うち1台(da0)にFreeBSD/amd64 を "User" インストールする。
ただし、OSのインストールには10GB程度しか使わず、残り20GBは空けておく。
OSインストール終了後、FreeBSD ハンドブックを参考にしてgmirrorでミラーリングする。
(zfsを使うよう /boot/loader.conf や /etc/rc.conf を書き換えておく。)
ミラーリング出来たら、空き容量のある mirror/gm0s1 に見えるので、
# gpart add -b xxxxx -s xxxxxx -t freebsd-zfs
で空いてる部分を mirror/gm0s1g として作成する。
この mirror/gm0s1g を使って、zfsの領域を作成、適宜マウントする。
# zpool create tank mirror/gm0s1g
# zfs create tank/home
# zfs create tank/export
# zfs create tank/ulocal
# mkdir /home /export
# zfs set mountpoint=/home tank/home
# zfs set mountpoint=/export tank/export
# zfs set mountpoint=/usr/local tank/ulocal
# zfs set mountpoint=none tank

このあたりはいろいろなサイトに載っている普通の手順かと思います。
が、どういう訳かここで再起動すると、上記スクリーンショットのようなFatal errorが起きます。原因はよく分かりません。さて、実機でも同様なことが起こるのでしょうか……?

2009年10月8日木曜日

結局HDD障害だったようです。

先日からatacontrolでRAID1が構築出来なかった件ですが、その後 gmirror に乗り換えてみたところ……


ad16: FAILURE - READ_DMA status=51 error=40 LBA=93492224
GEOM_MIRROR: Request failed (error=5). ad16[READ(offset=47868018688, length=131072)]
GEOM_MIRROR: Synchronization request failed (error=5). mirror/gm0[READ(offset=47868018688, length=131072)]

というわけで、どうやらHDD障害だったようです。

カーネルパニックを起こしたatacontrolと違い、こんなエラーがあってもmirrorを続けるgmirrorはすごいですね。しかしこれでは使えない。エラーがあると思われる領域は /usr にあり、/usr/src を展開しようとしたら、その作業が止まってしまいました。

ディスクがエラーで使えないと分かったら即座にOfflineにするatacontrolの振る舞いも理解出来るんですが、まさかその使えないディスクを元にして懸命にrebuildしてたとは思わなかったようです。

mhddでチェックしたところ、当該部分はUNCとしてXがついてました。ただ、mhddがError:として返してきた位置は 93492434 なんですが、atacontrolのときやgmirrorのときに返された値とは若干ずれてます。やはりHDDとしてダメだったというこなのでしょう。ディスク障害に備えて新品のHDDで環境を構築しようとしたら、その前段階でコケるとは。

ところでmhddのフルスキャン、1TBのディスクをチェックするのに3時間弱かかります。で、とりあえずチェックしないといけないHDDは3本。これは……また帰りが遅くなりそうです。