- - PR -
Red Hat Linux 7.3にOpenOffice.orgをインストール失敗
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2002-07-17 19:49
Red Hat Linux 7.3にOpenOffice.orgをインストールするには（2002/7/11）
http://www.atmarkit.co.jp/flinux/rensai/linuxtips/193smbclientuse.html をみてやってみたのですが、できませんでした。 fonts.dirを書き換えても、 xfsを再起動すると戻ってしまいます。 何かやり方が間違っているのでしょうか？ |
|
投稿日時: 2002-07-19 13:18
xfsの再起動でfonts.dirが元に戻ってしまうという経験は私にはないのですが、
fonts.dirの書き換えはrootでしていますか? あとは、/usr/share/fonts/ja/TrueType/fonts.dirの1行目の数字が fonts.dirの行数−1になっているかどうか。 私の場合は、次のようになっています。 $ head -n 1 /usr/share/fonts/ja/TrueType/fonts.dir 63 $ wc -l /usr/share/fonts/ja/TrueType/fonts.dir 64 /usr/share/fonts/ja/TrueType/fonts.dir |
|
投稿日時: 2002-07-19 15:29
Redhat Linux 7.3 のFTP版（Linux Magazineのだったかな？ 今手元の無いので……）を使っていた時に同じ現象が起きました。そのとき調べた限りでは2chのRedhat板で同様の報告があったと思います。
原因は、不明なのですが、fonts.dirを書き換えると何故か/etc/rc.d/init.d/xfsの elif [ $(find . -type f -cnewer fonts.dir 2>/dev/null)" != "" ];then NEEDED = yes fi の行が真になってしまい、mkfontdirで新しいfonts.dirがで出来上がるという現象が起きていました。で、今手元にあるRedhat Linux 7.3(RedhatサイトのFTP版、kernel 2.4.18-5)で試してみたところ全く問題が起きないので、kernelとか配布元の差異（雑誌など）で問題の起こりかたが違うのかもしれません。 この他にも、kernel 2.4.18-4を入れるとNFS Clientがネットワーク上のディスクに対してロックをかけてしまうという問題のおかげで周りにずいぶん迷惑をかけました(^^; |
|
投稿日時: 2002-07-22 06:57
redhat7.3にOpenOffice.orgをインストールできました。
といってもインストールは文字化けしたままだったのですが、 起動後にフォントを置き換えることでつかえるようになりました。 TrueTypeフォントの設定はxfsではうまくいかないのでxttをつかいました。 OpenOffice.orgの以下のサイト( 情報交換 障害報告掲示板 ＃３２３ )で解説してます。 http://sun.obi.ne.jp/forum8/forum.cgi?Forum=sample |
|
投稿日時: 2002-07-22 16:48
Linux magazine付属のRed Hat 7.3をパッケージオプション［すべて］でインストールして試してみましたが（ただしVMwareに）、やはりfonts.dirが書き変わるということはありませんでした。(;;)
もしかして、Xを起動したままxfsを再起動したとか? なわけはないですよね。 |
|
投稿日時: 2002-07-22 20:17
私がためしたのはFTPでダウンロードしたRH73です。
結局、/etc/init.d/xfsを書き変えてmkdirを 実行しないようにしました。 なにかやっちゃたんでしょうか? わかりません。 |
|
投稿日時: 2002-07-23 00:33
>もしかして、Xを起動したままxfsを再起動したとか?
>なわけはないですよね。 Xを起動したままxfsを再起動させるとfonts.dirが書き変わるんですね。 まあ、ここの解説文ではそのことについて触れてないので、 特別に注意書きしてない限り陥りやすい点だとおもいます。 |
|
投稿日時: 2002-07-23 06:00
Linuxを空いてる領域に入れて確認してみました。前にLinux Magazineと書いてしまいましたが間違いで日経Linux付属の物です(がどうもディスリビューションは関係なさそうです)。
# とりあえずLinux Magazine 編集部の皆様ごめんなさい(^^; 以下は、インストール直後、以下のコマンドを発行した結果です。 # cd /usr/share/fonts/ja/TrueType # ls --time=ctime --full-time 合計 14592 -rw-r--r-- 1 root root 1548 火 7月 23 13:20:57 2002 fonts.alias -rw-r--r-- 1 root root 2730 火 7月 23 04:29:19 2002 fonts.dir -rw-r--r-- 1 root root 2730 火 7月 23 04:29:19 2002 fonts.scale -rw-r--r-- 1 root root 626 火 7月 23 13:20:57 2002 fonts.scale.xtt -rw-r--r-- 1 root root 4039596 火 7月 23 13:20:59 2002 kochi-gothic.ttf -rw-r--r-- 1 root root 17318 火 7月 23 13:20:59 2002 kochi-gothic.tti -rw-r--r-- 1 root root 5733792 火 7月 23 13:21:02 2002 kochi-mincho.ttf -rw-r--r-- 1 root root 17318 火 7月 23 13:21:02 2002 kochi-mincho.tti -rw-r--r-- 1 root root 2377272 火 7月 23 13:21:03 2002 wadalab-gothic.ttf -rw-r--r-- 1 root root 17318 火 7月 23 13:21:03 2002 wadalab-gothic.tti -rw-r--r-- 1 root root 2658724 火 7月 23 13:21:04 2002 watanabe-mincho.ttf -rw-r--r-- 1 root root 17318 火 7月 23 13:21:04 2002 watanabe-mincho.tti インストールした時点で、ほとんどのファイルがfonts.dirより後にステータスが変更されたことになっています。この状況だとxfsのスクリプト中でmkfontsdirが実行されて新しいfonts.dirが出来てしまいます。 fonts.dirの時刻は、psで表示されるxfsの起動時刻と同じであるため、xfsの起動時に生成されたと思われます。で、問題はfonts.dir以外のファイルの時刻で、この時刻は明らかに未来の時刻です(しかも約+9時間。ただしls -lで表示されるファイル生成時刻は４月になっている)。 この結果から、おそらくインストール時には、まずコピーによりディストリビューションが作成された時刻でファイルが生成され、その後ハードウェアクロックをGMTとみなしGMT+9でファイルステータスを変更、再起動後はハードウェアクロックを現地時間とみなしxfsがfonts.dirを生成という流れになりこのような問題が起きたのではないかと思います。 # ソースを追ったわけではないので嘘かもしれません。信じないでください(- -; このため、インストール後9時間以上経過後にfonts.dirが再生成されると問題が起きなくなるはずですし、ハードウェアクロックがGMTと一致している場合には問題が起こらないはずです。 まあ、どちらにしろxfs中の「find . -type f -cnewer fonts.dir」は求められている機能を考えると「find . -type f -newer fonts.dir」の方が適切だと思いますが。 > Xを起動したままxfsを再起動させるとfonts.dirが書き変わるんですね。 というわけではありません。まあ、xfsを再起動するのにXを起動した状態で行なうのは行義がいいとはいえないとは思いますけれど。 [ メッセージ編集済み 編集者: 英-Ran 編集日時 2002-07-23 06:09 ] |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。