マルチブートの仕方(Windows中級編)

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

  Windows初級編ではWindowsNT系とWindows9x系のOSのマルチブートについて説明してきたが、マルチにできるのはWindowsNT系OSの方だけでWindows9x系OS一つしか選択できない。NTLDRによる起動の仕組みとWindows9x系の起動の仕組みを良く理解すればその理由は分かると思うが補足しよう。

[WindowsNT、Windows95のブートシーケンス]
Windows95/98、WindowsNTのデュアルブート

 結局NTLDRが行うWindows9xの起動は迂回してきた起動シーケンスを元に戻すだけで、Windows9xの起動シーケンスの基本は殆ど変えない。DOS IPLはあくまでCドライブのIO.SYSしか読まず、IO.SYSもまたCドライブのMSDOS.SYSしか読まない。NTLDRによるWindows9xの起動もこの部分には一切関与しないため、分岐処理を持たないWindows9xの起動シーケンスを変更、補うことはできないのである。

 では一体どのようにしたらWindows9xのマルチブートが可能なのだろうか。現在私が思いつく方法は以下のものだ。

  1. それぞれを別の基本領域にインストールしてアクティブ領域を切り替えて起動する。

    この方法が最もオーソドックスで、安全で、かつスマートな方法です。どうしてこれによってWindows9xのマルチブートが可能になるかは後ほど説明するが、原理はそれほど厳密に理解しなくても構築自体は難しくはない。
     
    ただしこの方法は各OS毎に基本領域を必要とするため、インストール可能なOS数に限りがある。またMBRに導入し、アクティブ切り替えの可能なブートローダが必要だ。NTLDRにはその機能がないことがNTLDRではWindows9xのマルチブートができない理由の一つでもある。しかしフリーのローダでいくらでもそのような機能を備えているものはあるので、これは大した問題ではないだろう。
     
  2. Multi-FAT機能を利用する。
     
    基本領域の数に限りがあり、どうしても1番が利用できない場合に選択する方法だ。スマートに行うには市販のブートローダが必要なことが難点だが、スマートでなくてもいいのなら私の作ったツールMultiFATユーティリティでも可能である。この方法の詳細はMulti-FAT環境の構築を参照してほしい。このページでは扱わない。
     
  3. フロッピーディスク起動を行う。
     
    まあ、あまりスマートな方法ではないが結構お薦めの方法だったりする。
     
  4. DOS-IPLやIO.SYSを改造する。
     
    詳細は「Windows9xをNTLDRでマルチする」で言及している。ただ原理としては面白い話だが危険であり制約も多く実際に行うのはあまりいい方法とは言えない。
     
  5. IO.SYSなどをいちいちコピーする。
     
    これをやるくらいなら私のMultiFATユーティリティを使った方がましである。私のツールなど信用できないし、基本領域もないし、市販ツールを買う金などないし、IO.SYSを改造する自信もないという方が行う最後の手段だろう。

 このページでは1番のもっともオーソドックスな複数の基本領域を利用する方法を中心に説明する。

 


パーティション構成とドライブレター

 前述したように複数の基本領域を利用する場合はアクティブ領域を切り替える必要があるので、そのような機能のあるブートローダが必ず必要になる。殆どのブートローダはこの機能があるので、好きなものを使うといいだろうがMBMがお薦めだ。ブートローダについては「フリーツール編」以降を参照してほしい。

 早速だがパーティション構成の基本イメージは以下のようになる。

[Windows9xマルチの基本パーティション構成イメージ]

 上記のような構成にした上でMBRにアクティブ領域切り替え機能のあるブートローダを配置して、アクティブ領域を切り替えつつそれぞれのOSを起動し分けることになる。

 たとえば上記の基本領域2にあるWindows95 Bを起動するときはこの領域をアクティブにし、他の領域を非アクティブとして基本領域2のブートセクターをチェーンロードすることでこのOSが起動される。他の基本領域にあるOSの起動も同じ手法だ。

 そして、各OSが起動したときはCドライブがそれぞれのブートセクターがある領域に変わる。これはCドライブとは常に第1ハードディスクのアクティブな基本領域を指すという風にMicrosoftのOSでは決まっているからである。

 アクティブな基本領域がCドライブになるので、DOS-IPLもIO.SYSも次に読むファイルを正しく自分のパーティションのものを読み込む。この構成にすることでWindows9xのマルチブートが可能な理由はたったこれだけだ。

 さて、その構築の話に入る前にどうしても肝に銘じておいてもらいたいことがある。

 「パーティション構成」のページでもまた少し前でも第1ハードディスクのアクティブな基本領域Cドライブになると、私は何度も述べてきた。たぶんしつこいくらい述べているだろうし、またこれからのページでも述べるかもしれない。これはCドライブかそれ以外のドライブであるということはつまりその領域がアクティブな基本領域であるか否かはMicrosoftのOSのブートにとって極めて重要な要素となるからだ。

 これはMBRにあるブートローダはアクティブな基本領域にあるブートセクターしか読まず、またそのブートセクターのIPLもまたアクティブな基本領域のOSローダ(NTLDRやIO.SYS)しか読まない。さらにはIO.SYSなども次のデータ(MSDOS.SYSなど)をアクティブな基本領域からしか読まない。つまりブート系のデータはアクティブな基本領域にある場合にしかその意味を持たないのだ。このことは確り頭に叩き込んでおいてほしい。

 従って、ブートを考えるときにある領域がアクティブな基本領域なのかそれ以外の領域、つまり拡張領域(論理領域)、アクティブでない基本領域なのかといったパーティションの種類の違いは非常に重要である。

 どのようなパーティション構成になっているかはマルチブートにとって成功とトラブル回避の鍵となる。Windows系でもちょっと高度なマルチブートをしようと思うなら、もう一度「パーティション」のページを読んでこのことは確り理解しておいてほしい。

 そしてパーティション構成を表現する上で、極めて重要なのはどのパーティションが基本領域でどのパーティションが拡張領域や論理領域なのか、複数の基本領域がある場合はどのパーティションがアクティブなのかといったパーティションの種類で表現することである。

 多くの人がパーティション構成をCドライブがあって次にDドライブがあってEドライブにどうのといった感じですぐにドライブレターで表現しようとするがこれは非常にナンセンスだ。何度も述べているようにCドライブはアクティブな基本領域と同義なのでいいのだが、その他のドライブについてはドライブレターからはそのパーティションの種類を特定することができない。

 「Eドライブ」だと言ってもその領域が論理領域なのか、基本領域なのか、全く保証できない。第1ハードディスクの第2論理領域かもしれないし、非アクティブ基本領域かもしれない。もしかしたら第3ハードディスクのアクティブな基本領域かもしれないのだ。

 また「ドライブレター」でも詳しく言及しているようにちょっとした物理ドライブ構成の違いで、また前の段落でも述べているようにブートローダによるブートの仕方(どの領域をアクティブとして起動するか)でもドライブレターはころころ変わる概念なのでまったく当てにならない。従ってマルチブートの世界ではパーティション構成をドライブレターで表現することは厳禁だということを肝に銘じておいてほしい。

 ただし前述のように「Cドライブ」だけは特別な意味、響きを持っており、アクティブな基本領域を表現するのに便利なので利用しても構わない。また、私も説明のために表現が簡易で都合がよいので今後も利用する。「Cドライブ=アクティブな基本領域」の図式をもう一度肝に銘じてほしい。

 また、これはドライブレターがどうでもいい情報だということではない。あくまでパーティション構成の表現に利用するのは厳禁だという話だ。あるOSから見て各パーティションが何ドライブになるかは非常に重要な要素となる。Windowsは基本的にインストール時とは違うドライブレターに後で変わると正常に動作しなくなると考えてもいいくらいだ。ドライブレターそのものは常に気にしてマルチブートを構築していく必要がある。

 


Windows9xマルチ構成の構築

 さて、注意点はご理解頂けたと思うが、問題は複数基本領域構成をどのように構築するかだ。

 というのはWindowsのFDISKではそもそも複数の基本領域を作れない。Windowsの基本的な道具だけではどうしてもこの構成を構築することはできない。もっとも複数の基本領域が作れないといっても実際にWindowsのFDISKが作れないのは「複数のMS-DOS基本領域だ。「MS-DOS基本領域」とはFATファイルシステムの基本領域を指す。

 つまりWindowsのFDISKではFAT以外の基本領域は非MS-DOS領域として扱われ、通常の基本領域と見なされないため、既に複数の基本領域があってもそれがFAT以外なら、また別途基本領域を作成することができる。Windows9xマルチ環境はこの性質を利用して構築する。もう一度環境の完成イメージを見てほしい。

[Windows9xマルチの基本パーティション構成イメージ]

 この構成を実際フリーのブートローダのMBMを使って構築する例を説明しよう。

 順序としてはまず最初の基本領域1は最初だから普通にパーティションを作成してインストールできるはずだ。問題は基本領域2の作成だがそのインストールにあたって一旦基本領域1をFAT以外のファイルシステムにしてしまう。

 FAT以外のファイルシステムにするといっても実際の中身をフォーマットし直すということではない。既にWindows95Aもインストールしてあるのだから、そんなことをしなければならないのでは困る。このパーティションの中身は一切触ることなく、MBRに記述されているこの領域のパーティションタイプだけこっそり書き換えてしまうのだ。この時に利用するのが隠しパーティションの機能だ。この機能の詳細は「隠しパーティション」を参照してほしい。

 MBMには区画エディタという便利な機能があるのでこの機能を利用して、基本領域2を作成する前に基本領域1を隠しパーティションにする。市販のブートローダも必ずパーティション操作ツールがついているので、それを使って基本領域1を隠しパーティションにする。

 このようにして基本領域1を隠しパーティションにしておくとWindowsのFDISKからは「非MS-DOS領域」と認識されるので、WindowsのFDISKでもその後ろに更に基本領域をもう一つ作成することができる。作成したらこの領域をアクティブにすることも忘れないでほしい。MBMの区画エディタやパーティション操作ツールでも作成できるが、OSのツールでできることはなるべくOSのツールを使おう。

 基本領域2を作成し、フォーマットしてWindows95 Bのインストールが完了したら基本領域1を元のパーティションタイプに戻して(表示にする)MBRにMBMを導入する。MBMの詳しい使い方はこちらに譲るがこの程度ならいとも簡単にWindows95AとWindows95Bのデュアルブートが実現できたはずである。

 ところでこの隠しパーティションだが、今回の私の説明だとそもそも一つしか基本領域を作れないWindowsのFDISKで複数の基本領域を作るための方便として利用していると受け取られてしまうかもしれない。だとすると一旦パーティションを作ってしまった後は表示に戻してもいいように思える。しかし隠しにするには実はもっと様々な効果がある。

 たとえばWindowsの製品版インストールメディアは既存のWindows環境を見つけるとインストールを拒否したりする。また拒否しない場合でも既存の環境を勝手に引き継いだりもする。あるいは既存環境を変えてしまう場合もある。そうした様々なことから既存環境の保護、また安定した現環境のインストールを行うために少なくとも現環境のインストールが完了するまでは隠しパーティションにしておくべきである。

 またもし可能なら普段の運用でも重要なパーティションは他のパーティションのOSが起動しているときには隠しておいた方が無難かもしれない。

 基本領域3の構築も基本的には同じだ。一旦基本領域1と基本領域2を隠しパーティションにし、同じように通常のFDISKの機能でパーティションの作成、アクティブ化、フォーマット、OSのインストールと進む。ただしWindows9x系のインストーラはOSのインストールの過程でMBRにMS、IBMオリジナルのブートストラップローダをインストールしてしまうため、先ほど導入したMBMが消えてしまう。もっとも慌てる必要はない。これはまたMBMを導入し直せばいいだけである。

 隠しパーティションにしたり、戻したり、アクティブ属性を変更したり、ブートローダの導入したりといったことを何度か繰り返す必要があるが、上記のような手順を踏めばWindows9xのマルチブート構成は比較的簡単に構築していくことができる。市販のツールではこれらの作業を自動化してあるものもある。SystemCommanderのOSウィザードなどが典型である。

 ただフリーのブートローダの中にはそもそも隠しパーティションの機能が無かったり、あっても導入していないと使えないものが多いので、たとえブートローダしては使わなくてもMBMは是非入手しておいてほしい。MBMの区画エディタはMBMを導入していない状態でも使うことができるので、上記のような環境構築時に非常に便利だ。フリーだからパーティション操作ツールとして一つ持っていて損はない。PartitionMagicのようにデータを保持したままサイズ変更などができる訳ではないが、マルチブート環境構築には大きな手助けになる。

 以上で複数基本領域を利用したWindows9xのマルチブートの説明は終了である。

 


Cドライブが既にNTFSの場合

 もしあなたがWindowsNTWindows2000をインストールした後でWindows9xをインストールしたいと思った場合、どのようにすればいいのだろうか。

 NTLDRの存在する領域(以前これはアクティブな基本領域なので即ちCドライブとなると説明した)がFATの場合、「インストールの順序」でも説明している通り、2,3の注意点だけ留意すれば特に問題はない。問題はこの領域(Cドライブ)がNTFSになっている場合だ。

 勿論もう一度フォーマットからやり直しても構わないというのであれば全然問題ないのだが、せっかく構築した今の環境を壊すことなく、ゲーム用にWindows98をインストールしたいという場合があるだろう。

 この場合、NTLDRを使ったマルチブートは通常は使えない。結局この場合も現在のNTFSのあるCドライブとは別に基本領域を用意して、そこにWindows9xをインストールすることになる。やり方は上記の構築方法とほぼ同じだ。むしろNTFSはWindows9xのインストーラからは既に「非MS-DOS領域」として認識されているので、隠しパーティションにする必要がなくて、楽なくらいである。

 ただし、最近のWindowsMEなどのインストーラは既にNTなどがインストールされていると、変な警告を出したり、インストールができない場合があると聞く。このような不測のトラブルを避けるためにもNTFSのパーティションをMBMの区画エディタで、全く関係なさそうなパーティションタイプ(例えば0xCAとか)にしてしまった方が無難だ。

 


複数のハードディスクを利用する場合

 今まで、一つのハードディスクに複数の基本領域を作成する方法を説明してきた。これが複数のハードディスクを利用する場合はどうなのだろうか? 基本的な考え方は変わりないが、肝に銘じておかなければならない概念が2つある。それは以下だ。

  1. ハードディスクのBIOSからみた順序
  2. その順序と起動OSからみたドライブレター

 ハードディスクの位置を、たとえばプライマリーマスターとか、セカンダリースレーブといったIDEの接続位置で表現する場合があるだろう。またSCSIの場合、SCSI IDで表現する場合があるだろう。勿論これはこれで非常に重要なことだが、マルチブートにとって、それ以上に重要なのが、結局その接続によって、どのハードディスクが、BIOSからみて、1番目なのか、2番目なのかといういった順序である。

 まあ普通はないかもしれないが、セカンダリスレーブだといってももしかしたらそれが第1ハードディスクかもしれない。BIOSでブートシーケンスを変えている場合もあるだろう。またIDEとSCSI混在の場合もあるだろう。

 とにかくマルチブートにおいてはハードディスクのBIOSから見た順序はWindows系に限らず、常に気にしていなければならない重要なポイントとなる。

 更にWindows系OSの場合、その順序や、パーティション構成によって引き起こされるドライブレターの振られ方が重要になってくる。またOSによっては理解できるファイルシステムが違うためにハードディスクの順序もパーティション構成も同じでありながら、ドライブレターの振られ方が、OSによって全然違ってくる。ドライブレターを読んで、これも確り頭に入れておいてほしい。

 上記の踏まえた上で、実際の作業時に問題となる点を、2点ほど言及しておく。

 一つはOSのインストール時は一旦必ずそのハードディスクが第1ハードディスクになるように接続を変えるなり、BIOSのでブートシーケンスを変更するなりした上で、行う必要があるということだ。最終的にそのハードディスクが何番目になるかに関わらず、インストール時は必ず第1ハードディスクとしておいてほしい。

 もう一点は「第2ハードディスク以降の起動」でも説明しているようにWindows系OSの第2ハードディスク以降からの起動は何かと問題がある。インストールが完了した後、どのOSが入っているハードディスクを第1ハードディスクにするかを、きちんと決める必要がある。「第2ハードディスク以降の起動」の表を見て、構成と選択するブートローダを決める必要があるだろう。

 いずれにしてもブートローダは第1ハードディスクと決めたハードディスクのMBRに導入することになる。

 これらの点を、確り念頭においておけば、後のことは一つのハードディスクの場合と何ら変わりはない。

 


Cドライブ派

 Windows9xをマルチブートするには基本的に複数を基本領域を用意して、MBRに置くブートローダでアクティブ切り替えで起動するのが一般的であることは説明した。一方NT系OSの場合、元々持っているNTLDRによるマルチブート手法により、複数の基本領域が必ずしも必要ないことも説明した。

 しかしNT系OSの場合も複数の基本領域を仕立てて、アクティブ切り替えでのマルチブートを行っても勿論構わない。こうすることにより、各OSのシステムパーティションがCドライブとなるため、好んでこのような構成にする人は多いと思う。以前はシステムパーティションはCドライブであるべきという一種のCドライブ神話と言えるようなものがあった。確かにシステムがCドライブにないと動作しない、またはインストールできないというようなアプリケーションも存在したのだ。しかし今ではそんなアプリケーションはまずないと思うし、あってもそんな稚拙なつくりのアプリケーションは決して使ってはいけない。

 そうは言っても今でもシステムがCドライブにないと気分の悪い人は多いのではないだろうか。かく言う私もそんなCドライブ派の一人である。しかし私がCドライブに拘るにはもっと別の理由がある。

 それは現在のハードディスクが外周内周でかなり読み書きの速度が違うことに起因している。外周の方がずっと速いのだ。アドレス的に先頭のパーティションが外周となるので速いパーティションということになる。よってメインのOSはなるべくこの先頭パーティションに置くようにしたいと誰もが考えるだろう。

 あるOSから別のOSに乗り換える時、そのOS間の違いにもよるだろうが、遅かれ早かれ新OSがメインになるはずである。私などは最初から新OSの使用頻度が非常に高く、一ヶ月もすると前OSは殆ど起動しなくなる。そのため新OS導入の時点から先頭パーティションにインストールしたいと考える。

 たとえば現在Windows98をCドライブで使っていたとしよう。ここにWindows2000を導入する場合、Dドライブ(論理領域)に入れてNTLDRでマルチブートするというのが最も一般的で楽な導入方法だろう。しかしそうするとすぐにメインOSとなるWindows2000が後ろのパーティションになってしまう。それを避けるためにWindows2000をCドライブに導入するとWindows98とProgram Filesディレクトリを共有することになり好ましくない。またWindows98のシステムディレクトリを論理領域であるDドライブに変更することはできない。

 結局Windows98を後ろの別の基本領域に移してこれをCドライブのままで起動し、先頭の基本領域にWindows2000を新たに導入する他なく、必然的に両方のOSがCドライブになっていってしまうという訳である。最近のWindowsXPの導入時も同じだ。単純にDドライブに導入すれば簡単だが、やはりCドライブに導入するために同じ作業を行った。

 またアップグレードをしつつ、マルチブートを行っていく場合も必然的にこのような構成になる。現在のOSをアップグレードして更にそのOSを従来どおり利用するには一旦現在のOSのクローンを作り、一方をアップグレード用に他方をそのまま利用するということになる。このような場合もどうしてもCドライブオンリー構成になってしまう。


 では具体的に実際私がWindows2000からWindowsXPへの移行時に行った方法を例に取りながら、Cドライブオンリー構成の構築方法を説明しよう。まず手順を箇条書きにしてみよう。

  1. クローンの作成
    後ろにもうひとつの基本領域(第2基本領域)を作成し、現在の先頭基本領域(第1基本領域)をコピーする。
     
  2. boot.iniの変更
    基本領域の位置が変更になるので、ARCパスを変更する。
     
  3. MBRのNTシグニチャの消去
    Windows9xの起動ディスクで起動して、「fdisk /mbr」を実行する。
     
  4. MBRへのブートローダの導入
    MBMなどのMBR導入型ブートローダをMBRにインストールする。
     
  5. ブートローダで各OSの起動確認
    MBRに導入したブートローダで第1基本領域、第2基本領域の各OS(Windows2000)を起動し、それぞれがCドライブで起動し動作に問題がないか確認する。
     
  6. 第1基本領域のWindows2000をWindowsXPにアップグレード
    第1基本領域のWindows2000をアップグレードセットアップによってWindowsXPにする。

 手順としては以上である。それぞれのステージを細かく説明しよう。

 まずクローンの作成だが、私の場合PowerQuestのDriveImageを持っているのでこれを利用した。安全かつスマートに行うにはこのようなツールを使うのがベストだ。廉価版のDriveCopyやNortonのGhost、シェアウェアのwashなどでも可能である。

 しかしOSのコピーのためだけに市販ツールやシェアウェアを購入するのがいやだという人は別のWindows2000のシステムにハードディスクを接続してエクスプローラでコピーをしても構わない。ただしこの場合、ファイルシステムがNTFSであるときはすべてのディレクトリ、ファイルをEveryoneフルコントロールにしておく必要がある。そうでないと別システムからコピーできないことがある。

 いずれにしても、もう一つの基本領域を作成するための空き領域がないと困るわけだが、これは用意して頂く他ない。私の場合以前のWindows98用に使っていた第2基本領域をこの際潰すということを行ったが、第2基本領域の用意が難しい人も多いだろう。データ領域があるなら、バックアップの上これを一旦潰してしまう必要があるかもしれない。

 既にハードディスクがひとつの基本領域になってしまっている人は別システムから起動して、どこかにシステムごと退避しパーティションを作成し直して、また戻すといった作業をする必要がある。こういった場面でもDriveImageやGhostなどは非常に重宝するので、この際ひとつ購入するというのが私としてはお勧めである。

 
 次のboot.iniの変更はクローンとして作成したWindows2000は第1基本領域から第2基本領域に移動することになるので、従来のままのboot.iniの記述では起動しなくなることに備える対策だ。起動不能となる理由はARCパス(詳細は後述するboot.iniの記述を参照してほしい)が変わってしまうからである。そこでARCパスを書き換えるのだが、一応念のため書き換えではなく追加とした方がいいだろう。第1基本領域にある場合でも第2基本領域にある場合でも起動できるように柔軟にしておくためだ。
 
[boot.iniの変更前の内容]
[boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect

[boot.iniの変更後の内容]
[boot loader]
timeout=10
default=multi(0)disk(0)rdisk(0)partition(2)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional 1" /fastdetect
multi(0)disk(0)rdisk(0)partition(2)\WINNT="Microsoft Windows 2000 Professional 2" /fastdetect

 このようにしておくことで、システム領域が第1基本領域でも第2基本領域でも選択起動によって対応できる。基本的には今後第2基本領域から起動することになるので、第2基本領域をデフォルトとしておいた方がいい。全部の移行が完了し、安定稼動を確認したら、第1基本領域のエントリは削除しても構わないだろう。
 
 
 次のMBRのNTシグニチャの削除だが、この作業は極めて重要である。これを行わないと第2基本領域にコピーしたシステムが正常に起動しない。NTシグニチャはシステムが各ドライブ、パーティションの情報を保持するための識別子として、MBRのパーティションテーブルの少し前あたりに記録するもので、通常はドライブレターの保持などに重要な役割を果たす。しかしこれがシステムの引越しの時などには返って混乱の元となり、ひどい時はWindows2000を起動不能にしてしまう曰くツキのデータである。

 NTシグニチャを削除しないまま第2基本領域のシステムを起動すると、たとえこの第2基本領域をアクティブにしても依然第1基本領域がCドライブのままとなり、第2基本領域はおかしなドライブレター(例えばGドライブなど)が振られてしまう。一見正常に起動しているように見えるが、実は第1基本領域のデータと第2基本領域のデータの双方を使いつつ起動しているという非常に変則的な起動状態になってしまう。このまま後で第1基本領域をWindowsXPにアップグレードすると確実に第2基本領域のWindows2000は起動不能に陥る。

 現在MBRのNTシグニチャを削除する方法として最も手っ取り早いのがfdisk /mbrなのだが、他に方法がない訳ではない。しかし結構面倒な方法ばかりだ。UNIXシステムに接続してddコマンドを使うとか、特別なツールを利用するなどなど。特にシグニチャはパーティションテーブルに隣接しているので、気をつけないとシグニチャ削除時にあやまってパーティション情報まで消してしまう恐れもある。自信のない人はやはり何としてもWindows9xの起動ディスクを用意してほしい。

 尚、シグニチャは削除してしまってもまた再度作成されるので問題はない。CD-ROMドライブなどを別途Rドライブなどといった自分の好きなドライブレターに割り当てていた場合、これがクリアされてしまうが、また割り当てのし直しをすればいいだけである。


 次のMBRへのブートローダの導入は「フリーツール編」あたりを参考に好きなブートローダを導入してほしい。

 ブートローダでの両OSの起動確認は必ず行ってほしい。NTシグニチャの削除により、最初の起動時はやたらハードディスクがガリガリ言うと思う。これはシグニチャの再作成のためにパーティションをいろいろ調べているからだ。シグニチャの再作成後、再起動の要求などもあると思うが、それに従って再起動も行い、通常と変わらない起動が両方のOSでできるようになるまでちゃんと確認してほしい。

 第2基本領域のWindows2000クローンが正しく起動するようになったら、これでWindows2000のクローン化は完了したことになるので、後は第1基本領域のWindows2000は好きなようにすればいい訳である。WindowsXPにアップグレードしてもいいし、それこそフォーマットして新規インストールしても構わない。

 


boot.iniの記述

 今まで、初級編でもboot.iniというファイルについてはいろいろと言及してきた。またその書き換え方なども説明してきたが、基本的にWindowsNT系以外の記述のことばかりだった。

[boot.iniの内容]
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINNT
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version 4.00"
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows NT Workstation Version 4.00 [VGA mode]" /basevideo /sos

 多くの人が、上記のWindowsNT系エントリの記述である、「multi(0)disk(0)rdisk(0)partition(1)\WINNT」の部分は一体どういう意味を持つものなのか疑問に思っていただろう。これはNTカーネルの存在するディレクトリを示すパスなのだが、各数字の意味に疑問をもった思う。単純なマルチブートの場合、このことについての知識はあまり必要ないのだが、やはり高度なマルチブート環境を構築していくにあたってはこの記述の理解は避けて通れない。

 これはARC(Advanced RISC Computing)パスと呼ばれるもので、以前存在したACE(Advanced Computing Environment)コンソーシアム(Compaq、MS、MIPS、DEC、SCO他)が、かなり前に策定したMIPS R4000ベースのワークステーションの仕様に則ったハードディスクの位置を示す表記方法である。この表記をWindowsNTで採用した理由はかなり前、WindowsNTがまだOS/2 3.0と呼ばれていたころ、これをIntel x86だけでなくARC仕様機でも動かす予定だったからだ。その後NT 3.1としてデビューしたこのOSは x86とMIPSに加えてAlphaとPowerPCでも動くようになったわけだが、MIPS版はPowerPC版ともども NT 4.0を最後に消えたが、その名残として残っているものである。

 ARCパスはプラットフォームによって記述方法が違うのだが、x86プラットフォームの場合、以下のような2種類の記述方法がある。

  1. multi()構文: IDEハードディスク、及びBIOS付きSCSIアダプターに接続されたSCSIハードディスクの場合。
     
    multi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>
      
  2. scsi()構文: BIOSでサポートされないSCSIハードディスクの場合。

    scsi(X)disk(Y)rdisk(Z)partition(W)\<winnt_dir>
     

 まず、前者だが、これはIDEハードディスクの他、BIOS付きSCSIアダプターに接続されたSCSIハードディスクを示す場合のものだ。つまりとにかくBIOSでサポートされるハードディスクの場合ということになる。これをmulti()構文と呼ぶ。

 multidiskという先頭2つの識別子は常に「0」である。

 次の rdisk という値は「BOOT.INI and ARC Path Naming Conventions and Usage」の記述によると、IDEの場合、「0」から「3」まで。たぶんプライマリ、セカンダリ2チャネルのそれぞれのマスターとスレーブということだろう。またSCSIの場合は「2」まで。更にIDE、SCSI混在の場合はIDEのみに適用と書いてあるが、実際テストしてみると大分違う。

 IDE、SCSI混在だろうが、なんだろうが、とにかくBIOSが認識する物理ドライブの番号となっている。また特に上限値はないように見える。私の環境でできうる限りのハードディスクを接続して、テストした結果、以下のような rdisk値になった。IDEハードディスク3つをオンボードIDEに2つと、PromiseのUltra66に一つ。SCSIハードディスク3つを、AdaptecのAHA2940Uに全部接続した。BIOSのブートシーケンスはIDEが先である。
 

rdisk値

接続場所

0 オンボードIDEプライマリーマスター
1 オンボードIDEセカンダーマスター
2 Adaptec AHA2940U SCSI ID 0
3 Adaptec AHA2940U SCSI ID 3
4 Adaptec AHA2940U SCSI ID 4
5 Promise Ultra66 プライマリーマスター

 完全にBIOSが認識する順序になっている。また上限値も上記ページの記述と違って、この6つのハードディスク全てにWindowsNTのシステムディレクトリをインストールできた。

 このような仕様となっていることから、マルチブート時に注意しなければならないこととして分かることは環境変更などで、この値のずれに気をつける必要があるということである。

 つまり、例えば、今AHA2940UのSCSI ID 3のハードディスクにインストールしたWindows NTのboot.iniは以下のようになっているはずだ。

 multi(0)disk(0)rdisk(3)partition(1)\WINNT

 ところが、もしここでIDEのセカンダリマスターのハードディスクを外すと、この順番は当然ずれ、このSCSIハードディスクはBIOSからみた順序が3番目、つまり rdisk値は「2になってしまい、このエントリでは起動できない訳だ。この場合はたまたま「3」は次のSCSI ID 4のハードディスクがあるので、こちらが起動するのだろうが、もし、この後ろにハードディスクが無ければ、次のようなエラーメッセージを出力して、起動不能となる。

次のファイルが存在しないかまたは壊れているため、Windows2000を起動できませんでした:
<windows 2000 root>\system32\ntoskrnl.exe.
上記のファイルをインストールし直してほしい。

 勿論ハードディスクがあってもそこにWINNTディレクトリが無ければ、同じことである。(もっとも上記メッセージは後述するpartition値の誤りである場合の方が多いかもしれない。)

 当然逆に例えばIDEプライマリースレーブにハードディスクを増設した場合もrdisk値のずれが起こる。CドライブがNTFSである場合、起動不能になると、もはやboot.iniを書き換えるということも難しくなるので、環境変更時はある程度予測して、予めエントリを作っておくといったことが必要になる場合もあるだろう。

 次の partition という値だが、その名の通りパーティション(領域)の番号を示します。「1」から始まるところが、他の値と違うのだが、連番の規則は基本領域が先、論理領域が後となっている。若干ドライブレターの振られる順序に似ているが、アクティブ属性によって左右されない点が違う。以下のようなイメージだ。

[partition値(丸数字)]

  基本領域に関してはアクティブ属性にも関係なく、また図だと誤解されがちなのだが、実際のパーティションの物理的位置とも関係なく、単にMBRのパーティションテーブルのエントリ順(ただし拡張領域(Type0x05、及び0x0F)と空領域(Type0x00)はカウントされない)に番号が付く。そして基本領域の次に論理領域が振られる。

 これから分かることはやはり環境変更時に気をつけなければならないことがあるということだ。もし論理領域にWindows2000のシステムディレクトリをインストールしていた場合、ハードディスクに空き領域があるからといって、そこに新たに基本領域を作ると、当該論理領域の partition値がずれてしまう訳である。やはりこの場合も逆があって、複数の既存の基本領域のうち、どれかを削除すると、論理領域の値は前にずれることになる。

 partition値の場合もrdisk値の場合と同様に環境変更時にはあらかじめエントリを記述しておくなどの対策を講じておく必要がある。

 ただしPartition Magicで基本領域を作成した場合、ブートパーティションに存在するBoot.iniをちゃんとメンテナンスしてくれる。つまり基本領域作成時にずれたpartition値を正しい値に自動的に変更するのだ。さすがPowerQuest、こうした仕様をちゃんと理解している訳だね。もっともバイナリであるbootsect.dosすら変更するのだから、プレーンテキストであるboot.iniを書き換えるくらいPowerQuestには朝飯前なのだろう。

 因みにPartition Magicの上記動作はバージョン4、5.01、及び6で確認した。結構古いバージョンから、この機能をサポートしているんだね。これより前のバージョンは持ってないので分かりまへん。

 ただし論理領域を基本領域に変更した場合はboot.iniを書き換えてくれない。さすがにここまでは面倒みきれないのだろうか。理論的には上記と比べて特に難しいということはないような気がするが。

 BIOSでサポートされるディスクの場合の、multi()構文についての説明は以上である。

 
 さて、次はscsiで始まる記述の説明だ。誤解のないように繰り返しておくが、SCSIの場合でもBIOSでサポートされるものはmulti()構文である。これから説明するのはSCSI BIOSでサポートされない、たとえばBIOSなしのSCSIアダプターや、BIOS付きでもBIOSを無効にしているSCSIアダプターに接続されたハードディスクの場合だ。これをscsi()構文と呼ぶ。

 通常ブートという作業はBIOSのサポートなしには何もできないことが多いのは今までページを読んできた方には理解してもらっていると思う。WindowsNTの場合もやはりNTLDRまではBIOSに頼るためブートパーティションは絶対にBIOSでサポートされるディスク上に存在する必要がある。

 しかしWindowsNT/2000のシステムディレクトリに関してはBIOSでサポートされないディスク上に置くことができる。これはNTLDRがSCSIドライバーをサポートしているため、カーネル起動前でもそれらのディスクにアクセスができるからである。

 WindowsNT/2000のインストール時にまだシステムインストールディスクを決定する前に夥しい数のSCSIドライバーを読み込んでいるフェーズがあるのを、覚えている人もいるだろう。またインストールブートディスク(フロッピーディスクやCD-ROM)に入っていないSCSIドライバーもシステムインストールディスク決定前にインストールするフェーズがある。これは当然インストールCD-ROMを認識するためという目的もあるのだが、その他にBIOSでサポートされないSCSIハードディスク上にもシステムディレクトリをインストールできるようにするためにこの段階で行っているのである。

 インストール時にシステムディレクトリの指定を、このようなディスク上にした場合、そのディスクが接続されたSCSIアダプターのドライバファイルが、NTBOOTDD.SYSという名称で、Cドライブの直下に置かれる。そしてboot.iniのエントリはscsi()構文で作られる訳だ。これらの行為はインストーラが自動的に行ってくれる。特にインストール時にユーザが指定する必要はない。ただ単にBIOSでサポートされないディスクをシステムディレクトリを置く場所として選択するだけである。

 そして起動時の動きとしてはscsi記述のエントリが選択されると、NTLDRはNTBOOTDD.SYSを読み込んで、そのドライバがサポートするSCSIアダプター上のディスクにアクセスを試みるといった手順になっている。

 先頭の scsi値はNTBOOTDD.SYSがサポートするSCSIアダプターが複数ある場合(例えば同じ種類のSCSIカードが複数ある場合)、NTBOOTDD.SYSが認識する、「0」から始まる順番になる。通常はPCIスロットの番号の若い方が「0」となるだろう。

 残念ながら、異なったSCSIドライバーを必要とする複数のSCSIアダプターはサポートされない。これはNTLDRが読むSCSIドライバーは「NTBOOTDD.SYS」という名前固定で、変更できないからだ。ただしSystem CommanderなどのMulti-FAT機能ではこのファイルを起動時に差し替えて、複数の異なったSCSIアダプターをサポートすることを可能にしている。

 あとの、disk値rdisk値はSCSIではおなじみの識別子である、SCSI IDLUN(Logical Unit Number)なので、説明する必要もないだろう。multi()構文とはその意味するところがかなり違う訳だが、やはり環境変更時には気をつける必要がある。不用意にシステムディレクトリのあるハードディスクのSCSI IDを変更すると、起動できなくなる。

 partition値に関してはmulti()構文の場合と同じである。

 


ブートシーケンスの変更

 もし現在あなたが以下のような構成でデュアルブートを行っていたとしよう。

[NTLDRによるデュアルブートシーケンス]

 まあ、見ての通り、単なるNTLDRによる、最も簡単なデュアルブートだ。普通とちょっと違うのはWindows2000のカーネルのある領域が基本領域だということだろう。普通にこの手の環境を作った場合、Dドライブは論理領域だろうから。

 さて、ここで後ろにある空き領域(あったとして)に更に基本領域を作って、Windows98などを導入したとしよう。今まで述べてきたようにその場合、MBRにアクティブ切り替え型のブートローダを配置して、起動し分ける訳だが、このままだとWindowsMEとWindows2000はそのブートローダから直接起動することはできない。結局、MBRに配置したブートローダと、NTLDRの2つのメニューを選択しないとブートできないという、2段階ブート手順を余儀なくされる。折角Dドライブが基本領域なのだから、これをなんとかできないだろうか?

 単純に考えれば、NTLDRやNTDETECT.COMなど、Windows2000のブート系ファイルを基本領域2に持っていって、Windows2000を起動するようにし、基本領域1はsysコマンドでブートセクターをDOS-IPLに戻し、直接IO.SYSを読みにいくようにして、WindowsMEを起動するようにしてしまえばいいように思える。

 WindowsMEの方はこれでOKだ。しかしWindows2000の方は問題が一つある。それは上記環境で基本領域2がWindowsME上でフォーマットされていた場合である。「ブートセクターの役割とこれを作る人」でも言及しているようにWindowsME上で(DOS/Windows9xでも同じだ)フォーマットした場合、基本領域2のブートセクターにはDOS-IPLが書かれており、これをMBRに導入したブートローダが起動してもその後、このIPLがNTLDRを読んでくれない。

 結局、基本領域2をWindowsNT/2000上からフォーマットし直すか、この2段階ブート構成に甘んじるしかないのだろうか? しかし今まできちんと読んできて頂いた方なら、「インストールの順序」で私が言及したブートセクターの検査(修復)回復コンソールのfixboot、及びBootPartユーティリティが使えるのではないかと気づいたはずだ。

 正解である。それで大丈夫だ。ただし以下の点に注意してほしい。「ブートセクターの検査」と「BootPartユーティリティ」Cドライブ(アクティブな基本領域)のブートセクターを修復しようとするので、必ず基本領域2をアクティブにしてから行ってほしい。これは回復コンソールのfixbootも基本的に同じだが、fixbootは以下のように引数に修復パーティションを指定できるので、この方法でも構わない。

 > fixboot  d:

 こうして基本領域2のブートセクターをNT-IPLのものにしておけば、NTLDRを読み込めるようになるので、MBRに配置したアクティブ切り替え型ブートローダで、ダイレクトに各パーティションを起動し分けることができるようになる。もちろんboot.iniを編集して、WindowsME用のエントリは消しておき、タイムアウト値などを0または小さくして、NTLDRの存在を意識しないで済むうようなカスタマイズは適宜行う必要がある。前項で述べたARCパスはこの場合、変更しないでも問題ないはずである。変更後のブートシーケンスは次のようなイメージになるだろう。

[アクティブ切り替え型ブートローダによるブートシーケンス]

 勿論基本領域2がNTFSだったり、FAT32でもWindowsNT/2000上でフォーマットしたものであるならば、既にブートセクターのIPLがNT-IPLになっているはずなので、ブートセクターの修正手順は必要ない。

 ただしこの場合、もう1点だけ、注意が必要だ。変更前はWindows2000のシステムディレクトリはDドライブにあった訳だが、変更後はアクティブな基本領域になるので、Cドライブに本来はなるはずである。

 確かにWindowsNTの場合はそうなる。従ってシステムディレクトリのドライブレターが変わる訳だが、WindowsNTの場合は基本的に問題なく起動する。しかしページファイルなどがそのままだとDドライブに作ろうとするので、気をつけてほしい。新しいDドライブがどのドライブになるかはその環境によるのだろうが、もし新環境ではDドライブがなったり、あってもそこがCD-ROMドライブだったり、FAT32パーティションである場合、WindowsNTではページファイルを作れないので、起動時に警告がでる。この場合、速やかにページファイルの位置を正しい位置に変更しよう。

 一方Windows2000はインストール時のシステムディレクトリのドライブレターはその後変更できないので、上記例の場合、ブートパーティションでありながら、依然Dドライブのままとなる。ブートパーティションがDドライブというのが、気持ちが悪い人もいるのだろうが、これを変更する方法は基本的にない。某サイトにこれを変更する方法が記載されていたが、私の環境では成功したためしがなく、私の周辺でも圧倒的に失敗例の方が多い。失敗するとWindowsの起動が不能となり、再インストール以外、復旧の方法がないので、この方法は紹介しない。

 また、言うまでもないことだと思うが、上記例のWindows2000のシステムディレクトリのある領域が論理領域だった場合、そもそもこんな構成変更はできない。

 


NTFS上のWindows NT SP3とWindows 2000の共存

 「NT系OS同士のマルチブート時の注意」で述べたようにWindows NT SP3以前NTFS5を認識できないため、NTFSを使ったままではWindows 2000との共存ができない。SP4以降にするか、FATパーティションを利用するほかないと同ページでも説明した。

 しかし、SP4以降にもせず、またFATを利用しないでも共存可能な方法がある。それはWindows 2000起動時にWindows NT 4.0 SP3以前がインストールされたパーティションを隠してしまえばいいのである。

 隠しパーティションについてはこれまでも説明してきた。ところがWindows 2000に対しては単純な隠しパーティションは通用しない。これまで説明してきた隠しパーティションはパーティションタイプをMicrosoftOSの知らないタイプのものに一時的にするものだった。具体的にはNTFSの0x07などに0x10を足して、0x17などとするものだ。

 しかしMicrosoftのファイルシステムは実はブートセクターにファイルシステムの情報が全て記述されているので、パーティションタイプを見ないでも正確なファイルシステムの情報が分かる。それでもWindows 2000以外はまずパーティションテーブルのパーティションタイプを確認していたのだが、Windows 2000ではパーティションタイプを全く無視して、ブートセクターのみからファイルシステムの情報を取得する。

 従って、いくらパーティションテーブル上のパーティションタイプを、0x17や、もっと極端に例えばLinux ext2fsの0x83など全くNTFSと関係ないパーティションタイプに変更したとしても効き目がない。ブートセクターからしっかりNTFSを見つけ出してしまう。(すごい執念だね、Windows 2000は。ゲシュタポのようだ。)

 しかし、Windows 2000から、旧NTFS領域を隠す、守る方法が3つだけある。

 一つはパーティションタイプ00にしてしまう方法である。パーティションタイプが00の場合はさすがにパーティション情報がないと判断するようで、ブートセクターまで検査にいかず、NTFSの存在を隠すことができるのだ。

 具体的方法としてはやはりNTLDRだけではこのようなことはできないので、grubなどのブートローダが必要だ。grubの使い方の詳細は別途、「GRUB」を参照してもらうとして、実際次のような、menu.lstで実現可能である。

[設定ファイル「/boot/grub/menu.lst」の記述例]
title Windows 2000
parttype (hd0,1) 0x00
root (hd0,0)
makeactive
chainloader +1

title Windows NT SP3
parttype (hd0,1) 0x07
root (hd0,1)
makeactive
chainloader +1

 この例では第1基本領域にWindows 2000を、第2基本領域にWindows NT 4.0 SP3をインストールしている。Windows 2000起動時には第2基本領域のパーティションタイプをparttype」コマンドで、0x00にする。

 Windows NT起動時は自分のパーティション(第2基本領域)を、0x07に戻してから起動する(戻さないと起動しない)。尚必須ではないが、Windows NT起動時にWindows 2000のパーティションを隠した方がいいだろう。どうせNTFS5は見えないのだから、完全に隠した方が安全だ。何しろ、SP3からNTFS5パーティションにアクセスすると、エクスプローラが落ちてワトソン博士が登場する。見えない方が何かと無難だろう。その場合はWindows 2000起動時に自分のパーティションタイプを戻すことも必要になるので、次のような設定になるだろう。

[設定ファイル「/boot/grub/menu.lst」の推奨例]
title Windows 2000
parttype (hd0,1) 0x00
parttype (hd0,0) 0x07
root (hd0,0)
makeactive
chainloader +1

title Windows NT SP3
parttype (hd0,0) 0x00
parttype (hd0,1) 0x07
root (hd0,1)
makeactive
chainloader +1

 こうすることで、Windows 2000から、旧NTFSパーティションを守ることができ、SP3以前のWindows NTでもWindows 2000と共存しつつ、NTFSファイルシステムを利用することができる。

 GRUB以外にもこのようなことができるブートローダがあると思うが、GRUBが一番簡単だと思う。尚、MBMでは現バージョン(0.36b)においてはパーティションタイプを00にするとパーティション情報を全て(アドレス情報などもみな)消してしまうので、この方法では使用することはできない。

 
 もう一つの方法はシステムコマンダー7や上記方法が使えなかったMBMが用意している特別な方法である。MBMが上記の方法をサポートしていないのはパーティションの整合性を捨てたくないという作者のポリシーによるもので、あえて採用しなかった。そこで上記方法によらずにWindows 2000から、NTFSパーティションを守る方法として、パーティションタイプだけでなく、ブートセクターまで書き換えてしまうというものだ。具体的にはシステムコマンダーではブートセクターのOEM名と呼ばれる部分で、NTFSの場合「NTFS」と書いて部分を「ntfs」と小文字に変えている。一方MBMではブートセクター全体をビット反転している。

 システムコマンダーでは標準でこの機能を持っているが、MBMではこれを危険視しているので、標準のバージョンにはこの機能がない。特別バージョンでサポートしている。


 さて、最後の方法はWindows NT 4.0 SP3のシステムディレクトリ(WINNTディレクトリ)が、論理領域にある場合に使える手で、拡張領域(0x05か0x0F)を自体を隠してしまう方法だ。この場合もWindows 2000が内部を検索すべき拡張領域であることが分からないので、論理領域にあるNTFSを見つけることができない。

 この場合は0x15といった通常の隠し機能でも通用する。ただしこの方法の難点はシステムディレクトリが論理領域にある場合だけだということの他、Windows 2000からは論理領域が一切利用できなくなってしまうことだろう。

 またブートドライブ(Cドライブ)がNTFSである場合は当然NTFS5にされてしまう訳だが、システムディレクトリさえ旧NTFSならば、NT SP3は起動はする。しかしNTからこのCドライブがドライブとして存在するが、中身は見れないという状態になる。MicrosoftのOSで、Cドライブが見えないという状態が、どれほど通常運用に耐えられるかはちょっと予想がつかないね。

 従って後者は決してお薦めの方法ではない。一応こんな方法もあるということで。

 


ブートコード領界

 NTLDRのみを利用したデュアルブートの場合、ブートパーティション(NTLDRやIO.SYSなどがあるパーティション)はハードディスクの先頭に置くだろうから、あまり気にしなくていいと思うが、複数の基本領域を一つのハードディスクに置いて、それぞれをブートパーティションとする場合、その位置に気をつける必要がある。ブートパーティションの位置というか、IPLやIO.SYS、NTLDRなどのブート関連のプログラム(ブートコード)のハードディスクの先頭からの位置に制限がある。これをここではブートコード領界と呼ぶ。(これは私の造語だ)

 MS-DOSWindows3.1Windows95初期バージョンの場合はブートコード領界は2GBとなっている。Windows95 OSR2以降Windows98、及びWindowsMEは制限はない。またMS-DOSでもWindowsのDOSはそのWindowsと同じ動作である。つまりWindows98のCommand Prompt Onlyなどはブートコード領界の制限はない。

 しかしIBMオリジナルのブートストラップローダで起動する場合は注意が必要だ。Windows95初期バージョンのFDISKが作るブートストラップローダはLBAに対応していないので、たとえWindows98でもブートセクターが8GB以降にあった場合、起動できない。Windows95 OSR2以降のFDISKで作成したブートストラップローダの場合、LBA対応しているので、パーティションタイプがFAT32XFAT16Xのものに対してなら、起動可能である。Windows95 OSR2以降のFDISKで作成したパーティションなら、8GB以降に領域が及ぶ場合、FAT32XまたはFAT16Xで作成される。

 このようにOS、そのOSに付属のFDISKプログラム、そのOSのインストーラまたはその付属のFDISKで作ったIBMブートストラップローダはみな、それぞれバージョンで整合性が取れているので、なるべく同じバージョンのものを使おう。Windows98を使っているのにWindows95初期型のFDISKで、「FDISK /MBR」などを行うと、8GB以降から起動できない。もちろんブートパーティションが8GB以内にあるなら、全く問題はないが。IBMブートストラップローダの詳細はブートストラップローダの詳細を参照してほしい。

 Windows NTではファイルシステムがFATの場合、ブートコード領界は2GBとなっているが、ファイルシステムがNTFSである場合は4GBに増える。またService Pack 5以上の場合、これがもう少し増えるのだが、5GBだったり6GBだったりと不安定だ。これはよく分からないが、何か環境依存するのだろうか。WindowsNTではこの問題から、インストール時に次のような問題が起こる。

 WindowsNTの初期インストール時にパーティションをフォーマットする場合、たとえNTFSを選択しても一旦FATでフォーマットされるため、やはり2GBの制約を受ける。従ってハードディスクの先頭から2GB以降のパーティションをブートパーティションとすると、一見インストールは進むのだが、フォーマット後の最初の再起動時にブートできずインストールが先に進まない。この問題に関しては別のPCに繋げるなどして、予めNTFSでフォーマットだけは済ませておくことで回避できる。

 しかしこのようにして、2GB制約を回避したとしてもWindowsNTのインストールディスクはSP1までしかあたっていないのものが多いと思うので、次の4GB制約は逃れられない。

 尚、Windows2000/XPはブートコード領界は存在しない。

 しかしIBMブートストラップローダで起動する場合は注意が必要だ。Windows2000のインストーラや、回復コンソールのfixmbrで作るブートストラップローダはNTFSに対してもLBAモードを使うため問題ないが、Windows9xのFDISKが作るブートストラップローダはLBA対応しているものでもNTFSパーティションに対してはCHSモードを使うので8GB以降だと起動できないということになる。

 しかし制限のないWindows95 OSR2、Windows98、WindowsME、及びWindows 2000も実際は無限という訳ではない。きちんと検証してないが、ハードウェアなども制限も受けて、事実上は32GBなどの上限があるかもしれない。

 またブートコード領界とは違うのだが、Windows NT 4.0 Service Pack 3以前ではIDEハードディスクについて8GB以上を扱えない。Service Pack 4でこの制限はなくなった。

 


←前へ(機能編)  次へ(Linux中級編)→

 


目次へ