Top > multipleboot
HTML convert time to 0.184 sec.


Tips: マルチブートするなら2段階ブート方式に統一しよう

Last-modified: 2015-08-08 (土) 16:41:02

(2015-8-2)内容に変更はありませんが、ここに冒頭コメントを記述しておきます。
このページの内容はWindows 10 時代でも64bit、32bitを問わず、一応(その理由は後述)問題なく通用します。実際既に私は複数のPCでこのページのやり方を用いた、Windows 10を含んだ(64bit,32bit混在の)マルチブート環境を構築しています。ただしこのページのやり方には、ブートに関わるHDDやSSDのサイズが2Tバイト以内まで、という制限が昔からあります。昔は2Tバイトを超えるサイズのHDDなどなかったので全然問題なかったんですが、最近は、HDDだと2Tバイト超(3Tバイトとか6Tバイト)がある程度一般的になってきました。そのようなサイズの大きなHDDにシステムドライブを設ける場合は残念ながらMBMを推奨するこのページのやり方は使えません。対してSSDの場合は今のところ全て2Tバイト以下に収まっているので理論的には実在する全てのSSDでこのページのやり方が使えます。ただしこのページのやり方を実践する為にはパーティションテーブルの形式がGPTでなく、MBMが対応している従来形式のMBR形式(呼び方はMSDOS形式等その他様々)のパーティションテーブルである必要があります。近年の大メーカーのプリインストールPC等の場合、統計はとっていませんが、大容量HDDを付けたPCと管理方法を統一したい等の理由で、SSDであってもGPTを採用している例が多くなってきているのではないでしょうか。そのような場合、そのPCにパッケージ版Windowsのインストーラに準ずる機能を持つリカバリDVDやリカバリUSBメモリが備わっていて、パーティションテーブルの切り直しからやり直す等しない限り、本ページのやり方を完全に実践することはできないでしょう。したがって、本ページのやり方は、今では自作PCやBTO・PCや中古PCおよび(USBカードリーダに挿したSDカードやCFカードを含む)USBメモリやUSB接続HDDに限定したやり方となりつつあると言えるのかもしれません(但しUSBデバイスに通常はWindowsをインストールできないので、その場合はWindowsを除くOSのマルチブートとなります)。歴史の長いMBR形式のパーティションテーブルは拙作を含めリカバリーユーティリティーが充実しているので、私はまだまだ使い続けていくつもりです。GPTにせざるをえない2T超のHDDは1パーティションだけにしてデータ専用にしています。皆さんにも2Tバイト以内のHDDやSSDを新規購入した際は不都合は(Secure Boot等を除き)ほぼないので(MBR形式のパーティションテーブルからブートするようにUEFIを初期設定から変更する必要が生じる等の影響はあり得ます)、これからもMBR形式のパーティションテーブルを選ぶことをお勧めします。(2015-8-8追記)私自身は2段階ブートの信奉者ですから、Windows7, 8.1, 10 等を並べた、各Windowsブート環境が夫々完全に独立した(どのパーティションをゼロクリアしても他の環境のブートに何の影響も及ばさない)マルチブートを実現しています。これは他の多くのサイトで紹介されている「Win10とWin8.1のマルチブート環境」等とは明らかに異なります。ただし、私自身はそれを朝飯前に構築していますが、(Vista以降のWindows複数を完全な2段階ブート化は)他の方に勧めるにはちょっと手順が長すぎるので未だにどこにも具体的に紹介していません。興味のある方はこのページの後半あたりをヒントにしてみて下さい。

(2013-2-6)ページ末尾にWindows 8に関する記述があります。

Linuxのデフォルトのブート環境の問題点を解消しよう(各OSのブート環境は独立させよう)

※Linuxインストール後に二段階ブートに変更する場合に必須となる「grubのPBRへのセットアップ」のやり方はこちら(grub2_and_grub1)に掲載しています。

初出 2007-1-13
最終更新 2010-8-23
(2010-5-16)grubのページに、Ubuntu系でインストール後にgrub2をMBRからPBRにセットアップし直した方への重要な注意点をアップしました。

(2009-12-8)ページ作成後3年も経った今頃?という感もしますが、いくつかのマルチブートの手法を解説した図を作成してみました。
クリックすると大きな画像で見ることができます。またPDF版:filemultiboot_techniques.pdfもどうぞ
multiboot_techniques_s.png
ダウンロード filemultiboot_techniques.xls この図の出力元となったファイルです。良ければご自由に利用して下さい。
(2010-3-7追記)上記資料中のWindows 7は、Windows 7のインストールより前に手動でパーティションを作成しておくことにより、Windows 7固有の100Mバイトのブートパーティションを作成しない形式をとっています。BitLockerを使用する予定がないのであればWindowsに貴重な基本パーティションを浪費されないように事前に手動でパーティションを作成しておくことを強く推奨します。(2010-10-26追記)最近増えてきたAFT(Big Sector)を採用したHDDにXPや2000をインストールする場合も事前にパーティションを作成してことをお勧めします。というかほぼ必須です(論理4kバイトのHDDの場合は互換モードにした上で)。基本的ににはSSDと同じように扱うべきです。こちらを参照下さい。
当サイトには本ページを補足するページ群があります。←全部合わせてセットとなっています。
深く関連mbm,grub2_and_grub1,hduse,fixpbr,少し弱く関連ntfsbkup,linuxbkup,minimum-ubuntu,utlshell

(2010-8-23)参考として私のMBMの画面を掲載しておきます。MBMはチェーンロードするだけなのでどのWindowsでもどのLinuxでも起動できます。その他のOSも可です。
multipleboot_5_s.jpg
(Windows 7,XP 2つ,Ubuntu,CentOS,openSUSEのマルチブートです。拡張領域にはいろんなLinuxをまだまだ追加できます。同一のOSを複数入れたり、バージョン違いを並べることも自由自在です。このようなことの実践時には特にこの2つのページ(grub2_and_grub1,mbm)の情報をうまく活用して下さい。FreeBSDやSolarisなら基本領域のOSのどれかを入れ替える必要があります。Vistaや7を複数インストールする場合はhduseも読んでおいた方がいいと思います)
 

(2009-6-6 更新)
このページは当初技術系で興味のある人にだけ理解してもらえばいいと思って書いたのであまり読みやすい状態になっていません。しかし実際には初心者に近い方のアクセスも多く、以前から「もっとわかりやすく書き直したいな」と思いながら実行できていない状態です。しかし当ページを参考にされておられる方々(フォロワー様と言っていいでしょうか)のページのいくつかが当ページのわかりやすい要約になっていると思います。いくつか紹介しますので、先にそれらのページを読み、その後に当ページを読むっていうのはどうでしょうか? 掲載は気付いた順
multipleboot_1_s.pngmultipleboot_2_s.pngmultipleboot_3_s.png
マルチブート時のブートローダの選択について路地裏緑書: MBMによる「2段階ブート」の実践・・マルチブート環境の構築|〜magi mode・・
(2010-8-23)新たにこちらもどうぞmultipleboot_4_s.png
Windows/Linux混在環境での二段階ブートの確立方法 - den8の日記

 

自分でも手短に、これが本ページの"意訳"かな?と思うことを追記しておきます。
MBMや類似のブートローダをMBRにいつでもインストール出来る手段を用意しておきましょう。その上で2段階ブートに統一すれば、"どんな順番でどのOSをインストールしても"マルチブートが実現できます。再インストールの順番も自由です。マルチブートを実現する際の敷居がぐっと低くなります。」
(2009-5-4追記)いま世間で一般的なマルチブートの方法は、日頃から頻繁にマルチブートしている立場からみると不便極まりないです。一般的なgrubの使われ方はおかしいと感じます。またWindows同士のマルチブートの方法に関してもgrubと同様によろしくない方法が一般的になってしまっていると思います。「マルチブートに反対なマイクロソフトの推奨するマルチブートの方法が便利なわけがないのに」って思います。←実はWindows同士のマルチブートの問題については今のところあまり書いていません。でも一応このあたりは参考にして頂きたいと思います。(2009-6-13追記)当ページはWindowsだけのマルチブートにとっても大事なページだと自薦します。(Windowsの)BootmgrやNTLDRを使ってのマルチブートにはgrubを使ってのマルチブートと同じくOS毎のブート環境が独立しない短所があります。そもそも理系や技術系の人間ならば基本パーティションが4個作成できることを知ったその時点でgrubやBootmgrやNTLDRでマルチブートすることの問題点に気付いてもおかしくないと思います。ものごとの対象性や階層構造が自然と気になる根っから理系の人なら多分私と同じように気付くと思います。私はこのページの方法(OS毎のブート環境を独立させる方法)を使ってのWindows複数のマルチブートをWindows95の頃、PCを使い始めた数ヵ月後から既におこなっていました。


 

2007年現在、各Linuxディストリビュータからリリースされている一般的なLinuxの標準的なブート方式は、他のOS(Windows、Solaris、FreeBSD)のそれと比べると特異とも言えます。現在のLinuxの標準的なインストーラが構築するデフォルトのブート環境は1段階ブート方式(後で説明します)です。先に挙げた他のOSは全て二段階ブート方式(後で説明します)を採用しています。このページを読んで頂ければご理解頂けると思いますが、私はLinuxもデフォルトで他のOSと同様に2段階ブート方式を用いるべきだと思っています(※1)。

 

現行LinuxのPC用各ディストリビューションは標準でマルチブート対応のブートローダであるgrubを採用しており、その点ではLinuxとLinux、あるいはLinuxとWindows等のマルチブート環境構築への敷居は一見低そうに見えます。しかし、Linux標準の1段階ブート方式には「各OSのブート環境が独立しない」という大きな欠点があり、一般的なユーザがマルチブート環境の構築で問題に直面し、その状況の理解にも苦労する一因になっています。顕著な影響としては「マルチブート環境を構築する際はOSのインストール順が大切」などと、一般的に認識されてしまっていることが挙げられます。しかし考えてみて下さい。前記の場合においてOSのインストール順が決められていたとしたらそれは大変なことです。インストールに順番があるのなら、当然アンインストールや再インストールにも順番があるということにもなり、余程の上級者以外にとっては「OSの構成の変更」は非常に困難な作業ということにもなってしまいます。「マルチブート環境を構築する際はOSのインストール順・・・」という言葉にはそのような困難さを含んでいるにもかかわらず、平然と当たり前のように言われている現状はかなり問題だと言えるのではないでしょうか。
本ページではLinuxにおいても他のOSと同様なブート方式の環境を構築し、非常に柔軟性の高いマルチブート環境を実現する手法を紹介します。

 

マルチブート環境を構築する際はOSのインストール順が大切」などと巷で言われる原因の99.9%は、

  1. Linuxがデフォルトで1段階ブートを採用していること
  2. Windowsのインストーラが問答無用で機能の劣る(マルチブートに対応していない)ブートローダをMBRにインストールすること

の2つにあると言えるでしょう。この2つが組み合わさることの多いことが解決を困難にしています。
実は1の問題を解消すれば2の問題もMBM等の高機能なブートローダをインストールすることで解消できます。
このページを読んで2段階ブートに統一すれば「WindowsとLinux」, 「Windows複数」, 「Linux複数」あるいはその組み合わせや、Solaris, FreeBSD等との組み合わせも簡単に構築でき、構成の変更も自由だということを理解しましょう。

 

マルチブートはディスクレスOSよりも私の得意な分野です(※2)。しかし、当サイト開設以来今まではマルチブートに関する記述をおこないませんでした。マルチブートの成功には基礎知識が重要だと私は思うのですが、既にネット上に基礎知識の解説を載せたサイトは存在するからです。当サイトのPC系分野にはできる限り独自コンテンツを掲載する方針です(※3)。しかし、私があまりネット探索をおこなわないことも影響しているかもしれませんが、ネット上で私が実践しているマルチブート手法を見たことがないのでここで紹介することにしました。
本ページでCD,DVDのマルチブートは扱いません。それらはカーネルの切替に過ぎません。isolinux,isolinux+memdisk,grub,CDShellなんかを使って実現しちゃって下さい。LinuxのインストールCDを参考にすれば簡単です。追記:USBメモリなんかをsyslinuxを使ってマルチブート化するのも同じくカーネルの切替に過ぎません。本ページでは扱いません。それらはWindows風にたとえると単一ドライブ内でマルチブートしているだけです。

 

(2010-01-22追記)下の追記はあくまでもVista以降を含む複数のWindowsをマルチブートする場合のみに影響する話です。
長い説明が絡み合った文なので元々知識のある方でないと正確に理解するのは難しいと思います。
ちょうどうまい具合に誤解した例が見つかりましたので、これを題材にしてどこが誤解しやすいかを示したいと思います。

このはてなの回答には、私の文に対する二つの誤解があります。

【一つ目の誤解】

  • そもそもこの質問の環境は条件に当てはまらないので下の追記とは関係ありません。殆どの方には言うまでもないと思いますが、この質問の場合ももちろんMBM等を最優先に選ぶべきケースです。

【二つ目の誤解】

  • 下の追記は、条件にあてはまる環境ではMBMを使わないことを薦めるという意味ではありません。たとえVista以降を含む複数のWindowsをマルチブートする場合でも、他にLinuxやFreeBSDやSolarisをインストールした場合は、当然、MBMをインストールすべきです。ここに書いてあるようにMBMとマイクロソフト式のマルチブート手法とは常に並立可能です。

(2009-12-15)重要な追記

【「(Vista以降を一つ以上含んだ)Windows OS複数+他OS」のマルチブート環境の場合は純粋な二段階ブートではなく、「MBM等によるマルチブートとBootManagerによるマルチブートの複合(マルチブート)環境」を推奨します。】

冒頭のこれを読んで頂いたことを前提として以下を記述します。

「NTシグニチャ」という言葉はご存知でしょうか?

当サイトでも何箇所かで取り上げていますが、あらためて説明しますと、Windows NT系OSがハードディスクの識別用として使用する為に各ハードディスクの先頭のMBR内の4バイトの領域にバイナリ形式で書き入れるIDのようなものです。役割をそのまま表す「Disk identifier」と呼ばれることもあります。

NT系OSは起動時に、現在接続されているハードディスクの「NTシグニチャ」と、自身のレジストリ内に保持している、過去に使用したハードディスクの「NTシグニチャ」との照合をおこない、それをその後の処理に生かします。

Vista以降のWindows OS(Vista, Server 2008, 7)では、従来OS(NT, 2000, Server 2003)とはブート方式が変更されたことに伴い、起動時に「NTシグニチャ」がクリアされていることを検知した際の振る舞い(仕様)が変更されました。

従来OSでは起動時に「NTシグニチャ」がクリアされていることを検知した場合、その起動処理の中で、そのハードディスクに新たな「NTシグニチャ」を書き入れていました。いわばOS本体の中に“NTシグニチャ自動修復機能”のようなものがあったわけです。

Vista以降のOSでは仕様が変更され、OS本体から“NTシグニチャ自動修復機能”は取り去られてしまいました。起動時に「NTシグニチャ」がクリアされていることを検知した場合、起動処理はそこで中止し、ユーザに「スタートアップ(環境の)修復」の実行を促す形となりました。ユーザが「スタートアップ修復」をおこなうと、その過程で新たな「NTシグニチャ」が当該ディスクに書き込まれます。

これだけなら「ちょっと不便になったな」くらいで済む問題かもしれませんが、実はこの変更に付随してマルチブートの分野に大きな影響が生じました。

「スタートアップ修復」は単に新たな「NTシグニチャ」を書き入れるだけでなく、複数のWindowsシステムドライブを検出した場合、問答無用でブート環境を“マイクロソフト的な初期状態”に変更してしまうのです。この仕様は従来OSから受け継いでいるのですが、従来OSでは滅多に「スタートアップ修復」をおこなう必要がなかったので影響は限定的でした。

しかしVista以降のOSでは「NTシグニチャのクリア」をおこなうと必ず「スタートアップ修復」が必要になり、格段にその頻度が増えてしまいました。

「『スタートアップ修復』の処理中に複数のWindowsシステムドライブを検出した場合に“マイクロソフト的な初期状態”に変更されてしまう」と書きましたが、これはマルチブート環境を二段階ブートに統一してあって、複数のWindowsのうちどれが壊れようが消されようが、他のWindowsは一切影響受けずに問題なく起動が可能な(理想的な)マルチブート環境に構築してあったとしても、「スタートアップ修復」をおこなうと“そういう状況”は一切無視され、一つのWindowsパーティションから別のWindowsがパーティションが呼び出されるという、Windows OSどうしの独立性の低い(依存性の高い)、マイクロソフト的なマルチブート環境に勝手に作り変えられてしまうということです。

この“勝手な変更”を阻止するには、「スタートアップ修復」を一度でおこなうのではなく、Windowsシステムパーティション毎に個別におこなうことにし、対象外としたいシステムパーティションのPBRを都度、一時的に壊しておいて、修復プロセスにNTFSパーティションだと認識されないように処置しておく必要があります。もちろん壊したPBRをバックアップから戻すという作業も必要になります。詳しくはこちらを読んで下さい。しかしまあ簡単に言ってとても面倒な作業で多くの人にとって実践できるレベルではないと思います。

従ってWindows複数のマルチブート環境で「NTシグニチャのクリア」に起因する「スタートアップ修復」を余儀なくされた場合に勝手に“マイクロソフト的な初期状態”に変更されてしまうのは「仕方がない、あきらめるしかない」と言う他はないと思います。純粋な二段階ブートに統一していても一度の「NTシグニチャのクリア」で統一が保てなくなるくらいなら、最初から純粋な二段階ブートに統一することは諦めた方が賢明だと思います。保てなくても各Windowsをインストールする際に都度パーティションをアクティブにしておけばシステムドライブは常にCになるのでデメリットは「各Windows OSのブート環境が独立しない」という一点に限定されると思います。また「スタートアップ修復」でWindows以外のOSのブート環境は勝手に変更されないのですから、尚更良しとしなければと思います。

結論は冒頭に書いたものになります。

↑(2010-3-7追記)この文章は人様に対して情報を提供する立場として少々保守的な味付けで書いたものです。実際には複数のVista以降のOSを含むマルチブート環境であっても、この記事のような既存環境のコピーをせず、全てのWindowsを個別にインストールすれば、NTシグニチャをクリアしなければならない機会は通常はないわけですから、(Microsoft的なブート手法を併用しない)純粋な二段階ブートでの運用は十分(ほぼ問題なく)可能です。

 

1. 2段階ブート方式のすすめ(頻繁にOSを入れ替える人向けのマルチブート手法)

1-1. 理解する為に必要な知識(各OSのブートの方式)

マルチブート手法の紹介の前に各OSのブート方式を簡単な言葉で説明させて下さい。
(2007-7-18)赤文字の説明を追加しました。

  • DOSおよびWindows全て(Vistaや7も含む)
    MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム
      (多くの人が半ば無意識
      のうちに使用している。
      インタラクティブな選択
      機能はない。
      後述のように他の種々の
      ブートローダで代替可(常にバックアップなしに上書き可))
  • FreeBSD
    MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム
      (インストールを選んだ
      場合にインストールさ
      れるのは、FreeBSD
      独自のマルチブート対
      応ブートローダ。
      後述のように他の種々の
      ブートローダで代替可(常にバックアップなしに上書き可))
  • Solaris x86(Solaris 10 1/06(=update1)以降)
    MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム
      (自動的にインストール       (専用の)grub
      されるのは、Solaris
      独自のブートローダ。
      grubがマルチブートに
      対応しているので、
      以前はあった、インタ
      ラクティブな選択機能
      は省かれた。
      後述のように他の種々の
      ブートローダで代替可(常にバックアップなしに上書き可))
  • Linux(SUSE、openSUSE)2010-5-4:今までは注釈内でLinuxの例外としての記述でしたがきちんと項目として挙げる必要があると思い、ここに追記しました。
    MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム
      (自動的にインストール       grub
      されるのは、Windowsの
      MBR互換のブートローダ。
      後述のように他の種々の
      ブートローダで代替可(常にバックアップなしに上書き可))
    ユーザが普段意識することはないのですが、上に挙げたOSは全て、MBRのブートローダとPBRのブートローダが数珠繋ぎに呼び出されて最終的にOSが起動する形式をとっています(※4)。このブート方式を「2段階ブート」と表記することにします。;
    (2010-5-4追記)上に挙げた2段階ブートの環境がそのままの状態でベストな完成形というわけではありません。しかし2段階ブートに統一すると、MBRにMBM等の高機能なブートマネージャーをインストールすることが可能となり、マルチブートする際の使い勝手が劇的に向上します。こうした意味でOSは標準状態で2段階ブートになっているべきです。
  • Linux(SUSEを除く)
    1段階ブート(← 標準的なLinuxのデフォルト)
    MBRのブートローダ → パーティション内のプログラム
      (インストーラによって       Linuxカーネル
      インストールされるのは
      grub。grub以外にも
      いくつか選択肢がある。
      但しこの状態では安易
      に上書きは出来ない)
    もしくは
    2段階ブート(← オプションで選択可能)
    MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム
      (先にブートローダが        (インストーラによって
      インストールされていな       インストールされるのは
      ければ、 必ずユーザが       grub。変更すべきではない)
      インストールしなければ
      ならない。
      後述のように種々の
      ブートローダを使用できる。
      そのブートローダは、
      常にバックアップなしに上書き可
    からユーザが選択

(2008-2-11追記) 要は2段階ブートの場合、MBRのブートローダをいつでもバックアップなしに上書き可能だというのが最大のポイントです。
ここでも触れているように、MBRのブートローダは意図せず上書きされてしまうことがありますが、2段階ブートにしておけば、そうなっても平気だということです。

1-2. 現在のLinux標準の1段階ブート方式を採用した場合の欠点

前項を一見するとわかるようにLinuxだけ他と違って、デフォルトのブート方式が1段階ブートです。

 

これは1段階ブート方式でマルチブートする場合の典型的なgrub設定ファイルの例ですが、

#boot=/dev/hda
default=0
timeout=5
splashimage=(hd0,1)/boot/grub/splash.xpm.gz

title Fedora Core (2.6.18-1.2849.fc6)
	root (hd0,1)
	kernel /boot/vmlinuz-2.6.18-1.2849.fc6 ro root=/dev/hda2 rhgb quiet
	initrd /boot/initrd-2.6.18-1.2849.fc6.img

title	Debian GNU/Linux, kernel 2.6.17-2-686
	root	(hd0,2)
	kernel	/boot/vmlinuz-2.6.17-2-686 root=/dev/hda3 ro 
	initrd	/boot/initrd.img-2.6.17-2-686

title Microsoft Windows XP Professional
	root (hd0,0)
	makeactive
	chainloader +1

前述のとおり1段階ブート方式には「各OSのブート環境が独立しない」という大きな欠点があり、この例の場合、

  • /dev/hda2を使用しているFedora Coreを削除するとDebianやWindows XPもブートできなくなってしまいます。
  • Debianのカーネルをアップデートした場合、手動でこのファイルを修正する必要があります。
  • /dev/hda1を使用しているWindows XP上の「ディスクの管理」でFedoraのパーティションを削除すると(次回起動時から)Windows XPが起動しなくなります。もちろんDebianも起動しなくなります。
全ての人には通じない喩えですが、プログラミングで「グローバル変数は使っては駄目!」とか、「オブジェクト指向が優れている」とか、言いますよね
Linuxデフォルトのブート手法をプログラミングに喩えて言うなれば、この「グローバル変数をバリバリに使っていたり」、「”オブジェクト指向!”って何?」な状態だと思います。
じゃあ何故、優れたプログラマーの集まりであるLinuxディストリビューションの開発者達がこんな方式を採用してしまっているのかと言うと、その原因はLinuxが「真似(コピー)の文化」だからだと思います。最初に始めた人以外の人達はただ真似をしているだけの傾向が強いと思います。

1-3. 各OSのブートの方式を2段階ブートに揃えた場合のメリット

前項の欠点を解消する為にLinuxでも

MBRのブートローダ → PBRのブートローダ → パーティション内のプログラム

の2段階ブート方式を選択することにしましょう。具体的にはLinuxインストーラのブートローダに関する設定インターフェースで「高度なオプション」等を選んだり「拡張」ボタンを押すなどしてgrubのインストール先を問われた際に「(hd0,?)の形式で指定したり」(Debian, Ubuntu等)して設定します。これによって、マルチブートされる全OSのブートの方式が二段階ブートに統一されます(※5)。

初心者の方向けのアドバイスをしておきます。↑このブートローダのインストール形式に限らず、マルチブート環境の構築を念頭においてLinuxをインストールする際には、とにかくカスタマイズしようとする(orオプションダイアログを表示してみる)ことが原則です。どれくらい徹底的にそうするべきか?はディストリビューションによって事情が異なりますが、そういう決意でインストール作業に臨んだ方が良い結果(望みの環境)を得る可能性が高いと思います。
 

マルチブートするOS全てを2段階ブート方式に統一すれば、MBRのブートローダは「各パーティションのPBRのブートローダ(※6)をコールする」役割だけをこなせば済むことになります。

 

つまり、このようになります。

2段階ブート方式に統一 = 各OS固有のブート環境が独立する
 

これによって1-2で挙げた欠点が解消されます。以下にさらに詳しく2段階ブートに統一することによる特徴を挙げます。

2段階ブート方式に統一した場合の特徴
特徴説明
1各OSは自由にアップデート等がおこなえ、またその際にマルチブート環境であることによる余分な作業が発生しない1-2で挙げたようなカーネルアップデート時の問題は発生しない
2パーティションの大きさをどんなに変更しても、MBRのブートローダ(マルチブート用のブートローダ)及び直接関係のないOSは影響を受けないMBRのブートローダは、ユーザの指定したパーテョションの番号をキーにして、起動される度にパーティションテーブルを読み直すので、パーティションの大きさ変更に全く影響を受けない。それに対して1段階ブート方式の場合、マルチブート用のブートローダとして変更対象のOSのものを使用していると全OSが影響を受けてしまう
3パーティションを一旦削除した上で確保し直したり、パーティションの数を変更しても、MBRのブートローダ(マルチブート用のブートローダ)及び直接関係のないOSは影響を受けない基本的には2と同様に影響は受けないのだが、パーティション数まで変更した場合にはMBRのブートローダの種類によっては影響を受けこともあり得る
4MBRのブートローダを世界中の様々なブートローダに交換できる別の言い方をすれば、MBRのブートローダが別の種類のもので上書きされても、それがマルチブートに対応していれば問題が生じない(SolarisとかFreeBSDのインストール後に既にこのような経験をされた方もいるでしょう)
5全く別の種類のOSにインストールし直した場合でも、MBRのブートローダ(マルチブート用のブートローダ)は変更せずにブートできる但しMBRのブートローダとしてgrubを使用した場合は、事前に設定変更をおこっていなかったからといってブートできないわけではないが、多少の影響を受ける(後述)

※ MBRのブートローダとしてgrubを使用する場合は後述の注意が必要です。

1-4. 2段階ブートの設定の実際

上記1-3を実践するだけです。
現在のLinuxデフォルトの違いをまとめます。

  • MBRのブートローダ
    • MBRには「MBR用のブートローダ」をOSのインストーラに頼らずに自前でインストールする。grubも技術的には使用可能だと言えるが、この用途にgrubは非常に不向き。設定用のパーティションが不要で論理領域のOSもブート可能なMBMの採用を強く推奨する。
    • 「MBR用のブートローダ」としてMBMのような適切なブートローダを採用した場合には、そのインストールはLinuxのインストール前・インストール後のみならず、あらゆるOSのインストール前・インストール後の何時いかなる時期に何度おこなってもいい
  • PBRのブートローダ
    • 各Linuxインストール時には、grubブートローダのインストール先としてMBRではなくPBR(基本的にはそのOSのシステムパーティションの先頭セクタ)を選ぶ。1-3と(※9)を参照して下さい。
 

※少し不親切ですが、詳細な手順(作業の順番)までは記述しません。手順は人それぞれだからです。実際の作業では、Linuxインストール時にインストーラによってMBRにgrubをインストールして一旦は1段階ブート方式の環境を構築し、後から2段階ブート方式に変更する選択肢も十分あり得ます。

 
既存の1段階ブートのLinux環境の2段階ブートへの変更(※)は、このような作業の後に、このパッケージを使用すればLinux上だけで簡単に完了します。

これはUbuntu,Fedora,openSUSE,Debianはもちろん、grubを標準のブートローダとする殆ど全てのLinuxで共通の手順です。※:grub2ならこちら
  • 2段階ブート環境構築の代表的な例(以下の例について、ここには詳しい説明は載せていません)
    • 先にWindowsだけがインストールされている環境に何らかの方法でLinux用のパーティションを確保し(元々の空きパーティションを利用する,新たなハードディスクを用意する,Windowsパーティションを狭める,等で)、Linuxを1段階ブート方式でインストールし、後から2段階ブート方式に変更する
    • まっさらのハードディスクに、最初からマルチブートに適したパーティション群を確保し、Windowsをインストールし、MBM等をインストールし、Linuxを最初から2段階ブート方式でインストールする。
    • まっさらのハードディスクに、最初からマルチブートに適したパーティション群を確保し、Linuxを1段階ブート方式でインストールし、2段階ブート方式に変更し(MBM等をインストールし)、Windowsをインストールし、再度MBM等をインストールする
               ・
               ・
               ・
      他にも無限にパターンは考えられますが、上記の記述が納得できるまで理解が進んでいれば、
      応用も自由自在だと思います。

1-4-1. MBRのブートローダとして、grubを使用する場合(非常に推奨しないけど)

この項は技術的な参考として記述しているに過ぎません。通常は、次の項の方法を使用して下さい。
2段階ブートに統一すると1段目の(MBRの)ブートローダは各パーティション先頭のPBRをコールするだけなのに、設定ファイルや格納するパーティションが必要なgrubを使用するのは、どう考えてもナンセンスです。MBRは様々なOSによって上書きされやすい場所であり、そこ(MBR)のブートローダがパーティションや設定ファイルを必要とすると著しく環境変化に対する耐性を欠いてしまいます。←各Linuxディストリビューション・デフォルト設定によるマルチブートの現況


この場合、Linuxを起動する際には「MBRのgrub」 → 「PBRのgrub」という形で複数のgrubによる”リレー”がおこなわれます。このページに興味を持たれる方ならすぐ理解できると思いますが、様々なOSを起動できるブートローダとしての性格上、grub同士の数珠繋ぎの起動が可能なのは当然です。この”リレー”は無限に可能です。

 

grubの設定ファイルやstageファイルを格納するパーティションは何とか適当に確保して下さい。次節「リモート環境にあるPCをマルチブートする手法」の記述を参考にして下さい。

 
  • MBRのgrub用設定例1
    実際にはこの部分には出来る限りMBMを使用して下さい。(2010-8-23)MBMでのマルチブート画面を追加しました。
    あくまで2段階ブートの場合の「MBRのブートローダ」がどのような仕事をするのかを理解してもらう為にgrubの設定ファイルを用いて示したまでです。
    grubのchainloader機能は「ないよりはあった方がマシかな」程度のもので利用は極力避けるべきものです。
    MBMはchainloaderとして優れた機能・使い勝手を持っています。「餅は餅屋」と言われるようにチェーンロード処理は専門職のMBMに任せましょう。MBMは、WindowsがインストールするMicrosoft謹製のMBR用ブートローダやgrubのchainloader機能の上位互換となる高機能なブートローダです。
    grubは本職のカーネルローダとして大いに利用して下さい。grubを2段階目のブートローダとして使用すること=grubをカーネルローダとしての役目に専念させることです。
    ※この例ではLinuxだけ複数ですが、Windows・FreeBSD・Solaris x86もそれぞれを複数インストール出来ます。(ただしこれらOSは基本的には基本パーティションからしかブートできません。また複数をインストールする為にはちょっとした裏技も必要です)
    ※(2009-3-21追記)Solaris x86のインストーラにはずっと以前から延々と続く欠陥があります。パーティションテーブルのヘッダ(H)の数値が255で1トラックあたりのセクタ(S)の数値が63、つまりH=255,S=63以外の場合にSolarisをインストールするとパーティションテーブルが破壊とまでは言いませんが異常な状態に更新されてしまいます。後から復旧することは可能ですが、それをやり易くする為にも事前にfdisk -lの結果等を保存しておくべきです。保存していなかった場合にはこんな作業が必要になったりします。簡単に言うとH=255,S=63以外の状態で他のOSとマルチブートさせようとの思惑でSolaris x86をインストールすることは避けるべきです。
    (2009-12-3追記)まだ世間ではWindowsは1台のハードディスクに1つのシステムドライブしか作れないと誤解している人がかなりおられるようです。Windows(7,Vista,XP,2K,NT,Me,98,95,2K3)全て、1台のハーハードディスクにシステムドライブを最大4個(拡張領域を使用する場合は最大3個)作ることが出来ます。OS種の組み合わせも完全に自由です。つまり下の図の(hd0,0),(hd0,1),(hd0,2)を全てWindowsの独立したシステムドライブにすることが出来ます(参考:Windowsを同一ハードディスク上にコピーしてマルチブートを実現する方法)
    default=0
    timeout=3
    color cyan/blue white/blue
    title Microsoft Windows (95, NT, 98, Me, 2000, XP, 2003, Vista, 2008, 7)
    	root (hd0,0)
    	makeactive
    	chainloader +1
    title FreeBSD
    	root (hd0,1)
    	chainloader +1
    title Solaris 10 x86
    	root (hd0,2)
    	chainloader +1
    title Linux open SUSE
    	root (hd0,6)
    	chainloader +1
    title Linux Debian etch
    	root (hd0,7)
    	chainloader +1
    title Linux Debian lenny
    	root (hd0,8)
    	chainloader +1
    title Linux Ubuntu
    	root (hd0,9)
    	chainloader +1
    title Linux Fedora
    	root (hd0,10)
    	chainloader +1
    title Linux CentOS
    	root (hd0,11)
    	chainloader +1
         ・
         ・
    title Minimum Ubuntu
     	kernel /vmlinuz
    	initrd /initrd.img
    title Ubuntu Live
    	kernel /ubuntu/vmlinuz 
     iso-scan/filename=/UBUNTU/ubuntu-ja-X.XX-desktop-i386.iso (前の行の続き)
     file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash  (前の行の続き)
     tz=Asia/Tokyo utc=no --                                   (前の行の続き)
    	initrd /ubuntu/initrd.gz
    title KNOPPIX
    	kernel /KNOPPIX/linux fromhd=/dev/hda10 
     bootfrom=/dev/hda10/KNOPPIX/knoppix_v5.3.1CD_20080326-20080520-AC.iso (前の行の続き)
     lang=ja vga=normal quiet noeject (前の行の続き)
    	initrd /KNOPPIX/minirt_kai.gz
       ※直上の2セクションはrescueやユーティリティ用のOneCDLinux。私の場合FAT32かNTFSの
           パーティションに余裕があればそこにOne CD Linux(Live Linux)を置いておきます。
           ただし、このPCのように他に沢山Linuxが入っている場合は本来必要ありません。
    (Ubuntu のLiveについて)
      この例のようにisoファイルのまま利用することをお薦めします。
      isoファイルは無条件にNTFS上に置いていいのですが、カーネルとイニシャルラムディスク(vmlinuzと
      initrd.gz)は、使用するブートローダの対応ファイルシステム上に置く必要があります。
      FATの場合、設定ファイルに記述するパスを大文字小文字を逆にして記述する必要が生じる可能性が高いです。
    (KNOPIX について)(2009-3-14更新)
      私の場合、古いPCにはUbuntuよりKNOPPIXを使うようにしています。
      上記バージョンのKNOPPIX上を使用しているのですが、このバージョンはどうもそのままではisoのままで
      の利用が出来ないようなので、initrdにすぐ下に掲載の修正パッチを加えて使用しています。このパッチ
      ではisoを置いたNTFS等のパーティションをバックアップ先としても使用可能とする為に書き込み可とする
      修正もおこなっています。オプションには適宜使用PCに合わせてxmodule=fbdevとかno3dとかを付加して下さい。
    ダウンロード fileknoppix_v5.3.1CD_20080326-20080520-AC_for_isoboot.patch
    このパッチは本格的なものではなく、自分が使用する為だけに作成した"なんちゃってパッチ"の類です。使用例でオプションが冗長なことからもそれはわかると思います。
     

注意点はLinuxを起動するセクションにはmakeactiveを記述してはならないことです。
●savedefaultやmakeactiveはgrubのバージョンによっては非対応だったりします。その辺は適宜対応して下さい。これら機能はどちらかというと私はあまり使わないです。
●上のサンプルの最後の2セクションはレスキュー・バックアップ・リストア用のOne CD Linuxをハードディスクに内蔵(常備)しておく手法です。こちらも多少参考になると思います。→NTFSのデータ専用ドライブにgrubのstage1,stage2,menu.lst(grubの全て)をインストールする

 

こんな風に記述してもいいでしょう。非常に汎用的で、場合によってはずっと変更しないで済みます。

  • MBRのgrub用設定例2

    繰り返しますが、実際にはこの部分には出来る限りMBMを使用して下さい。
    grubのchainloader機能は「ないよりはあった方がマシかな」程度のもので利用は極力避けるべきものです。
    MBMはchainloaderとして優れた機能・使い勝手を持っています。「餅は餅屋」と言われるようにチェーンロード処理は専門職のMBMに任せましょう。MBMは、WindowsがインストールするMicrosoft謹製のMBR用ブートローダやgrubのchainloader機能の上位互換となる高機能なブートローダです。
    grubは本職のカーネルローダとして大いに利用して下さい。grubを2段階目のブートローダとして使用すること=grubをカーネルローダとしての役目に専念させることです。
    default=0
    timeout=3
    color cyan/blue white/blue
    title OS(Partition 1)
    	root (hd0,0)
    	chainloader +1
    title OS(Partition 2)
    	root (hd0,1)
    	chainloader +1
    title OS(Partition 3)
    	root (hd0,2)
    	chainloader +1
    title OS(Partition 4)
    	root (hd0,3)
    	chainloader +1
    title OS(Partition 5)
    	root (hd0,4)
    	chainloader +1
    title OS(Partition 6)
    	root (hd0,5)
    	chainloader +1
         ・
         ・
    makeactive行が全くありませんが、Windowsを一つだけしかインストールしていない場合は、そのパーティションを元々(そして常に)アクティブにしておけば問題はありません(※7)。
     
  • PBRのgrub用設定例
    各ディストリのユーティリティが作成したそのままを使用すれば良いので省略します。

1-4-2. MBRのブートローダとして、MBMを使用する場合(おすすめ)

サイト内のMBM特集ページ


2段階ブートに統一されている場合に「MBRのブートローダ」として使用できるブートローダは世界中に沢山ありますが、中には基本パーティションのPBRだけしかブートできないものがあります(※8)。Linux等の拡張領域からブート可能なOSを使用する場合にそのようなブートローダは使えません。拡張領域内のパーティション(論理領域)のPBRもブートすることが可能で、且つフリーソフトなMBMをMBR用のブートローダとして使用することを強く推奨します。MBMは国産の有名なブートローダです。
あとの説明は、リンクに任せます。

 

サイト内リンク:MBM(ChaNさんの高機能・マルチブート用ブートローダ)をもっと便利に使う情報とツール
有益な情報やツールがダウンロード出来ます。


サイト内リンク:Windowsを同一ハードディスク上にコピーしてマルチブートを実現する方法
(2009-7-9追加)


参考リンク:OSのインストール順・再インストールが自由なマルチブートの方法
(リンクが切れていたら教えて下さい)

 
 
結論として言えば、マルチブートする際にOSを選択するインターフェースとしてのgrubブートローダの使用は非常におすすめしません。つまりgrubのチェーンロード機能は使用すべきではありません。grubはPBRにインストールして、そのパーティションのOSをブートすること=カーネルロード処理に専念させるべきです。grubでのマルチブートのメリットはその入手性の良さくらいで、機能的にはデメリットが目立ちます。注意点をいろいろ記述しなければならなかったことで、それはご理解頂けると思います。チェーンロードは本来、設定にパーティションや設定ファイルが不要であるに関わらず、grub付属のチェーンロード機能は設定パーティションと設定ファイルを必要とします。著しく環境変化に対する柔軟性を失っています。チェーンロード機能は他のソフトウェアに任せれば良かったところなのに、機能を欲張った為に本来はなかった大きな欠点が生じています。非常に筋の悪い技術の典型(※)です。ただし設定を保存する為にパーティションを必要とする欠点が逆に次節「リモート環境にあるPCをマルチブートする手法」ではメリットとして生きてきます。
※なのに使われている理由は他にGPLで論理領域に対応したローダがなかったからでしょう。
 
冒頭にも記述しましたが、現在の標準的なLinuxが構築するブート環境は改善したほうが好ましいと思います。他のOSと同様に必ず2段階ブート方式を用いる仕様へと変更して、インストーラは、MBRのブートローダとしてMBMに似たブートローダ、PBRのブートローダとしては現行と同様にgrubをインストールすれば良いと思います。またMBRを上書きしたくない人の為にFreeBSDのインストーラのようにオプションも設ければ良いと思います。つまり、現行のFreeBSD、Solaris 10 x86のブート環境のいいとこ取りをするといった感じになります。

2.リモート環境にあるPCをマルチブートする手法

ネットワークブートに関しては専用ページ:ディスクレス化に関する情報をご覧下さい。


ネットワークの向こう側にあるPCをmultibootで使用する手法です。ネットワークブートでのマルチブートと混同しないよう注意して下さい。(御存じの方には当り前のことですが、ネットワークブートでのマルチブートは、ブート方式が共通のOS同士では非常に(あまりに)簡単です。ググって記事が見付からないのは書く必要性を殆どの人が感じないからだと思います。)
基本は前節の手法を使うことにします。
このマルチブート手法に使用可能なブートローダを選択するポイントは以下の1点です。

  • マルチブート用ブートローダのコンフィグレーションを事実上どんなOSから書き込めるFAT上に置くことが可能であること

ということで、当然ながら入手性の面からもgrubをマルチブート用のブートローダとして採用することになります。

 

私はこのような場合、拡張パーティションの中に数十メガバイトの小さなgrub専用のFATパーティション(※9)を確保することにしています。
そのパーティションの中はこんな感じです。

grub----
        |--fat_stage1_5
        |--menu.lst
        |--stage1
        |--stage2
        |--menu.win
        |--menu.lin
        |--win.bat
        |--lin.bat
        |--win.sh
        |--lin.sh

このgrubをMBRにインストールしてもいいのですが、私ならMBRにはMBMをインストールして、このgrub(のstage1)はこのパーティションのPBRにインストールします。つまり3段階ブートとなります。MBRのMBMがこのgrubのバックアップのブートローダとなってくれるからです。(MBMには[F3]でタイマーをセットしておきます。デフォルト起動パーティションを"前回起動と同じ"かスペースキーで確定しておくか、は使い方次第です)その場合fat_stage1_5は使用されません。

 

menu.win

default=0 # menu.linの場合はdefault=1、リモートでsavedは機能しないので記述しない
timeout=1
color cyan/blue white/blue
title Microsoft Windows XP Professional
	root (hd0,0)
	makeactive
	chainloader +1
title Linux
	root (hd0,1)
	chainloader +1

ネットワークの向こう側にあるPCのgrubメニューを操作することはできませんから、この例ではgrub設定ファイル中のどのOSを起動するかを指し示すdefault値を変更することによって、起動するOSを切替えています。

 

※FATパーティションを大きく確保して、その中にレスキュー・レストア用Knoppix等を置いておくのもおすすめです。もちろん、このgrub用設定ファイルにエントリを記述しておきます。各常用OS群から完全に独立しているのでレストア用途にはピッタリです。

 

win.bat

copy menu.win menu.lst
 

lin.bat

copy menu.lin menu.lst
 

win.sh,lin.shはbatファイルからコマンドと改行コードを変えたただけのものです。さらにそのスクリプトを以下のようなスクリプトで呼び出すといいのではないでしょうか? 私はランチャーに登録しています。

#!/bin/sh

if [ "$1" != "-f" ]; then
  zenity --question --title="デフォルトブートOSの変更" --text \
                         "Windowsをデフォルト起動OSにしますか?"
  if [ $? = 1 ]; then
    exit 1
  fi
fi

cd /KYOYU/grub
exec /KYOYU/grub/win.sh

オリジナルのgrubの設定ファイル名はmenu.lstなのですが、ご存知のようにredhat系では設定ファイル名をgrub.confに変更しています。FATのようにシンボリックリンクのないファイルシステムを使用する場合はこの点を明確に意識しておく必要があります。上記説明におけるmenu.lstは適宜grub.confに読み替えて下さい。

この章関連でこんなページを作りました。↓
NTFSのデータ専用ドライブにgrubのstage1,stage2,menu.lst(grubの全て)をインストールする

 

サイト内関連ページ:強力な(?)NTFSのPBR修復法



※1:ブートローダの種類を変更する際に、それを最初におこなったディストリビューションが、そのタイミングを逃さずに他のOSと同様の標準のブート方式に改めておけば良かったと思います。確かgrubを初採用したのはRedHatだと思いますが、今となっては罪つくりなことです。当時既にWindowsがMBRを勝手に上書きすることはわかっていたのに
(2009-12-23追記)MBRがWindowsに上書きされることは阻止できないんだから、上書きされる側は上書きされても困らない構成を取るべきではないでしょうか。その点でLinuxディストリビューター達は何を考えているんでしょうか?同じくgrub2の開発者も何を考えているんでしょうか? FreeBSDやSolarisは上書きされても困らない構成をちゃんととっています。上書きされた場合でもMBM等を再インストールするだけで復旧する構成をとっています。

 

(2007-8-18) openSUSEをインストールしてみると標準が2段階ブートでした。そういえばSUSEは以前から2段階ブートだったような気がします。本文ではメジャーディストリは皆標準が1段階ブートだみたいな書き方をしていますが、こういう例外もあります。ご容赦下さい。10.3はそうではなかった。ただしSUSEをマルチブートするにはいろいろとやっかいな事項があります。インストーラがしつこく独自のパーティション割をおこなおうとするのでこちらもしつもくエキスパート設定を選ぶ必要があります。また大したことではありませんが「Write generic Boot Code to MBR(日本語の場合は汎用の・・・)」のチェックを外さないとMBRに簡単なブートローダがインストールされてしまいます。(2009-3-21)openSUSE11.1をインストールしてみました。相変わらずパーティションテーブルの変更を避けるにはかなりの注意力か経験が必要だと思いました。しかしエキスパートの設定を選ぶ限り、1段階ブートと2段階ブートのどちらを選ばせるかということについて差が殆どなく、好ましいと思いました。あと余談になりますが、拡張領域内の論理領域のPBRにgrubをインストールすると、拡張領域のPBRにもgrubが必ずインストールされてしまいます。確かにこの仕様は殆どの人にとってはそうしてくれた方が好ましいのですが、私の場合、その場所(拡張領域のPBR)は独自に使用することが多いので、インストールしないように指定することも可能にして欲しいです。もちろん後で自分で上書きすれば済むことではあります。

 

(2009-6-13)数ヶ月前にopenSUSE11.1をインストールした際のメモを主体にちょっと書いておきます。
 openSUSEはインストーラが柔軟で様々なカストマイズができ、2段階ブートの指定も、MBRのブートローダの上書きをおこなわない指定も可能なのですが、慣れていない人がそれらの指定を完璧におこなうのはまず不可能ではないかと思えるほど画面構成が複雑となっています。実際どんな感じか書き出します。※簡単なメモ書きをたよりに書いていますので、実際の画面で同一画面上なのか別ダイアログ上なのかは再現できていません。様々な画面のつながりを全て「 -> 」で表現しています。
 既に2段階ブートに統一してマルチブート構成で運用している環境の中の1パーティションにopenSUSEをインストールする場合はこんな感じの設定となります。

  1. 左側ペインで、[パーティション分割の提案] -> [パーティション設定の作成] -> [熟練者向けパーティション設定]を選択する
  2. [起動] -> [ブートローダの設定] -> [ブートローダのインストール] -> [ブートローダの場所]で、
    「ブートパーティションから起動」についてはチェックを外し、「カスタムブートパーティション」についてはチェックを入れる
  3. [ブートローダのオプション] -> [ブートメニュー]で「MBRに汎用ブートコードを書き込む」のチェックを外す

 私自身は一度も間違えずに自信を持ってこれらの指定を正しくおこなえるのですが、さてどれだけの人がこれらを最初から間違えずに、しかも教えられずにおこなえるだろうかと思ってしまいます。まあ必須なのは「熟練者向けパーティション設定」を選ぶことだけで、他は間違っても指定し忘れても後で手直しが効く部分ではあります。
 ただしopenSUSEに限らない話ですが、各ディストリともあまりに「新規にパーティションを作る」ことに拘り過ぎてるんじゃないかと思います。既存のパーティションを検出したなら早い段階で「既存のパーティションにインストールする」選択肢を示すべきじゃないかと思います。


※2:10年近くの間に数百回、研究(?)してきました。


※3:必然的に当サイトのPC系コンテンツはニッチなネタばかり扱うことになります。但しちょっとそのポリシーに反すると思うのがこれ(manの後追いだから)。


※4:FreeBSDはインストール時、MBRにFreeBSD独自のブートローダをインストールしていいか確認してくれます。DOSおよびWindows、Solarisは、既存ブートローダの存在にかかわらず、MBRに独自のブートローダをインストールします。


※5:Linuxでこの形式を選択した場合、インストーラはMBRのブートローダをインストールしません。先にマルチブート対応のMBRのブートローダをインストールしておけば問題ありませんが、そうではない場合には注意が必要です。
また、grubブートローダをインストールするパーティションの指定を誤り、NTFSパーティションのPBRをgrubで上書きすることのないようにして下さい。DebianやUbuntu系の場合は間違いやすいインターフェースなので特に注意が必要です。もし上書きしてしまった場合は、こちらで修復をおこなって下さい。


※6:それぞれ各OSに元々付属しているPBR用のブートローダ


※7:Windowsを複数インストールした場合、個別のシステムドライブを持ち、且つ、システムパーティションを変動させてもシステムドライブを常にCに保つ場合は、makeactiveを記述する必要があります。


※8:WindowsXPのMBRもこのようなブートローダの一種です。アクティブフラグを付け替えることによって基本パーティションにインストールされた複数のOSをブートすることが出来ます。Windows2000のMBRはXPのそれより機能が劣ります。


※9:FAT16パーティションだけではなく、巨大なFAT32のパーティション上にgrubディレクトリを置くこともできます。また、そのFATパーティションをブートしない(データ専用パーティションとして使用する)場合は、そのFATパーティションのPBRにgrubのstage1をインストールすることもできます。

  • 一般にgrubのstage1をインストール出来ない場所
    • NTFSのPBR(先頭セクタ)
    • FATのブートパーティションのPBR(先頭セクタ) ・・・大丈夫だったかも...
    • raidパーティションのPBR(先頭セクタ)
  • (意外にも)grubのstage1をインストール出来る場所
    • 拡張領域のPBR(先頭セクタ) 私は3段階ブートの際よく利用します。でもOSのインストーラに消去されたりします。邪道であることは確かです。事実上3段階以上ブートの場合専用と言っていいでしょう。
    • ブートさせないFATパーティションのPBR(先頭セクタ) ※: ブートパーティションにもインストールは可能ですが意味がないです。
 

※:検索エンジンの誤誘導対策
grubの(再)インストールに関する情報に関しては、当サイト内であれば、
ブート環境の復旧(grub再インストール時の注意点)
grubのインストール
1-3
あたりが参考になると思います。

 

ご要望、ご意見、質問を下のフォームにどうぞ
(でもここより、掲示板書き込みフォームのページに書いて頂いた方が気づき易いと思います。)

  • ずっと困っていたことが、わかり易く解説されていてずごく参考になりました。 -- 赤帽子? 2008-06-07 (土) 02:16:55
  • ビンゴ! MBM->XP/Grub-Ubuntu で、すごく快適。ありがとう! -- キタ? 2009-06-09 (火) 12:37:21
  • MBMというのは初めて聞きました。この方法でやってみようと思います -- やまま? 2009-12-26 (土) 00:41:51
  • 新しいPCを購入するので、今のPCでも実施している grub を使った2段ブートの方法を思い出そうと調べている中で流れ着きました。 今のPCではマスターgrub用に1つ小さなパーティションを用意しているので、無駄ですね。色々と勉強になりました。 そもそも「思い出さないといけない」くらい複雑なのは間違っていると気付きました。 シェルスクリプトのページも非常に参考になります。ありがとうございました。 -- てつ? 2012-06-28 (木) 02:36:22
  • 活用して頂きありがとうございます。 -- disklessfun? 2012-07-08 (日) 23:42:00
  • Windowsだけの環境でもWindows 7まではMBMでいけてメンテナンス性が上がりました。8はブートプロセスの関係でWindowsブートマネージャじゃないとダメっぽかったです。 -- Tatsu? 2012-12-23 (日) 15:44:38
  • 有益な情報ありがとうございます。ちなみにSecure Bootは有効な状態ですか? -- disklessfun? 2012-12-26 (水) 20:48:48
  • MBRなのでSecure Boot自体が存在しない状態です。 -- Tatsu? 2013-01-03 (木) 23:21:42
  • Tatsuさん、当方で独自に検証作業をおこなったところ、Windows 8でもWindows 7以前と同様に、MBMでマルチブート環境が実現できることを確認しました。 -- disklessfun? 2013-02-05 (火) 22:11:35
  • 上記に異論、疑問のある方はここに書き込むなり、メール頂く等の手段でご連絡下さい。当方の検証手順をお知らせしたいと思います。 -- disklessfun? 2013-02-05 (火) 22:17:57
  • 検証する際、各Windows上でフォーマットして作成したPBR間に互換性がないということを前提において作業願います。 -- disklessfun? 2013-02-13 (水) 01:25:51
  • WIN XP Pro 64 上でマルチブート環境を具体的なガイドを望みます -- 長谷川 武? 2013-08-29 (木) 20:57:26
  • このページおよびmbmのページで紹介している手法は基本的に、(1)各OSがLegacy(BIOS)ブートに対応している、(2)UEFI採用マザーボードの場合は「Legacy Boot」を選択している、(3)ブートに関係するHDDもしくはSSDの容量が2Tバイト以下、の条件を満たしている場合に、x86-32bit(i386)OS、x86-64bit(amd64)OSの別なく適用できる筈です。私の場合、同じHDDに32bitのWindows, Linuxと64bitのLinuxを混在させることは日常的におこなっています。64bit版XPについてはわかりません。インストーラに(マルチブート環境構築を邪魔するような)変な機能が含まれていたりすると、厄介かもしれませんね。テスト環境を作って試してみてはいかがでしょうか。 -- disklessfun? 2013-08-31 (土) 08:48:28
  • リモートPCのマルチブートで、起動するパーティションの選択だけでなくパーティションマスク機能なども利用したい場合は、MBRを直接書き換えてしまうのが一番手っ取り早いでしょうか。PBRに制御を移す直前までのMBMの処理をWindowsやLinux等の上で実現できれば操作しやすいのではないかと思うのですが、作る手間がかかる割に需要は少ないですよね。 -- 2014-05-25 (日) 21:07:03
  • 最初の文について:その通りだと思います。2番めの文について:この話は前文に引き続いてリモートPCについての話でしょうか。詳細な理由説明は省略しますが、完全には腑に落ちません。多分「Intel AMT的なインターフェースで起動OSが選択したい」みたいなイメージですよね。UEFIにそんな機能が付けばいいですね。因みに(ご存知でしょうが)「次回起動するOSの選択&次回起動時に見せるパーティションの選択」を高級なOS上でおこなうだけなら簡単にGUI化できます。 -- disklessfun? 2014-05-26 (月) 19:37:29
  • 05-25(日)21:07の者です。AMT的な物を使ったことは無いのですが、想定していたのはそれではなく「OSを起動させる以外のMBMの動作を高級なOS上で」(∵現在のリモートPCでも使えるように&ローカルPCでもシャットダウンから再起動まで放置できるように)です。MBMの機能にこだわらず、自分が欲しい最低限の機能だけ考えたり少し妥協したりすれば、そんなに難しい話でも無いような気がしてきました。ありがとうございます。 -- mil? 2014-05-27 (火) 22:22:20
  • 特別な情報ではないんですが、Windows 10について言及しておきます。ブートに関しては基本的にWindows 8.1以前と同じです。MBMを使ってWindows 10を含むOS群をマルチブート環境にできます。 -- disklessfun? 2015-06-28 (日) 16:43:04
  • マルチブートを主眼にしたPCじゃないんですが、一応の参考として私のメインPCのハードディスクの分割状況を公開します。 ダウンロード filefdisk-l-my-mainpc.txt UEFIのマザボですがMBMでマルチブートしています。パーティション4(拡張領域)は境界に沿っていませんがここはパフォーマンスに関係ないのでそもそも沿わせる必要がありません。Windows 7以降複数のマルチブートは他のページで扱っていますがこの例では実施していません。 -- disklessfun? 2015-07-12 (日) 00:03:47

URL B I U SIZE Black Maroon Green Olive Navy Purple Teal Gray Silver Red Lime Yellow Blue Fuchsia Aqua White