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

#23の
$ sudo apt-get install grub
を実行。無事インストールされたようです。

$ sudo grub-install /dev/sda
を実行。

Probing devices to guess BIOS drives. This may take a long time.
Searching for GRUB installation directory ... found: /boot/grub
Installing GRUB to /dev/sda as (hd0)...
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(fd0)    /dev/fd0
(hd0)    /dev/sda


＃２４の
$ sudo parted -l
を実行。

モデル: ATA WDC WD20EARS-00S (scsi)
ディスク /dev/sda: 2000GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
1    1049kB  99.6MB  98.6MB  ext4
2    99.6MB  4100MB  4000MB  linux-swap(v1)
3    4100MB  2000GB  1996GB  ext4


警告: /dev/sr0 を読み書き可能な状態にオープンできません(Read-only file system)。/dev/sr0
は読み込みのみ可能な状態でオープンされました。
エラー: /dev/sr0: ディスクラベルが認識できません。 

と表示されました。

　10.04は試してないんですが、中身がどうでもよくて新規でインストールするのなら、最初の数ブロックをZeroFillしてしまってから、クリーンインストールしてどうなるか確認してみてほしいような気はします。
　何か読み落としているのかもしれませんが、流れ自体がすごく妙です。

　まず、WDのあのドライブは、ファームの実装がいい加減なので、自分の物理セクタを申告しません。
　型番から分岐処理していれば別ですが、ソフトウェアからみた場合、通常のHDDと同じように見えてしまうので、ファームに特定パターンにおけるバグでも無ければ、挙動が変わりようがありません。従って、物理セクタ境界をまたいでアクセスした場合の極端なパフォーマンス低下による、タイミングの変化くらいしか、問題は基本的には起きないはずです。
　従って、WDのアレが原因ということは考えにくく、また、2TBといっても、そのセクタの最大値はMBRパーティションでもオーバーフローする範囲にはなく、容量にも特殊条件は存在しません。
　もし、この容量で勝手にGPTを基準にシステムを作るようになっているのなら、それはバグに近い挙動であって、報告されるべき物であるかと思いますし、そうであれば、LBAによる最大セクタが、データシート上で同一であるWD20EADS、SEAGATEの2TB等も同じ挙動を示すはずです。
　現実問題として、今現在は、BIOSはEFIを利用されることはまず無く、旧来のMBRパーティションと、BIOSを基準とした動作をしています。が、パーティションテーブルの表現可能な値の範囲の問題から、パーティションとしては、GPTを理解するように実装するようになっています。
　しかし、GPTパーティションをBIOSは理解しませんので、基本的にEFIを持っていないと起動デバイスとして利用できません。
　grub2は、GPTを理解するので、BIOS管理下からGRUB2を起こしてやれば動作するのもまた普通の挙動です。

　また、GPTパーティションは、MBRパーティションをEFIで確保されていると登録し、実パーティションは、GPTパーティションテーブルに記載されます。
　従って、どちらからみても、破壊されないようになっているはずなのですが、前述の通り、現状、無指定、自動設定でインストール時に選択されるべきパーティションテーブルの形式は、MBRパーティションの方が利便性は高く、容量だけをみて、EFIを前提としたインストールをしてしまうのなら、インストーラの容量確認か、ロジックにバグでもあるんじゃないかと思われます。
　逆に、何らかのインストールプロセスや、それ以前の操作によって、一度でもGPTパーティションを選択した（Vista以降のPCで領域確保、フォーマットをGPTを指定して行うなど、明示的にGPTの利用を宣言)した場合、それはそのディスクが、GPTパーティションを利用しているという情報が書き込まれるわけですから、破壊を防ぐために選択されるのは真っ当な動作であると思われます。

　ということで、HDDに何らかの残骸が残っている状態で操作をしても純粋な初期動作とはならないので、システムとしては「なんか、GPTつかってるっぽいからそうなのだろう」という前提で動作をする可能性はあり、それ故に何度やっても同じようになっているように見えます。
　本当に購入直後のPCにインストールして、この挙動なら、本体BIOSにEFIの動作をシステムから認識させる仕掛けがあるか、インストーラに誤動作の原因を抱えているようにも思います。

　#29は、4KiBセクタHDD対応も含め、シリンダ境界からの開始をやめ、8の倍数のセクタからパーティションを切るようにした結果だと思いますので、気にする部分ではないです。
　これらの対応は、10.04で入っているので、それ以前と挙動が違うことには問題はありません。
　XP以前のWindowsインストーラはシリンダ境界であることを確認していたはずですが、CHSパラメータ自体が過去の遺物ですので、だいぶ前から慣習のようなものですから、起動不良、インストールの不具合の原因になることは無いかと思います。
　購入直後、もしくは、ZeroFillされたドライブに対する新規インストールであることを担保する記述は見あたらないため、どうもそのあたりが怪しいように思うのですがどうでしょう？

　というか、基本的に今の中身が必要か？を確認して、無理矢理いじくり回してそれを起こすより、スタンダードな状況を作って新規で入れてもらう方が場合によっては最適解の気がするのですけども。
　もし、今HDDにあるデータが不要、もしくは、必要な物をバックアップすることが容易ならば、現状書き込まれているデータの影響、干渉を避けるため、一度HDDをZeroFillしたうえで、クリーンインストールを試みるのも手かとは思います。

　Data Lifeguard Diagnosticでも可能なはずです。
　今回の場合は、とりあえず「残骸がありそうなら壊してみよう」ということなので、ddコマンドでも良いのですが、純正ツールならチェックも兼ねますので、問題のあるセクタがあれば代替してくれるはずです。
　基本的にはパーティションテーブルがありそうな場所だけで良いのですが、何に引っかかってるのかわかりませんので、時間があるようなら全消去だと、読み出される物は無くなりますから確実かとは思います。
　HDDも輸送時の問題や、初期不良がありますので、容量が大きい物は最初に念のため、こういったツールで一度は異常の有無を確認しておいた方が、運用や、データの保存には安心です。
　初期不良は多くの場合、運用開始直後に出やすいですし、エラーセクタなどがあって、交換する場合、長く運用するほどバックアップは面倒になりますので。

　また、「別のOSを入れる」事ではなく「利用したか？」が問題でもあります。
　前述の通り、Vista以降では、GPTパーティションでのフォーマットがOSから可能になっていますし、パーティションテーブルを作成した時点で、少なくとも区分けとパーティションのデータは書き込まれてしまいます。ですので、そういったデータを書き込んでいないか？というのは一つの条件であると思います。

　なお、書き込んだものも、BIOSとパーティションの関係はちょっとおかしかったですね。
　基本的にはブートコードに遷移した時点で、そのローダが理解できないと起動できないわけですので、BIOS自体はパーティションを意識した動作はしないです。
　ただ、一般的にMBRに書き込まれるブートコードはMBRパーティションテーブル以外を（コードサイズの制限もあり）認識できないので、GPTパーティションは多くの場合、2TiBを超えたセクタサイズを利用しない場合、可搬性、利便性の面で、現状は劣ってしまうのは事実です。

　なお、開始位置が違うのは、Vista以降のWindowsでも同じようにパーティションが生成されます。
　これが従来通りになっていると、Alignされていない部分にあるデータのアクセス速度は極端に低下しますし、おそらく、10.04よりも前の物では、このドライブでは速度が低下していると思われます。

　また、VirtualBoxで、8GiBのHDDイメージに、ディスク全体でインストールした場合は、GPTパーティションテーブルにはなっていなかったようです。

まったく見当はずれかもしれませんが、

R2D2C3PO による投稿:

インストール後、ＬｉｖｅＣＤを取り出してリターン　→　再起動　で
No bootable device-- insert boot disk and press any key

BIOSでSATA HDDをAHCIで使うかそうでない(CompatibleやIDE等の名前)かを設定する場所がありましたら、AHCIを使わないよう設定できますでしょうか？
また、その設定だけではOSが起動しなかった場合、AHCIを使わないよう設定された状態でもう一度インストール作業を行ってみてください。

横から失礼します。

R2D2C3PO さんの投稿:
＃２４の
$ sudo parted -l
を実行。

モデル: ATA WDC WD20EARS-00S (scsi)
ディスク /dev/sda: 2000GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
1    1049kB  99.6MB  98.6MB  ext4
2    99.6MB  4100MB  4000MB  linux-swap(v1)
3    4100MB  2000GB  1996GB  ext4

を見るに起動したいHDDに起動フラグを設定していないのではないかと思います。

ack さんの投稿:

まったく見当はずれかもしれませんが、

R2D2C3PO による投稿:

インストール後、ＬｉｖｅＣＤを取り出してリターン　→　再起動　で
No bootable device-- insert boot disk and press any key

BIOSでSATA HDDをAHCIで使うかそうでない(CompatibleやIDE等の名前)かを設定する場所がありましたら、AHCIを使わないよう設定できますでしょうか？
また、その設定だけではOSが起動しなかった場合、AHCIを使わないよう設定された状態でもう一度インストール作業を行ってみてください。

Ｎｏ bootable device ということは、起動用のドライブではないといっているだけではないのでしょうか。
ＬｉｖｅCDでHDDのＢｏｏｔフラッグを設定すれば、動くのではないかと。
私も９．１０から１０．０４のアップグレードでDISK BOOT FAILURE　とか　ｎｏ ｓｕｃｈ disk とか No bootable device-- insert boot disk and press any key とか、修復に一晩かかりましたので．．．
ＬｉｖｅＣＤでHDDにＢｏｏｔフラグを設定してください。

うまくいけばいいのですが。

MBRパーティションに実パーティションが無いですね。
ということで失敗です。
フォーマッタとか、パーティショニングする側というより、インストーラにもしかすると容量判定のバグがあるのかもしれないですねぇ。
自動じゃなくて、明示的にパーティション容量指定してもだめなんでしたっけ？
後は、設定項目があればそれなんですけども。

9.10LiveCDを用いて、あらかじめパーティションつくったり・bios-grub領域つくったり（この設定項目が10.04では無いのですが、、、わたしだけでしょうか？）いろいろやってみたのですが、一向に上手くいきませんでした。

最初から数えると通産数十回インストール作業をくりかえして、正直疲れました。（容量大きいのでやたら時間かかるし）
いまだ、私自身の一人相撲の可能性も否定できませんが、ほんとにバグがあるのかも？って話なので、はやいとこ改善されるといいなとおもいます。（10.10では直ってるといいな）

私個人はインストール自体よりもインストール後にやりたいことのほうが重要なので、これ以上の検証とかは止めようと思います。

たくさんＲｅｓいただいた方々、ありがとうございました。

　何となく書かれている内容に納得がいかないのでテストをしてみました。結果から言えば時間の無駄。やりとりしているときにきちんと整合性を、机上値も出して確認しないとろくな事にならない典型。質問者の理解や、作業の質をあてにしてはいけないし、その気があるのなら、回答する側も、確認までしないとだめらしい。

　テスト環境は、ATOM-GM1-330とちょっとばかり色物ではあるものの、チップセット、CPUは質問者と同じ物であり、BIOSのコンフィギュレーション等の違いこそ考えられるが、概ね同じような物である。
　HDDは、手持ちにこれしかないので、中身を他に移し、WD20EADSを利用したが、残りは本題に関係すると思えないため割愛。尚、チップセットや、価格帯もあり、ATOMで多く使われる945系のチップセットには、RAIDだのAHCIだの気の利いた機能なんて物はない。

　次。#39のコードによりGPTパーティションが初期値としては自動処理において判定、設定されることが提示されている。
　どっちにしろ、「2TiB以内」なら、MBRパーティションの表記内に有るため、勝手にGPTを設定するのはやはりどうかしてると思われ、2TiB「より大きい」が正しいとは思う。
　とりあえずインストーラが起動しないシステムを入れるなんてのは論外なので、インストールオプションは、「ディスク全体を削除してから使用する。」を使い、標準的な新規インストールを試みる。
　ほぼ自動インストールであるため、設定項目はアカウント程度しかなく、設定可能な設定項目は初期値のままでインストールを実行した。
　結果から言えば、動作するシステムが作成された。
　パーティションタイプは、MBRパーティションにはGPTに設定され、始点から、終点に掛けて、GPTとして、宣言、確保されている。
　GPT部分の情報は下記の通り。EARSでも、セクタサイズが同じであるように、基本的にソフトウェアから区別をすることは出来ない。
　開始位置が1059kBになっているように、無条件にAlignされているのと同様の位置からパーティションは生成されている。

モデル: ATA WDC WD20EARS-00S (scsi)
ディスク /dev/sda: 2000GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
1    1049kB  2097kB  1049kB　　　　　　　　　　　　　　bios_grub
2    2097kB  1990GB  1990GB  ext4
3    1900GB  2000GB  10.0GB  linux-swap(v1)

　パーティションについては、きちんとgrub2用の領域も用意され、インストールプロセスでもきちんとgrub-installが実行しているため、grubは起動可能な構成できちんとHDDへと書き込まれているし、処理に抜けはなく、問題はない。
　但し、これらは自動設定の内容であり、自分でパーティションを切ったのならその限りではないことは自明。
　これで動かなければ大笑いなのだが、残念ながら至極まっとうな動作をしていて悩むべきところすら見つからないし、動いているのだから騒ぐべきバグも存在していない。

　が、基本的に、これは自動設定し、且つ、HDD全体を利用して良いと宣言した場合のインストールなので、MBRパーティションテーブルでもインストールは可能なのかも確認しておく。こちらなら、grub2は別パーティションを必要しないはずである。
　この辺りで、作成しているパーティションが、インストーラに指定された物ではない構成をしつこく試していることを回答側は認識すべきだったのかもしれない。

　ということで、MBRパーティションへのインストールもテスト。
　gpartedによって、パーティションテーブルそのものをMBRパーティションで宣言し、インストールを実行する。
　手順としては、gpartedにて、メニューバーのデバイスをクリック、パーティションテーブルの作成で、デフォルトであるmsdosを選択すれば完了である。適用後、インストールを実行する。
　今回はパーティションを明示するため、「手動でパーティションを設定する（高度な知識が必要です）」の項目で続行する。
　インストール時には、パーティションを手動で設定し、質問者の希望に合わせ、/bootに100MB、LinuxSwapに4096MB、残りに/を割り当てた。
こちらも当然ながらまともに起動する。
起動後、fdisk -lの結果は、
ディスク /dev/sda: 2000.4 GB, 2000398934016 バイト
ヘッド 255, セクタ 63, シリンダ 243201
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x00096730

デバイス ブート      始点        終点     ブロック   Id 
システム
/dev/sda1   *           1          13       96256   83
Linux
パーティション 1 は、シリンダ境界で終わっていません。
/dev/sda2              13      243202  1953416193    5 
拡張領域
/dev/sda5              13         511     3998720   82
Linux
スワップ / Solaris
/dev/sda6             511      243202  1949416448   83
Linux
となっており、異常はない。つまり、MBRパーティションテーブルを用いたインストールも、#39での提示の通り可能であり、ここでも起動しないシステムが書き込まれるという事態は発生していない。
ただし、パーティション作成時に、パーティションテーブルを初期化することも可能であり、それを行った場合、パーティションタイプが変更される可能性がある。WD20EADSで行った場合は実フォーマット時にGPTに変更された。

これらのインストールの成功については再現性があり、どれも異常は示さない。従って、修正すべき問題も存在しない。

結果から推測できることは、インストール時にパーティションテーブルを初期化していて、その際、選択されるパーティションテーブルに選択肢はなく、容量からインストーラが設定するパーティションテーブルはGPTになってしまい、grub2がインストールされるためにはgrub_biosパーティションを必要とするにもかかわらず、全体を用いた設定も行わず、且つ手動設定によって、それらの作成も行わないため、grub2がきちんとインストールされず、結果、起動できないシステムが書き込まれるという結果に至っている可能性が高い。
http://www.ibm.com/developerworks/jp/linux/library/l-grub2/?ca=drs-jp
ということで、基本的にはGPTへのインストール時、EFIではないシステムから起動する際には、パーティションにモジュールが必要ということらしい。
また、手動でのパーティション作成時には、gpartedと違いフラグの編集が存在しない。
従って、bios_grubフラグを指定することはインストーラ上からは出来ないのが強いて言えば不親切ではあるが「（高度な知識が必要です）」と書かれた項目を選んでおきながら、ブートストラップに必要な条件を認識せずに設定不足で起動しないのをインストーラに責任転嫁するのは無理があると思われる。
ただ、最後にgrub_bootフラグ付きのパーティションを作らずにGPTへインストールしてみたが、それも問題なく起動してしまっている。それが動作したシステムの残骸による物かどうかは不明だが、MBRパーティションテーブルへのインストールが可能である以上、動作するシステムをインストールすることは不可能ではないはずで、検証としては必要充分と判断した。面倒くさい上、起動しないシステムを作るという不毛な作業をする気もないので、検証もしない。
MBRがBIOSでProtectedになっているなど、ブートローダが書き込まれないなどの状況がなければ、起動できるシステムをインストールすることは難しくないはずというのがテストの結果。
似たようなシステムでも問題は出ないので、手順でデフォルト値以外の指定をしている場所があればそれが原因と考えられる。

>MBRがBIOSでProtectedになっているなど、ブートローダが書き込まれないなどの状況がなければ、
　というのは、実際にインストーラは必要な作業を実行していると思われるので、ブートローダのインストールを拒絶する要素は、エラーで止まるか、書き込みが禁止されるかであるという推測に基づきます。
　それに続く行については「普通に設定すれば、起動するように適宜設定される」という意味しかありません。もっとも選択肢の少ない自動に近いインストール項目では少なくとも起動可能なシステムが構成されることは確認しています。

>このとき、2TiB以上だとGPTになるものの
　2TiB≠2TBです。実際にMBRパーティションテーブルで問題になるのは2TiB境界なので、2TBでは判定の必要は無いと思いますが、実際にはGPTで構築されます。
　ただし、この場合も、起動に必要なパーティションは作成されているので問題はありません。

>あらかじめGpartedでMSDOSパーティションテーブルを切っておき
　手順では、「MBRパーティションテーブルをGpartedで明示的に作成している」だけで、切っては居ません。
　空でも問題はないと思いますが、インストーラでのパーティション作成時には、デバイスを選択した場合、パーティションテーブルの初期化が可能になっています。その項目には選択肢がないため、MBRパーティションが書き込まれていてもそこで初期化してしまうと、条件によっては、GPTになってしまいます。

>あらかじめGpartedでGPTを作成しておいてbios_grubのパーティションを作成しておいて、インストーラーのパーティショニングで手
>動を選択してbios_grubのフラグを付けようとしても・・・bios_grubのフラグを付けるのが無理なので、問題が生じそうということでしょ
>うか。

　「手動」でパーティショニングするわけですが、インストーラ側ではフラグが制御できません。
　が、事前に用意されたパーティションは前述のような作業をしなければ非破壊のはずなので、事前にbios_grubのフラグを立てた領域を作成しておいた上で、インストーラを起動し、インストールすれば、恐らくおっしゃりたかっただろう事は実現できるかと思いますし、最後にgrub-installも実行されているはずですので、きちんとモジュールが入る場所を確保できる可能性はあります。
　作業としては通常のインストールのフローを崩さずにテストすることが目的でしたので、それらの提示は無視しています。
　bios_grubフラグの付いたパーティションが無い場合起動できなければ試すこともあったかもしれませんが、起動できてしまったので、追試をしていません。
　「GRUB 2 は /boot ディレクトリーの中のファイルに対応するディスク・セクターのリストを利用します。そのファイルシステムを何らかの理由で調整すると、セクター・リストが無効になり、GRUB のブート機能が使えなくなる可能性があります。そのため、GPT ディスクの場合は BIOS ブート・パーティションを使うことを強く推奨します。」ともあるので、恐らく私の環境では、/bootディレクトリ配下に必要な物を書き込んでくれた物と思われます。ですので、必ずしもパーティションが無くても（環境変化には弱くなりますが）起動するシステムは構築できる可能性の方が高いです。
　ただ、別の版のUbuntuを質問者はインストールできており、MBRパーティションを利用した場合なら、問題なく動作しそうな気がするので、情報としては必要十分であると考えています。

　編集できないので、追記になってしまうのですが、結論も経緯も間違っていたように思いますので、補足という形で一部訂正です。

　編集できないのもいろいろ問題がありそうです…。

　さて、GPTパーティションにおいても、質問者と同様のパーティション構成でのインストールを行い、起動できています。
　事前に頭から2MiB程の領域をゼロクリアしても同様なので、bios_grubフラグの付いたパーティションが無くとも、grub2が理解するパーティション内に書き込めれば、起動は可能であるというのが実情と考えられますし、実際そのように構成されますので、起動は可能です。
　インストーラはファイルシステムを作り、ファイルを転送し、最後の辺りで、ブートコードを書き込んでいますので、基本的には前提条件特殊なファイルシステムを指定しない限りは満たします。
　実際に書き込まれる位置や、状況を考えた場合、パーティションタイプの変更を行い且つ、事前に直前に書き込まれるであろう場所の破壊をした場合、残骸により偶然動作するということは考えにくく、少なくとも、その構成は推奨であり、必須ではないわけですから、該当フラグが存在しなくとも、起動すること自体は、おかしな事ではありませんし、少なくとも、ここに起動実績が存在することを明示しておきます。

　無視されていることですが、No bootable device-- insert boot disk and press any key.はgrubのバイナリに存在する物ではありません。
　誰が吐いているのか？といえば、これは、マザーボードのBIOSという話になります。
　少なくともMBRパーティションには署名が確認でき、仕様としては有効なMBRとなっているので、あとはMBRに有るべきgrubのコードがあるかどうか。存在した場合、BIOSがMBRのブートストラップコードに処理を移さないというふざけたことをしているのが原因と言えます。
　本来、BIOSはパーティションテーブルを認識せず、起動デバイスの最初のブロックが有効であれば、そこへ処理を移すのが仕事です。
　が、「起動デバイスではない」と判断するということは、処理を渡していないと言うことで、それ以前に蹴られる原因があるということです。
　ブートフラグが存在しなくても、それを解釈、停止するのは、MBRのブートストラップコードの役割であり、処理を渡していないのではその次点で止める権限がある仕組みは本来は有りません。

　http://d.hatena.ne.jp/lllliiii/20081001
　上の様なケースもあり、「必ずしもUbuntu 10.04だけ」で発生している物ではなく、パーティション構成の変更によって状況が変わっていることから、BIOSが余計なことをして判断している可能性は高いです。
　少なくとも10.04は最初のパーティションの開始位置までに隙間があります。場合によっては、パーティションを詰めるか、数を変更するなどした場合、その制限を抜ける可能性があります。
　10.04がその地雷を踏んでいるのは確かだと思われますが、明らかにわかっているのは、2TBの条件分岐と、パーティション開始セクタの位置あたりくらいです。
　ただ、これはハードウェア固有の問題ではなく、BIOSの実装側の問題なので、同一機種、同一版のBIOSでなければ、条件の検証は出来ないと思われます。
　各々のケースで、ブートストラップコードが書き込まれているのか？それが有効なのか？は検証できる資料が無いのですが、別の同様のブートローダはインストールできているのであれば、書き込まれている可能性は高いと思われますが、質問主は、別の手段で回避しているので、これ以上の進展は無いと思われますし、既に終息に向かう製品ですから、重要度も高いとは思えません。

　以上のことから、このトピックのケースでは基本的にはブートローダの問題としてとらえることは正しくなく、別のケースに実績を当てはめることは間違っていると考えます。
　ブート条件については、環境依存のケースもあるかと思いますが、先の実験結果で普通につっこめば普通に動作するということで問題はないと思われます。

　また、基本的には、利便性、ノウハウの蓄積、可搬性等の問題で、明示的にGPTを使うべきケースは「普通の質問者」には少ないと思われます。何らかの問題が発生し、それが非破壊を要求しない場合は、小細工によって動かすような誘導は不適であると考えます。
　勿論素直に動くときや、必要なときは別ですけれど。
　MBRパーティションを前提とすることで、多くの人が持つ過去の蓄積の応用が可能になる面もあり、考えて語られるべきかとは思います。
　効率性、何らかの障害回避、利便性など、「その手段を取る理由があるときに」実行するのが「大人のとるべき例外的手段」です。
　そこにリスクや、手間、手順の煩雑さがあるのなら、それは遠回りを近道と喜ぶ子供の論理で無価値な物です。
　基本的には思いつきを書き殴ってしまっているので、言えた義理ではありませんが、誰もがコンピュータを楽しいと思って使っているわけではなく、誰もが深くその事象に興味があるわけではないということは忘れない方が良いとは思います。

半分くらいはあってます。
GPT自体が基本的にEFIとセットの物ですから、パーティションテーブルにそのパーティションIDが存在することで、ブート対象外のアーキテクチャと判断している可能性もありますし、「BIOSの胸三寸なので理由はわかりません。」。
MBRパーティションとしては、先頭から、最後部まで、GPTとして確保されている形になっているので、空間は無いのです。
ただ、旧Ubuntuと目に見えて違う仕様は、GPTが（このケースでは）使われることと、実パーティションの開始値が違うことで、仕様の違いという面ではその辺りが地雷を踏んでいる可能性は高いというレベルの話で、確定できる情報はこのトピックには存在しません。

また、GPTに「推奨される」パーティションを構築しようとしていますが、「無くても本来MBRの後続ブロックに確保される物はファイルシステムの中に入るため、起動は可能である」ということで、且つ、手順としても必ずしも必須とは限らない物が含まれていたため、#41は確認フローとして考慮していません。また、少なくとも1MiBの空間ができていることは記載されており、必要とされる最低サイズもわかっているので、どうしても試したければ、先に使うのはここと、grub2の再インストールだと思われます。
制御するフラグの内容がわかっているのなら作業の前提条件もまたわかると思います。

それ以外の部分については、「正直、悪い予感しかしない」食い付き方をしているのと、先日「管理者に言われたことをきちんと理解していれば無いだろうなぁ」という発言も見られるので、誤読されうる状況の補正と、「この手の場所で真剣に相手の言うことなんて必ずしも真剣に読まれはしないし、興味も本人が必ずしも強く持っていて取り組んでいるとは限らない」ということを書いています。このトピックには必ずしも関連しない部分でも、感想は同じです。

また、よいお歳の方と見受けられるのですが、「ゆとり」のごとく「自分を守るための言い訳でしかない蛇足」は無意味です。読めばわかる「#～をお読みくださいは無駄だ」と言われるくらい無駄です。
おかしな返しがきたら届く言葉を紡げない私が無能なのでしょうし、それを補正する内容を記述するのがコミュニケーションです。前もって違っているかもなんて下らない責任逃れの小細工を「慎重とは言わない」のですよ。それらの「一応考えはしましたけど」というポーズには、責任回避の機能すらないことはそろそろ理解してください。無意味で適当な倒置法と、自分はできることはしましたというポーズは言責に対する逃げであって、無責任な安いプライドだけの低年齢層の記述におけるセオリーですけど、それをいい歳をした大人が使う物ではありません。

これでも、最初に頭に浮かんだ文言よりは1000倍くらい希釈された表現ですが、自分で気づかれる雰囲気もないので、どう見えているかということで記してはおきます。経過からすれば、結果は期待してませんし、返事は今後の言動で見えれば結構です。

ははじめましてHIDと申します。
よろしくお願いします。
早速ですが、私のところでも同様の症状が出ましたので報告させていただきます。

環境

マザーボード: Intel D510MO（ATOM D510 CPU）
BIOS: Ver.0303（最新）
メモリー: IODATA DX800-2GX2（4GB）
HDD: Seagate ST32000542AS（2TB SATA300）
DVD: HP dvd 1260i（SATA DVD）
インストールメディア: Ubuntu 10.04 LTS Desktop 日本語 Remix CD (x86用)
※USBメモリにインストール済の Ubuntu 10.04 LTS 日本語版を接続し、起動すると正常に起動する
※HDD交換して Seagate ST3320620AS（320GB SATA300）に Ubuntu 10.04 LTS 日本語Remix CD (x86用)をインストールすると正常に起動する

インストール方法（HDDは購入時のままのクリーンな状態）

ようこそ: Ubuntu 10.04 LTS をインストールする
どこにお住まいですか: アジア、日本時間
キーボードレイアウト: 規定値 Japan
ディスクの準備: ディスク全体を削除してから使用する
あなたの情報を入力してください: ログイン時にパスワードを要求する
インストール: インストール準備完了: インストール

症状

インストールを終了、再起動するとHDD起動がスキップされ、ネットワークブートがはじまり、結局起動できずに終了する
BIOS上ではインストール前後とも、認識している、ただし容量は方法がわからないため確認していない。
「Ubuntu 10.04 LTSを試す」等で見る限りインストールされたデータそのものは見ることが出来る。

試した対策と結果

BIOS Update Ver.0154、0210、0303、それぞれ変化なく起動しない。
BIOS設定、IDEモード、AHCIモード、それぞれでインストール後再起動、変化なく起動しない。
Ubuntu 9.10 Desktop 日本語 Remix CD (x86用)をインストール後 10.04 LTSにアップグレードする方法は正常に起動する（ただしパフォーマンス等については未検証）。

その他

10.04をクリーンインストールせず、9.10からアップグレードしたことで、パフォーマンス等に何らかの影響を及ぼさないかどうかということは若干気になっております。

以上、丸１日かけてインターネットで情報を集めながら試行錯誤した結果報告でした。
次回アップグレードでは改善されていることを期待しております。