Sun Java Communications Suite 5 インストールガイド

インストールに関する問題の解決

ここでは、インストール時に発生する可能性のある次の問題について説明します。

アンインストール時に残されたファイルによるインストールの失敗

アンインストール時に製品コンポーネントやパッケージが削除されずに残されることがあります。このような場合、Communications Suite を再インストールする前に、製品コンポーネントやパッケージを手動で削除する必要があります。この問題には、次のものが該当します。

アンインストーラで問題が発生し、アンインストールに失敗したパッケージの名前が表示される。
一度削除した製品コンポーネントをインストールしようとしたが、インストーラはその製品コンポーネントがすでにインストールされていることを示す。

部分的なインストールのクリーンアップ

次のコマンドを使用して、一部だけがインストールされたパッケージがないかどうか調べます。

Solaris OS の場合: pkginfo -p

Linux の場合:
rpm -qa |grep —I ^sun | xargs rpm -V
コマンドの出力で、一部だけがインストールされたパッケージのリストが表示されます。『Sun Java Enterprise System 5 インストールリファレンス (UNIX 版)』の第 5 章「インストール可能なパッケージの一覧」を参照し、返されたパッケージ名に基づいてそれらのパッケージが属している製品コンポーネントを調べます。

コンポーネントまたはパッケージを削除します。
- Solaris 9 または Solaris 10 では、prodreg というツールを使用します。
  
  prodreg ツールを使用すると、ホスト上のパッケージベースのコンポーネントを管理できます。各製品コンポーネントとそのパッケージについて、相互依存関係を含む完全な情報を参照できます。prodreg ツールを使用して、安全に製品コンポーネントをアンインストールし、パッケージを削除することができます。prodreg ツールで製品コンポーネントを削除すると、再インストールできるようになります。
- Linux では、rpm -e コマンドを使用します。
  
  製品のレジストリファイルを編集するには、/var/opt/sun/install/productregistry ファイルを開きます。この XML ファイルには、各製品コンポーネントの説明があります。各製品コンポーネントの説明は、<compid\> タグで始まり、</compid\> タグで終わります。製品コンポーネントのエントリ全体を削除します。

次のディレクトリに Communications Suite 製品コンポーネントまたはパッケージが含まれていないことを確認します。

/opt

/etc/opt

/var/opt

インストーラをもう一度実行します。

アンインストール後に製品レジストリに含まれる共有コンポーネントが削除されたためにインストールが失敗する

Communications Suite 5 release から、インストールが終了すると、製品レジストリファイル内に共有コンポーネントが登録されるようになっています。

アンインストーラは、製品コンポーネントをシステムから削除しますが、共有コンポーネントは削除しません。アンインストールが終了しても、製品レジストリには共有コンポーネントのエントリが依然として含まれています。アンインストール後に共有コンポーネントを手動で削除しても、それらのコンポーネントは製品レジストリからは削除されません。したがって、次回の Communications Suite 5 のインストールは失敗します。なぜなら、手動で削除された共有コンポーネントに対するエントリが製品レジストリ内には依然として存在するため、インストーラはそれらのコンポーネントが存在するものと仮定するからです。

ヒント –

Communications Suite の共有コンポーネントをシステムから手動で削除しないでください。

推奨される解決方法: 製品レジストリファイルから対応するエントリを削除するか、製品レジストリファイル自体を削除します。製品レジストリファイルからエントリを削除するとファイルが壊れる危険性があるため、製品レジストリの全体を削除することをお勧めします。これを行う前に、Communications Suite コンポーネント以外の製品が製品レジストリファイルを使用していないことを確認してください。

Linux では、Solaris OS に存在するグラフィカル製品レジストリに相当するものがありません。Linux でファイルを手動で削除した場合、製品レジストリファイルを手動で編集して、それらのエントリを削除する必要があります。

予期せぬ外部エラーが発生する

電源障害またはシステム障害が発生した可能性があります。または CTRL/C を入力して、インストーラのプロセスを停止した可能性もあります。

推奨される解決方法: インストール中または設定プロセスで障害が発生した場合は、おそらく一部だけがインストールされたままになっています。アンインストーラを実行します。アンインストーラが失敗した場合は、「アンインストールが失敗し、ファイルが削除されずに残った」の手順に従います。

グラフィカルインストーラが応答しない

イメージが入力を受け付けるようになる前に、インストーラによって画面上にイメージが作成されることがあります。待ちきれずにインストールウィザードで何度も「次へ」をクリックすることは避けてください。

推奨される解決方法: デフォルトの選択肢を表すボタンには、青い四角形が表示されます。この四角形は、ボタンが表示されたあとに表示されることがあります。ボタンをクリックするときは、青い四角形が表示されるまで待ってください。

サイレントインストールの失敗: 状態ファイルに互換性がない、または破損している

使用しているプラットフォームで作成された状態ファイルを使用している場合、ファイルが壊れ、原因不明であるというエラーが発生する可能性があります。この問題の解決には、次の 2 つの方法があります。

新しい状態ファイルの生成

サイレントインストールを実行しているのと同じプラットフォームで状態ファイルを作成した場合は、新しい状態ファイルを生成して再インストールします。
別のプラットフォームまたは別のバージョンで作成した状態ファイルを使用している場合、問題は、その状態ファイルが、作成したときと同じタイプのプラットフォームだけで実行できることです。たとえば、状態ファイルを Solaris 9 で作成した場合、そのファイルは Solaris 10 では使用できません。また、x86 プラットフォームで作成した状態ファイルは、SPARC プラットフォームでは使用できません。

プラットフォームに適した新規 ID の作成

状態ファイルを作成したプラットフォームが、サイレントインストールを実行しているプラットフォームと異なる場合、状態ファイルに対してプラットフォームに適した ID を新たに作成します。この方法については、「プラットフォームに適した状態ファイル ID の作成」を参照してください。

サイレントインストールに失敗した

状態ファイルを編集した場合、それによってエラーが発生した可能性があります。次の点をチェックし、「状態ファイルの作成」の説明に従って状態ファイルを再生成します。

すべてのローカルホストパラメータが設定され、矛盾のない値が設定されているか。
パラメータ値の大文字、小文字の区別は適切か。
目的のパラメータを入力せずに、必須のパラメータを削除してしまっていないか。
使用するすべてのポート番号は有効であり、かつ割り当て済みではないか。

推奨される解決方法: 問題を解決し、状態ファイルを再生成します。

マニュアルページが表示されない

この問題が起きる場合、たいていはインストールしたコンポーネントの MANPATH 環境変数が正しく設定されていないことが原因です。

推奨される解決方法: 新しいマニュアルページに直接関連付けるように /etc/MANPATH を更新します。「MANPATH の確認」を参照してください。