このセクションでは、Oracle Solaris 11.3 リリースでのファームウェアに関する問題について説明します。
マスターブートレコードの EFI_PMBR エントリ (唯一のパーティション) がアクティブでない場合に BIOS ファームウェアを含む一部のシステムがブートしません。Oracle Solaris 11.3 のインストール後、システムがブートしません。次のメッセージが表示されます。
No Active Partition Found
考えられる原因 1: ブートディスクが GUID パーティションテーブル (GPT) 分割スキームを使用してパーティション化されているため、システムファームウェアがそのブートディスクを正しく処理しません。
回避方法 1: fdisk プログラムを呼び出してから、ブートディスク上で Protective Extensible Firmware Interface (EFI) パーティションをアクティブ化します。
考えられる原因 2: システムが最初に UEFI モードでインストールされましたが、レガシー (BIOS) モードでリブートされました。
回避方法 2: ファームウェア設定オプションを (たとえば、「ブートモード」や類似のオプションを選択して) 変更することにより、システムをレガシーモードでインストールします。
GPT ラベル付きディスクのサポートが SPARC ベースのシステムで利用可能です。次の表で、SPARC プラットフォームでサポートされるファームウェアについて説明します。
|
SPARC T4、T5、M5、または M10 システムに古いファームウェアが搭載されている場合、次の手順を実行して、My Oracle Support から更新済みのファームウェアをダウンロードします。
My Oracle Support にサインインします。
「パッチと更新版」タブをクリックします。
「パッチ検索」ボックスで、「製品またはファミリ (拡張)」検索オプションを選択します。
「製品は _ です」フィールドに、製品名の一部を入力して一致のリストを表示し、製品名を選択します。
「リリースは _ です」ドロップダウンメニューから 1 つ以上のリリースを選択します。
「検索」ボタンをクリックして、パッチとして一覧表示されている入手可能なダウンロードのリストを表示します。
ダウンロードするパッチ名を選択します。
ダウンロードページが表示されます。
「ダウンロード」をクリックします。
ISO イメージからの UEFI モードでのブートに非常に時間がかかります。これは、Oracle VM VirtualBox ファームウェアの既知の問題です。
回避方法: ありません。
x86 システムで、古い Emulex FC HBA カードを使用するディスクで Oracle Solaris がブートしません。
Emulex 製 FC HBA カードでは次のエラーメッセージが表示されます。
error: no such device: 07528c2afbec7b00. Entering rescue mode... grub rescue> ls (hd0) (hd0,gpt9) (hd0,gpt2) (hd0,gpt1) (hd1) grub rescue>
回避方法: 次のいずれかを選択してください。
古い Emulex FC HBA カードを最近のモデルと交換します。SG-XPCIEFCGBE-E8、SG-XPCIE1FC-EM8-Z、SG-XPCIE2FC-EM8-Z、LPe16002-M6-O、または LPem16002-M6-O を使用できます。
システムブートボリュームが 2T バイト未満であることを確認します。
ZFS は、プールデバイス上の書き込みキャッシュを有効化して、システム電源喪失時にキャッシュのフラッシュを安全に処理します。ただし、データが安定したストレージにまだコミットされていないときに、リセット時電源オン条件が発生する可能性があります。
単一点障害がない場合は、次回のデータ読み取り時にこのような状況が ZFS によって自動的に検出されて修正されます。プールの定期的なプール消し込みによって、失われた書き込みの検出および修復が増加する可能性があります。
単一点障害のある環境では、この問題がデータ損失につながる可能性があります。
この問題は、クラスタ化構成からエクスポートされた LUN にアクセスするときに起こりやすくなります。クラスタのフェイルオーバー時は、動作しているヘッド上の SCSI ターゲットによって明示的に送信されたリセット時電源オンイベントが原因で、問題のあるヘッドによってキャッシュされたデータが失われるおそれがあります。このような状況では、単一点障害のないプールであっても影響を受けることがあります。
この問題の症状としては、永続的なチェックサムエラーがまとまって発生します。fmdump –eV からの出力を使用すると、チェックサムエラーが永続的であると診断されたかどうかを判断できます。fmdump –eV の出力内の zio_txg エントリは、データのブロックが書き込まれた時間を表します。永続的なチェックサムエラーというパターンは、デバイス、ソフトウェア、またはハードウェアの障害の症状としてもあり得ます。
回避方法: クラスタからエクスポートされた LUN に依存するシステムや、単一点障害のあるシステムの場合は、システム上のデバイスの書き込みキャッシュを無効にすることを検討してください。
SCSI (sd) または FC (ssd) デバイスの書き込みキャッシュを無効にし、キャッシュのフラッシュを抑制するには、次の手順を実行します。
ストレージデバイスに応じて、/kernel/drv/sd.conf ファイルまたは /kernel/drv/ssd.conf ファイルを /etc/driver/drv ディレクトリにコピーします。
/etc/driver/drv/sd.conf ファイルまたは /etc/driver/drv/ssd.conf ファイルを編集して、書き込みキャッシュを無効にし、キャッシュのフラッシュを抑制します。
SPARC と x64 システムの両方で、VID、PID、または SUN COMSTAR の値を、sd(7D) のマニュアルページの説明のように適切な値で置換するための行を追加します。
sd-config-list="SUN ZFS Storage", "throttle-max:10, physical-block-size:8192, disable-caching:true, cache-nonvolatile:true";
システムをリブートし、高速リブートオプションをオーバーライドします。
# reboot -p