この節では、OS プロビジョニング (配備) に関して判明している問題点をまとめています。
OS プロファイルに製品キーがないため、配備に失敗します。しかし、OS プロファイルにプロダクトキーを追加しようとすると、「OS profile is in use.」というメッセージが表示されて処理に失敗します。
回避策: ジョブのタイムアウトが発生するまで待ってから、OS プロファイルに製品キーを追加します。
DHCP オプションを使用して Red Hat OS をシステムに配備するときに、DHCP 範囲内の IP アドレスがシステムに割り当てられません。
回避策: 次の手順を実行します。
管理サーバーにログインします。
/opt/sun/scs/data/allstart/scripts/dhcp_redhat.sh ファイルを編集します。
DEVICE=eth0 FILE=/etc/sysconfig/network-scripts/ifcfg-$DEVICE cat <<_EOF_> $FILE DEVICE=$DEVICE BOOTPROTO=dhcp _EOF_ chown root.root $FILE chmod 644 $FILE
Device エントリを、DHCP の実行に必要な適切なインタフェースに変更します。
dhcp_redhat.sh スクリプトをサーバーの OS プロファイルに追加します。
#n1sh add osprofile osprofile-name script /opt/sun/scs/data/allstart/scripts/dhcp_redhat.sh type=post
Sun Blade X8400 サーバーの CMOS 設定では、デフォルトで ACPI が有効になっていますが、この場合、Linux のインストールが対話型モードになります。
回避策: load コマンドに追加のカーネルパラメータを指定します。
N1-ok> load server <servername> osprofile <profilename> ... kernelparameter pci=nommconf
このパラメータは、load コマンドを実行するたびに指定します。
インストールプロトコルとして nfs を指定すると、OS の配備が対話型モードになります。
回避策: インストールプロトコルとして http を指定します。
拡張モジュールを使用して Sun Blade X8400 サーバーに Red Hat Enterprise Linux 4.0AS Update 3、64 ビットのオペレーティングシステムをプロビジョニングしたあとにサーバーが完全に再起動されません。Kudzu が有効になっている場合に再起動に失敗する可能性があります。処理は「Checking for new hardware」というメッセージで停止します。
Linux OS のプロファイルを使用して Sun Blade X8400 サーバーで Kudzu を無効にするには、次の手順に従います。
スーパーユーザーとして管理サーバーにログインします。
次の行を含むシェルスクリプトファイルを作成します。
#!/bin/sh chkconfig kudzu off
ファイルを既知の場所 (たとえば /scripts/kudzu.sh) に保存します。
N1 System Manager のコマンド行から add osprofile コマンドを使用して、スクリプトを OS プロファイルの post セクションに追加します。
たとえば、Red Hat Enterprise Linux 4 Update 3 の OS プロファイルが rhel4u3 という名前の場合は、次のように入力します。
N1-ok> add osprofile rhel4u3 script /scripts/kudzu.sh type=post |
スクリプトは適切な OS プロファイルに追加してください。
更新したプロファイルを使用して Red Hat Enterprise Linux 4 Update 3 を Sun Blade X8400 サーバーに再び配備します。
回避策: 手動ネットブートを指定せずに配備します。
配備に失敗し、「Reread of the partition table failed.」というメッセージが表示されます。
回避策: サーバーの OS プロファイルで device 属性に hde を指定します。
多数の管理対象サーバーに OS を配備する場合、OS 配備ジョブがジョブまたはジョブステップのタイムアウト値を経過すると OS の配備に失敗する場合があります。この問題が発生した場合、ジョブはエラーになりますが、エラーの説明が空白で、インストールは実際には正常に終了した可能性があります。次に例を示します。
bash-3.00# n1sh show job 12 ジョブ ID: 12 日時: 2006-03-29T01:06:53+0000 種類: OS のロード ステータス: エラー (2006-03-29T03:07:00+0000) コマンド: load group sparc-srvrs osprofile sol-sparc networktype=static ip=10.0.108.81-10.0.108.90 所有者: root エラー: 10 警告: 0 ステップ ID 種類 開始始 完了 結果 1 ホスト取得 2006-03-29T01:06:54+0000 2006-03-29T01:06:54+0000 完了 2 ホスト取得 2006-03-29T01:06:54+0000 2006-03-29T01:06:54+0000 完了 . . サーバー 3 〜 28 . 29 ホスト取得 2006-03-29T01:06:56+0000 2006-03-29T01:06:57+0000 完了 30 ホスト取得 2006-03-29T01:06:56+0000 2006-03-29T01:06:57+0000 完了 31 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 1 32 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 2 33 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 3 34 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 4 35 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 5 36 Java の実行 2006-03-29T01:06:56+0000 2006-03-29T03:06:58+0000 エラー 6 37 Java の実行 2006-03-29T01:06:57+0000 2006-03-29T03:06:58+0000 エラー 7 38 Java の実行 2006-03-29T01:06:57+0000 2006-03-29T03:06:58+0000 エラー 8 39 Java の実行 2006-03-29T01:06:57+0000 2006-03-29T03:06:58+0000 エラー 9 40 Java の実行 2006-03-29T01:06:57+0000 2006-03-29T03:06:58+0000 エラー 10 エラー エラー 1: 説明: エラー 2: 説明: . . 3 〜 8 まで空白のエラーメッセージ . エラー 9: 説明: エラー 10: 説明: |
回避策: n1smconfig を使用してジョブのタイムアウト値を大きくするか、既存のタイムアウト値を超過する原因 (ネットワークの待ち時間の問題など) を改善します。また、一部の OS 配備は正常に終了した可能性があります。サーバーが正常にインストールされたかどうかを確認するには、「すべてのサーバー」ページの「使用 OS」列を確認するか、シリアルコンソールを使用してサーバーにログインします。
Windows で RIS サーバーのホストキーが管理サーバーの ./ssh/known_hosts ファイルにない場合、create os コマンドは失敗します。
回避策: RIS サーバーのホストキーが管理サーバーの ./ssh/known_hosts ファイルにあることを確認します。ssh コマンドを使用して管理サーバーから RIS サーバーに手動でログインすると、ホストキーが自動的に作成されます。
networktype=dhcp 属性を指定して Windows OS を配備すると、Windows のインストール後に管理対象サーバーに割り当てられる IP アドレスが、bootip 属性で指定した IP アドレスになります。IP アドレスは、DHCP サービスによって自動的に割り当てられる必要があります。
回避策: インストールの完了後に管理対象サーバーを再起動します。サーバーのプロビジョニング IP アドレスが、DHCP サーバーから正しく再割り当てされます。
Solaris 10 Update 2 OS を Sun Fire X4500 サーバーに配備するには、特殊なプロファイルが必要であり、ディスクを無作為に選択できません。サーバーの正しい起動ディスクを判別するには、先にシステムを起動する必要があります (工場出荷時の OS または CD-ROM から)。
正しい起動ディスクを検出するには、次の手順に従います。
端末ウィンドウを開きます。
次のコマンドを入力して、最初の起動可能なディスクを検索します。
#cfgadm | grep sata3/0
次のように表示されます。
sata3/0::dsk/cXt0dY
ここで X と Y は数値です。例: c4t0d0
次のいずれかを実行して、2 番目の起動可能なディスクを検索します。
0 に 4 を加算します。たとえば、最初のドライブが c4t0d0 の場合、2 番目のドライブは c4t4d0 になります。
または次のコマンドを入力します。#cfgadm | grep sata3/4
次のように表示されます。
sata3/4::dsk/cNtNdN
ここで N は数値です。例: c4t1d0
手順 2 と手順 3 の情報を使用してインストールを続行し、サーバーの OS プロファイルに適用します。
回避策: 回避策はありません。
N1SM の製品マニュアルに記載されているように、Sun Fire V20z サーバーの bge1 デバイスパスは /pci@0,0/pci1022,7450@a/pci17c2,10@3 です。ただし、新しい Sun Fire V20z サーバーでは bge1 デバイスパスが変更されているため、bootpath 属性に bge1 デバイスパスを指定すると、OS の配備に失敗します。
回避策: 新しい Sun Fire V20z サーバーでは、bootpath 属性に次の bge1 デバイスパスを使用します。/pci@0,0/pci1022,7450@a/pci17c2,10@2,1
BIOS コンソールのボーレートが 9600 (デフォルト) に設定されていないと、Sun Fire V20z または V40z サーバーへの OS の配備に失敗します。したがって、load server コマンドまたはブラウザインタフェースの「OS のロード」ウィザードで consolebaudrate の値を変更できません。
SP コンソールのボーレートが 9600 以外に設定されていた場合、OS の配備は正常に終了しますが、connect server コマンドを使用したコンソールで文字が正しく表示されません。
回避策: OS の配備後に BIOS コンソールのボーレートを手動で変更します。変更するには、ターゲットサーバーを再起動し、起動処理中に BIOS 設定画面を表示します。BIOS の設定を変更する方法については、サーバーのマニュアルを参照してください。
Grid Engine アプリケーションがあるサーバーに OS プロファイルをロードしようとすると、「処理が失敗しました。」というメッセージが表示されて処理に失敗します。
回避策: ターゲットサーバーから Grid Engine アプリケーションをアンロードします。