東芝DynaBook SS S5のHDD換装

これまた長く使いまくっている私用のS5でも、かなり前から、R100の時と同じく、内蔵のMK2003GAHのキュルキュル音が出始めていた。交換そのものはどうということはないが、HDD上のリカバリ領域をうまくコピーするのに多大な労力が想像できて、躊躇していた。ところがついにCRCエラーが出始め、MK8007GAHに換装することを決意。

以前から、ノートPCの壊れたハードディスクを交換する(上)と(下)（浅田知広の温泉放牧中）やiPodのHDDをDynaBook SS に換装する（紅玉日記(2004-07-29)）により、S5でリカバリ領域を残してHDDを換装する方法が存在することは認識していたが、このためだけにTrue ImageやNorton Ghostを買うのもなんだかもったいないし、GPartedでなんとかやってみることにした。用意したのは、新しいHDDのほかに、100GBのUSB外付けドライブ、USBの純正CD-ROMドライブ、前に焼いたGParted LiveCD 0.3.4-11。

GPartedで起動して元のHDDを確認したところ、

/dev/hda1  ntfs  16.63GiB  boot
/dev/hda3  fat32  1.99GiB  hidden, lba

となっていた。そこで、とりあえずUSBドライブの後半を作業用に半分ほど空け、いろいろ試行錯誤する。以下はその抜粋。

まず、hda3だけUSBドライブの空き領域にコピー&ペーストし、HDDを交換して、新しいHDDの末尾に再度コピー&ペーストしてみたが、0を押して電源を入れても _ が出たままうんともすんとも言わなかった。

次に、hda1とhda3をそれぞれUSBドライブにコピー&ペーストして、それぞれ新しいHDDに同じサイズのままコピー&ペーストしたところ、Windowsは起動するが、0を押して電源を入れても無視してWindowsが起動してしまった。

次に、USBドライブの後半をext2でフォーマットして/dev/sda2をマウントしておき、hda全体をddでコピーしておいて（CRCエラーがあるのでconv=noerrorが必要）、新しいHDDにddで戻したところ、hda3のフォーマットがUnknownになってしまい（いったいなぜ？）、起動したところWindowsは起動途中でブルースクリーン、0押しリカバリはOSがみつからない風のメッセージが出た。（最初、このコピーをbzip2で圧縮して作成したが、bzcatが死ぬほど遅くて、圧縮などせずにddしてしまう方がはるかに速いことがわかった）

そして、MBRとかのパーティション外部のデータが重要そうだと気付き、最後にたどりついたのが、

1. USBドライブにext2パーティションを作りマウントしておく。
2. hda全体とhda3をddしてコピーをUSBドライブに保存しておく。
3. 新しいHDDに交換し、hda全体をddで戻す。
4. /dev/hda3をfat32でフォーマットし直す（たぶん不要。未検証）。
5. hda3をddで戻す。
6. パーティションエディタでhda3をHDD末尾に移動させ、hda1を後ろにいっぱいまで広げる。
7. 0を押して電源を入れ、リカバリ。
   

という手順。もっと簡便な手順もあるかもしれないが、とりあえずうまくいったので、手間をかけて探すのはやめる。力尽きた。

リカバリせずに元の環境を移したいなら、新しい方のhda1を一旦削除してGPartedの機能でコピー&ペーストした後、広げればいいのではないかと思う（けど当然未確認）。

ezjailで遊ぶための自分用メモ

jailを使ってサーバ群を構成し直そうと、ezjailで遊んでみた。グリーンITも簡単（か）。

1. FreeBSD 7.0 を入れる。/etc/rc.confでインタフェースのalias（例えば192.168.0.3としておく）を登録。
2. ホスト側のプロセスがjailのアドレスでlistenしないようにする。
   
• sshdのListenAddressをいじってアドレスを限定する。
• syslogdに-bをつけてアドレスを限定する。
• ntpdはそのまま。jailのアドレスでListenしても問題ない（はず）。
  
3. sysutils/ezjail を入れる。ezjail_enableを設定。
   
4. /usr/local/etc/ezjail.conf で、ezjail_jaildir をjail群用のでかいディスクに割り当てる（例えばTOPとしておく）。
• ちょっとしたWEBサーバやメールサーバなら1個あたり何百MBで十分。
5. ezjail-admin update -p
   
• ソースツリーをビルドし直し、portsnap fetchしてjail用のportsツリーもportsnap updateしてくれる。
• -Pならportsツリーのみ。jailが走っていても実行できる。
• -iをつけるとbuildworldせずにinstallworldのみ。
• 実行後はportsツリーも含めてTOP/basejailにインストールされる。basejailはjail内のbasejailにnullfsマウントされて、リンクされる。
• TOP/newjailもbasejailへのリンク+αとして作成される。これをコピーしてちょっとフレーバーを加えてjailになる。
6. フレーバーを作成。
• TOP/flavours/defaultを適当な名前（例えばwebとしておく）でコピー。
• web/etc/{master.passwd, resolv.conf, localtime, newsyslog.conf, ssh/sshd_config, ...} とか、web/root/.ssh/authorized_keyを用意しておく。
• web/etc/rc.confやらweb/usr/local/etc/sudoersやらを必要ならいじっておく。
  
• web/pkg/を作成し、pkg_addしてほしいパッケージを入れておく。
• create時に走らせたいスクリプトがあればweb/ezjail.flavourをいじる。（デフォルトの処理内容はpkgがあればその中をインストールすることだけ）
  
7. ezjail-admin create -i -s 1g -c eli -f web -r hoge hoge.example.com 192.168.0.3
   
• TOP/hoge.example.comだと長すぎてdfが見づらいのでrootを短い名前で設定。
  
• しばらく待ってgeliのパスフレーズを入力。暗号化しないなら-i -s 1g -c eliとかいらない。
• ntpdが*：123で待ってると文句を言われるが、たぶん影響ないので無視。
8. jailが動いてないときにjailのイメージをいじりたいときは、ezjail-admin config -i attach hoge.examle.comでできるが、attachがへたくそでdetachできないバグがある。すぐ直せる。
9. /usr/local/etc/rc.d/ezjail.sh start hoge.example.com か startcrypto で、パスフレーズを入力するとjail開始。
10. sshが設定できてるならそのままsshするとか、jlsして目的のJIDにjexec JID /bin/shするとか、あとは好きなように。
    

• 電源が落ちたりして正常に終了できなかったときは、startcryptoする前に ezjail-admin config -i fsck hoge.example.com するべきかも。
  

ezjailは関係ないけど、当面気になるjailの制約まとめ:

• domainnameが設定できない。ただし、ホストのdomainnameを参照することはできるので、同一ドメインでならjailでNIS（rpcbind, ypbind）を使うことは可能。ypservは不明。hostnameはjailごとにあるのに、NISなんてレガシーな技術はあんまりサポートしないという方向性か。
• マウントができないのでNFSクライアントは無理。NFSサーバは試す気なし。
• BPFがない。でも、net/isc-dhcp3-serverはsocket（）あたりを使って動かせるっぽい。
• localhostにbindできないので、setgidなsendmailを叩いてlocalhostで待ってるMTA（msp）を経由してメールを出すことができない。外部の指定したMTAに直接つなぎに行くか、rootにsetuidする必要がある。/etc/mail/README参照。

ともかく、
Happy jail life!

FreeBSDでISOイメージを焼く自分用メモ

ひさびさにFreeBSDでISOイメージを焼こうとしてすっかり忘れていたのでメモ。使わないと、オプションどころかコマンド名まですべて忘れて、manさえできない。

ATAPIのCD-R/RWドライブ（/dev/acd0）で焼くにはburncdを使う。

% burncd -f /dev/acd0 -s max data file.iso fixate

速いドライブなら600MBでも3分ほどで終わる。


追記 (8/26)

手元のPCを7.0に上げたあと、CD-Rを読み書きしようとすると、

acd0: TIMEOUT - READ_BIG retrying (1 retry left)

のようなエラーが出て、実用的な時間で終わらなくなってしまった。

ハードウェアが悪いのか7.0が対応していないのかよくわからなかったが、/boot/loader.conf に hw.ata.atapi_dma="0" を追加。7.0をCD-ROMからインストールする場合も同じように刺さるので、起動時のオプションでLoader Promptを出して、

set hw.ata.atapi_dma=0
boot

とする必要がある。

XfceとThunarでちゃんとアイコンを出すにはlibrsvg2が必要

普段のPCではXfceがなかなか快適になったが、VMware Player用のFreeBSDでXfce4を入れて動かすと、アイコンが全然かっこよくならない。メニューの設定から、インタフェースを選んで、アイコンテーマをGnomeにするとデスクトップはたしかに変わるが、Thunarのメインのペインが変わらなかったり、挙動がよくわからない。

で、しかたがないので、xfdesktopのソースにデバッグプリントを入れてみると、xfdesktop_file_utils_get_file_icon（）でxfce_themed_icon_load（）が失敗してxfdesktop_file_utils_get_fallback_icon（）を呼び、/usr/local/share/pixmaps/xfdesktop/xfdesktop-fallback-icon.pngを表示している雰囲気。

そこから、
→gtk_icon_theme_load_icon()
→gtk_icon_info_load_icon()
→icon_info_ensure_scale_and_pixbuf()
→load_svg_at_size()
→gdk_pixbuf_loader_new_with_type()
→gdk_pixbuf_loader_load_module()
→_gdk_pixbuf_get_named_module()
→_gdk_pixbuf_load_module()
→_gdk_pixbuf_load_module_unlocked()
と大追跡を行って、最後に g_module_error() が "Cannot open "/usr/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so" と出力しているのをつきとめた（たぶんもっと上のレベルでエラーメッセージを探した方が早かったかも）。

このファイルは、graphics/librsvg2 によってインストールされるもので、gimp がこれに依存しているせいで、PCの方にはちゃんと入っていたようである。xfce4-desktopとthunarもこれに依存するようになってないといけなかったわけである。

というわけで、解決。


追記（2/21）

事態はそう単純ではなくて、本当の問題はもっと深いところにあった。

最初からxfceしか入れていないマシンを作ったところ、librsvg2なんか入っていなくてもちゃんとアイコンが表示された。そのマシンで追跡したところ、gtk_icon_info_load_icon（） にはSVGではなくPNGファイルが指定されて呼ばれている。では、そもそもなんで呼ぶ側の gtk_icon_theme_load_icon() がSVGを指定したりPNGを指定したりするかが問題で、これを追いかけていたら /usr/local/etc/gtk-2.0/gdk-pixbuf.loaders というファイルに行きあたった。これに image/svg を開くためのモジュール /usr/local/lib/gtk-2.0/2.10.0/loaders/svg_loader.so が登録されているかどうかを調べて、あればアイコンの拡張子を svg に決めるらしい。ではこのファイルは誰が用意するのかというと、gtk20をインストールするときにモジュールの有無を調べて、svg_loader.soがあればそれを登録するようになっているっぽい。

つまり、たまたまXfceとかThunarとかのアプリケーションがひっかかっただけで、gtk20とlibrsvg2の関係に問題があった。しかし、gtk20がlibrsvg2に依存すればいいかというとそうではなくて、もともと逆向きの依存があるので、循環させるわけにいかない。librsvg2のインストール・アンインストール時にgdk-pixbuf.loadersの中身をいじるようなしかけを作るくらいしかないのかもしれない。この場合、将来別のフォーマットのモジュールが出てきたら、同じしかけを追加していくことになる。

で、話はそれだけではなくて、同じようにgtk20がインストール時に探して登録してしまうものに、IM関連がある。/usr/local/etc/gtk-2.0/gtk.immodules がそれで、SCIMのモジュールがあればここに追加されるようである。依存関係についてはlibrsvg2の場合とまったく同じことになっていて、本来は同じような対処をちゃんとやっておく必要がある。


追記（2/22）

と思ったら、librsvg2もscimも、インストール・アンインストール時にgdk-pixbuf-query-loadersとgtk-query-immodules-2.0を動かすことになっていて、ちゃんとpkg_deleteすればgdk-pixbuf.loadersが更新されている。

問題は、librsvg2をインストールした状態でgtk20のパッケージを作り、それだけを別のマシンにインストールしたことだった。gtk20のインストール時にも走らせればいいのかも。