GHOさん、アドバイスありがとうございます。
今、その手順にて試しております。結果は後ほど。

orange634さん による投稿:

hexeditのリファレンスが分からないのですが、よろしければ教えて頂けますでしょうか？出来ればこのブートドライブの値を変えてブートしてみたいので

ghex パッケージをインストールすると　GUI の hex エディタが使えるようになります．アプリケーション -> プログラミング に追加されます．

orange634さん による投稿:

確かに可能性はありますし、このようであって欲しいです。そうすると良く理解できます。ですが、sda にはWindowsが最初からずっと
一貫して入れてありますので、GRUBを sda に入れた、と言う事はないように思います。また、フォーマットでは、セクター１は消されませんか？もし、消されなければPBRの方では可能性はあるかもしれません。

念のため

$ sudo hexdump -C -s 512 -n 512 /dev/sda

で確認して頂けませんか？

00000300  00 eb fe 4c 6f 61 64 69  6e 67 20 73 74 61 67 65  |...Loading stage|
00000310  31 2e 35 00 2e 00 0d 0a  00 47 65 6f 6d 00 52 65  |1.5......Geom.Re|

の行が見えたら /dev/sda のセクター 1 に stage1.5 が有ります．

orange634さん による投稿:

grub> root (hd1,0)
grub> setup (hd1)
grub> setup (hd1,0)
最初が sdb (MBR)　へのGRUBのインストールです。２番目が sdb1 (PBR) へのインストールです。

$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /dev/sdb
$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /dev/sdb1
$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /dev/sdb
$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /dev/sdb1

の結果を貼付けて下さい．
もし，前回の試みで NTFS にコピーしたものが保存してあるならば，それらに対し，

$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' stage1.mbr
$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' stage1.pbr
$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' stage1.mbr
$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' stage1.pbr

の結果も欲しいです．

Stage1.5の周辺についてはまた次の機会に．

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

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

#7, #15 で，

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

とだけ記し，コマンドを明記しなかったのは orange634 さんから

grub> setup (hd1)
...略...
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)
...略...
Running "install /boot/grub/stage1 (hd1,0) /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded

の情報(#23)がもらえるかどうか，わからなかったからです．これで setup コマンドが内部で install コマンドをどう呼び出しているかが判明しました．

そのままだと前に説明したように 0xFF が stage1 stage1.5 に埋め込まれます．
「d オプションを追加して (hd1) を示す 0x81を埋め込めるだろうか？ #15 の最後の図式に持ち込めるか？」
と考えていたのです．

PBR に stage1, stage1.5 を介さない場合

grub> install /boot/grub/stage1 d (hd1,0) /boot/grub/stage2 p /boot/grub/menu.lst

または MBR に stage1, stage1.5 を介する場合

grub> embed /boot/grub/e2fs_stage1_5 (hd1)
grub> install /boot/grub/stage1 d (hd1) (hd1)1+17 p (hd1,0)/boot/grub/stage2 /boot/grub/menu.lst

思考しただけで試行はしていません．

grubのHDD認識順はBIOSの設定に従います。
ので、HDD2から起動する場合は、HDD2の最初のパーテーションはgrub上では(hd0,0)として認識されます。
ここは間違えやすいのでrootを設定する場合は、気をつけてください。必ずしも/dev/sda1=(hd0,0)ではないのです。
また起動に際しては、/boot/grub 内の device.mapは影響を与えないと思いましたので（この辺うろ覚え）変更する必要はないかと思います。
ただ、どちらのHDDから起動するにせよ、Ubuntu9.04ならroot (hdX,Y)の代わりにUUIDをつかっていますのでmenu.lstの書き換えなしでUbuntuを起動できるはずなんですよ。

HDD2からの起動で使い続けるなら、Winの起動設定に関しては手を加えてあげなければいけないのですが、今回はそうではないのでその手順は省略してます。

今、Win環境なのであれですが、時間がとれたら再検証してみます。

フォロー有り難うございます、入出力も間違っていたとは。
起動を省く確認作業は行ったのですが、どうも最後のまとめがアウトですね。
grubコマンドの引数は合っているでしょうからUSBデバイスを代用して応用出来るよって事で。

bootファイルの場所を明示する為に(hd1,0)を提案したのですがだめでしたか。
起動順序をHDD2にしたのなら(hd0,0)はおかしく無いですよ。HDD1が起動しないときはmapで入れ替えになるのかな？

einundzwanzighundertsechsさん、有り難うございます。
知ら無い事に興味を持つと、ついのめり込んでしまいます、暫くはハマりそうです。

皆様、夜遅くまで、また朝早くから、ご教示大変ありがとうございます。また、大変お疲れ様でした。
＃１１－大変ありがとうございます。非常に分かりやすいです。流れと今後の最終目標と良く分かりました。また、GRUBの流れが分かり、「もやもや」の気持ちが取れ、スッキリしております。お忙しいのに本当にありがとうございます。
＃１２－すみません、私には、ソースコードから解析出来る能力を今は持っておりません。遠い昔（懐かしいな～）でしたらアセンブラーのプロでしたが、今では命令もかなり変わっている事でしょう。
＃１５－＃１１と同じく大変分かりやすいです。最終目標は良く分かります。
＃１６－hirOさん、コンピューターに触るのが大好きなのですね？私もです。ですから気になった事とかを出来るだけ試してみたいのです。
＃１７－kiyoshiさん、気になる点などをその都度云って頂き、大変ありがとうございます。
＃１９－実際に試させて頂きました。単純に、Ubuntuをsdb1 にCDから印スt－ロして、GRUBを(hd0) にインストールしました。
　　　　　結果、/dev/sda : stage1 (0x80)/MBR -> stage1.5 (0xFF) になっていましたので、そのまま終わりました。
＃２２と＃２７－hirOさん、夜遅くにお疲れ様です。解決策３のサンプルありがとうございます。
＃２８－夜遅くまでお疲れ様です。また、大変ありがとうございます。すみませんでした。＃２９の書き込みと交差したみたいで、
einundzwanzighundertsechsさんの書き込みに気が付きませんでした。まさか、未だどなたか起きておられようとは．．．
本当にありがとうございます。
　－先ず、sda に stage1.5 が入っていました！！　Windowsを入れても、セクター１はそのままなのですね？？
　－他ご依頼の情報添付致します。
00000300  00 eb fe 4c 6f 61 64 69  6e 67 20 73 74 61 67 65  |...Loading stage|
00000310  31 2e 35 00 2e 00 0d 0a  00 47 65 6f 6d 00 52 65  |1.5......Geom.Re|
00000320  61 64 00 20 45 72 72 6f  72 00 bb 01 00 b4 0e cd  |ad. Error.......|
00000330  10 46 8a 04 3c 00 75 f2  c3 00 00 00 00 00 00 00  |.F..<.u.........|
00000340  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000003f0  00 00 00 00 00 00 00 00  02 00 00 00 0f 00 20 02  |.............. .|
00000400
ubuntu@ubuntu:~$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /dev/sdb
ff
ubuntu@ubuntu:~$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /dev/sdb1
ff
ubuntu@ubuntu:~$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /dev/sdb
1
ubuntu@ubuntu:~$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /dev/sdb1
49104896
ubuntu@ubuntu:~$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /mnt/pa1/sdb.mbr
ff
ubuntu@ubuntu:~$ sudo hexdump -s 0x40 -n 1 -e'"%x\n"' /mnt/pa1/sdb1.pbr
ff
ubuntu@ubuntu:~$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /mnt/pa1/sdb.mbr
1
ubuntu@ubuntu:~$ sudo hexdump -s 0x44 -n 4 -e'"%d\n"' /mnt/pa1/sdb1.pbr
17696800

＃３０－kiyoshiさん、いえ、今回はVista/W7からの起動を目的としております。しかし、GHOさん＃８のアドバイスもありましたので
実行させて頂きました。kiyoshiさんのアドバイス、大変ありがとうございます。GRUBでは起動されたHDDが(hd0,0)になるのですね？そして、ROOT=/dev/sdb1は、カーネルから見たファイルシステムでの指定になるのですね？勉強になりました。
また、云われました通り、　geometry (hd0) では、HDD2の内容、geometry (hd1) では、HDD1の内容でした。
cat (hd0,0)/boot/grub/menu.lst　の内容も合っておりました。
云われております通り、全てをUUIDで指定をしていれば問題はありませんでした。今回たまたま ROOT (hd1,0) と ROOT=/dev/sdb1としていたためにブートが出来ず、更に (hd0,0)でブートが出来たので混乱をしました。でも、お蔭様で全て
納得致しました。ありがとうございました。
＃３１－これも良く分かりました。分も簡潔で大変分かりやすかったです。ありがとうございました。
＃３２－kiyoshiさんも夜遅くまで(朝早く？？）お疲れ様です。
＃３４－これがファイナルですね。次の投稿にします。
＃３６－GHOさんも朝早くからありがとうございます。大変良く分かります。確かに、UUIDですとパーティションの移動や切り直しがなければ全く問題なくブートできました。
＃３７－GRUB内のDUMPコマンド、貴重な情報ありがとうございます。
＃３８－了解です。ありがとうございます。

すみません、また長くなりましたので、次に続くです。

すみません、追加で可能性があればと思い記します。
GRUBシェルの'setup' コマンドに、stage1.5 または stage2 用のブート指定（もちろん省略可、通常は省略）のパラメーターを追加して頂けたらもっと簡単にGRUBのインストールが出来るのに？と思いました。ex; stage (hd1), stage (hd1,0)
でも、graub-install や　システムをインストールする時にも追加しなければならないのでしょうね？
これは、あくまでも思った事を書いただけですので、気になさらないで下さい。

他のスレッド https://forums.ubuntulinux.jp/viewtopic.php?pid=36935#p36935 (そちらには書き込みたくない)で
拡張領域「先頭」の「隙間」の話題が出ていたので，

$ sudo fdisk -lu /dev/sdb
... 略 ...
デバイス ブート     始点        終点    ブロック   Id システム
/dev/sdb1   *          63    14988644     7494291   83  Linux
/dev/sdb2        14988645    15759764      385560    5  拡張領域
/dev/sdb5        14988708    15759764      385528+  82  Linux スワップ / Solaris

の状況で拡張領域 /dev/sdb2 に grub をインストールしてみました．セクタ 14988645 には最初の拡張パーティションテーブルが有るだけで，続く 62 セクタは未使用です．

grub> root (hd0,0)

grub> setup (hd1,1)
 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,1)"... failed (this is not fatal)
 Running "embed /boot/grub/e2fs_stage1_5 (hd0,0)"... failed (this is not fatal)
 Running "install /boot/grub/stage1 d (hd1,1) /boot/grub/stage2 p /boot/grub/menu.lst "... succeeded
Done.

fdisk の結果に変化は無く，拡張パーティションテーブルに障りは無かったようです．警告は出るものの bootflag をつけることも可能でした．

コマンド (m でヘルプ): a
領域番号 (1-5): 2
警告: 領域 2 は拡張領域です
...　略 ...
デバイス ブート     始点        終点    ブロック   Id システム
/dev/sdb1   *           1         933     7494291   83  Linux
/dev/sdb2   *         934         981      385560    5  拡張領域
/dev/sdb5             934         981      385528+  82  Linux スワップ / Solaris

個人的に期待していた stage1.5 は embed されませんでした．

$ sudo ./trace-grub.sh /dev/sdb2
stage1 on /dev/sdb2 looks at sector 1514087 in /dev/sda (hd0)
 -> stage2 v0.97 at sector 1514024 on /dev/sda1 looks for /boot/grub/menu.lst
 -> /boot/grub/menu.lst

此方には Windows の MBR は唯の 1 つも残っていないので，/dev/sda の grub からの chainloader で起動実験して成功しました．

Bootflag の設定で標準の MBR からブートできるならば，既存の MBR，基本領域・論理領域の既存の PBR のどれにも触れることが無いのでメリットが有りますね．

ただ，プリインストールマシンでは拡張領域「先頭」に独自の何かが入っている可能性は否定出来ません．

まったく、どこが本来書く場所なんだか解らなくなってますけども、しっぽがここらしいので。

MBRは、本来あの場所で完結するべきで、446Byte+パーティションテーブルです。
かつてのHDDのアドレッシングの方法だったCHSのパラメータにおいて、第二トラックに第一パーティションの先頭があるので、CHSが実際の実装とは異なり、数値だけの存在になった為、続く63セクタは「未使用」領域になっています。位置的に近いことや、パーティション構成に関わらず、最初のパーティションより前で、場所が固定されることから、MBRに加えて使われる領域になってます。
拡張パーティションもMBRパーティションテーブルとほぼ同じ構造をとる（領域も4つ定義できる)再帰的な構造になっており、トラックの先頭にパーティションが存在するという本来の仕様を守った場合、同様に空き領域が生成されます。
ただ、PBRはパーティション構造が崩れると場所が変わりますし、削除、再生成するなど、普通にパーティション操作をした場合にも壊れてしまう可能性がありますし、大きな領域をとりたい場合、普通はパーティション内にまとまったデータを生成するので、そこまでトリッキーなコードで実装されることは無いのではないかとは思います。

ということで、余程ひねくれたシステムじゃない限りはそんなことはしないんじゃないかと。
空間が存在するのは盲腸的な仕様によるもの。使えるけども大きさも小さいので、何か補助的なデータの保存に使われることはあっても積極的には使われないと思われます。
心配だったら、全部バックアップして障害時に書き戻せば良いんじゃないかと思われます。

仕様の穴なので、積極的に使うことは無いと思いますから、普通のWindowsなら大丈夫だと思います。^^;
前述のように「起動周りでちょっと足りない」ときに使われてしまう場所なので。
容量が欲しければ、システムコマンダーの様にファイルシステムにメインモジュールを生成するか、MBMの拡張メニューのようにファイルシステムの最終シリンダに間借りするなどするんじゃないかと。
ただ、特殊な機能（セキュリティーや、バックアップ、ファイルシステム周り）が実装されている場合は要注意ですが、民生品のPCはそこまで凝ったことははしないでしょうし、特殊な機能、実装が明記されていない機種で気にするのは「あの人」みたいに過剰な心配だと思いますよ。
わざわざシステムから見にくい穴に埋め込むような処理って悪意のあるウィルスか、余程トリッキーなシステムの深い場所で動作する物だと思いますので、そういう物が広告にも載ってないことはないんじゃないかと。
Gobackとか、パーティションテーブル丸ごと握られた上にMBRまで乗っ取られてしまうとちょっと普通の方法での共存は難しいですけど。

あとは、リカバリ等で使われるMBRのコードがきちんとブートフラグを見てくれるかって問題が有りますが…。
その辺りはどうでしょうねぇ？

こんにちは。Grubをインストールした領域にbootフラグを立てる件、目から鱗です。ありがとうございます。

あとは、リカバリ等で使われるMBRのコードがきちんとブートフラグを見てくれるかって問題が有りますが…。
その辺りはどうでしょうねぇ？

https://forums.ubuntulinux.jp/viewtopic.php?id=4690
のように、リカバリー領域にブートフラグが立っているのに、普段はブートフラグのないWindowsの領域からブートする不思議なシステムもあるようです。
（どんな仕組みなんだろう）
「０」を押しながら電源を入れるとブートフラグのあるリカバリー領域から起動するようです。

このようなPCでGrubをインストールした領域にブートフラグをつけると、「０」を押して起動するとUbuntu、普通に起動するとWindowsとそれはそれで素敵なデュアルブートになるかも知れませんが・・・・。
初心者が迂闊にブートフラグを移動すると本来あるべき場所を見失う可能性もありそうです。