回答ありがとうございます。
Ubuntu（と言うか、Linux）は8.10から自宅での使用を開始し、ディストリビューションアップデートの度にsdaをクリーンインストールして、sdbの/homeは継承するという形でやってきました。
ご指摘のとおりsdaの構成はswapのパーティションもありますので、sda0:/boot、sda1:root(/)、sda2:swapの3つに手動で分割しています。

今回障害が発生したのは職場で使っているもので、これは9.10のリリース開始に合わせてUbuntuを導入しました。
と言うより、9.10になって初めてLive CDでの起動ができたので、動作の重いWindowsから乗り換えた形です。

基礎になっている本体はeMachinesのJ2955で、これにAGPのRadeon 9600 (障害後Radeon 9200に換装)とRam 512Mb、HDDの増設を行っています。
ATIの古いVGAカードなので、示唆していただいたプロプライエタリドライバは使っていませんし、クリーンインストール後のxorg.0.logにWarningは見られません（クリーンインストール前のログを残しておかなかったことが悔やまれます）。

現在もLive CD（カーネル2.6.31-14）からの起動はできますし、最初に書いたとおりプロンプトからのstartxも滞りないのに、なぜ通常起動だけができないのか、不思議で、悔しくてなりません。
引き続き、お力添えいただければ幸いです。


追伸：
　　最初の投稿で挙げた疑問の1つ、プロンプトからのstartxの場合、bashの上にx-sessionが乗っかるということで、自己解決しました。

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

>>hiro0さま

ご指摘いただいた/bootのgrub.confは最初に疑った部分です。
$sudo update-grubは幾度と無く試しました。
ちなみに、本件の機体は9.10からですので、grub2がインストールされています。

また、web検索でブートメニュー（grub読み込み中にshift、"e"で編集できる奴です）からのgrub.confの編集についての記述がありましたので、これも試みました。
障害のあるコンピュータが手元にないのと、件のサイトが見つからず一部あやふやですが、（確か）2行めくらいのif .....　fiのエラー処理を一時削除して回避し、CTRL+XでXを起動すると言う手順だったと思います。
それで期待された効果が得られなかったので、プロンプトから直接grub.confを書き換えるのは試みていません。
これについて、このフォーラムの記述をたどりながら、おかしな部分がないかもう一度チェックしてみます。

kiyoshiさんのおっしゃるとおり、sdaのパーティションについてはインストール前に読んだウェブサイトの受け売りで、/と/bootを分ける意義はあまり感じていなかったりします。
どちらかといえば、MySQLを格納している/varを分割しておく方がまだマシだったかもしれません（バックアップ時に結構手間がかかりました）。
どちらにせよ、分割したおかげでgrub.confもややこしくなっているでしょうね ^^;
しかし、せめて/homeくらいはパーティションを切って（自分の場合は別ドライブですが）おいた方が、こう言うトラブルのときに安心じゃないですか（結果的に初期化してしまったとはいえ）?

とにかく明日、grub.confをチェックして、また改めてご相談することになるかと思います。
引き続きお力添えいただければ幸いです。
貴重なご意見ありがとうございました。

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

横からですが、KMSの疑いは？
GRUBメニューの編集で「quiet splash」の後に「radeon.modeset=0」を追記してみるとどうなります？

自分が寝た後にもいろいろとご示唆いただき、ありがとうございました。
午前中は別件で手を出すことができず、午後の入りもバタバタして、電源だけ入れて放置していたのですが……
状況がガラリと変わりました。

ノーマルブートできています。
放置していたらログイン画面が出ていたので、そこで再起動をかけ、カーネルの停止から再起動までのログが以下のとおりです。

Dec 24 13:44:26 EMJ2955-Ubuntu kernel: Kernel logging (proc) stopped.
Dec 24 13:52:25 EMJ2955-Ubuntu kernel: imklog 4.2.0, log source = /var/run/rsyslog/kmsg started.

つまり、電源投入後、grubを読み込み、そこで約8分間空白（HDDアクセス無し）の時間があって、カーネルが立ち上がっている。
この空白の時間に、自分は今まで起動しないと勘違いして、rebootしてしまっていたということの様です。

まだちょっと済ませなければいけない用事があって、皆様の回答にお答えできませんが、差し当たり報告まで。

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

やはりカーネル側の問題でデバイスの認識に手間取っているような気が。
止まったときにUSB機器をどれか外してみたら起動が進むという事はありませんか？

何故か/boot/bootとか言うディレクトリが生成されていたのはご愛嬌ということで

ご愛嬌では済まないかも…。
おそらくkiyoshiさんの方からお叱りの言葉があると思います。

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

Super8kaiさんへ。
旧GRUBへの完全移行？は、/boot/grubディレクトリを移動（リネーム）させて「grub-install（--root-directoryオプションは使わないように）」「update-grub」で良さそうです。GRUB2の/boot/grubが残っているとmenu.lstにチェインの項目が追加されてしまうようです。
（Synapticだけでというのは元々不可能のような。grubパッケージをインストールしただけでは、MBRやPBRにGRUBはインストールされないはずなので）

それと、起動が止まる原因がsplashであるのなら、GRUBなら「/boot/grub/menu.lst」、GRUB2なら「/etc/default/grub」に記述されている「splash」を「nosplash」とすれば良いかもしれません。

ただ、鵜呑みにはしないでください。
最近ちょっと外しまくりなので、他の方のアドバイス待ちでお願いします。


kiyoshiさんへ。
出張中でしたか。余計な事を言ってしまい申し訳ありませんでした。

トピックを立てた身でありながら、長らく不在にしており申し訳ございませんでした。

#18,19 kiyoshi様
出張中と言うお忙しい身でありながら、暖かいお言葉、痛み入ります。
/boot/bootが生成された原因は以下のコマンドによるものでした。
　　sudo grub-install --no-floppy --root-directory=/boot /dev/sda3
何のことはなく、ただ単に、rootディレクトリを指定すべきところを、インストールディレクトリと勘違いして入力してしまったのが原因でした。
内部の構成は、既に消してしまいましたのではっきりしたことは言えませんが、本来/bootに収められるべきファイル群が収められていた形だったと記憶しています。
initramfsについては間違いなくHDDに収められていることを確認しました
grubまわりをいじっている際に気づいたのですが、update-initramfsもupdate-grubとセットで行うべきだったかも知れません(synapticでgrubを更新する際には、同時に行われている様でしたので)。

#20,#21,#22 kiyoshi様、Templer様
なるほど。9.10からもgrub 0.97のインストールは一応加能ということなのですね。
実はこのフォーラムに不在だった間に、9.04から9.10にdist-upgradeなどと言う強引な手法でやっておりました:D

最初からこのトピックに注目していた方はおや?と思われた方もいるかも知れませんが、#3に記した「9.10になって初めてLive CDのブートができるようになった」という内容の原因は、当方のパソコンのマザーボードに内蔵されているG945GEグラフィックチップに起因していたようで、9.10の導入にあわせて発掘してきたAGPカードを刺しておけば、9.04以前でも難なく起動できていた様です(同様に8.10でも起動を確認しました)。

ちなみに、9.04でそれぞれのパーティション(/boot, / ,/home)をext4でフォーマットした環境ではノーマルブートの遅延現象は観察されませんでしたが、そこからgrub 0.97のまま9.10にアップグレードすると、やはり遅延が発生するようになりました。

さらに、/bootを分離せず、partitionerにおまかせでクリーンインストールも試みました(初めっから言われてたんだから、もっと早くやっておけと)。
が……結果は惨敗でした:(
少なくとも、このトピックを立てる前までは普通に起動していたはずなんですが……

nosplashについてですが、grubメニュー(1.97)から"e"の簡易編集で試してみると……今度はまったく起動しない:(
no-splashとでも打ち込んでいたんでしょうか。
とりあえずこの投稿の後に再度試してみます（初期のころに試したmodesetのこともあるので、今度は直編集で）。

さて、#18で述べたbootchartのログ解析の方ですが……先の投稿では桁を一つ間違えていて、実はアーカイブを解くと約130MBでした。
しかも、内容の読み方がさっぱり分かりません。
とりあえずproc_diskstat.log (約20MB)の最終の一塊は以下のとおりです。

51979
   1       0 ram0 0 0 0 0 0 0 0 0 0 0 0
   1       1 ram1 0 0 0 0 0 0 0 0 0 0 0
   1       2 ram2 0 0 0 0 0 0 0 0 0 0 0
   1       3 ram3 0 0 0 0 0 0 0 0 0 0 0
   1       4 ram4 0 0 0 0 0 0 0 0 0 0 0
   1       5 ram5 0 0 0 0 0 0 0 0 0 0 0
   1       6 ram6 0 0 0 0 0 0 0 0 0 0 0
   1       7 ram7 0 0 0 0 0 0 0 0 0 0 0
   1       8 ram8 0 0 0 0 0 0 0 0 0 0 0
   1       9 ram9 0 0 0 0 0 0 0 0 0 0 0
   1      10 ram10 0 0 0 0 0 0 0 0 0 0 0
   1      11 ram11 0 0 0 0 0 0 0 0 0 0 0
   1      12 ram12 0 0 0 0 0 0 0 0 0 0 0
   1      13 ram13 0 0 0 0 0 0 0 0 0 0 0
   1      14 ram14 0 0 0 0 0 0 0 0 0 0 0
   1      15 ram15 0 0 0 0 0 0 0 0 0 0 0
   7       0 loop0 0 0 0 0 0 0 0 0 0 0 0
   7       1 loop1 0 0 0 0 0 0 0 0 0 0 0
   7       2 loop2 0 0 0 0 0 0 0 0 0 0 0
   7       3 loop3 0 0 0 0 0 0 0 0 0 0 0
   7       4 loop4 0 0 0 0 0 0 0 0 0 0 0
   7       5 loop5 0 0 0 0 0 0 0 0 0 0 0
   7       6 loop6 0 0 0 0 0 0 0 0 0 0 0
   7       7 loop7 0 0 0 0 0 0 0 0 0 0 0
   8       0 sda 3889 10974 343735 513572 308 658 7704 7632 0 23180 521200
   8       1 sda1 40 965 1838 444 0 0 0 0 0 392 444
   8       2 sda2 3802 9938 340953 512892 305 658 7704 7632 0 22772 520520
  11       0 sr0 0 0 0 0 0 0 0 0 0 0 0
   8      16 sdb 468 941 9062 3152 49 147 1466 1108 0 3868 4260
   8      17 sdb1 420 852 7966 2960 40 147 1466 900 0 3492 3860
   8      32 sdc 0 0 0 0 0 0 0 0 0 0 0
   8      48 sdd 0 0 0 0 0 0 0 0 0 0 0
   8      64 sde 0 0 0 0 0 0 0 0 0 0 0
   8      80 sdf 0 0 0 0 0 0 0 0 0 0 0

どうも各種記憶デバイスの割り込み状況?を示したダンプの様に思えますが。
最初の数字が126スタートでどんどん加算されていく形、接続しているデバイス(sda,sdb)の数値セットがオール0スタートから適宜加算されていっている様に見えます。

次にproc_stat.log (約10MB)

51979
cpu  14094 0 34632 1892 1319 30 14 0 0
cpu0 14094 0 34632 1892 1319 30 14 0 0
intr 149104 50 30 0 0 2 0 0 0 0 0 0 0 220 0 4824 536 4156 204 0 89 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
ctxt 81300
btime 1262043764
processes 2038
procs_running 1
procs_blocked 0
softirq 265559 0 126127 8 48 5480 25 0 0 133871

こちらは記憶デバイス以外といったところでしょうか。

その他、proc_ps.log (約100MB!!、プロセスと数値セット)がありますが、こちらは長すぎるので割愛します。
とりあえず正常起動しているもののログと比較するくらいしかなさそうです:(

長らくお付き合いいただきましたこのトピックですが、おかげさまで、ようやくノーマルブートに漕ぎ着くことができました:D
#21で示唆いただいたとおり「nosplash」が決定打となりました。

自分の環境に依存した問題と思いますが、一応今後同様の現象に遭遇された方のために手順を詳細に記しておきます。

1. "/etc/default/grub"をroot権限で編集（sudo vi とか）
2. GRUB_CMDLINE_LINUX_DEFAULT="quiet nosplash"
　　を
　　GRUB_CMDLINE_LINUX_DEFAULT="quiet nosplash radeon.modeset=0"
　　に改める（radeon.modesetは不要かもしれません）。。
3. 端末から"sudo update-grub"を実行（ついでに"sudo update-initramfs -u"も実行しました）

以上です。

本件について、年末の慌しい直にもかかわらず、暖かいご示唆をいただきましたhir0様、kiyoshi様、Templer様に心よりお礼申し上げます。
自分も今後技術・知識の研鑽に努め、このフォーラムで困っている方に力添えできるよう努力することで恩返しが出来ればと考えております。
皆様のご助力に重ねて御礼申し上げます:)