| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
マニュアルページセクション 1M: システム管理コマンド Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
マニュアルページセクション 1M: システム管理コマンド Oracle Solaris 11 Information Library (日本語) |
- システムカーネルまたはスタンドアロンプログラムのブート
boot [OBP names] [file] [-aLV] [-F object] [-D default-file]
[-Z dataset] [boot-flags] [--] [client-program-args]kernel$ /platform/i86pc/kernel/$ISADIR/unix [boot-args]
[-B prop=val [,val...]]ブートストラップとは、スタンドアロンプログラムを読み込んで実行する処理のことです。ここでのブートストラップとは、ブート可能なオペレーティングシステムを読み込んで実行することを意味します。通常、スタンドアロンプログラムはオペレーティングシステムカーネル (kernel(1M) を参照) ですが、代わりに任意のスタンドアロンプログラムをブートすることもできます。SPARC ベースのシステムでは、オペレーティングシステム以外にブートできるスタンドアロンプログラムの代表的な例として、マシンの診断モニターがあります。
スタンドアロンプログラムが動的にリンクされる実行可能プログラムとして識別された場合、boot は実行可能形式によって指定されたインタプリタ (リンカー / ローダー) をロードし、そのインタプリタに制御を渡します。スタンドアロンプログラムが静的にリンクされている場合は、そのスタンドアロンプログラムに直接ジャンプします。
カーネルは読み込まれると、UNIX システムを起動して、必要なファイルシステム (vfstab(4) を参照) をマウントし、/usr/sbin/init を実行して、システムを /etc/inittab で指定されている「initdefault」状態にします。inittab(4) を参照してください。
SPARC ベースのシステムでは、ほとんどのマシンでのブートストラップ手続きは次の基本フェーズからなります。
マシンの電源を投入すると、(PROM 内の) システムファームウェアが電源投入時自己診断テスト (POST) を実行します。この診断テストの形式と範囲は、システムに搭載されているファームウェアのバージョンによって異なります。
診断テストが正常に完了した後、ファームウェアが使用する不揮発性記憶領域に適切なフラグが設定されていれば、ファームウェアは自動ブートを試みます。ファームウェアは、読み込むファイルの名前とそのファイルを読み込むデバイスを選択することができます。
これらのフラグと名前は、シェルから eeprom(1M) コマンドを使用するか、またはシステムの停止後に ok プロンプトで PROM コマンドを使用することにより、設定できます。
第 2 レベルのプログラムは、ファイルシステム固有のブートブロック (ディスクからブートする場合) または inetboot または wanboot (ネットワークからブートする場合) のどれかです。
ネットワークブート
ネットワークブートは 2 段階で行われます。 まず、クライアントが、二次ブートプログラムの読み込みに必要な IP アドレスとその他のすべてのパラメータを取得します。次に、二次ブートプログラムがブートデバイスからブートアーカイブをロードします。
IP アドレスは、 PROM で使用可能な機能と PROM の構成に応じて、RARP、DHCP、手動構成のいずれかの方法を使って取得できます。sun4u および sun4v カーネルアーキテクチャーのマシンは、DHCP に対応した PROM を備えています。
次に、2 種類のネットワークブート方式を指定する boot コマンド構文を示します。
boot net:rarp boot net:dhcp
次のコマンドを見てください。
boot net
このコマンドのように、rarp または dhcp 指示子を指定しないと、net が別名になっているネットワークインタフェースを介して、デフォルトのネットワークブート方式が呼び出されます。
以降では、RARP/bootparams を使用するネットワークブートのイベントシーケンスについて説明します。そのあとで、DHCP を用いたシーケンスについて説明します。
RARP/bootparams を使ってネットワークからブートする場合、PROM はまず、応答を受信するまで逆 ARP 要求をブロードキャストします。応答を受信すると、TFTP 要求をブロードキャストして inetboot の最初のブロックを取得します。続いて、その最初のブロック要求に一番先に応答したサーバーに後続の要求が送信されます。読み込みの完了後、inetboot も同様に、逆 ARP を使って IP アドレスを取得した後、bootparams RPC 呼び出し (bootparams(4) を参照) をブロードキャストすることで、構成情報とルートファイルシステムを検索します。次に、inetboot が NFS を使用してブートアーカイブをロードし、そのアーカイブに制御を渡します。
DHCP を使用してネットワークからブートする場合、PROM はハードウェアアドレスおよびカーネルアーキテクチャをブロードキャストし、IPアドレス、ブートパラメータ、およびネットワーク構成情報を要求します。(可能性のある複数のサーバーの中から) DHCP サーバーが応答し選択されると、そのサーバーがクライアントに IP アドレスおよびクライアントのブートに必要な他のすべての情報を送信します。この情報を受信したクライアントの PROM は、読み込むファイルの名前を調べ、そのファイル名が HTTP URL であるかどうかにより、2 種類の動作のいずれかを実行します。ファイル名が HTTP URL でなかった場合、PROM は、inetboot をダウンロードし、それをメモリー内に読み込んで実行します。inetboot はブートアーカイブをロードし、そのブートアーカイブがマシンを引き継いで inetboot を解放します。その後、開始スクリプトが DHCP エージェント (dhcpagent(1M) を参照) を開始します。以降の DHCP アクティビティは、その DHCP エージェントによって実行されます。
読み込むファイルが HTTP URL の場合、PROM は、その参照ファイルを HTTP を使って読み込みます。クライアントが HMACSHA-1 鍵を使って構成されていた場合、クライアントは読み込んだファイルの整合性を検査した後で、そのファイルを実行します。そのファイルは wanboot バイナリであるとみなされます。WAN ブートプロセスは、DHCP または NVRAM プロパティーのどちらかを使用してインストールサーバーとルーター、およびその接続に必要なプロキシを発見するように構成できます。ブートされた wanboot は、処理を継続できるだけの情報がそろっているかどうかを判断します。必要な情報が不足していた場合は、適切なエラーを出力して処理を終了するか、コマンドインタプリタを起動して必要な構成情報の入力をユーザーに求めます。必要な情報を取得した wanboot は、HTTP 経由でブートローダーをメモリー内に読み込みます。クライアントに暗号化鍵がインストールされている場合、wanboot は、ブートローダーの署名とそれに付随するハッシュを確認します。暗号化鍵は存在するが、ハッシュキーがない場合はエラーとなります。
wanboot ブートローダーは、HTTP またはセキュリティー保護された HTTP のどちらかを使用してクライアントと通信できます。 HTTP を使用する場合でかつ、クライアントが HMAC SHA-1 鍵を使って構成されていた場合、ブートローダーはルートファイルシステムの整合性検査を実行します。ルートファイルシステムがメモリーに読み込まれた (場合によっては、さらに整合性検査が実行された) あと、ブートアーカイブがサーバーから転送されます。なお、wanboot.conf(4)ファイルで boot_logger URL が指定されていた場合、wanboot は処理状況に関するログを定期的に記録します。
すべての PROM が URL を処理できるわけではありません。クライアントにその機能が備わっているかどうかを判断するには、list-security-keys OBP コマンド (monitor(1M) を参照) を使用します。
現在のところ、x86 プラットフォーム上では WANブートは利用できません。
wanboot コマンド行
クライアントプログラムが wanboot である場合、クライアントプログラムは、次の形式の client-program-args を受け入れます。
boot ... -o opt1[,opt2[,...]]
ここで、各オプションに指定できるアクションは、次のとおりです。
DHCP 経由で構成パラメータを取得するように wanboot に指示します。
コマンドインタプリタをブートするように wanboot に指示します。
下記のインタプリタコマンドのいずれか。
...または、下のインタプリタパラメータ名を使用した代入文。
wanboot コマンドインタプリタ
ブート時に client-program-args として「-o prompt」を指定すると、wanboot コマンドインタプリタがブートされます。単一のコマンドまたは代入文、もしくは、コンマで区切られた一連のコマンドまたは代入文が入力可能です。利用可能な構成パラメータは、次のとおりです。
クライアントの IP アドレス (ドット区切り 10 進表記)。
デフォルトのルーターの IP アドレス (ドット区切り 10 進表記)。
サブネットマスク (ドット区切り 10 進表記)。
DHCP クライアント識別子 (引用符付き ASCII 文字列または 16 進 ASCII)。
DHCP トランザクションで要求するホスト名 (ASCII)。
HTTP プロキシサーバー指定 (IPADDR[: PORT])。
利用可能な鍵名は、次のとおりです。
トリプル DES 暗号鍵 (48 個の 16 進 ASCII 文字)。
AES 暗号鍵 (32 個の 16 進 ASCII 文字)。
HMAC SHA-1 署名鍵 (40 個の 16 進 ASCII 文字)。
最後に、WANブート CGI の URL を参照する方法を示します。
WANブート CGI の URL (OBP の file パラメータと同等)。
インタプリタが受け入れるコマンドは、次のとおりです。
利用可能なコマンドの簡単な説明文を出力します。
valを var に代入します。ここで、varは、構成パラメータ名、鍵名、bootserver のいずれかです。
パラメータ var の設定を解除します。
すべてのパラメータとその設定値を一覧表示します (OBP 経由で取得された鍵の値は表示されません)。
未設定パラメータに対する値の入力を、ユーザーに求めます。各パラメータの名前と現在値 (もしあれば) が出力されます。ユーザーは、Return キーを押して現在値を受け入れることもできますし、新しい値を入力することもできます。
すべての値の入力を完了したら、インタプリタを終了しブート処理を継続します。
ブートインタプリタを終了し、OBPの ok プロンプトに戻ります。
前述の代入文やコマンドは、コマンド行の -o オプションの一部として、いくつでも指定できますが、boot コマンドの引数の長さには 128 バイトの OBP 制限があります。たとえば、「-o list,go」とすると、パラメータの現在値 (デフォルト値) が一覧表示された後、ブート処理が継続します。
iSCSI ブートは、x86 と SPARC の両方でサポートされています。
x86 上の iSCSI ブートx86 上の iSCSI ブートの場合は、ブートされるホストに iBFT (iSCSI Boot Firmware Table) に対応した NIC が装着されているか、またはメインボードの BIOS が iBFT に対応している必要があります。ACPI (Advanced Configuration and Power Interface) 3.0b 仕様で定義された iBFT では、iSCSI ブートプロセスに有効な、さまざまなパラメータを含む情報のブロックが指定されています。
ファームウェアで実装された iBFT は、iSCSI ターゲットへの接続を確立することによって、ブート可能なデバイスとしてブート中に BIOS 内に iSCSI ディスクを提供します。iSCSI ブートの残りの処理は、ローカルディスクからのブートと同じです。
ユーザーが iBFT を正しく構成するには、各ハードウェアベンダーのドキュメントを参照する必要があります。
SPARC 上の iSCSI ブートSPARC 上の iSCSI ブートは OpenBoot レベル 4.31 以降でサポートされ、特定の NIC は必要ありません。
OpenBoot でのブートコマンドには、keyword=value 形式に従った、宛先の iSCSI ターゲットを識別するための一連のキーワードを指定します。iSCSI ブートコマンドの完全な形式は次のとおりです。
boot net:iscsi-target-ip=t-ip,iscsi-target-name=name
host-ip=h-ip[,router-ip=r-ip]
[,subnet-mask=m-ip]
[,iscsi-port=port]
[,iscsi-lun=lun]
[,iscsi-partition=partition]前述のキーワードの説明を次に示します。
ブート対象ホストの IP アドレス。
経路指定するゲートウェイの IP アドレス。
host-ip のサブネットマスク。
OS を格納している iSCSI ターゲットの IP アドレス。
OS を格納している iSCSI ターゲットの名前。
ブート可能なルートを含むパーティション。
ターゲットの IP ポート。
ターゲット上のブートされる LUN。
iscsi-target-ip、route-ip、および subnet-mask の値は、標準の IPv4 ドット区切り 10 進数の形式です。たとえば、subnet-mask に 255.255.255.0 を指定します。IPv6 は、現在の OpenBoot 実装ではサポートされていません。
iscsi-port の値は、1 から 65535 までの 10 進数です。
iscsi-lun の値は、ダッシュで区切られた 16 進数の LUN、ffff-ffff-ffff-ffff の形式です。詳細は、RFC 4173 のセクション 5 を参照してください。先頭のゼロと以降のダッシュは除外できます。そのため、たとえば、3 は 0003-0000-0000-0000 と同等です。
iscsi-partition の値は、ルートパーティションを指定するために使用される 1 つの ASCII 文字です。一般には、a です。
iscsi-target-name の値は、RFC 3720 と RFC 3722 によって指定されている文字列の形式です。
ターゲット側での CHAP 認証を提供するために、2 つのセキュリティーキーが追加されます。これらのキーは次のとおりです。
CHAP 名
CHAP シークレット
現在、これらの 2 つのキーは、OpenBoot PROM (ok) プロンプトでコマンド set-ascii-security-key を使用して設定できます。例:
ok set-ascii-security-key chap-user chap name ok set-ascii-security-key chap-password chap password
双方向の認証は、まだサポートされていません。これらの 2 つの変数は、OpenBoot PROM プロンプトでのみ変更できます。
DHCP サーバーから iSCSI ブート情報を取得するために、RFC 4173 がサポートされています。DHCP サーバーは、ブート対象クライアントのルートパスオプションを指定する必要があります。そのあと、クライアントは、単純コマンドを使用して iSCSI ブートを実行できます。
boot net:dhcp
現在は、iSCSI ブート中に物理ブートデバイスのパスを取得するために、キー boot-device が使用されます。このキーは、Solaris のインストール中に設定されます。キー値を手動で変更すると、iSCSI ブートが停止することがあります。
ディスクからブートする場合、OpenBoot PROM ファームウェアは、ブートデバイスとして指定されたパーティションのブロック 1 ～ 15 からブートブロックを読み取ります。このスタンドアロンのブートプログラムには通常、ブートアーカイブを読み取ることができる、ファイルシステム固有のリーダーが含まれています。
スタンドアロンプログラムのパス名が相対パス名の場合 (スラッシュで始まらない場合)、第 2 レベルのブートにおいて、プラットフォームに依存する検索パスでスタンドアロンプログラムが検索されます。このパスには必ず、/platform/platform-name が含まれています。多くのSPARC プラットフォームでは、次にプラットフォーム固有のパスエントリ /platform/hardware-class-name が検索されます。filesystem(5) を参照してください。絶対パス名の場合、boot は指定されたパスを使用します。その後、boot プログラムは該当するアドレスからスタンドアロンプログラムをロードし、制御を渡します。
ブートアーカイブがブートデバイスから転送されたあと、Solaris はマシンを初期化し、その制御を引き継ぐことができます。このプロセスは、下の「ブートアーカイブのフェーズ」でさらに詳細に説明されており、すべてのプラットフォーム上で同一です。
ファイル名がコマンド行で、または boot-file NVRAM 変数などで指定されていない場合、boot はシステムにインストールされているソフトウェア、ハードウェアおよびファームウェアの能力に基づいて、読み込むべきデフォルトのファイルを選択します。
カーネルへのパスには、スペースを含めてはいけません。
ZFS では、デバイス指定子によって単一のルートファイルシステムではなく、ストレージプールが識別されるため、ZFS からのブートは UFS からのブートとは異なります。ストレージプールには、複数のブート可能データセット (つまり、ルートファイルシステム) が含まれていることがあります。そのため、ZFS からブートする場合、ブートデバイスを指定するだけでは十分ではありません。ブートデバイスによって識別されたプール内のルートファイルシステムも指定する必要があります。デフォルトでは、プールの bootfs プロパティーで指定されているデータセットが、ブート用に選択されます。このデフォルトの選択は、-Z オプションで代替のブート可能データセットを指定することによって上書きできます。ZFS プール内のブート可能データセットを一覧表示するには、-L オプションを使用します。
ブートアーカイブには、メモリー内ディスクを使用してマウントされるファイルシステムイメージが含まれています。このイメージは自己記述型であり、特にブートブロックにはファイルシステムリーダーが含まれています。このファイルシステムリーダーは RAM ディスクイメージをマウントして開いたあと、その中に含まれているカーネルを読み取って実行します。 デフォルトでは、このカーネルは次の場所にあります。
/platform/`uname -i`/kernel/unix
ZFS からブートする場合は、アーカイブとカーネルファイルの両方のパス名が、前の節で説明した、ブート用に選択されたルートファイルシステム (つまり、データセット) 内で解決されます。
カーネルの初期化は、I/O をオンにし、ルートファイルシステムをマウントできるまで、メモリー内ファイルシステムから必要なドライバとモジュールを読み込むことにより続行されます。ルートファイルシステムがマウントされると、メモリー内ファイルシステムは必要なくなり、破棄されます。
OpenBoot boot コマンドは、次の形式の引数をとります。
ok boot [device-specifier] [arguments]
デフォルトの boot コマンドに引数はありません。
ok boot
boot コマンド行で device-specifier を指定しない場合、OpenBoot は通常、boot-device 変数または diag-device NVRAM 変数を使用します。オプションの arguments をコマンド行で指定しないと、OpenBoot は通常、boot-file または diag-file NVRAM 変数をデフォルトの boot 引数として使用します。(システムが診断モードの場合、boot-device および boot-file の代わりに、diag-device と diag-file が使用されます)。
arguments には複数の文字列を指定できます。すべての argument 文字列は二次ブートプログラムに渡され、OpenBoot では解釈されません。
boot コマンド行に arguments を指定した場合、boot-file または diag-file NVRAM 変数のどちらも使用されません。NVRAM 変数の内容がコマンド行の引数とマージされることもありません。次に例を示します。
ok boot -s
このコマンドでは、boot-file および diag-file の設定値は無視され、文字列 -s は arguments として解釈されます。この場合、boot は boot-file または diag-file の内容を使用しません。
以前の PROM におけるコマンド例を示します。
ok boot net
このコマンドでは引数が指定されていないため、代わりに、boot-file または diag-file の設定値 (設定されている場合) が、boot に渡すデフォルトのファイル名および引数として使用されます。ほとんどの場合、システムタイプ、システムのハードウェアとファームウェア、およびルートファイルシステムにインストールされているソフトウェアに基づいて boot コマンドに適切なデフォルト値を選択させるのが、最善の方法です。boot-file または diag-file を変更すると、状況によっては予期せぬ結果を招くおそれがあります。
これは、大部分の OpenBoot 2.x および 3.x ベースのシステムにおける一般的な動作です。ただし、プラットフォームによっては動作が異なる可能性もあります。
次のコマンドを見てください。
ok boot cdrom
...このコマンドも通常は、引数を指定しません。したがって、boot-file に 64ビットカーネルのファイル名が設定されている環境で、「boot cdrom」と入力してインストール CD または DVD をブートしようとしても、インストールメディアに 32 ビットカーネルしか含まれていなければ、そのブート処理は失敗します。
使用される boot コマンドの形式によっては、boot-fileまたは diag-file の内容が無視されるので、プロダクションシステムで boot-file に依存することは一般に推奨しません。
ローカル (CD または DVD 上) に存在する wanboot コピーから WAN ブートを実行するには、次のコマンドを使用する必要があります。
ok boot cdrom -F wanboot - install
最近の PROM に含まれるネットワークブートサポートパッケージは、次の構文をサポートするように強化されており、引数を処理できるようになっています。
[protocol,] [key=value,]*
すべての引数は省略可能であり、指定する順序にも制限はありません。ただし、リストの末尾でない限り、引数の後にはコンマが必要です。ここで指定した引数は、すべてのデフォルト値よりも優先されるほか、DHCP を使ってブートする場合には、それらの引数に対応する DHCP サーバーから提供される構成情報よりも優先されます。
前述の protocol には、使用するアドレス検索プロトコルを指定します。
key=value 属性ペアには、以下の構成パラメータを指定します。
TFTP サーバーの IP アドレス。
TFTP を使ってダウンロードするファイルの名前、または WANブートの URL。
クライアントの IP アドレス (ドット区切り 10 進表記)。
デフォルトのルーターの IP アドレス。
サブネットマスク (ドット区切り 10 進表記)。
DHCP クライアント識別子。
DHCP トランザクションで使用するホスト名。
HTTP プロキシサーバー指定 (IPADDR[: PORT])。
TFTP の最大リトライ回数。
DHCP の最大リトライ回数。
ネットワークブートサポートパッケージによって処理される一連の引数は、次のいずれかの方法で指定します。
パッケージの open メソッドに渡される引数として
NVRAM 変数 network-boot-arguments 内に指定する引数として
network-boot-arguments 内に指定された引数は、パッケージの open メソッドに引数が 1 つも渡されなかった場合にのみ処理されます。
引数の値
protocol には、使用するアドレス検索プロトコルを指定します。rarp、dhcp のいずれかを指定できます。
このドキュメントで定められた新しい構文とスタイルを使って他の構成パラメータが指定されていた場合、protocol パラメータが指定されていなければ、手動の構成を意味します。
他の構成パラメータが 1 つも指定されていない場合や、他の構成パラメータが現在サポートされている位置に基づくパラメータ構文を使って指定されていた場合、protocol パラメータを指定しなければ、ネットワークブートサポートパッケージは、プラットフォーム固有のデフォルトのアドレス検索プロトコルを使用することになります。
手動構成を行う場合、IP アドレス、ブートファイル名、ブートファイルイメージの提供元サーバーのアドレスの各情報を、クライアントに提供する必要があります。また、ネットワークの構成によっては、subnet-mask と router-ip も指定する必要があります。
protocol 引数が指定されなかった場合、ネットワークブートサポートパッケージは、プラットフォーム固有のデフォルトのアドレス検索プロトコルを使用します。
tftp-server は、TFTP を使用する場合、ダウンロードするファイルを提供する TFTP サーバーの IP アドレス (標準 IPv4 のドット区切り 10 進表記) です。
DHCP を使用する場合、その値は、DHCP 応答に指定された TFTP サーバーの値よりも優先されます。
サーバーが引数として指定された場合と DHCP 応答内に指定された場合、TFTP RRQ はサーバーにユニキャストされます。それ以外の場合、TFTP RRQ はブロードキャストされます。
file には、TFTP を使用する場合は TFTP サーバーから読み込むファイルを指定し、HTTP を使用する場合は URL を指定します。ファイル名が URL である場合、すなわち、ファイル名が http: で始まる場合 (大文字小文字の区別あり)、HTTP が使用されます。
RARP と TFTP を使用する場合、このドキュメントで前述したように、デフォルトのファイル名はクライアントの IP アドレスの ASCII 16 進表記になります。
DHCP を使用する場合、この引数は、DHCP 応答に指定されたブートファイル名よりも優先されます。
DHCP と TFTP を使用する場合、デフォルトのファイル名は、root ノードの name プロパティーから自動生成されます。その際、コンマ (,) はピリオド (.) に置き換えられます。
ファイル名をコマンド行から指定する場合、ファイル名にスラッシュ (/) を含めることはできません。
URL の形式については、RFC 2396 で説明されています。HTTP サーバーは、IP アドレス (標準 IPv4 のドット区切り 10 進表記) として指定する必要があります。ポート番号 (省略可能) は、10 進数として指定します。ポートを指定しなかった場合、ポート 80 (10 進) が使用されます。
指定された URL は「安全にエンコードされている」必要があります。というのも、パッケージは、指定された URL にエスケープエンコーディングを適用しないからです。コンマを含む URL は、引用符付きの文字列として指定する必要があります。それ以外の URL は、必ずしも引用符で囲む必要はありません。
host-ip には、クライアントすなわちブート対象システムの、IP アドレス (標準 IPv4 のドット区切り 10 進表記) を指定します。アドレス検索プロトコルとして RARP を使用している場合にこの引数を指定すると、RARP を使用する必要がなくなります。
DHCP を使用している場合に host-ip 引数を指定すると、クライアントは、RFC 2131の「Externally Configured Network Address」で規定されている手順に従うようになります。
router-ip には、直接接続されたネットワーク上にあるルーターの IP アドレス (標準 IPv4のドット区切り 10 進表記) を指定します。このルーターは、ネットワーク通信の最初の接続先として使用されます。この引数を指定した場合、そこで指定されたルーターは、DHCP 応答に指定された推奨ルーターよりも優先されます。
subnet-mask (標準 IPv4 のドット区切り 10 進表記で指定) は、クライアントが存在するネットワークのサブネットマスクです。サブネットマスクが (この引数または DHCP 応答を通じて) 指定されなかった場合、ブート対象クライアントに割り当てられたアドレスに対するネットワーククラス (Class A、B、C のいずれか) に適するデフォルトマスクが使用されます。
client-id には、クライアントの一意に決まる識別子を指定します。DHCP クライアント識別子は、この値に基づいて生成されます。クライアント識別子の指定方法には、次の 2 つがあります。
識別子の ASCII 16 進表現
引用符付きの文字列
したがって、「client-id="openboot"」と「client-id=6f70656e626f6f74」はどちらも、DHCP クライアント識別子 6F70656E626F6F74 を表わします。
コマンド行から指定される識別子には、スラッシュ (/) やスペースを含めることはできません。
DHCP クライアント識別子の最大長は、32 バイト (ASCII 16 進形式を使用する場合は 32 バイトを表す 64 文字) です。後者の形式を使用する場合、識別子を構成する文字数は偶数でなければなりません。有効な文字は、0 ～ 9、a ～ f、A ～ F です。
クライアントが正しく認識されるためには、クライアントが接続されているサブネット上で、クライアント識別子が一意に決まる必要があります。この要件を満足する識別子を選択するのは、システム管理者の役割です。
コマンド行で指定されたクライアント識別子は、任意の DHCP メカニズムを使って指定された識別子よりも優先されます。
hostname (文字列として指定) には、DHCP トランザクション内で使用されるホスト名を指定します。この名前は、ローカルドメイン名で修飾してもしなくてもかまいません。ホスト名の最大長は、255 文字です。
注 - hostname パラメータは、クライアントが、希望するホスト名を DHCP サーバーに提供することが必要なサービス環境で使用できます。クライアントが、希望するホスト名を DHCP サーバーに提供すると、DHCP サーバーは、そのホスト名とクライアントに割り当てられた IP アドレスを、DNS を使って登録します。
http-proxy は、次のようなホストの標準記法を使って指定します。
host [":"" port]
...ここで、host には IP アドレス (標準 IPv4 のドット区切り 10 進表記) を指定し、port (省略可能) には 10 進数を指定します。ポートを指定しなかった場合、ポート 8080 (10 進) が使用されます。
tftp-retries は、TFTP 処理が失敗したとみなされるまでの、最大リトライ回数 (10進で指定) です。デフォルトのリトライ回数は、無限回です。
dhcp-retriesは、DHCP 処理が失敗したとみなされるまでの、最大リトライ回数 (10 進で指定) です。デフォルトのリトライ回数は、無限回です。
x86 システム上では、ブートストラップ手続きは、カーネルのロードと、カーネルの初期化という概念的に異なる 2 つのフェーズからなります。カーネルのロードは、システムボード上の BIOS ROM および周辺装置上の BIOS ROM 拡張機能を使用して、GRUB (GRand Unified Bootloader) 上で実装されます。BIOS は、ハードディスク、DVD、または CD の先頭の物理セクターから開始して GRUB をロードします。ネットワークアダプター上の ROM でサポートされている場合は、BIOS はネットワークサーバーから pxegrub バイナリをダウンロードすることもできます。GRUB は配置されると、メニューにあるコマンドを実行して UNIX カーネルと、カーネルモジュールやデータを含む、事前に構成されたブートアーカイブをロードします。
GRUB によってブートデバイスとして識別されたデバイスに ZFS ストレージプールが含まれている場合は、GRUB メニューを作成するために使用される menu.lst ファイルが、プールのデータセット階層のルートにあるデータセット内で検索されます。 これは、プール自体と同じ名前のデータセットです。プール内にはこのようなデータセットが常に正確に 1 つ存在するため、このデータセットは、menu.lst ファイルなどのプール全体にわたるデータに適しています。システムがブートされたあと、このデータセットは、ルートファイルシステム内の /poolname にマウントされます。
プール内に複数のブート可能データセット (つまり、ルートファイルシステム) が存在することがあります。デフォルトでは、menu.lst ファイル内のファイル名のエントリが解決されるファイルシステムは、そのプールの bootfs プロパティーによって識別されるファイルシステムです (zpool(1M) を参照)。ただし、menu.lst のエントリに bootfs コマンドを含めて、プールの代替データセットを指定することもできます。このように、menu.lst ファイルには、プール内の複数のルートファイルシステムに対応するエントリが含まれている場合があります。
カーネルの初期化は、GRUB がブートアーカイブの読み込みを完了し、UNIX バイナリに制御を渡した時点で開始されます。この時点で、GRUB は非アクティブとなり、ブートデバイスとの入出力はこれ以上発生しません。UNIX オペレーティングシステムは、ルートファイルシステムを初期化し、ブートアーカイブの必要なモジュール内にリンクして、実際のルートデバイスにマウントします。この時点で、カーネルは、ストレージに対する入出力を再開し、さらなるファイルシステムをマウントします (vfstab(4) を参照)。そして、多様なオペレーティングシステムのサービスを開始します (smf(5) を参照)。
Solaris オペレーティングシステムでは、古いブートアーカイブなどの状況から回復するために、現在のブートデバイスからシステムを自動的にリブートできる smf(5) プロパティーがサポートされています。
サービス svc:/system/boot-config:default には、ブール型のプロパティー auto-reboot-safe (デフォルトで false の設定) が含まれます。これを true に設定すると、システムの BIOS およびデフォルトの GRUB メニューエントリの両方が、現在のブートデバイスからブートされるよう設定するための通信が行われます。このプロパティーの値は、svccfg(1M) および svcadm(1M) を使用して変更できます。たとえば、自動リブートを有効にするように auto-reboot-safe を設定するには、次のようにコマンドを入力します。
example# svccfg -s svc:/system/boot-config:default \
setprop config/auto-reboot-safe = trueほとんどのシステムは、現在のブートデバイスから自動的にリブートするように構成されています。ただし、場合によって、不明なオペレーティングシステムへの自動リブートにより、好ましくない結果が生じることがあります。このような場合に auto-reboot-safe プロパティーを使用すると、目的の動作を指定できます。
ブートアーカイブに組み込まれたルートファイルシステムのイメージからブートし、ルートを実際のルートデバイスに再マウントするためには、ブートアーカイブとルートファイルシステムの内容に一貫性が必要です。 そうでない場合は、マシンの正しい動作や整合性を保証できません。
「一貫性がある」という用語は、ルートファイルシステム内のすべてのファイルとモジュールがブートアーカイブ内にも存在し、かつ同一の内容であることを示します。このブート方式では、最初にブートアーカイブを読み取って第 1 段階のルートイメージとしてマウントすることが必要なため、実際のルートファイルシステムと一致させるには、ロード不可能なすべてのカーネルモジュールと、ブートアーカイブの内容に基づいた初期化が必要です。このような一貫性がない場合、システムの実行に際して、リブート前にルートデバイスには適用されたがルートアーカイブではまだ更新されていないカーネルモジュールやパラメータが使用される可能性があります。この不一致のために、システムが不安定になったり、データが損失したりすることがあります。
ルートファイルシステムがマウントされたあと、メモリー内ファイルシステムを放棄する前に、Solaris はこの 2 つのファイルシステムに対する一貫性検証を実行します。不一致が検出された場合、Solaris は通常のブートシーケンスを中断し、フェイルセーフモードにフォールバックします。この状態を修正するには、管理者が次の 2 つの手順のうちの 1 つを実行する必要があります。推奨される手順は、フェイルセーフアーカイブにリブートし、ブートアーカイブを再構築するこことです。これにより、既知のカーネルがブートされ、アーカイブの再構築処理に対して機能することが保証されます。あるいは、この不一致によって正しいシステム動作が損なわれることがない場合、管理者は、一貫性のないブートアーカイブのサービス状態をクリアーし、システムの動作を続行することを選択できます。svcadm(1M) を参照してください。
ブートアーカイブサービスがクリアーされ、システムの動作が続行された場合 (上の 2 番目の選択)、システムは、ルートファイルシステムに関して期限が切れたロード不可能なカーネルドライバまたはその他のモジュールを使用して実行される可能性があります。そのため、正しいシステム動作が損なわれることがあります。
ブートアーカイブの一貫性を保証するために、reboot(1M) や shutdown(1M) によって開始される通常のシステムシャットダウン処理では、umountall(1M) マイルストーンの完了時にブートアーカイブへの更新をチェックし、適用します。
umountall サービスが完了したあとにブートアーカイブに含める必要のあるカーネルファイル、ドライバ、モジュール、またはドライバ構成ファイルになんらかの更新が発生すると、次回のブート中にブートアーカイブの一貫性検査は失敗します。この事態を回避するために、常にマシンをクリーンな状態で停止することをお勧めします。
umountall サービスの完了後にカーネルへの更新が必要な場合、管理者は、次の呼び出しによってアーカイブを再構築することを選択できます。
# bootadm update-archive
フェイルセーフアーカイブを使用すると、保守またはトラブルシューティングのために、マシンを任意の時点でブートできます。フェイルセーフブートアーカイブは、ミニルートアーカイブをソースとしてマシンにインストールされます。フェイルセーフアーカイブをブートすると、マシンは、メモリー内ファイルシステムをルートデバイスとして使用してブートされます。
SPARCSPARC フェイルセーフアーカイブは次のとおりです。
/platform/`uname -i`/failsafe
...また、次のようにブートできます。
ok boot [device-specifier] -F failsafe
ユーザーが特定の ZFS ブート可能データセットからのフェイルセーフアーカイブのブートを希望する場合は、これを次のように実行できます。
ok boot [device-specifier] -Z dataset -F failsafex86
x86 フェイルセーフアーカイブは次のとおりです。
/boot/x86.miniroot-safe
...また、GRUB メニューから Solaris フェイルセーフの項目を選択することによってブートできます。
次の SPARC オプションがサポートされています。
boot プログラムはこのフラグを問い合わせと解釈し、スタンドアロンプログラムの名前を要求します。'-a' フラグはその後、スタンドアロンプログラムに渡されます。
default-file を明示的に指定します。一部のシステムでは、なにも指定されていない場合、boot は動的デフォルトファイルを選択します。このオプションを使用すると、default-file を明示的に設定できます。kmdb(1) をブートする場合に便利です。これは、kmdb がデフォルトで、boot プログラムによってエクスポートされたデフォルトファイルを読み込むためです。
名前付きオブジェクトを使用してブートします。このオブジェクトは、ELF 実行可能ファイル、またはブートブロックを含むブート可能なオブジェクトのどちらかである必要があります。主に、フェイルセーフまたは wanboot ブートアーカイブのブートに使用します。
ZFS プール内のブート可能データセットを一覧表示します。リスト内のいずれかのブート可能データセットを選択できます。そのあと、そのデータセットをブートするための詳細な手順が表示されます。その手順に従って、選択したデータセットをブートします。 このオプションは、ブートデバイスに ZFS ストレージプールが含まれている場合にのみサポートされます。
詳細なデバッグ情報を表示します。
boot プログラムはすべての boot-flags を file に渡します。これらの引数は、boot では解釈されません。デフォルトのスタンドアロンプログラムで使用できるオプションについては kernel(1M) および kmdb(1) のマニュアルページを参照してください。
boot プログラムはすべての client-program-args を file に渡します。これらの引数は、boot では解釈されません。
ブートするスタンドアロンプログラムの名前。boot コマンド行または boot-file NVRAM 変数でファイル名を明示的に指定しないと、boot は適切なデフォルトファイル名を選択します。
OpenBoot PROM 指定を行います。たとえば、Desktop SPARC ベースのシステム上で /sbus/esp@0,800000/sd@3,0:a を指定した場合は、スロット 0 の esp ホストアダプタで、SCSI バス上の lun0 、ターゲット 3 の SCSI ディスク (sd) を意味します。
指定した ZFS データセット内のルートファイルシステムからブートします。
次の x86 オプションがサポートされています。
カーネルに渡される 1 つ以上の属性値ペア。複数の設定値ペアはコンマで区切られる必要があります。このオプションの使用方法は、次のコマンドと同様です。 eeprom prop=val設定情報とその有効な値については、 eeprom(1M) を参照してください。
このメニューエントリに対応するルートファイルシステムが ZFS データセットである場合は、メニューエントリに次のオプションを追加する必要があります。
-B $ZFS-BOOTFS
boot プログラムはすべての boot-args を file に渡します。これらの引数は、boot では解釈されません。カーネルで使用できるオプションについては、kernel(1M) および kmdb(1) を参照してください。
特に指定しないかぎり、x86 システムでは /platform/i86pc/kernel/amd64/unix がブートされます。
PC 互換マシンの電源を投入すると、BIOS ROM のシステムファームウェアが電源投入時自己診断テスト (POST) を実行し、周辺ボード上の ROM の BIOS 拡張機能を実行し、ソフトウェア割り込み INT 19h のブートストラップをブートします。INT 19h のハンドラは通常、標準の PC 互換ブートを実行します。その場合、1 番目のハードディスクから先頭物理セクターの読み取りを試みます。次にプロセッサは、メモリー内でこのセクターイメージの先頭バイトにジャンプします。
ディスクメディアの先頭セクターにはマスターブートブロック (GRUB ステージ 1) があります。ステージ 1 は GRUB ステージ 2 をロードします。この時点で GRUB は準備が完全に整います。GRUB は、メニューファイル (/boot/grub/menu.lst) を読み込み、実行します。同様のシーケンスが DVD あるいは、CD ブートでも発生します。しかし、マスターブートブロックの位置と内容は El Torito 仕様で規定されています。El Torito 準拠のブートでも、strap.com が読み込まれ、それが次に boot.bin が読み込まれます。
ハードディスクの最初のセクターには、マスターブートブロックがあり、そのブロックにはマスターブートプログラムと FDISK テーブルが含まれており、PC プログラムがそのテーブルを管理しています。マスターブートは、 FDISK テーブルの中のアクティブパーティションを探し、その先頭セクター (GRUB ステージ 1 ) をロードして、メモリー内の先頭バイトにジャンプします。ハードディスクからの標準の PC 互換ブート処理はこれで完了します。GRUB ステージ 1 がマスターブートブロック上にインストールされると ( installgrub(1M) の -m を参照)、ステージ 2 が、アクティブパーティションかどうかにはかかわらず Solaris FDISK パーティションから直接ロードされます。
Solaris ソフトウェア用 x86 FDISK のパーティションは、1 シリンダのブートスライスから始まり、これは、GRUB のステージ 1 を先頭セクターに含んでいます。そして、第 2 および第 3 のセクターは、標準 Solaris ディスクラベルおよびボリューム構成テーブル (VTOC) を含んでいます。そして、第 50 とその後続セクターは、GRUB のステージ 2 を含んでいます。第 4 から 第 49 までのセクターには、Solaris の古いバージョンのブートブロックが含まれている可能性があります。これによって、同じ FDISK の中に、複数の Solaris リリースを同時に存在させることが可能になります。Solaris ソフトウェア用 FDISK パーティションがアクティブパーティションの場合、マスターブートプログラム (mboot) は、先頭セクターにあるパーティションブートプログラムをメモリーの中に読み込み、そこへジャンプします。次に GRUB ステージ 2 プログラムをメモリーに読み込み、そこへジャンプします。GRUB メニューが表示されると、ユーザーは異なるパーティション、異なるディスク、あるいは 可能であればネットワークからオペレーティングシステムをブートできるよう選択できます。
Intel の Preboot eXecution Environment (PXE) 規格が、ネットワークブートのためにサポートされています。PXE を使用してネットワークからのブートを行う場合には、システムあるいはネットワークアダプタの BIOS が DHCP を使用してブートサーバ上のネットワークブートストラッププログラム (pxegrub) を見つけ、Trivial File Transfer Protocol (TFTP) を使用してそのプログラムを読み込みます。BIOS が、メモリ上の先頭バイトにジャンプすることで、pxegrub を実行します。pxegrub は、メニューファイルをダウンロードし、ユーザーにその項目を表示します。
カーネルの開始処理は、カーネルのロード処理に依存しません。カーネルが開始している間、コンソール入出力は、console プロパティーで指定されたデバイスで行われます。
UFS からブートする場合、ルートデバイスは bootpath プロパティーで指定され、ルートファイルシステムの種類は fstype プロパティーで指定されます。これらのプロパティーは、Solaris インストールおよびアップグレード処理で/boot/solaris/bootenv.rc の中に設定されるべきです。そして、前述のように (eeprom(1M) を参照) -B で上書きされます。
ZFS からブートする場合、ルートデバイスは、GRUB メニューエントリ内の kernel または module のどちらかの行にある -B $ZFS-BOOTFS パラメータが指定するブートパラメータで指定されます。この値は、-B オプションで指定されるすべてのパラメータと同様に、GRUB によってカーネルに渡されます。
コンソールプロパティーが存在しない場合、コンソールの入出力は、デフォルトで screen と keyboard になります。ルートデバイスはデフォルトで ramdisk になり、ファイルシステムはデフォルトで ufs になります。
例 1 対話モードでシングルユーザーとしてデフォルトのカーネルをブートする
対話モードでシングルユーザーとしてデフォルトのカーネルをブートするには、ok プロンプトで次のいずれかを入力します。
boot -as boot disk3 -as
例 2 WANブートに対応した PROM によるネットワークブート
さまざまな boot コマンド行呼び出し間の微妙な違いを示すために、ここでは network-boot-arguments が設定されており、以下のコマンドのように net に対してデバイス別名が設定されているものとします。
次のコマンドでは、デバイス別名内のデバイス引数が、デバイスドライバによって処理されます。ネットワークブートサポートパッケージは、network-boot-arguments 内の引数を処理します。
boot net
次のコマンドでは、デバイス引数なし、とみなされます。ネットワークブートサポートパッケージは、network-boot-arguments 内の引数を処理します。
boot net:
次のコマンドでは、デバイス引数なし、とみなされます。rarp は唯一のネットワークブートサポートパッケージ引数です。network-boot-arguments は無視されます。
boot net:rarp
次のコマンドでは、指定されたデバイス引数が処理されます。ネットワークブートサポートパッケージは、network-boot-arguments 内の引数を処理します。
boot net:speed=100,duplex=full
例 3 以前の PROM における wanboot の使用
次のコマンドでは、DVD または CD から wanboot バイナリが読み込まれます。読み込まれた wanboot は、DHCP の実行時にコマンドインタプリタをブートし、鍵やその他の必要な構成情報をユーザーが入力できるようにします。
boot cdrom -F wanboot -o dhcp,prompt
例 4 対話モードでシングルユーザーとしてデフォルトのカーネルをブートする
シングルユーザー状態の対話モードでデフォルトのカーネルをブートするには、コマンド行で GRUB を次のように編集します。
kernel /platform/i86pc/kernel/amd64/unix -as
initdefault 状態が指定されているテーブル
initdefault 状態にシステムを移行するプログラム
システムをブートするデフォルトのプログラム。
ブートに関連するファイルが置かれているディレクトリ。
GRUB によって表示されるブート可能なオペレーティングシステムのメニュー。/rpool は共通する規約です。パス名は、インストーラの機能に応じて構成可能です。
システムをブートするデフォルトのプログラム。
kmdb(1), uname(1), bootadm(1M), eeprom(1M), init(1M), installboot(1M), kernel(1M), monitor(1M), shutdown(1M), svcadm(1M), svccfg(1M), umountall(1M), zpool(1M), uadmin(2), bootparams(4), inittab(4), vfstab(4), wanboot.conf(4), attributes(5), filesystem(5), smf(5)
RFC 903, A Reverse Address Resolution Protocol, http://www.ietf.org/rfc/rfc903.txt
RFC 2131, Dynamic Host Configuration Protocol, http://www.ietf.org/rfc/rfc2131.txt
RFC 2132, DHCP Options and BOOTP Vendor Extensions, http://www.ietf.org/rfc/rfc2132.txt
RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax, http://www.ietf.org/rfc/rfc2396.txt
『Sun ハードウェアマニュアル』
『OpenBoot Command Reference Manual』
boot ユーティリティは、ブート可能プログラムとして使用できるファイルかどうか判別できません。ブート不可能なファイルをブートするように要求された場合、boot ユーティリティはそのファイルをロードし、そのファイルに制御を渡します。その場合の結果は予測できません。
platform-name を調べるには、uname(1) の -i オプションを使用します。hardware-class-name を調べるには、uname(1) の -m オプションを使用します。
現在のリリースの Solaris オペレーティングシステムは、UltraSPARC-I CPU を搭載するマシンをサポートしません。
|