在干净的SSD安装(18.04)后,Ubuntu加载/启动画面出现长时间延迟

我从正式发布当天开始使用18.04版本,并进行了干净的SSD安装,至今没有遇到任何问题。
启动到登录界面只需几秒钟(最多10秒)。

然后,今天早上我进行了一次正常升级。

$ sudo apt update && sudo apt dist-upgrade

安装/升级的软件包如下:

Install: linux-headers-4.15.0-24:amd64 (4.15.0-24.26, automatic), linux-headers-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-extra-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-modules-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic), linux-image-4.15.0-24-generic:amd64 (4.15.0-24.26, automatic)
Upgrade: gnome-control-center-data:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-headers-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-image-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), linux-signed-generic:amd64 (4.15.0.23.25, 4.15.0.24.26), gnome-control-center-faces:amd64 (1:3.28.1-0ubuntu1.18.04.1, 1:3.28.1-0ubuntu1.18.04.2), linux-generic:amd64 (4.15.0.23.25, 4.15.0.24.26)

升级完成后,我重新启动了一次,并注意到Ubuntu加载/闪屏界面(登录之前)有2-3分钟的延迟(点上没有任何进度/活动指示)。
我关机后再次尝试启动,但现在始终出现这种延迟。同时关闭也变得更慢了。 更新 #1(2018-07-03):
对systemd进行了分析。
$ sudo systemd-analyze blame
3min 53.073s plymouth-quit-wait.service
    2min 20.699s snapd.seeded.service
         49.949s snapd.service
          6.186s NetworkManager-wait-online.service
          1.148s dev-sda2.device
          1.098s plymouth-start.service

显示出 plymouth-quit-wait.service(我现在相信与Ubuntu的加载/启动画面有关)和 snapd.seeded.service 是启动时间最长的服务。因此,我比较了 dist-upgrade 前后的时间:
$ journalctl -u plymouth-quit-wait.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:38:05 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:15:46 user-laptop systemd[1]: Started Hold until boot process finishes up.
-- Reboot --
Jul 03 04:21:17 user-laptop systemd[1]: Starting Hold until boot process finishes up...
Jul 03 04:24:52 user-laptop systemd[1]: Started Hold until boot process finishes up.

在升级之前,plymouth-quit-wait.service需要3秒钟。在升级之后,它需要3分钟35秒钟
$ journalctl -u snapd.seeded.service --since today
-- Logs begin at Fri 2018-04-27 13:01:30 BST, end at Tue 2018-07-03 12:42:14 BST. --
Jul 03 04:15:43 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:15:43 user-laptop systemd[1]: Started Wait until snapd is fully seeded.
-- Reboot --
Jul 03 04:22:47 user-laptop systemd[1]: Starting Wait until snapd is fully seeded...
Jul 03 04:24:49 user-laptop systemd[1]: Started Wait until snapd is fully seeded.

在升级之前,snapd.seeded.service只需要0秒。升级后,它需要2分钟2秒。
更新#2(2018-07-06): 今天早上的启动出现了延迟的问题。 所以我猜我们仍在等待内核/plymouth/snapd的更新。
更新#3(2018-07-12): 问题似乎已经解决,但我没有看到snap或plymouth的任何更新,我仍在运行4.15.0-24内核。所以我不确定是哪个软件包的更新修复了问题,还是问题自己解决了。阅读launchpad上的错误更新,对于哪个软件包做了什么(或正在进行什么)对我来说并不清楚。如果有人能澄清这一点,那将非常有用。

看起来snapd正在进行种子操作(刷新snap数据库)长达2小时20分钟。这是一个罕见的事件,没有出现任何故障。如果每次都发生这种情况,请向snapd提交错误报告。 - user535733
谢谢。到目前为止,在升级后,snapd种子每次启动都保持在2分钟以上,而之前则为零秒。 - Broadsworde
1在安装了Ubuntu 18.04的新系统后,我遇到了相同的问题:3分57.515秒 plymouth-quit-wait.service2分24.588秒 snapd.seeded.service - Alessandro Gaballo
1今天我也遇到了同样的问题,原因是我将内核升级到了4.15.0-24-generic版本。 - user605331
1请考虑在https://forum.snapcraft.io上开启一个主题。那里是Snap开发者聚集的地方。如果您愿意帮助他们进行故障排除和测试,请务必开启一个主题。每个人都应订阅同一个主题,并避免无用的“我也是”评论 - 保持噪音较低,以免开发者感到泄气并停止参与。 - user535733
2我在https://bugs.launchpad.net/snapd/+bug/1779872上记录了一个错误。我当然愿意帮助进行故障排除。 - Broadsworde
这个问题在我升级内核后第一次启动时影响了我的Ubuntu 18.04 LTS系统。但是第二次和第三次启动时,它不再影响我的Ubuntu了。 - sudodus
请你如果有新的或者后续问题,请打开一个新问题?如果你在现有问题上追加不相关的问题,会扩大问题的范围,使得回答变得更加困难。而且,这可能会使现有答案失效。我已经自行还原了添加后续问题的修改。谢谢。我已经擅自还原了那些剧变。 - David Foerster
这不是与Ubuntu开发版本相关的问题。它与发布的版本18.04有关,并且是由定期发送给所有用户的明显错误的软件更新触发的问题。 - msc
4个回答

这是一个与内核相关的回归问题,launchpad 上的 bug 是:https://bugs.launchpad.net/ubuntu/+bug/1779827

作为一种解决方法,在启动时按键或移动鼠标。

简言之,现在使用 /dev/urandom 或 getrandom() 的服务会阻塞,直到足够的熵可用。过去对于 /dev/urandom 需要的熵要少得多。

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1779961/comments/5 中的最新状态是:

元包已被回滚,修复正在进行中并已应用和上传。

snapd 团队也研究了这个问题,并与 bson 上游合作,确保启动不需要 /dev/unrandom (https://github.com/snapcore/snapd/pull/5464)

因此,这个问题很快会通过内核或 snapd 的更新得到解决。


1我刚刚尝试了“shift”启动,似乎反映了更新之前我所看到的登录时间...那么这里出了什么问题呢?顺便说一下,“shift”启动并没有给我提供grub菜单,但确实让我更快地登录了。 - Broadsworde
Michael,你能否编辑这个回答,并将你另一个回答中的信息合并到这个回答中,然后删除另一个回答?在这里,我们喜欢一个问题对应一个回答...谢谢!;-) - Fabby
请联系管理员以合并您的账户。 - Zanna
@Broadsworde,在Ubuntu 18.04 LTS中,频繁按下Shift键或Esc键会呼出grub菜单。(仅仅长按键不足以触发此功能;我猜这可能因计算机而异。) - sudodus

你可以移动鼠标或增加系统熵。
sudo apt install haveged

haveged网站

适用于默认内核和从ukuu安装的内核。这使系统可以在4.17.4内核上正确启动。


有趣的解决方案。我目前还没有这个问题,因为我最近切换到了4.4.0-130版本进行Virtualbox实验,但我安装了haveged来未雨绸缪。 - WinEunuuchs2Unix

我在我管理的两台台式电脑上遇到了这个问题。运行以下命令来安装rng-tools解决了我的问题:
sudo apt install rng-tools

来自Arch维基:rng-tools是与内核中的随机数生成相关的一组实用工具。主要用于增加内核中的熵量,以加快/dev/random速度。


我遇到了与“4.15.0-24-generic #26-Ubuntu SMP”相同的问题。
user@nb:~$ systemd-analyze blame |head
         4min 2s plymouth-quit-wait.service
          1.440s systemd-udev-settle.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

为了临时解决这个问题,你只需要在启动时移动鼠标/触摸板,就能实现“正常”的启动时间;在我的情况下:
user@nb:~$ systemd-analyze blame |head
          1.440s systemd-udev-settle.service
           882ms plymouth-quit-wait.service
           562ms dev-sda1.device
           313ms udisks2.service
           240ms systemd-rfkill.service
           231ms NetworkManager.service
           194ms networkd-dispatcher.service
           180ms systemd-backlight@backlight:acpi_video0.service
           179ms systemd-journal-flush.service
           147ms systemd-logind.service

修复来源: https://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509