※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

皆様、早速のご回答ありがとうございます。
'kaorin'様ありがとうございます。GRUBの方がWindowsまで見てくれて良いとは思うのですが、今回は私としましては、Windows
のブートでUbuntuとのマルチブートを試したいと思っております。一応、同じHDDでのマルチブート（Vista,W7,Ubuntu）をGRUBからのブートでは、今回の勉強の最初のテストで行いました。何もせずにただUbuntuを最後にインストールするだけで、マルチブートが完成しました。未だ、２台のHDDでは試しておりませんが。一応最終目標がWindows Server 2003(2008)にVista,W7,Ubuntuのイメージを持ち、ワークステーションにマルチブートを展開する（調べる事がいっぱいありますが）。にしております。
でも、ご質問大変ありがとうございます。何でも言って頂けますと大変安心して投稿できます。
'CMasami'様、同じくアドバイスありがとうございます。今回マルチブートをするに当たって、このサイトも読ませて頂きました。他のサイトのトピックも合わせまして、参考にさせて頂き、インストール手順を上記’＃１’のように、同じHDD内なら問題なくマルチブートが完成致しました。また、Ubuntuのパーティションも別に切ってそこへの移動も上手く行きました。でも、どうしても２台目のHDDにUbuntuを
入れてのマルチブートが出来ないのです。
でも、貴重なお時間を割いて調べて頂きまして、大変ありがとうございました。
'hiro'様、具体的な解決案、ありがとうございます。早速試しました所、「esc」キーが効きませんでした。OS選択画面でUbuntu選択後、即「esc」キーを押したのですが、直ぐにエラーメッセージが出て駄目でした。ちなみに、カウントダウン？もありません。
Ubuntu選択後、即下記エラーメッセージが出ました。（前から同じエラーメッセージです）
－OS選択
－即エラーメッセージ表示
　　GRUB Loading stage1.5,
   
    GRUB Loading, please wait...
    Error 17
です。尚、上記メッセージ間には時間差はなく、見た目には即全てが表示されます。
以上です。何か参考になりましたでしょうか？
ちなみに、もしご存知でしたらGRUBをPBRにインストールした場合、Stage1、Stage1.5は何処にあるべきなのでしょうか？
Stage2は、/boot/grub内にあるので通常のプログラムとして起動されるのですね？
Stage1はPBRの最初のセクターに配置されるのでしょうね？そしてStage1.5は？　GRUBのインストールがMBRの場合には
Stage1はブートストラップの中に書かれ、Stage1.5はセクター６２？に書かれるのですか？どうしても繋がりが理解できておりません。ご教示頂けましたら大変助かります。
以上、よろしくお願い致します。

以下のコマンド実行例で使用したのものは，此方の環境で
MBR にインストールした stage1 を stage1.mbr
PBR にインストールした stage1 を stage1.pbr
としてコピーしたものです．

また，「stage1 が 直接 stage2 にバトンを渡すのか？」，「stage1.5 は stage1・stage2 のどちらと同じドライブにインストールされるのか？」は状況によって違います．
以下の内容が orange634さんの状況に当てはまるかは現在の情報からははっきりとは解りません．

== 起動できない理由の推測 ==

stage1 が次にロードする stage1.5/stage2 の存在するドライブは stage1 のオフセット 64 の 1 バイトに格納されています．

$ hexdump -s 64 -n 1 -e'"%d\n"' stage1.mbr 
255

数値 255 は 「ブートドライブと同じ」 を表しています．
grub-install での「ごく普通」のインストールでは stage1 と stage1.5/stage2 は同じブートドライブに配置されますので255 が通常の値です．

/dev/sdb の MBR/PBR に「ごく普通」にインストールした stage1 を /dev/sda にコピーして　/dev/sda からブートした場合，
stage1 は「同じドライブ」の /dev/sda に stage1.5/stage2 を期待することになります．

== 解決法 ==

次の3つの方法が思いつきますが，どれも私には経験が有りません．結果も保証出来ません．人柱覚悟でしょう．

1) 既にコピーした stage1 のオフセット 64(0x40)　の 1 バイトを　hexedit 等で grub の表記で (hd1) にあたる 129(0x81) に書き換え．

2) grub-install で /boot のあるドライブ /dev/sdb とは別のドライブの PBR に stage1 をインストールした上でコピー．
    注:MBR へのインストールではおそらく stage1 は 「同じ」ドライブのセクター 1 に stage1.5 を期待する．

3) grub シェルの setup コマンド または install コマンド(setup コマンドは内部でこのコマンドを呼び出す)のオプションを駆使して
    stage1 のオフセット 64 に stage1.5/stage2 の存在するドライブを明示的に書き込みつつ stage1 をインストール，そしてコピー．

== インストール先を PBR から MBR に換えてメッセージが変わった理由の推測 ==

stage1 が次にロードする stage1.5/stage2 のドライブ上での位置(セクタ単位)は stage1 のオフセット 68 の 4 バイトに格納されています．

$ hexdump -s 68 -n 4 -e'"%d\n"' stage1.mbr 
1
$ hexdump -s 68 -n 4 -e'"%d\n"' stage1.pbr
123044305

此方でブートドライブの位置を調べると，
stage1.mbr が次にロードする セクター 1 には stage1.5 が，
stage1.pbr が次にロードする セクター 123044305 には stage2 が
有りました．

orange634さんの状況で，stage1.pbr を /dev/sda にコピーして /dev/sda からブートした場合，
stage1.pbr は /dev/sda の セクター x ( x はかなり大きい数値)をロードしますが，それは stage1.5 でも stage2 でもありません．
その結果が

orange634さん による投稿:

GRUB_"が表示されてハングアップしてしまいします。

でしょう．

stage1.mbr を /dev/sda にコピーして /dev/sda からブートした場合は /dev/sda のセクター 1 をロードします．そこに以前の

orange634さん による投稿:

色々と勉強を兼ねて挑戦をしております。同じHDDへのインストールとデュアルブート、... 略 ...などです。

の stage1.5 が残っているのではと推測します．
その結果が

orange634さん による投稿:

”ERROR　17”が出てハングアップしました。

でしょう．

私の環境では[sda1]Windows, [sda5]Ubuntuで
MBRはWindowsからでboot.iniからgrub4dosを呼んでいます。
/dev/sdaにStage1.5 , /dev/sda1にntldr , /dev/sda5 は空っぽです。

$ grub-install /dev/sda5
grub> root (hd0,4)
grub> setup (hd0,4)

全てエラー無く完了しましたが/dev/sda5にStage1.5はセットされませんでした、不思議です。
grubコマンドで"embed" Stage 1.5 ファイルを埋め込むと有りますがエラー12となり、、、
う〜ん一日これで楽しみたいですが残念、修復方法の２と３を考えていたのですが昼休みが終わりそうです。

ブートシーケンスのメモ -- grub のソースコードから理解できること

BIOS は MBR のブートローダを呼び出す前に DL レジスタをブートドライブを示す値に設定することになっています．
注：その点 buggy な BIOS もあるそうです．
grub の chainloader コマンドでも DL レジスタを設定してから次のブートローダを呼び出します．

BCD のエントリの記述で stage1 呼び出し時の DL レジスタの値を設定できれば問題は解決できそうですが，Windows の BootMgr のことは全く知りません．
>> 詳しい方にバトンタッチ

以下コードタグによる図式では () 内は次の stage のドライブを指示するため埋め込まれたバイト．
stage1 ではオフセット 0x40 に，stage1.5(Version0.97)ではオフセット 0x21a の位置．
0xFF = 255 : x86 の DL レジスタの値を使用=「ブートドライブと同じ」
0x80 = 128 : (hd0)
0x81 = 129 : (hd1)

* ごく普通のケース

/dev/sda: stage1(0xFF)/MBR → stage1.5(0xFF) → stage2

* 起動ドライブと別のドライブに linux をインストールするケース
  または，着脱可能メディア /dev/sdb に全てインストールするつもりで，grub を間違えて /dev/sda にインストールしてしまう「ありがちな」ケース

/dev/sda: stage1(0xFF)/MBR → stage1.5(0x81)
                                ↓
/dev/sdb:                    stage2

* 同じドライブの PBR にインストールした stage1 をコピーし，BootMgr を使って同じドライブの Linux を選択するケース
  おそらく stage1.5 は介在しない．BootMgr は DL レジスタに期待通りの 0x80 を設定していると推測される．

/dev/sda: BootMgr → stage1(0xFF)/NTFS (→ stage1.5(0xFF)) → stage2

* 今回のケース
stage1 を別ドライブにコピーする場合，BootMgr の DL レジスタ設定を BCD エントリで 0x80 から 0x81 に変更出来ないならば，
stage1 に 0x81 が埋め込まれることが必要条件でしょう．

/dev/sda: BootMgr → stage1(0x81)/NTFS 
                       ↓
/dev/sdb:           stage1.5(0xFF) → stage2

または，stage1.5 を介さない場合で

/dev/sda: BootMgr → stage1(0x81)/NTFS 
                       ↓
/dev/sdb:           stage2

が目標の状態となります．

hir0さん による投稿:

全てエラー無く完了しましたが/dev/sda5にStage1.5はセットされませんでした、不思議です。
grubコマンドで"embed" Stage 1.5 ファイルを埋め込むと有りますがエラー12となり、、、

grub-0.97 の ソースコードによると PBR に grub をインストールする場合，stage1.5 を embed 可能なファイルシステムは JFS と ReiserFS に限られていました．

連続投稿，お見苦しくて申し訳有りません．
机上の論理に過ぎませんが，
#7 == 解決法 == のアイディアを図にしました．
何れも目標は

/dev/sda: BootMgr → stage1(0x81)/NTFS
                       ↓
/dev/sdb:           stage2

の図式です．

1)現状の

/dev/sda: BootMgr → stage1(0xFF)/NTFS → エラー

/dev/sdb:           stage2

の stage1 の埋め込みパラメータ 0xFF を hexedit で 0x81 に変更して目標の図式へ

2) grub-install /dev/sdcX 等として，別のドライブの PBR に stage1 をインストール

/dev/sdb:       stage2
                   ↑
/dev/sdc: ??? → stage1(0x81)/PBR

この stage1 を /dev/sda の NTFS にコピーして目標の図式へ

3) grub シェルのコマンドを駆使して明示的に 0x81 を埋め込んで /dev/sdb の PBR にインストール

/dev/sdb: ??? → stage1(0x81)/PBR → stage2

この stage1 を /dev/sda の NTFS にコピーして目標の図式へ

※規約違反により追放されたユーザの投稿は、ログインユーザにのみ表示されます。

しつこいですが,もう一つ．#11 の「ありがちな」ケースからの変化なので，確実性は高い？

現状の /dev/sda の Win の MBR のバックアップをとって，grub-install /dev/sda で /dev/sda の MBR に grub をインストール

/dev/sda: stage1(0xFF)/MBR → stage1.5(0x81)   BootMgr
                                ↓
/dev/sdb:                    stage2

この stage1 を /dev/sda の NTFS 起動パーティションに移し，バックアップした Win の MBR を /dev/sda に書き戻す．

/dev/sda: BootMgr → stage1(0xFF)/NTFS → stage1.5(0x81)
                                           ↓
/dev/sdb:                               stage2

空論になってはイカンと思って，/dev/sda2 の linux を USBメモリ /dev/sdb の MBR から boot できるよう，
grub シェルで root (hd0,1) に続けて setup (hd1) として，埋め込みパラメータを確認してみました．

/dev/sda:                    stage2
                                ↑
/dev/sdb: stage1(0x81)/MBR → stage1.5(0x80)

stage1 の埋め込みパラメータは 0xFF ではなく 0x81 でした．

したがって，#11 の第 2 図式「ありがちな」ケースと #19 の変化形の 2 図式の
計 3 図式の記述において stage1(0xFF) を stage1(0x80) に訂正します．

hirOさん、einundzwanzighundertsechsさん、GHOさん、kiyoshiさん
皆様、お忙しいのに大変すばらしいアドバイス、感謝いたします。
凄いですね！！　感動です！！
遅くなりました。私は今就活中で、今日インタビューがありました。しかし、３ヶ月の契約でしたので、検討中です。
自宅に戻り投稿拝見致しました。合わせて、できる限りの所で皆様のアドバイスを確認しました。einundzwanzighundertsechsさんの部分では確認できない部分がありますので、またよろしければご教示下さい。
先ず、hirOさんの＃６ですが、云われました menu.lst を変更して試しましたが、全く同じエラーでした。この設定は以前に Ubuntu のパーティションを移動してブートした時に行いましたので間違いなく設定できていると思います。　－－色々とやって行く内に分かったのですが、Error 17はGRUBのO/S選択画面が出る前、出た後にも出るエラーなのですね。今の所、WindowsのO/Sの選択画面は出ますがGRUBのO/S選択画面は出ていません。
einundzwanzighundertsechsさん、大変ご丁寧な且つ詳細な情報ありがとうございます。＃７ですが、大変良く分かりました。ちょうど色々とためしている時に、云われておりますような感じで動いているのでは？とも思っておりましたが、具体的なアドレスの場所とか値、貴重な情報、本当にありがとうございました。私のも確認しましてオフセット６４は２５５でした。そうですか、基本的にStage1,Stage1.5,Stage2は/boot　と同じドライブにありますよね。まさか、GRUB開発時にMBRへインストールされたローダーが
分離され違うパーティションに置かされるとは考えなかったのでしょうね？また、基本的には hd0 がブートになるのですね。
また、hd0 内でのステージの分割までは考えられたのでしょうが、まさかhd0 と hd1~ とかに分かれようとは．．．．と、云う所ですかね？Stage1ではこのブートドライブのパラメーターをちゃんと見ている分けですね。＃２１のテストにより確認された、と言う事にもなりますか？　であれば、単純にGrubシェル、Grub-installコマンドにて、Stage1.5,Stage2のドライブをセットしてもらえれば、良いような気がします？　（余談ですが、hexeditのリファレンスが分からないのですが、よろしければ教えて頂けますでしょうか？出来ればこのブートドライブの値を変えてブートしてみたいので）

”orange634さんの状況で，stage1.pbr を /dev/sda にコピーして /dev/sda からブートした場合，
stage1.pbr は /dev/sda の セクター x ( x はかなり大きい数値)をロードしますが，それは stage1.5 でも stage2 でもありません．その結果がorange634さん による投稿:
GRUB_"が表示されてハングアップしてしまいします。”
納得です。

”stage1.mbr を /dev/sda にコピーして /dev/sda からブートした場合は /dev/sda のセクター 1 をロードします．そこに以前の
orange634さん による投稿:
色々と勉強を兼ねて挑戦をしております。同じHDDへのインストールとデュアルブート、... 略 ...などです。
の stage1.5 が残っているのではと推測します．
その結果がorange634さん による投稿:
”ERROR　17”が出てハングアップしました。”
確かに可能性はありますし、このようであって欲しいです。そうすると良く理解できます。ですが、sda にはWindowsが最初からずっと
一貫して入れてありますので、GRUBを sda に入れた、と言う事はないように思います。また、フォーマットでは、セクター１は消されませんか？もし、消されなければPBRの方では可能性はあるかもしれません。
でも、すばらしい解析です。大変参考になります。ちなみに、GRUBを再度インストールしていた時に、ハタ、と気が付きました事がありますので、下記コピーを添付します。－もちろん、既にご存知の事とは思いますが、これを見まして何か更なるお気づきがあれば、と思い記します。
grub> root (hd1,0)

grub> setup (hd1)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1)"...  17 sectors are embedded.
succeeded
Running "install /boot/grub/stage1 (hd1) (hd1)1+17 p (hd1,0)/boot/grub/stage2
/boot/grub/menu.lst"... succeeded
Done.

grub> setup (hd1,0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "embed /boot/grub/e2fs_stage1_5 (hd1,0)"... failed (this is not fatal)
Running "install /boot/grub/stage1 (hd1,0) /boot/grub/stage2 p /boot/grub/menu
.lst "... succeeded

最初が sdb (MBR)　へのGRUBのインストールです。２番目が sdb1 (PBR) へのインストールです。
勝手な解釈ですが、MBRへのインストール時は、Stage1.5がセクター１から１７セクター埋め込まれる。
PBRへのインストール時には、Stage1からStage2へ繋がり、Stage1.5は埋め込まれない。察する所、Stage1.5はファイルシステムにも関係していますが、実際にはStage1とStage2の距離を繋ぐのでは？Stage1は、わずか５１２バイトです。しかも昔の考えが継承されていれば、単純にファイルシステムも関係なしに、OSブートローダーに繋がれば良かったはずなので。でも、何故Stage1.5が埋め込まれたり、埋め込まれなかったりするのかは分かりませんが．．．全てStgae1.5を使うようにして、Stage1をPBRから抽出する時に、Stage1とStage1.5までの範囲で抽出（トータルで約１０KB)できれば、いちいちStage1.5のために、MBRやPBRのセクター１に飛ぶ必要がないように思われます。これはあくまでも私の短い時間での調べた事なので、間違った解釈をしていましたら、申し訳ありません。取り合えず、長くなりましたので次に続くにします。

あーっ＃２３ではなく＃２２をなしで。
いつの間にかorange634さんの書き込みが、すみません２３ではなくて＃２２です。