VMware Workstationが7.1.3に更新されましたね。公式に2.6.35へ対応しています。
Fedora13上の旧版(7.1.2)そのままで、Fedora14を入れてしまうと起動できずにUpdate通知が出ないんですよねぇ。当方は一旦非公式パッチを7.1.2へ当ててF14を起動し、Updateさせています。
もしくは7.1.3を落としてきてInstallでしょうか。
旅先で、貰い事故
・事故処理も終わり、一応決着したので公開とします。
１０月に旅行したとき、泊り先のホテル駐車場で車に当てられました。当て逃げでなかったところは救いでした。
本人が寝ている間に当ててくれました。何か電話が鳴っているような夢を見た気がしていたのですが、夢ではなかったようです（夢であってほしかった・・・）。
下は翌朝に撮った写真。ホテルのフロントで当てられた話を聞いて、「自走不可の場合にどう対応するかな」などと考えながら駐車場に行ってみると、こんなでした。
ちょうどモール部分に当たり、抉ったようです。あとはバンパー中央に擦り傷。バンパー本体にガタはなく、モールを戻せばよさそうでしたのでちょっと安心しました。
相手は大型バスです。フロント左タイヤのボルトと、フェンダーが当たっています。
１０時の位置のボルトにプラスチックの抉りカスが付着していました。もう少し強く当たっていたらバンパー本体が落ちていたかもしれません。角で切り返しをしたときに当たってしまったとのことです。「暗くて見えなくて・・」と言っていましたが、交差点も近くにあり真っ暗にはならない所です。プロの運転手とは思えない言い訳です。
小生も長いこと運転していて、事故は初めてではありませんが、今回の相手バス会社の対応には疑問が残るものがありました。いちいち此処には書きませんが。会社にもよるのでしょうか？ 勉強させていただきました。
貰い事故ですので相手側10割での修理になります。部品としてはバンパーモール、バンパー、バンパースポイラー、ナンバー再発行です。ただ、部品は全て未塗装ですので、これに塗装代が加わります。見積りを見せていただきましたが、かなり高いです。自分で払うなら、バンパーモールの交換だけで済ませてしまうかもしれません。
皆さんも、事故には気をつけましょう。
Fedora14 cronでコマンドが実行されない件
Fedora14を入れた機械で、yum updateを実行しました。
翌朝、この機械からlogwatchのメールがきていませんでした。「これは落ちたか？」と思いながらログインしてみると、特に問題なく動いている様子。今日は仕事が暇でしたので、仕事場からログインして探ってみることにしました。
ログを観察すると、cronからlogwatchが呼ばれていないようです。下流のコマンドからコンソールで起動して動作を確認してみました。
- logwatch 正常
- anacron 正常
- run-parts 正常終了だが、下流コマンドを呼んでいないご様子
ということで、run-partsが怪しそうです。シェルスクリプトですので、簡単にechoコマンドをトラップ代わりに仕込んで動作を見てみます。結果、コマンドを呼ぶときにファイル名を正しく呼んでいない事が判明。ついでに引数の処理も怪しいことが判明。下記のように修正しました。
- ４２行目 ： for i in $(LC_ALL=C; echo $1*[^~,]) ; do -> for i in $(LC_ALL=C; echo $1/*[^~,]) ; do
- ６７行目 ： if [[ $list == 1 ]]; then -> if [ “$list” = “1” ]; then
- ６９行目 ： elif [ $test == 1 ]; then -> elif [ “$test” = “1” ]; then
これで動作するようになります。
(2010/11/15 追記)
昨日の”crontabs-1.11-1.20101111git.fc14.noarch”で修正が入ったようですね。公開前に十分にテストをしていただきたいものです。
ThinkPad T60 へFedora14 を入れてみる ２
メールクライアントやDVDプレーヤを新しいパッケージ及びGCCでコンパイルして更新しました。これは動作するので問題無しです。
Fedora14では2.6.35.6が導入されますが、これがVMware Workstation 7.1.2のhostとして動作できないことが判明。モジュールのコンパイルでエラーとなってしまいます。ただ、先人達の方々の努力でパッチが提供されていますね。（http://communities.vmware.com/thread/272625）ここにあるスクリプトとパッチファイルを任意のフォルダにおいて、スクリプトを実行するとパッチが適用されコンパイルが行われます。無事にエラー無く終了すれば、Workstationを起動して使うことが出来ます。
自己責任でどうぞ。
(2010/11/11追記) 下図はデスクトップ。xine,vmware,firefox,sylpheedを起動し、gimpでショットしてみました。
ThinkPad T60 へFedora14を入れてみる
さて、T23ではあまり芳しくないFedora14でしたが、メイン機に入れる前にサブ機へ導入してみました。このサブ機はメイン機とほぼ同じHW構成と、全く同じHDDディレクトリ構成でそのままバックアップ機として利用しています。
FedoraのサイトのUpgradind Fedora using yumのページの手順に従って入れました。更新パッケージはおよそ1600、約３時間ほどかかりました。
T23の後でしたので、レベル3で起動してXの動作を確認。問題なかったのでレベル５で通常起動。今のところ大きな問題なく動いています。この後、ソフトの再コンパイルや３rdベンダのパッケージを入れて動作をみてみます。
ThinkPad T23 にFedora14を入れてみる ２
先日は「savageが使えない」、としました。３Dが使えないときのエラーメッセージ
(EE) SAVAGE(0): Insufficient Videoram available for 3D — Try a lower color depth or smaller desktop. For integrated savages try increasing the videoram in the BIOS.
(EE) SAVAGE(0): DRI isn’t enabled
この時は、２Dのみで使えます。
次にローカルアドレスアクセスでのエラーですが、gnome-settings-daemonが出しているようですね。なぜVESAドライバがOKで、savageドライバがNGなのかは解りませんが・・。下記のエラーがGDM起動時に発生してクラッシュし、延々とGDM再起動を繰り返します。
(gnome-settings-daemon:1958): GdkPixbuf-CRITICAL **: gdk_pixbuf_format_get_name: assertion `format != NULL’ failed
X: /usr/include/xorg/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized’ failed.
gnome-session: Fatal IO error 104 (接続が相手からリセットされました) on X server :0.0.
gcm-apply: Fatal IO error 104 (接続が相手からリセットされました) on X server :0.0.
xinit: connection to X server lost.
gnome-settings-daemon: Fatal IO error 2 (そのようなファイルやディレクトリはありません) on X server :0.0.
GNOMEを使わない環境（XDM+twm/fvwm等）では、アクセラレーションが効いたsavageドライバが使えます。KDE(KDM+KDE4)でも使えますが、この機械には重すぎる・・・
ThinkPad T23 にFedora14を入れてみる
人柱的な目的で、Fedora13を入れていたT23にFedora14をupgradeで入れてみました。
yumを使うUpgrade手順に従い行いましたが、今回もトラブル発生しています。毎回手順通りに行ったことがないので想定内ですが・・。依存エラーが出ますので、必要ない物であれば取り敢えず削除して再試行します。おおよそ1500程のパッケージ更新でしたので、寝る前に動かして翌朝に結果を見てみます。この時はエラーなくパッケージの更新は終わっていました。
で、再起動させますが、黒画のまま表示されません。まあ、よくあることですが。Xorgのログを見ると，ドライバ（savage）がデグレした感があります。「３D使うにはメモリが不足している」とか、「ローカルアドレスへのアクセスができない」とか、Fedora13では問題なく動いた物が動かなくなっています。仕方ないのでVESAドライバでxwindowを動かしますが、メール、WWWなどは動きますが、DVD等動画は実用になりません。早いうちにsavageドライバの更新を希望するところです。
PowerManagerは改善されてバッテリー詳細、統計などが再び見えるようになりました。
NetworkManagerはipv6を「手動」にして「すべてのユーザに許可する」をチェックするとipv6側のデフォルトルート情報が保存されないバグがありますが、まだ直っていないようです。
さて、次の休みはradeon搭載のT60で試してみることにしましょうか。現時点ではT23ではテキストモードで使うか、VESAドライバを使うしかないようで、実用にならないですね。