更新9
我决定尝试一个实验。我从台式机上卸下了SSD，并暂时将其放入Dell Latitude笔记本电脑中。瞧，它加载initrd速度快了一个数量级，将启动时间缩短了6秒 ...
我现在有点困惑...也许GRUB的主板芯片组有问题？
更新8
因此，我注意到了有关HDD活动指示灯的一些有趣信息。加载时initrd，几乎就像以10％的占空比或其他方式对光进行PWM调制一样。这使我想知道GRUB的读取是否没有优化，也许是像在做OS调用那样读取每个字节而不是将图像作为字节流读取吗？
更新7
似乎加载初始虚拟磁盘是问题的很大一部分。
在GRUB内部，我按下C了手动命令提示符。然后，我一次一次键入默认配置中的每一行（输入这些UUID很痛苦！），并记下命令完成所花费的时间。这是我发现的：
- 大多数命令可立即完成
- 加载内核的命令耗时约一秒钟
- 加载初始虚拟磁盘的命令耗时7秒
输入配置文件中的所有行后，然后运行boot。从我按下Enter键到显示登录屏幕的时间，大约需要7.5秒。
有趣的是，它加载的initrd映像为36MB。因此，如果加载花费了7秒钟，那么它只能以5MB /秒的速度读取它！
塔上的磁盘活动指示灯会持续亮整整7秒钟...
这也是Wikipedia页面上有关initrd的有趣片段：
其他Linux发行版（例如Fedora和Ubuntu）会生成更通用的initrd映像。它们仅以根文件系统的设备名称（或其UUID）开头，并且必须在引导时发现其他所有内容。在这种情况下，软件必须执行一系列复杂的任务才能安装根文件系统
更新6
Nathan Osman在聊天中以单用户模式请求了启动时间。
从我打F10GRUB到提示出现的时间，这需要13秒。
另外，我在聊天中与Zanna和Rinzwind聊天，从按下电源按钮开始，他们俩的启动时间均为8秒。我的20秒来自GRUB。如果我算上POST时间，那会更长！
更新5
Ubuntu可以以550MB /秒的最高速度读取我的SSD。
更新4
因此，我quiet splash $vt_handoff从笔记本电脑上的GRUB中的启动命令中删除了参数（请记住，该笔记本电脑没有SSD），并在启动过程中注意到了一件非常有趣的事情：
它在此行上挂起15秒：
[ 4.374390] init: plymouth-upstart-bridge respawnng too fast, stopped
这是一张（低质量）图片：
不知道那是什么意思...
更新3
我定时启动了另一台运行14.04的计算机的启动时间（请记住，这台计算机没有SSD），从我打入GRUB直到出现登录屏幕，这需要40秒钟。
按下Enter键后，它会在同一空白的紫色屏幕上停留20秒钟，然后加载Ubuntu动画，然后又需要20秒钟才能登陆登录屏幕。
我查看了的输出dmesg，但无法完全确定启动的位置。我认为它在25秒时完成。这是最后几行：
[ 24.916824] wlan0: associated
[ 24.916852] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 25.215550] init: kdm main process (869) killed by TERM signal
[ 25.441216] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[ 25.445587] vboxdrv: Found 2 processor cores.
[ 25.446142] vboxdrv: fAsync=0 offMin=0x18c offMax=0x960
[ 25.446228] vboxdrv: TSC mode is 'synchronous', kernel timer mode is 'normal'.
[ 25.446230] vboxdrv: Successfully loaded version 4.3.36_Ubuntu (interface 0x001a000b).
[ 25.476940] vboxpci: IOMMU not found (not registered)
[ 33.174926] init: plymouth-upstart-bridge main process ended, respawning
[ 36.495811] init: anacron main process (933) killed by TERM signal
如果我正确地解释了它，这似乎是一个普遍的GRUB问题。
更新2
通过使用C在GRUB中按时访问的命令行将GRUB的背景色设置为绿色，我可以确认这是GRUB的问题。
当我按Enter键时，在加载Ubuntu启动动画之前，我会得到一个空白绿屏，约15秒...
更新资料
我认为问题在于GRUB花费很长时间来加载内核映像。
题
我已经在三星850 Pro 512GB SSD上安装了Ubuntu 16.04，但我不明白为什么启动时间为20秒。（从我在GRUB中按Enter键开始）。请记住，我要引用的20是登录屏幕上的17，然后是桌面3。
另外，不确定是否相关，但是：
- Ubuntu以MBR模式安装，因为我不喜欢UEFI。
- 我安装了专有的Nvidia驱动程序
查看由生成的图像systemd-analyze plot > bootimage2，我的创业公司显然花了3秒钟？
看一下dmesg，我的创业公司显然花了4秒钟。但是我用秒表给它计时，花了20秒！（不包括开机自检时间），请再次记住，我引用的20是登录屏幕上的17，然后是桌面3。
启动顺序如下：
- 开机自检
- GRUB负载
- 当我按ENTER键时，我启动秒表
- 我会看到空白的紫色屏幕约15秒
- 我看到Ubuntu启动动画两秒钟
- 我登陆登录屏幕
- 我停秒表
- 我输入密码，按Enter，然后再次启动秒表。
- 3秒后，我降落在桌面上
- 我再次停止秒表。
这是来自以下网站的完整输出dmesg： http : //paste.ubuntu.com/23955108/
这是输出的第一行systemd-analyze blame：
365ms dev-sda5.device
327ms networking.service
287ms accounts-daemon.service
286ms ModemManager.service
233ms systemd-logind.service
216ms apport.service
213ms grub-common.service
209ms ondemand.service
200ms irqbalance.service
183ms speech-dispatcher.service
178ms apparmor.service
160ms gpu-manager.service
148ms thermald.service
148ms pppd-dns.service
146ms systemd-user-sessions.service
142ms alsa-restore.service
140ms console-setup.service
137ms rsyslog.service
105ms NetworkManager.service
104ms upower.service
102ms avahi-daemon.service
100ms systemd-udev-trigger.service
这些人有同样的问题：
- https://ubuntuforums.org/showthread.php?t=2325045
- https://www.bleepingcomputer.com/forums/t/598260/booting-ubuntu-temporarily-stuck-on-a-purple-screen/
- 而且似乎ARCH使用者也有这个问题...
有任何想法吗？
systemd-analyze blame。奇怪的是，Grub由于文件大小而应该在瞬间内停留在“加载初始ram磁盘”上约10秒钟。然后滞后就消失了。也许这是内核更新？也许我不确定我所做的更改plymouthd。