マルチブートの仕方(その他のOS編)

2001/10/13
目次
  1. プロローグ
  2. Windows初級編
  3. Linux初級編
  4. 機能編
  5. Windows中級編
  6. Linux中級編
  7. その他のOS編
  8. フリーツール編
  9. 市販ツール編
  10. 裏技編
  11. 特別編
  12. 特殊環境編
  13. 究極編
  14. 豆知識編

チェーンロードで殆どのOSが起動可能

 後で紹介する多くのブートローダの起動可能なOSを見ると、実に多くのOSに対応しているのに驚くかもしれない。さぞ作者はいろいろなOSに対応するのに苦労しただろうと思われるだろう。しかし実際は各OSのためにブートローダが特別な処理を追加するということは、特殊な起動方法(第2ハードディスク以降からの起動や、アクティブ設定をしないで起動するなど)に対応する場合を除いて殆どない。ローダの起動可能OSに列挙されているのは、単に動作(起動)確認を行ったOSが書かれているだけだろう。

 これは、ブートローダとしては、IBM、Microsoftオリジナルのブートストラップローダの機能であるチェーンロードの機能さえ備えていれば(これを備えていないブートローダなどないと思うが)、殆どのPC/AT互換機上のOSを起動することができるからである。では、どうしてチェーンロードの機能だけでそれが可能なのだろうか。

 ブートの仕組みで説明しているブートプロセスは、PC/AT互換機の一般仕様であると言及している。実際はMS-DOSのものが標準だが、IBMの技術書にも正式に記述されている正規の標準プロセスである。従って本来、あるOSがPC/AT互換機に移植された場合、また新たにPC/AT互換機に載るOSとして設計する場合、ブートプロセスもこれに準拠すべきとされている。

 各OSが、PC/AT互換機のブートプロセスに準拠するためのポイントは次の点だ。

  1. PC/AT互換機標準のMS-DOSパーティションの概念に対応すること。
  2. パーティションの先頭セクター(ブートセクター)にOSのブートコードを置き、これがMBRのブートコードから実行されることを前提にブートプロセスを設計すること。

 以上の2点だけ守れば、PC/AT互換機のブートプロセスに準拠したことになる。

 ただし、別のアーキテクチャ上で発展してきたあるOSをPC/AT互換機に移植するにあたり、開発者が最も苦労するのは、Intel CPUのx86プロセッサーに対応することだろう。これをしなければ、PC上でそのOSは絶対に動かないからだ。しかしMS-DOSパーティションへの対応は技術的には必須ではない。他のOSとの同居ということを一切考慮しないのなら、そのOS独自のパーティションの概念を持ち込んでも、基本的には問題ない。最低限、ハードディスクの先頭セクター(PC/AT互換機標準の所謂MBR)が、BIOSから最初に起動されるという、PC/AT互換機のBIOSの仕様にだけ準拠していれば、そのあとのプロセスは独自に設計できる。よって、中にはそのOSの独自のパーティションの概念がどうしてもMS-DOSパーティションと相容れないため、PC/AT互換機のブートプロセスに準拠していないOSもあるかもしれない。ただし私はそういうOSが何なのかは知らない。もしかしたらそんなOSは無いかもしれない。

 もっとも上記のようなOSは、あったとしても非常に特殊で、殆ど無視しても構わないだろう。従って殆どのOSは、特別なことさえ考えなければ、通常のブートローダで起動ができるのだと、考えて頂いて結構だと思う。

 しかしその「特別なこと」とはどういったことだろうか? OSによって様々だが、次の点が代表的な問題点と言える。

  1. 一つのハードディスクにそのOSの複数のバージョンを同居させる。
  2. 8GB以降にブートパーティションを置く。
  3. 第2ハードディスク以降にそのOSをインストールする。
  4. 論理領域にそのOSをインストールする。

 上記の4点さえ考えなければ、殆どのOSで問題ないと言えるだろう。特に3番と4番は、ここまでのページで説明してきたMicrosoftのOSやLinuxでも鬼門だったのはご理解頂けているはずである。2番もバージョンが古い場合は気をつける必要がある。

 とは言っても、OSやそのバージョンによっては上記問題が全くなかったり、ちょっとした注意でクリアできるものもある。逆に他にも注意しなければならない点があるものもあるだろう。MicrosoftのOSやLinuxについては散々述べてきたが、このページでは私の分かる範囲でその他のOSにおける問題点を明らかにしていきたいと思う。

 


FreeBSD

 FreeBSDはその名の通り、UNIX-OSの一つの大きなグループであるBSD UNIXの一つである。このBSD UNIXは独自のパーティションの概念を持っている。FreeBSDでは、PC/AT互換機に載せるにあたり、いったいどのようにして、このBSDパーティションの概念とDOSパーティションの概念を融合したのだろうか。

 FreeBSDでは、結局DOSパーティション(PC/AT互換機の標準のパーティション概念、UNIXの世界ではFDISKパーティションと一般的に呼ぶので、以後ここではこう呼ぶ)の一つの基本領域(Primary Partition)の中にBSDの世界を突っ込むということで、この融合をはかっている。つまり一つの基本領域の中に、更にBSDのパーティションが存在するのである。FDISKパーティションでいうところの拡張領域の中に論理領域があるのと、イメージ的には似ていると言えるだろう。

 そのため、FreeBSDでは、FDISKパーティションの基本領域のことをディスクスライス(disk slice)、または単にスライスと呼んで、BSDパーティションと区別している。FreeBSDでパーティションと呼ばれるのは、あくまで基本領域(FreeBSDで言うところのスライス)内に展開されたBSDパーティションのことを指す。BSDパーティションは7つまで作成することが可能である。

 FreeBSDの世界を包含することになるスライスは、FDISKパーティションから見るとパーティションタイプ0xA5の一つの基本領域だ。BSDパーティションは、このスライスの第2セクターにあるディスクラベルと呼ばれるところで管理している。FDISKパーティションでいうところのMBR内のパーティションテーブルにあたるものである。パーティションは前述のように7つまで作成できるのだが、エントリは8つある。一つは予約されているので7つまでしか使えない。

 こうしたパーティションの概念を踏まえて、FreeBSDのブートシーケンスを見てみよう。以下に概念図を示す。

[FreeBSDのブートシーケンス]
Boot Magicを利用した場合の起動シーケンスイメージ

 MBRに存在するboot0FreeBSD独自の汎用ブートローダだ。以前FreeBSDでは汎用ブートローダとしてbooteasyという名前のローダを使っていたが、こちらはDOSから導入するようになっていたため、FreeBSD上からメンテができないので不便だということで、全く別ものとしてboot0が開発された。これは汎用ということで、簡単なユーザインターフェースを備えており、他のOSのあるFDISK基本パーティションを選択してチェーンロードすることも可能だが、FreeBSD上から作成したり、設定を変更したりすることが可能である。機能的には非常に単純なものだが、一応boot0になってからLBAにも対応しており、FreeBSDスライスが8GB以降にあった場合でも起動することが可能だ。またMBRだけには収まっておらず、MBR後続セクターも利用している、比較的サイズの大きなローダである。

 もっともboot0はFreeBSDとしても必須のものではなく、MBRに置くローダは、IBM、Microsoftオリジナルのブートストラップローダでも構わない。その場合当然FreeBSDのスライスはアクティブな基本領域でなければならないだけだ。またここに他のブートローダを置いても一向に構わない。つまりFreeBSDのブートプロセスは完全にPC/AT互換機の一般のブートプロセスに準拠した作りになっている。

 PC/AT互換機のブートプロセスに準拠するには、前述のように、次に基本領域の先頭セクター(ブートセクター)にOSのブートコードを置かねばならない訳だが、それに相当するのがboot1である。これは次のboot2をロード、実行するだけのboot0よりも単純なプログラムだ。

 boot1から実行されるboot2は、ディスクラベルを含む、8kバイト程度のサイズ(厳密には、boot2はその8kバイトの先頭セクターを指し、続く1セクターがディスクラベルで、残りはBTXと呼ばれるプログラムから構成されている)があるので、ここでBSDパーティションとファイルシステムの理解が行われる。また簡単なユーザインターフェースも持っており、ここからカーネルをユーザが指定して、ロードすることも可能である。

 しかし現在はboot2は通常、カーネルロードは行わず、更にファイルシステム内に存在するloaderを呼び出す。boot2は1セクターという制約はないものの、ファイルシステム外に存在しているため、コードサイズには自ずと限界がある。そこで、もやはサイズの制限のないファイルシステム内に置いたloaderに制御を移すことにより、より多機能なカーネルロードを行えるようにしてある。

 loaderは通常ルートに置かれるが、当然ユーザインターフェースを持っており、柔軟で本格的なカーネルロード機能を提供する。

 以上が大まかなFreeBSDのブートシーケンスだ。気がつかれた方も多いと思うが、このFreeBSDのブートローダは非常に優れたもので、特にboot2の時点でファイルシステムを理解して、その後動作するため、ジオメトリの変化に非常に強くなっている。実際これをGRUBが模倣している。LILOがこの手法を取り入れたら、どんなにいいか知れない。

 
 さて、このFreeBSDのブートシーケンスを踏まえて、マルチブート環境構築の注意点の話に進もう。

 まずFreeBSDのスライスはFDISKパーティションの基本領域にしか設定できない。従って論理領域を利用することはできないので、FreeBSDをインストールするには、必ず一つの基本領域を用意する必要がある。2.2.8R以降ならLBA対応しているので、8GB以降にスライスを置くことが可能だが、それ以前のバージョンの場合、8GB以内にスライスを作成する必要がある。現在のようなローダの仕組みが確立したのも2.2.8頃である。

 次に、一つのハードディスクに複数のスライスを用意して、複数のバージョンのFreeBSDをインストールする場合、少し注意が必要だ。3.1R以降ならば問題ないのだが、これより前のバージョンの場合、boot1がboot2を探すにあたり、MSDOSパーティションテーブルのアクティブフラグを見ずに、FreeBSDのパーティションタイプ(システム標識)である0xA5だけを頼りに、先頭のパーティションから探す。そして一番初めに見つかった0xA5の領域からboot2を読もうとする。つまり常に(パーティションテーブルの位置的に)一番前のスライスのものしかブートできない訳である。

 従って、一つのハードディスクに3.1Rより古いバージョンを複数インストールすることはできない。3.1R以降のバージョンとなら複数インストールが可能だが、その場合でも、3.1Rより古いバージョンを、3.1R以降のバージョンよりも前のスライスにインストールする必要がある。これを回避する方法が、Hack to FreeBSD Boot programに記載されているので、挑戦できる人は、試みてもいいだろう。

 もっとも上記のように3.1R以降でも、boot1はパーティションタイプが0xA5でかつアクティブな領域のboot2を探すから、起動スライスは必ずアクティブに設定する必要があるので、気をつけてほしい。

  
 次に、Linuxと同居する場合の注意である。LinuxはFDISKパーティションの拡張領域を認識すると共に、BSDパーティションも認識することができる。LinuxのfdiskではBSDパーティションを作成することも可能だ。LinuxからはBSDパーティションをFDISKパーティションやLinux独自の拡張領域と同じように扱う。つまりBSDの各パーティションを一種の論理パーティションとして扱う訳である。

 問題は、各論理領域のデバイススペシャル名だ。Linuxはこれを先頭から順に評価してつけていく。基本領域は/dev/hda1から/dev/hda4と付けるわけだが、論理領域は/dev/hda5を基点に前のパーティションから順番につけていく。FDISKパーティションでは、拡張領域は一つしか作ることが許されていないので、何も問題は起きない。

 しかし、ここでもう一つの拡張領域との言えるFreeBSDスライスが登場するとどうなるだろう。もしFDISK拡張領域が /dev/hda2 で、BSDスライスが、/dev/hda3 である場合、論理領域の後に、BSDパーティションのデバイス名が振られることになる。

 従って、もしも後から拡張領域よりも前にBSD領域を作ると、拡張領域内の論理領域のデバイススペシャル名がずれてしまうことになる。

 更に問題なのは、LinuxではMSDOSやLinux拡張領域はブートのかなり早い段階から(というよりカーネルが読み込まれる前から)意識している(そうでないとそもそもLinuxのルートパーティションを論理領域に置けないので)のだが、BSDパーティションはカーネルが動きだしてから認識する。従ってやはり拡張領域よりも前にBSD領域があると、ブートの過程でころころ論理領域のデバイススペシャル名が変わるという事態になり、ブートに支障をきたすことがある。

 まあ、回避方法がない訳ではないが、余計な苦労をしないで済むようにLinux及び拡張領域と同居する場合は、FreeBSDスライスを拡張領域よりも後ろに作成しておいた方が無難である。

 


NetBSD

 NetBSDも、その名の通り、FreeBSD同様、BSD UNIXの系統となる。FreeBSDやLinuxと違って、非常に多くのアーキテクチャに対応しているのが特徴のOSで、PC/AT互換機(i386版)はその一つに過ぎないという位置付けである。ただPC/AT互換機上で使うぶんには多くの点がFreeBSDと似ているので、マルチブート上の注意についてはFreeBSDと比較しながら説明していこうと思う。

 パーティションの概念はFreeBSD同様、BSDパーティションの概念があり、FDISKパーティションをスライスと呼び、1スライスの中にBSDパーティションを展開する。NetBSDのスライスのパーティションタイプは以前はFreeBSDと同じ0xA5だったが、これと競合することを避けるために、Ver1.3.3から、0xA9になった。

 FreeBSDと同じようにBSDパーティションはディスクラベルで管理しており、このディスクラベルには同様に8つのエントリがある。FreeBSDでも1つは予約されていて実際には7つしかBSDパーティションを使えなかったが、この点NetBSDはより厳しくて、8つのうち、1つはスライス全体、一つはハードディスク全体を指すものとなるので6つが実際にスライス内のパーティションとして使える。

 更に一つはswapとなり、一つはルートになるので本当に自由に使えるのは4つとなる。更に厳しいのは、FreeBSDの場合、ディスクラベルで管理するのはあくまでFreeBSDスライス配下のBSDパーティションだけだが、NetBSDでは他のスライス(FDISKパーティション)、たとえばFATのパーティションなどもディスクラベルの管理下に置かれる。そしてこの管理下のものしかOSから見ることはできない。

 NTFS5もマウントできるのなどの対応の広さもこの仕組みがあだとなって実際は使いずらいものとなっている。そこで、バージョン1.5.1からディスクラベルの管理数が16に増加した。これで自由に使えるものが12個となるので、格段に便利になるはずである。

 ただしこれも「一つのハードディスクにつき」ということなので、複数のハードディスクを利用する場合は、この限りではない。

 FreeBSDとのもう一つの大きな違いは、今のところ、NetBSDスライス(0xA9パーティション)は、一つの物理ハードディスクに一つしか作れないということだ。0xA9パーティションを複数つくること自体は可能なのだが、動作が保証されないようである。

 またNetBSDでは、元々独自のブートローダを持っていなかったようだ。OS-BSが推奨ブートローダだった。逆に言えば、汎用のブートローダで全く問題なく起動ができるということである。Ver 1.4から独自のブートマネージャが用意されたようだが、あまり利用されていないと聞いている。まだ洗練されてないのだろうか。この点はまた調査して報告する。
 


Solaris

 Solarisは、BSDに対抗するUNIXの一方の雄であるSystem V系のOSで、Sun Microsystems社が販売する商用OSだ。もっとも前身のSunOS(といってもSolarisもまだSunOS 5.xなので、正確にはSunOS 4.1.4以前)はBSD系だったので、今でもBSD系の流れを汲む部分はかなりある。長らくRISCチップのSPARC上で動作するOSだったが、Intelプラットフォームにもかなり前に移植された。

[Solarisスプラッシュ画面]

 Solaris8(Solaris2.8、SunOS 5.8)からは、CPU8個まではフリーで使用でき、ソースも公開されたので、今後PC上で遊んでみようという人が増えるかもしれない(Free Solaris 8 バイナリのダウンロードからCDイメージをダウンロードできる)。そんな人々にとって、やはり他のOSとのマルチブートは一つの関心事だろう。まあこんな典型的なサーバOSをマルチブートの1OSとして使うのは、Sunがフリーとした思惑とは大分違うだろうが、それはここでは考えないことにしよう。

 Solarisも他のアーキテクチャで成長してきたため、独自のパーティションの概念があり、FDISKパーティションとの関係は前述のBSD UNIX達と同じである。一つのFDISK基本パーティションの中にSolarisのパーティションを展開する。呼び名も似てるのだが、FreeBSDなどとは逆で、Solarisの内部パーティションをスライスと呼ぶ(ここでも以後これをSolarisスライスと呼ぶ)。FDISKパーティションは、そのままFDISKパーティションと呼んでいる。

 Solarisスライスは、やはりディスクラベルで管理されている。内容についてはあまりよく分からないが、Linuxのfdiskなどでも作れるようだ。内部にSolarisスライスが展開されるFDISKパーティション(以後Solarisパーティションと呼ぶ)のパーティションタイプは0x82である。

 Solarisは独自のブートローダ(Solarisブートマネージャ)を持っている。一応他のOSの起動も可能だが、単なるチェーンロードで複数のハードディスクも扱えないため、マルチブートのツールとしてこれを利用しない方がいいだろう。ただSolarisカーネルローダとしては必須であり、また柔軟なものとなっている。後述する第2ハードディスク以降の起動が自由自在なのは、このローダの柔軟性に負うところが多いだろう。

 Solarisブートマネージャは、ドキュメントらしいドキュメントが見つからないので、私の実験結果から、独断と偏見で説明する。特にそれぞれの名称は私が勝手につけたものだ。

[Solarisブートマネージャのブートシーケンス]

 まず全体構成だが、MBRにインストールされるプリローダとSolarisパーティションのブートセクターにインストールされるプライマリローダ、ディスクラベル以降に配置されるセカンダリローダなどからなっていて、FreeBSDのブートローダと似ている。それぞれFreeBSDローダの、boot0、boot1、boot2に対応する。Solarisブートマネージャのプリローダにあたる、FreeBSDブートローダのboot0は、それ自身対話型になっていて、ここから他のOSを起動できたが、Solarisブートマネージャのプリローダは、対話型になっておらず、単にアクティブな基本領域のブートセクターをロードするだけの動作を行う。IBMのブートストラップローダと殆ど同じ動作だね。

 プライマリローダ対話型になっていて、パーティションの選択が可能である。ここでSolaris以外のパーティションを選択した場合はそのパーティションをアクティブにした上で、再びMBR(MBRにプリローダがあればそれ)に制御を戻すという、ちょっと変わった動作になっている。だからMBRに別のブートローダを置いておくと、またそのローダの画面が出るので、最初はちょっと不可解に思うかもしれない。

 もっとも他の領域をアクティブにするといっても、実際にアクティブにするのはメモリ上のパーティションテーブルだけで、実際のハードディスク上のMBRのパーティションテーブルは変えない。このことはMBRにSolarisブートマネージャのプリローダ以外のローダを置く場合に注意が必要な時がある。これについては後述する。

 プライマリローダの選択画面で、Solarisパーティションを選択するとセンカンダリローダが起動される。セカンダリローダも対話型になっているが、ここまで来るともはや他のOS(パーティション)の起動はできなくなる。Solarisカーネルの起動のためのオプション指定などのために対話型になっているのだ。

 プリローダは上記のようなものなので、他のLBA対応ブートローダで代用可能である。というより代用した方がいいだろう。これらのローダでプライマリローダをロードすれば、以降このローダやセカンダリローダがSolarisカーネルをロードしてくれる。ローダが対話型になっていて、それが煩わしいと思うが、タイムアウト値を短くすればいいだろう。ただしこのタイムアウト値を変更する方法は分からない。調査中である。

 しかし前述のようにSolarisブートマネージャのプライマリローダから他の領域を選択した場合、再びMBRのローダに制御が戻ってくる訳だが、この時メモリ上だけプライマリローダで選択したパーティションがアクティブになっている。実際のハードディスク上のMBRでは、依然Solarisパーティションがアクティブなままだ。ローダによっては、自分をロードしてくれたプログラムから引き継がれたメモリ上の値ではなく、実際のハードディスク上にデータを見に行くものがあり(こういう動作は本来すべきでないが、MSのローダなどはよくやること)、誤動作の元になる。基本的にSolarisブートマネージャは、Solarisカーネルのロードに徹し、他の領域の起動には使わない方がいいだろう。

 またSolaris8から、ミニルートと呼ばれるブート用の基本パーティション(ID 0xBE)が作成できて、そこにローダを置くようにすることができる。こんな構成の何がうれしいのか分からないが、単独インストールならこんなものが必要な訳がないので、何らかのマルチブート環境への配慮だと考えられる。しかしこんな領域が無くても全くマルチブート上困ることはないし、貴重な基本領域の消費は、かえってマルチ環境にとって不便を強いる訳で、ミニルートなど邪魔者以外の何者でもない。従ってこの構成については検証もしない。
 

 Solarisのマルチブート上の注意点、特徴は以下となる。バージョンよって当然違うのだが、基本的にSolaris8での話をする。それぞれ過去のバージョンについてもわかっているものは言及する。

  1. インストールはInteractiveで行うべき。
  2. 通常一つのハードディスクに複数のSolarisをインストールできない。
  3. Linux swapとパーティションタイプが同じなので、Linuxとの同居の時は注意。
  4. LBA対応だが、Solarisパーティションを8GB以降に配置不能。
  5. 第2ハードディスク以降からの起動も自由自在。
  6. Solarisパーティションはアクティブでなければならない。

 Solaris8の場合、マルチブートを行うなら、インストールは必ずInteractiveモードで行うべきである。Web Startモードで行うと、勝手に前述のミニルートが作られる。前述のようにミニルートは邪魔なので、Interactiveモードでインストールを行って、自分でパーティションを作成しよう。

 尚、Solaris8の「Installation CD」ではWeb Startモードのインストールしかできない。2枚目の「Software 1 of 2 CD」が第2のインストールCDとなっており、こちらのインストーラの場合、Interactiveモードのインストールが可能だ(逆にこのCDではWeb Startモードはできない)。もっともマルチブートを行わない場合でも、また過去のバージョンでもWeb Startモードは何かと問題があるようで、インストールはInteractiveモードを使うというのがSolarisユーザの間では常識のようである。
 

 次にSolarisを一つのハードディスクに複数インストールすることは通常はできない。ブートマネージャが最初に見つけた(パーティションテーブルの一番先頭の)0x82のパーティションからカーネルを読んでしまうためだろう。アクティブフラグを操作しても改善されなかった。勿論起動時に他のSolarisパーティションの隠して(他のIDに変えて)しまえばいいのだが、MSのパーティションと違い、ID 0x82に対する単純な隠し機能を備えたブートローダは無いようである。

 MBMなら区画エディタを起動してIDを変更した上で、目的のSolarisパーティションを起動すればいいのだが、ちと面倒だね。これが面倒くさくないという人なら、この方法でとりあえず一つのハードディスクに複数置くことができる。ただし少々古いハードディスクを利用している人は、ID変更に使用するMBMのバージョンに気をつけてほしい。必ずVersion0.35b以上を使おう。これより前のバージョンの場合、古いハードディスクに対してSolarisインストーラが不正なパーティションアドレスを生成する場合があり、これをMBMが、ID変更時に修正してしまう。MBMからすると修正だが、Solarisから見ると、それは即ち破壊なので起動不能になる。V0.35bからはID変更時にはアドレスには一切触れない仕様になったので、この破壊を免れる。尚、先頭のパーティションのSolarisを起動するときは、後ろのパーティションのSolarisを隠す必要はない。後ろのパーティションのカーネルをわざわざ読みにいくようなことはしないからである。
 

 次に、SolarisパーティションのIDが0x82であるため、Linuxとの同居において、そのswap領域と同じIDであることから、いくつかの注意を必要とする。問題が起こるのは、それぞれのインストール時だ。どちらを先にインストールするにしても、既存の0x82領域を隠すことが肝要である。

 Solarisインストーラは、既存の0x82領域を勝手にSolarisパーティションにしてしまうので、必ず既存のLinux Swapパーティションは隠しておかねばならない。隠すというのは、適当に別のIDに一時的にしておくことだ。Linux側を拡張領域に入れてしまうというものいい手だ。Solaris側では、Solarisパーティションはあくまで基本領域として作ろうとするので、拡張領域内の0x82論理領域など無視する。

 逆にLinuxインストール時は、ディストリビューションのインストーラによって違うのだが、やはり勝手に既存の0x82領域をswap領域として使って、フォーマットしてしまう場合があるので、Solarisパーティションを隠しておいた方が無難である。System CommanderはLinux native(0x83)を起動する時に限り、特定の0x82の領域を隠す機能を備えている。また前述のMBM V0.35b以上なら、その区画エディタがこれらの操作に使えるだろう。

 インストールさえしのげれば起動時は問題ない。Linuxはインストール時に設定した以外の0x82領域を勝手にswap領域にしてしまうことはない。Solarisの場合もLinux swapにはSolarisカーネルがないので、ここから起動しようとはしない。
 
 
 さて次のLBA対応だがSolaris7(Solaris2.7、SunOS 5.7)からブートマネージャが対応したのだが、依然Solarisパーティションをハードディスクの先頭から8GB以降に置くことができない。
 
 
 次に、Solarisは第1ハードディスク以外のハードディスクへのインストールについて非常に柔軟だ。第2、第3ハードディスクにインストールすることは勿論、インストール時は第1ハードディスクだった場合に、後から第2ハードディスク以降に移動した場合でも起動することができる(後述するが、むしろインストールは一旦第1ハードディスクで行った方が便利だ)。MSのOSの場合、非常に苦労したことであり、Linuxでもインストール後の変更には柔軟に対応できなかったので、ある意味驚きだった。これについてはSolaris2.6でも同様である。

 ただし、Solarisが用意している第2ハードディスク以降用の手順でインストールする場合は、専用のブートフロッピーディスクが必要だ。これはSolarisブートマネージャのステージ1では他のハードディスクのPBRをロードできないためだと考えられる。しかしこれだと起動にはいつもブートフロッピーディスクが必要となり、非常に不便である。

 そこであえてSolarisが用意した第2ハードディスク以降用の手順は用いずに、一旦インストールしたいハードディスクを第1ハードディスクとして接続して、通常のインストールを行う。その後第2ハードディスク以降に接続を変えて、MBRにMBMなどの複数ハードディスクに対応したブートローダを導入して、Solarisパーティションを選択すれば、簡単に起動することができるのでこの手法を用いた方が遥かにいいだろう。

 
 最後に、Solarisパーティションのアクティブ属性だが、これは必ずアクティブでなければならない。従って起動に使うブートローダは、アクティブ属性を設定できるものでなければいけない。まあ殆どのブートローダはアクティブ属性設定の機能があるので、通常は殆ど問題ないだろう。ただし、これがため、NTLDRによる起動は通常はできない。環境限定の裏技があるので、次項で解説する。

 


NTLDRによる各OSの起動

 「NTLDRによるNTと98とLinuxのトリプルブート」で扱った、NTLDRによるLinuxの起動だが、同ページでもLinux以外にもいろいろなOSが起動できると説明した。実際このページで取り上げているFreeBSDNetBSDも、Linuxと同じ手法で起動可能だ。それはこれらのOSが自分のパーティションがアクティブでなくても構わないが故に実現できるのである。

  NTLDRによる起動は、NTLDRの存在するパーティションが常にアクティブであるということが大前提になるため、当然のごとくアクティブ切り替えの機能を備えていない。もしそんな機能を持っていたら、次回から自分が起動されないので、自己矛盾を起こすことになるからだ。

 Linuxを始め、FreeBSD、NetBSD、BeOSなどは、自分のパーティションがアクティブであることを必ずしも要求しないのでこのような制約のあるNTLDRでも起動が可能な訳だが、FreeBSDの場合は多少注意点がある。

 FreeBSDは、一つのハードディスクに複数インストールする場合、3.1R以降を用いた場合でも、アクティブ属性によっていずれのFreeBSDを起動するか判断すると説明した。アクティブ属性を付与できない場合、常にパーティションテーブル上、上位のFreeBSDしか起動できない。従って、NTLDRによる起動の場合は、一つのハードディスクに複数インストールされたFreeBSDを制御することはできない。

 NetBSDは、そもそも一つにハードディスクに複数インストールすることが通常はできないので特にこのような問題はない。Linuxは全く柔軟なので一切問題ない。

 
 さて、Solarisについてだが、前項ではSolarisパーティションはアクティブである必要があるため、通常はNTLDRによる起動できないと説明した。しかしアクティブ属性は、ハードディスクドライブ単位で設定でき、NTLDRも第1ハードディスクのNTLDRの存在するパーティションさえアクティブなら、第2ハードディスク以降にアクティブな領域が存在しても、影響を受けない。

 そこで、Solarisパーティションを第2ハードディスク以降に置くということが可能なら、NTLDRでもSolarisを起動することが可能だ。インストールはSolarisの項でも説明したように、一旦当該ディスクを第1ハードディスクとして接続して、Solarisをインストールし、Linuxの時と同じようにブートセクター(パーティションブートレコード)をファイルする。最終的に接続を変えて(戻して)、このファイル化したブートセクターをNTLDRに読み込ませるという手法も同様だが、Solarisの場合は、このファイル化したブートセクターに細工が必要である。実際順を追って手順を説明しよう。

 まずは、ブートセクターのファイル化だが、Linuxの時同様にddコマンドにて行う。特に説明は要らないはずだが一応簡単に解説しておこう。

[ddコマンドによるSolarisパーティションブートレコードのファイル化]
  dd  if=/dev/rdsk/c0d0p1  of=sol8.pbr  bs=512  count=1 

 上記例は、Solarisパーティションが、IDEハードディスクの第1基本領域にある場合だ。SCSIハードディスクの場合は、「/dev/rdsk/c0t0d0p1」となる。また第2基本領域の場合は、末尾がp2となる。因みに末尾「p0」MBRを指す。上記例のファイル化はSolaris上での実行だが可能ならどんな方法でも構わない。

 正しくブートレコードをファイル化できたらこれをバイナリエディタでデータの一部を書き換える。BZで中身を見てみよう。

[Solarisパーティションブートレコードのバイナリ編集]

 Solarisパーティションブートレコードには、Solarisの項でも説明したように、Solarisブートマネージャのプライマリローダが居るはずである。この作業は正しくブートセクターをファイル化できたかも確認することにもなる。ブートセクターファイルが上記のようなデータになっているだろうか。最後の方に、プライマリローダがエラー時に出力するエラーメッセージなども見える。これと全然違うものだったら、ファイル化に失敗しているので手順を見直してほしい。

 さて、書き換えだが、第2ハードディスクの場合、先頭の6バイト「EB 04 50 32 2E 30の部分を、B2 81 90 90 90 90に換える。第3ハードディスクの場合は、81と換える部分を82とする。第4ハードディスク以降は同様にその数を増やすだけだ。殆ど場合は、この書き換えでいいはずである。

 ただし、環境によっては、先頭がEB 79 .. .. ..となっている場合もあるようだ。その場合は、B2 81 EB 77 90 90などと変更する。4バイト目の77は、元の79からを引いたものである。必ず元の値からを引いたものにして下さい。つまり元がEB 7C .. ..なら、B2 81 EB 7A .. .. とする訳である。

 このようにして書き換えたSolarisパーティションブートレコードを、後はNTLDRに読み込ませるだけだ。この後の手順は「NTLDRによるNTと98とLinuxのトリプルブート」と同じである。

 
 また、これまで説明した方法とは別にBootPartを使ったNTDLRによるマルチブートでも説明している、BootPartユーティリティを利用しても可能だ。この場合、出来上がったブートファイルを書き換える必要もないから、どちらかというと楽かもしれない。

 BootPartユーティリティの実行は、必ず最終的なハードディスクドライブ接続(第3ハードディスクにするつもりなら第3)にした上で行ってほしい。ハードディスクの接続順序を変更する場合はそれぞれにブートファイルを作成する必要がある。それ以外は特に注意点はない。上記ページの説明通りにトライしてみてほしい。


 尚、Solarisパーティションをアクティブにしておくことは、くれぐれも忘れないでほしい。



OS/2

工事中
 


←前へ(Linux中級編)  次へ(フリーツール編)→

 


目次へ