この節では、Debian のインストールに先立って必要となる ハードウェアの設定について見ていきます。 通常この作業では、システムのファームウェアの設定をチェックし、 場合によってはその設定を変更することになります。 「ファームウェア」は、ハードウェアが利用する中核的なソフトウェアで、 電源投入後のブートプロセスの間に起動される、最も重要なものです。 あなたが使うことになる Debian GNU/Linux の信頼性に影響を与えうる、 既知のハードウェアの諸問題についても、同様に取り扱っていく予定です。
OpenBoot は、 SPARC アーキテクチャのブートに必要となる 基本的な機能を提供するものです。 これは x86 アーキテクチャに置ける BIOS と機能的には似ていますが、 ずっと優れています。 Sun のブート PROM には Forth のインタープリタが組み込まれており、 これを使うと診断を行ったり、簡単なスクリプトを実行したり、 コンピュータに対してさまざまなことが行えます。
ブートプロンプトを呼び出すには、Stop キー (Type 4 キーボードより古いものでは L1 キー、 また PC キーボードアダプタを持っているなら Break キー) を押しながら A キーを押してください。 ブート PROM は ok あるいは > というプロンプトを表示します。 ok というプロンプトの方を好まれる方が多いようです。 古い方のプロンプトが表示された場合は、 n キーを押すと新しい方のプロンプトになります。
OpenBoot を使うと、特定のデバイスから起動したり、 デフォルトのブートデバイスを変更したりできます。 しかしこのためには、OpenBoot におけるデバイスの呼び方について、 ある程度詳しく知っておく必要があります。 これは、項A.4. 「Linux におけるデバイス名」 で説明した Linux におけるデバイスの命名法とはかなり異なっています。 またコマンドも OpenBoot のバージョンによって少々異なります。 OpenBoot に関するより詳細な情報は、 Sun OpenBoot Reference にあります。
新しい版では、たいていの場合 ``floppy'', ``cdrom'', ``net'', ``disk'', ``disk2'' などの OpenBoot デバイスが使えます。 それぞれ文字通りの意味です。 例えば ``net'' デバイスはネットワークからの起動用です。 さらに、デバイス名では特定のディスク・特定のパーティションを 指定することもできます。 例えば第 2 ディスクの第 1 パーティションから起動するには ``disk2:a'' のように指定します。 OpenBoot の完全なデバイス名は、
driver-name@ unit-address: device-arguments |
という形式です。 OpenBoot の古い版では、デバイス名の付け方が若干異なります。 フロッピーデバイスは ``/fd'' となり、 SCSI ディスクデバイスの形式は ``sd(controller, disk-target-id, disk-lun)'' となります。 新しい版の OpenBoot には show-devs というコマンドがあり、 これは現在設定されているデバイスを見るのに便利です。 どの版を使うにせよ、完全な情報は Sun OpenBoot Reference をご覧ください。
特定のデバイスから起動するには、 bootデバイス名 というコマンドを使ってください。 setenv コマンドを使えば、 その動作をデフォルトに設定することができます。 しかし設定する変数名は OpenBoot のリビジョンによって異なります。 OpenBoot 1.x では、 setenv boot-fromデバイス名 というコマンドを使います。 それ以降の版の OpenBoot では setenv boot-deviceデバイス名 というコマンドを使います。 なおこの設定は、Solaris の eeprom コマンドを使ったり、 /proc/openprom/options/ の適当なファイルを変更して 行います。例として Linux からなら
echo disk1:1 >/proc/openprom/options/boot-device |
Solaris なら
eeprom boot-device=disk1:1 |
のようにします。
多くの人たちが、例えば 90 MHz の CPU を 100 MHz で動作させるようなことに挑戦しています。 これはうまくいく時もありますが、温度などの要因に敏感で、 実際にシステムに損傷を与えることもあります。 この文書の著者は、自分のシステムを 1 年間オーバークロックで動作させたことが ありますが、その後カーネルのコンパイル中に gcc が 予期しないシグナル (unexpected signal) で中断するようになってしまいました。 この問題は CPU の速度を普通に戻すことで解決しました。
メモリモジュールの不良 (あるいはデータを改変してしまうその他のハードウェア障害) が起きた場合、最初にやられるのは gcc コンパイラであることが 多いようです。 gcc は膨大なデータ構造を構築し、それを繰り返し使うからです。 このようなデータ構造にエラーが生じると、不正な命令が実行されてしまったり、 存在しないアドレスへのアクセスを発生させたりします。 この結果として、gcc が予期しないシグナルで中断するのです。
Linux カーネルが、搭載されている RAM 容量の検出に失敗することがあります。 この場合の対処については 項5.2. 「ブートパラメータ」 をご覧ください。