自从正式发布之日安装干净的 SSD 以来，我一直在运行 18.04，没有任何问题。
开机登录时间为几秒（最多 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)：
今天早上的启动看到了延迟的回归。
所以我想我们还在等待 kernel/plymouth/snapd update。
更新 #3 (2018-07-12)：
问题似乎已解决，但我没有看到 snap 或 plymouth 的任何更新，而且我仍在运行 4.15.0-24 内核。所以我不确定哪个软件包更新解决了这个问题，或者它是否只是以某种方式自行解决。阅读启动板上的错误更新，我不清楚对什么包做了什么（或正在做什么）。如果有人能澄清这将非常有用。
这是一个内核相关的回归，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 更新来解决。
您可以在系统中移动鼠标或增加熵。
有网站
适用于默认内核和来自 ukuu。这允许系统在内核 4.17.4 上正确启动。
我在我管理的两个桌面上看到了这个清单。运行以下命令进行安装
rng-tools为我解决了这个问题：来自 Arch wiki： rng-tools 是一组与内核中随机数生成相关的实用程序。这主要用于增加内核中的熵以使 /dev/random 更快。
我有同样的问题
4.15.0-24-generic #26-Ubuntu SMP对于临时解决方法，您只需要在启动时移动鼠标/触摸板，从而获得“正常”的启动时间；就我而言：
修复来源：https ://ubuntuforums.org/showthread.php?t=2395451&p=13780509#post13780509