更新：mountall 似乎挂在了 emit_event() 例程中，它在 / 重新挂载后调用该例程以发出事件。在 emit_event 中，它调用 ply_boot_client_flush()，然后构造 env 数组，调用 upstart_emit_event()，然后调用 dbus_pending_call_block()。然后它就挂了。那么，您知道为什么 dbus_pending_call_block 会无限期挂起吗？plymouth 坏了吗？dbus 坏了吗？upstart 坏了吗？有什么修复或进一步诊断的建议吗？
重新启动我的 Ubuntu 10.04 LTS，64 位 AMD 机器时 100% 挂起。驱动器访问指示灯熄灭，但 alt-sysreq 键可以工作。硬件是联想 W700ds 笔记本电脑。现在，我提前道歉，因为我对系统的信息非常有限，也不知道我能用它做什么（因为它无法启动）。我可以从 10.04 CD 启动 - 像使用救援盘一样使用它。我可以 fsck、挂载和读写我的分区 - 它们很好。我已经尝试使用 mkswap 重新格式化我的交换分区。我的系统上有 4 个 ext4 分区：sda1 是 /，sda2 是 /usr，sda3 是 /home，还有第 4 个我用于数据存储的 /sdb1（是整个磁盘，挂载在我创建的挂载点 /hdb 上）。还有 /sda4，它是交换分区。现在，我正在通过 10.04 LTS 安装 CD 中的“救援会话”中打开的浏览器撰写本文。
我会极大地非常感谢大家的建议/评论，帮助我诊断出挂起的原因、原因以及我可以做些什么来修复它。我已经在网上搜索过了，但没有找到类似的东西（一些 1-1.5 年前的错误报告有类似的症状，但它们的修复没有起作用）。
我在 7 月 1 日左右在新磁盘上安装了 10.04，然后使用 aptitude 将所有内容更新到最新版本。从那时起，我一直在安装很多软件包（我将在下面附上 dpkg 日志）。由于 sda 为 750GB（/ 20GB，/usr 80GB），我有足够的空间来安装“将来可能会用到”的软件包。我想知道是不是我安装的这些软件包之一搞砸了我的系统？我安装了内核 2.6.32-32-generic 并重新启动，但此后又安装了更多软件包。我尽可能少地重新启动这台机器 - 宁愿在从一个地方到另一个地方时将其休眠。不过最近，我注意到与解除休眠相关的一些奇怪行为：当系统解除休眠时，它会调出 gnome 屏幕保护程序，并需要解锁密码 - 嗯，它无法识别我的密码！我不得不按 alt-F1，以 root 身份登录，然后关闭屏幕保护程序。然后一切都会好起来，至少看起来是这样。此外，在解除休眠后，我经常会在屏幕上看到短暂闪烁的彩色垃圾。它会消失，所以我没有尝试寻找原因。另一个可能相关的点是，我需要在安装 10.04 时使用“nomodeset”，当从同一张 CD 启动救援 shell 时，如果我只使用 nomodeset，它最终会挂起，NumLock LED 或 Caps Lock LED 闪烁（崩溃？），但如果我还使用“noapic nolapic acpi=off”，它就会正常启动。我已在我的系统中尝试了这些选项，看看它们是否能解决启动挂起问题 - 但事实并非如此。
这是我用来工作以及几乎所有其他事情的机器，因此让它再次启动是一件顶部优先级。/home 完好无损，这很好。但我几乎已经筋疲力尽，无法诊断（更不用说修复）导致启动挂起的原因。
我启动系统，它开始运行 /etc/init/mountall.conf 中的 mountall 配置脚本。我看到 mountall 运行 fsck 的输出 - 4 行内容：fsck from util-linux-ng 2.17.2（每个 ext4 分区一个）。然后 fsck 又有 4 行内容通知用户发现分区是“干净的”。就是这样 - 一切都停止了。驱动器活动 LED 熄灭。我可以使用 alt-sysreq 键，但到目前为止它们还没有被证明有用。我看到一个错误报告，其中一位用户使用 alt-sysreq-i 来终止进程，然后进入 shell。对我来说，它确实说它已经终止了进程（udev 和 udev-bridge 和 plymouth，说它正在重新生成 udev，等等），但我没有得到任何 shell。
我一直在尝试确定到底是什么挂起了。为此，我修改了 /etc/init/mountall.conf。我添加了 echo 行，并在 mountall 的 exec 中添加了 -v（详细）选项。在 mountall 的 exec 之后没有显示 echo 行，因此这可能意味着 mountall 挂起了。或者，它可能没有显示最后的输出 - 在这种情况下，mountall 可能已退出，其他东西可能挂起了。我注意到 alt-sysreq-i 并没有说 mountall 被杀死了。我试图通过从 fstab 中注释掉 sda3 (/home)、swap 和 sdb1 (/hdb) 来缩小系统可能挂起的范围，但它仍然挂起了。
我自己可以做很多事情，但感觉有些力不从心。例如，我想获取 mountall 的源代码，添加打印标志，重新编译并将其粘贴到我的系统上 - 以缩小 A) mountall 是否确实挂起，以及 B) 它挂在什么地方。但是，我无法将我的机器启动到可以在其中进行编译的 shell - 救援磁盘环境只有 2.6.32-28-generic #55 - 所以它与我的系统不匹配。我想删除或重新安装软件包，但同样，我无法启动我的机器并执行此操作。
（我的 dpkg 日志文件有几 MB，因此我将在下面的对话框中附加它）
谢谢，格雷格
答案1
Denwerko：我没有对我的机器做任何会导致此结果的事情。它在 Ubuntu 9.10 下非常稳定 - 从未发生过这样的事情。所有对源代码的修改、重新编译 - 都是用户空间代码。我根本没有对操作系统进行任何修改。我也没有在标准渠道之外安装任何操作系统空间代码（aptitude/synaptic 包管理器、通过这些工具获得的 deb 包）。Greg 昨天
但是，我已获得 mountall 2.15.3 的源代码，并在 5 次安装（libnih-dev、libnihdbus-dev、lindbus-1-dev、linudev-dev、libplymouth-dev）后，在救援环境中对其进行了编译。我已通过 nih_info() 调用在代码中添加了调试打印，并且已使执行 fsck 的 spawn 阻塞而不是非阻塞。我正在研究 mountall 在某处崩溃的理论（或 nih、dbus 或 plymouth...）。每次运行时，我似乎都没有将输出输出到代码中的同一位置，但它似乎在将 /dev/sda1 重新挂载到 / - 之后的某个时间停止（在 mounted() 例程中）。Greg 昨天
我还按照您的建议通过 chroot 对软件包执行了 dpkg -r，这似乎有效（除了一个想要对 /proc 进行操作的卸载脚本）。我卸载了 wine 以及它所需的 32 位兼容性软件包（lib32nss、ia32lib、lib32v4l 等）和几个未安装在救援环境中的 ibus 软件包（一些 ibus 软件包已安装，我小心翼翼地没有删除它们）-删除了 plasma-widget-kimpanel-backend-ibus、ibus-qt4、ibus-qt1。这些都对问题没有影响，所以我删除了更多我现在不需要的软件包（wx widget 和 jdk 软件包等）-没有影响
更新：mountall 似乎挂在了 emit_event() 例程中，它在 / 重新挂载后调用该例程以发出事件并产生相应效果。在 emit_event 中，它调用 ply_boot_client_flush()，然后构造 env 数组，调用 upstart_emit_event()，然后调用 dbus_pending_call_block()。然后它就挂了。那么，您知道为什么 dbus_pending_call_block 会无限期挂起吗？plymouth 坏了吗？dbus 坏了吗？upstart 坏了吗？有什么修复或进一步诊断的建议吗？
解决方案 所以，我似乎已经安装了 cloud-init 和 cloud-utils，因为我想有一天我可能会想用它。Will，结果发现 cloud-init 破坏了 ureadahead 配置，并在 dbus 事件“mounted /”发生时启动，这导致我的系统在发出该 dbus 消息后立即挂起，这种情况发生在 / 从 ro 重新挂载到 r/w 之后。我卸载了 cloud-init 和 cloud-utils，现在一切似乎都正常了。只是，我很困，已经失去了 24 小时的生命:\