☰

Ubuntu 14.04 更新后启动时在徽标处挂起

tag-icon • tag-icon boot upstart
Ubuntu 14.04 更新后启动时在徽标处挂起

昨天，我做了一个update/ dist-upgrade。今天，我打开机器，它挂在加载屏幕上，上面有徽标和循环点 - 我在这个屏幕上等了大约一个小时，但没有任何结果。如果我upstart用 ctrl-alt-del 中断，启动会恢复/完成，但它会让我进入 tty 控制台登录。X几秒钟后确实启动了，但立即弹出一个关于图形配置不正确的对话框。更新：X 问题已通过执行解决apt-get install nvidia-current。中断问题仍然存在。

不幸的是，我找到的所有关于为什么会发生这种情况的线索都变成了死路。这是我的boot.log（来自/var/log）显示了我中断启动的位置。您可以看到它在启动“启用剩余的启动时加密块设备”时挂起（这是来自cryptdisks），但删除该服务没有任何区别。我几乎尝试了所有来自此 Mint 错误报告，描述的症状与我的几乎相同，但毫无效果。现在，我相当确定这cryptdisks是个转移注意力的借口，完全是另一回事。

我还发现从恢复模式恢复启动似乎会以不同的顺序加载内容。Upstart仍然挂起，但之后不会cryptdisks。如果我按 ctrl-alt-del，它会将我带到图形登录管理器而不是 tty，我可以成功登录。但是，系统仍然没有完全发挥作用；USB 即插即用似乎不起作用，我无法使用我的第二台显示器，我必须手动操作start resolvconf才能访问互联网。这是其中一次启动的 boot.log。

我应该补充一下，我正在用 加密我的硬盘LUKS，成功输入解密密码后就会挂起。这是我的fstab，以防万一它与以下事情有关：

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=9e7c1e90-f3e4-4075-b3b0-e3ccb6d933c7 /boot           ext2    defaults        0       2
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

这里发生了什么？

答案1

根本原因是我的目录中的文件数量太多/tmp。

我之前曾使用该/tmp目录存储数百万个文件。结果发现，有这么多文件会导致清理服务/tmp花费很长时间（呃）。将文件移出后/tmp，问题就解决了。这与升级无关；那只是巧合。

以防以后对任何人有帮助，以下是我用来解决这个问题的过程。我启用了“神奇的 SysRq 键”通过更改etc/sysctl.d/10-magic-sysrq.conf。然后，我通过重新启动重现了该问题；当启动挂起时，我点击了Alt- SysRq- t。这会将以下内容转储到内核缓冲区中，使用 读取dmesg：

[   36.318527] SysRq : Show Blocked State
[   36.318696]   task                        PC stack   pid father
[   36.318719] find            D ffff88041dd93480     0   839    788 0x00000000
[   36.318721]  ffff880405d07a48 0000000000000082 ffff880401136000 ffff880405d07fd8
[   36.318723]  0000000000013480 0000000000013480 ffff880401136000 ffff88041dd93d18
[   36.318725]  ffff88041dfab460 0000000000000002 ffffffff811ef380 ffff880405d07ac0

它转储的内容远不止这些，但这是相关部分。这表明被阻止的任务是find。之后，只需要一个知识渊博的朋友知道/tmp清理服务可能是罪魁祸首。

答案2

感谢 Chaosed0 提供解决方案（即 /tmp 中的大量文件）。[我试图将此作为评论发布，但我没有足够的声誉点]

我在 Ubuntu 服务器（14.04）上遇到了同样的问题，很难诊断，直到我找到您的帖子。

当我重新启动机器时，它似乎在正常显示登录控制台之前被阻止了。可以通过按Ctrl+ Alt+来解除阻止Del，这将导致打印wait-for-state (rcplymouth-shutdown)已终止的日志消息。该日志消息让我走上了一条错误的道路，我尝试了各种 plymouth 脚本，然后试图完全禁用 plymouth :-(

其实，启动过程并没有死锁，只是在等待 的清理/tmp完成。那台机器下有数万个文件/tmp，所以清理工作花了很长时间。

因此，对我来说，解决方法是启动恢复系统，获取 root shell，然后rm -rf /tmp/*。大约一小时后，rm工作完成。然后我重新启动，一切正常。

如果在开始清理时可以打印日志消息就太好了/tmp。

相关内容