在整个系统更新之后（我通常会尝试避免这种情况），我以为无法启动，但这次我决定再等待一下。
因此经过恰好 6 分 5 秒（每次都是这么精确的延迟）后，它终于完成了启动 :(
更新之前速度非常快，所以我排除了任何硬件问题。
[您可以跳转至最新更新，当前更新时间为 2019-12-25]
我发现的其他问题与 LVM 无关，但这种情况似乎是因为最后的失败消息是关于扫描 LVM 的：
是的，最初有一些关于 irq 和 ACPI 的内容，我尝试添加这些但没有帮助acpi=strict，所以我猜测这是一个 LVM 问题。
我在日志中发现一些可能有帮助的内容（省略“重复”）：
#happens 5 times
syslog.1:Dec 18 18:52:29 MyHostName lvm[803]: WARNING: lvmetad is being updated, retrying (setup) for 10 more seconds.
syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Created slice system-lvm2\x2dpvscan.slice.
# happens 20 times, each for a different device
syslog.1:Dec 18 18:52:29 MyHostName lvm[814]: WARNING: lvmetad is being updated, retrying (setup) for 10 more seconds.
syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Starting LVM2 PV scan on device 8:31...
syslog.1:Dec 18 18:52:29 MyHostName systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
syslog.1:Dec 18 18:52:29 MyHostName kernel: [ 2.460879] random: lvm: uninitialized urandom read (4 bytes read)
#logs like this happened for each device also
syslog.1:Dec 18 18:52:29 MyHostName lvm[625]: 4 logical volume(s) in volume group "MyLvmGroupName" monitored
syslog.1:Dec 18 18:52:29 MyHostName lvm[911]: 4 logical volume(s) in volume group "MyLvmGroupName" now active
上面的内容，尽管说的是“再过 10 秒”，但似乎都发生在同一秒，即“12 月 18 日 18:52:29”，这对我来说没有多大意义，这是很多线程吗？无论如何......
注意：grub v 2.02-2ubuntu8.14
我使用以下方法检查启动时间sudo systemd-analyze time
经过这次最新更新后，当我打开电脑时，它通常会在第一次启动时“冻结”（在做出启动选择（正常或高级启动等）后），但我可以按 ctrl+alt+del。此后，它又出现了启动速度变慢的问题……
2019 年 12 月 19 日今天我看到了一些有趣的事情 +- 像这样：
/dev/mapper/MyLVMGroupName: clean我无法拍照，速度太快了，我在 /var/log 的任何地方都找不到它（ubuntu 没有启动日志？？？）嗯... 在我看来，fsck每次都在运行（一直在运行）并且需要 6 分钟才能完成？注意：昨天我正常关机了，所以我认为它应该已经干净了，不需要 fsck...
其他关于这一点：桌面红色 LED（显示是否正在发生某种硬盘 I/O）在显示 fsck clean 消息之前，在 6 分钟的延迟内没有闪烁一次，所以...它没有花时间进行读取/写入。那么发生了什么？可能是某种超时，但为什么它对此只字未提？
那里也没有任何systemd-analyze blame事情花费超过 6 秒的时间。
2019-12-25：到linuxgrub 命令中，我添加debug --verbose并得到了这个！
等待 60 秒后：
systemd-udevd 'SomeDevicePartition' is taking a long time
再等 120 秒后：
systemd-udevd 'SomeDevicePartition' killed
它们发生在 +-：60 秒、180 秒、240 秒、365 秒，
所以总共 6 分钟！！！
我想知道 udevd 终止超时是否可以降低到 10 秒并且不重试？（使用 grub 条目中的某些配置）
我最后的猜测是，这一切只是一些令人讨厌的错误 :(
那么，我该如何解决这个问题？
我可以提示 grub 快速检测 LVM 内容吗？
答案1
使用一种解决方法来解决这个问题：
https://unix.stackexchange.com/questions/559929/very-slow-boot-6m-how-to-force-change-systemd-udevd-timeout-to-5s/559979#comment1041816_559979
linux /vmlinuz-4.15.0-72-generic \
udev.event-timeout=5 \
root=/dev/mapper/MyLvmGroupName ro nosplash \
$vt_handoff debug --verbose
由于我没有进行大量测试来 100% 确定：
我认为两者都有debug，并--verbose让我知道发生了什么。
我认为udev.event-timeout=5必须在root=param 之前。
我确定rd.udev.event-timeout=5被忽略了。