![Ubuntu 14.04 更新后启动时在徽标处挂起](https://linux22.com/image/866210/Ubuntu%2014.04%20%E6%9B%B4%E6%96%B0%E5%90%8E%E5%90%AF%E5%8A%A8%E6%97%B6%E5%9C%A8%E5%BE%BD%E6%A0%87%E5%A4%84%E6%8C%82%E8%B5%B7.png)
昨天,我做了一个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
。