更新: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 小时的生命:\