[写真は多忙につきありませんw ]

多忙を言い訳にするのはよろしくないが、多忙すぎて手がでない。故にこのblogも放置され続けてしまった。月が飛ぶのも気分が悪い、とりあえずここ数日にあったことをメモしておく。

仕事用道具に金をかけなさすぎるのも問題だろう、ということで、今使っているThinkPad W500(4058-CTO)に、8GBメモリ(Transcendの4GB DDR3 PC8500 SODIMM 7-7-7を2枚)、IntelのSSD、さらにはWindows7 64bit Professionalを導入した。

メモリは本来4GBが上限ということになっているのだが、8GB乗せて動いたという情報があったのでそれを信じて人柱。これは問題なし。SSDは某所にかいてあった、空き領域を多めにするとその分寿命が延びるかもしれないということから１割減らして領域を確保。これも今のところ問題はない。

だが、問題は起こる。どうにも使っているとちょくちょくフリーズしてしまう。挙げ句の果てには全く起動しなくなって画面すら出ずビープすら鳴らないという状態になってしまった。
これにはまいったのだが、とりあえずねじ固定されていないものを全部外して、電源もバッテリも外して、メモリもいったん全部抜いて電源を入れてみるとビープがなる。ということはBIOSそのものは生きていると判断できる。
こりゃCMOSが怪しいか、とCMOS保持用の電池を外して(本機の場合はキーボード下にある。コネクタが弱いので折らないように注意)、そのまま小一時間放置。その間にブロアでたまった埃を飛ばしていると、CPUファンに相当な埃がたまっていたようで咳き込むほどの埃が出てきた。
その後、CMOS電池をつけ直してメモリを差して電源を入れると、果たして本機はよみがえったのであった。夜夜中に心臓に悪いイベントは勘弁していただきたい。

その後の調べで、どうやらATIのドライバがおかしく、CCC(Catalyst Control Center)よりPowerPlayを無効にしてやるといいという話を見かけたので試してみている。これが効くかどうかはわからないが、ちょくちょくフリーズする人は試してみる価値はあるかもしれない。こちらで効いたかどうかは追って書くことにしよう。

さらに欲を出してXP modeを入れてみる。VirtualPCが必要だと言うのだが、ここにはすでにVMWare Workstation6.5が入っている。これでも動かないか試行錯誤、NHCというユーティリティで、XP modeのvhdファイルをVMWareのvmdk形式に変換してやることでVMWareの仮想マシン用ディスクとして認識させ、起動させることができた。
起動したら、VirtualPC連携用のアプリケーションが入っているのをアンインストールする。アンインストールするまでマウスは使えないのでキーボードオペレーションでがんばること。
これでやっと使える－、と思ったのだが、アクティベーションが通らない。同じディレクトリにあるKEY.txtの中身を突っ込んでもだめ。本来はWindows7上で動いている限りアクティベーションは不要なはず。VMWare Workstation7やVMWare Player3にはXP互換モード、という専用のモードがあるあたり、もしかするとそれじゃないと意味がないのかもしれず。

時間がないのでものすごい駆け足で作業をしたつもりでも、丸一日近くとられてしまった。Windows7にはまだ慣れないが、なんとか慣れつつ遅れ挽回のためにまたしばらく黙して作業に勤しもう。

VMWare上のFedora9で、eth0(bridge)、eth1(NAT)設定をしているとき、DHCPでのIP取得を行おうとすると、eth0がDHCPに失敗する、という問題がでていた。

結論からいうと、下記許可ルールを追加すると解決する。

ローカル側：UDP 67-68ポート
リモート側：UDP 67-68ポート 信頼ゾーン

非常に気持ち悪いのだが、ひとまず解決策。

追記：
VMWareのIP幅を信頼ゾーンに加えてないと、失敗するかもしれない。未検証。

追追記：
サポートに推奨設定を問い合わせていたが、その返答がきた。曰く、

プロトコル：UDP
方向：内向き
アクション：許可
ローカルポート：68
リモートポート：67

を追加するようにとのこと。これで変なところで引っかからずきちんとファイアウォールを使うことができる。ありがたい。

　毎度毎度、VMWareとPersonal firewall製品との相性には泣かされる。bridgeとして設定したNICが、promiscuos modeで動作することと、(恐らく)Personal firewallが、自身の動作する宛先IP以外を宛先とするパケットを拒否してしまうからなのだが、理由がわかっても回避方法がないことが多い。

　今使っているのは、ESET Smart Security。その昔、NOD32があまり知られていなかった頃に価格.comでの問題を見つけて中の人に連絡したのが懐かしいが、そのNOD32を出しているところのFirewall込み製品だ。これまでは全体的に悪くないなと思って使っていたが、今回VMを外から叩く必要が出てきて問題が発覚した。これも駄目っぽい。
　昔、NOD32＋outpost(だったかSygate Personal firewallだったかどちらか)との組み合わせだとこの問題は回避できたように記憶している。やはり餅は餅屋、Firewall製品はFirewall製品屋で、ということなのだろうか。

　ひとまず今回はfirewall設定を切ることで対処した。やれやれ・・・。

参考サイト：Firewallと森で遊ぼう　このサイト、更新されていないのが本当に惜しい。