更新：mountallは、emit_event（）ルーチン内でハングしているようです。これは、/が再マウントされた後に呼び出され、その結果としてイベントを発行します。emit_event内では、ply_boot_client_flush（）を呼び出してから、env配列を作成し、upstart_emit_event（）を呼び出し、次にdbus_pending_call_block（）を呼び出します。そして、それがハングします。それで、dbus_pending_call_blockが無期限にハングする理由は何ですか？壊れたプリマス？dbus？新興？修正またはさらなる診断のための提案はありますか？
Ubuntu 10.04 LTS、64ビットAMDマシンを再起動すると、100％ハングします。ドライブアクセスライトはオフですが、alt-sysreqキーは機能します。ハードウェアはLenovo W700dsラップトップです。利用可能なシステムに関する情報と、それを使って何ができるか（起動しないため）が非常に限られているので、今は前もって謝罪します。10.04 CDから起動できます-レスキューディスクのように使用します。私は自分のパーティションに対してfsck、マウント、読み取りと書き込みを行うことができます-それらは問題ありません。私はすでにmkswapでスワップを再フォーマットしようとしました。私のシステムには4つのext4パーティションがあります。sda1は/、sda2は/ usr、sda3は/ home、および4番目はデータストレージ/ sdb1に使用します（ディスク全体、作成したマウントポイント/ hdbにマウントします） 。swapである/ sda4もあります。現在、10からの「レスキューセッション」で開いたブラウザからこれを書いています。
私は何がハングしているのか、なぜ、そしてそれを修正するために何ができるかを診断するのを助けるために何ができるかについての提案/コメントをいただければ幸いです。私はすでにウェブ検索を実行しましたが、これらの行に沿って新しいものは何も見つかりませんでした（同様の症状のある1〜1.5年前のバグレポートもありますが、修正は機能しませんでした）。
7月1日頃に新しいディスクに10.04をインストールし、aptitudeを使用してすべてを最新のものにしました。それ以来、LOTSをインストールしてきましたパッケージ（以下のdpkgログを添付します）。sdaが750GB（/ 20GB、/ usr 80GB）であるため、「いつか使用する可能性がある」パッケージをインストールするためのスペースがたくさんありました。私がインストールしたこれらのパッケージの1つがシステムをめちゃくちゃにしたのだろうか？カーネル2.6.32-32-genericをインストールして再起動しましたが、それ以降、さらに多くのパッケージをインストールしています。私はこのマシンを可能な限り再起動しません-ある場所から別の場所に移動する間は休止状態にすることを好みます。最近、私はハイバネーション解除に関連する奇妙な動作に気づきました。システムがハイバネート解除されると、ロック解除に必要なパスワードを使ってgnomeスクリーンセーバーが表示されます。まあ、それは私のパスワードを認識しません！私はalt-F1キーを押してrootとしてログインし、スクリーンセーバーを終了する必要がありました。その後、すべてが大丈夫か、そう思われました。また、休止状態になると、画面に色とりどりのゴミが点滅している間、私は頻繁に頻繁に目にしました。消えてしまうので原因を探ろうとはしなかった。別の関連する可能性のあるポイントは、10.04のインストールで「nomodeset」を使用する必要があり、同じCDからレスキューシェルを起動したときに、nomodesetだけを使用すると、NumLock LEDまたはCaps Lock LEDが点滅してハングすることです（クラッシュしますか？）、しかし私が "noapic nolapic acpi = off"も使用している場合、問題なく起動します。私のシステムでこれらのオプションを試して、ブートハングの問題を解決できるかどうかを確認しましたが、解決されません。nomodesetのみを使用すると、NumLock LEDまたはCaps Lock LEDが点滅してハングアップします（クラッシュ？）が、 "noapic nolapic acpi = off"も使用している場合は問題ありません。私のシステムでこれらのオプションを試して、ブートハングの問題を解決できるかどうかを確認しましたが、解決されません。nomodesetのみを使用すると、NumLock LEDまたはCaps Lock LEDが点滅してハングアップします（クラッシュ？）が、 "noapic nolapic acpi = off"も使用している場合は問題ありません。私のシステムでこれらのオプションを試して、ブートハングの問題を解決できるかどうかを確認しましたが、解決されません。
これは、私が仕事のためだけでなく、他のほぼすべてのために使う機械ですので、それが再び起動するようにされてきTOPの優先順位を。/ homeは無傷です。しかし、私は今や、ハングブートのこの原因を診断（直していない）しようとしています。
システムを起動すると、/ etc / init / mountall.confにあるmountall構成スクリプトの実行が開始されます。fsckを実行しているmountallからの出力が表示されます-util-linux-ng 2.17.2からのfsck（ext4パーティションごとに1つ）という4行です。次に、パーティションが「クリーン」であることが判明したことをユーザーに通知するfsckからの4行があります。そして、それだけです-すべてが止まるだけです。ドライブアクティビティLEDが消灯します。私はalt-sysreqキーを使用できますが、これまでのところ有用ではありません。1人のユーザーがalt-sysreq-iを使用してプロセスを強制終了し、シェルに落ちたというバグレポートを見ました。私にとっては、それはプロセスを殺したと言っていますが（udevとudev-bridgeとplymouth、その再生成されたudevなどと言っています）、シェルは取得していません。
何がぶら下がっているのか正確に判断しようとしています。そのために、/ etc / init / mountall.confをいじってみました。エコー行を追加し、mountallのexecに-v（詳細）オプションを追加しました。mountallの実行後のエコー行は表示されないため、mountallがハングしている可能性があります。または、最後の出力が表示されない可能性があります。その場合、mountallが終了し、他の何かがハングしている可能性があります。alt-sysreq-iはmountallがkillされたとは言っていません。fstabからsda3（/ home）、swap、sdb1（/ hdb）をコメントアウトして、システムがハングしている可能性があるものを絞り込もうとしましたが、それでもハングします。
自分でできることはたくさんありますが、ここは頭の中にいるような気がします。たとえば、mountallのソースコードを取得し、印刷されたフラグを追加し、再コンパイルしてシステムに貼り付けます-A）mountallが実際にハングしている場合、およびB）何がハングしているのかを絞り込みます。しかし、マシンをそこからコンパイルするためのシェルで起動することはできません-レスキューディスク環境は2.6.32-28-generic＃55だけなので、私のシステムと一致しません。パッケージを削除または再インストールしたいのですが、マシンを起動してこれを行うことができません。
（私のdpkgログファイルは数MBなので、次のダイアログボックスで添付します）
ありがとう、グレッグ