我正在尝试诊断 20.04.1 中更新后启动缓慢的问题。我运行了 systemd-analyze plot（输出已附上），但我不知道如何解释输出并找出导致延迟的原因。
systemd-analyze critical-chain 和 systemd-analyze blame 也是如此。我该如何解释它们的输出来确定是什么阻碍了事情的发展？在 critical-chain 中，我是在寻找那些需要很长时间才能启动 (+) 的事情，还是在前一个事情发生很久之后才开始活动 (@) 的事情，还是其他什么？在 blame 中，是不是只有那些（除了 plymouth-quit-wait.service）需要很长时间的事情？还是比这更复杂？
~$ systemd-analyze critical-chain
graphical.target @21.564s
└─multi-user.target @21.564s
└─systemd-logind.service @879ms +384ms
└─basic.target @812ms
└─paths.target @812ms
└─cups.path @810ms
└─sysinit.target @807ms
└─systemd-timesyncd.service @712ms +95ms
└─systemd-tmpfiles-setup.service @690ms +19ms
└─systemd-journal-flush.service @305ms +384ms
└─systemd-journald.service @235ms +68ms
└─systemd-journald.socket @232ms
└─-.mount @230ms
└─system.slice @230ms
└─-.slice @230ms
~$ systemd-analyze blame
20.555s plymouth-quit-wait.service
384ms systemd-journal-flush.service
384ms systemd-logind.service
359ms dev-mapper-vgubuntu\x2droot.device
271ms apport-autoreport.service
218ms accounts-daemon.service
215ms upower.service
199ms udisks2.service
178ms networkd-dispatcher.service
172ms systemd-resolved.service
134ms apparmor.service
128ms bolt.service
122ms lvm2-pvscan@253:0.service
107ms bluetooth.service
106ms polkit.service
103ms NetworkManager.service
101ms virtualbox.service
99ms systemd-rfkill.service
95ms systemd-timesyncd.service
90ms ModemManager.service
86ms [email protected]
85ms lvm2-monitor.service
78ms switcheroo-control.service
75ms gpu-manager.service
73ms thermald.service
71ms wpa_supplicant.service
68ms systemd-journald.service
66ms colord.service
64ms rtkit-daemon.service
61ms apport.service
58ms e2scrub_reap.service
57ms dev-mapper-vgubuntu\x2dswap_1.swap
56ms lm-sensors.service
55ms systemd-udev-trigger.service
54ms systemd-udevd.service
lines 1-35...skipping...
plymouth-quit-wait.service 启动，随后在一秒钟内执行十几个操作，最后以 upower.service 结束。然后 packagekit.service 延迟约 3 秒，两个蓝牙设备延迟约 5 秒，GUI 延迟约 11 秒。如何确定这些进程中的哪一个正在执行某项操作（或等待其他操作）导致延迟？
plymouth-quit-wait.service 的关键链（后续但类似的启动）：
~$ systemd-analyze critical-chain plymouth-quit-wait.service
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
plymouth-quit-wait.service +20.305s
└─systemd-user-sessions.service @1.090s +19ms
└─network.target @1.079s
└─NetworkManager.service @931ms +147ms
└─dbus.service @929ms
└─basic.target @894ms
└─sockets.target @894ms
└─uuidd.socket @894ms
└─sysinit.target @885ms
└─systemd-timesyncd.service @812ms +70ms
└─systemd-tmpfiles-setup.service @791ms +16ms
└─systemd-journal-flush.service @339ms +451ms
└─systemd-journald.service @254ms +83ms
└─systemd-journald.socket @251ms
└─system.slice @249ms
└─-.slice @249ms
我之所以关注这部分图，是因为从普利茅斯启动画面到 GUI 的延迟是新问题。在更新之前，启动画面会显示几秒钟，然后在一秒钟内进入 GUI。现在，启动画面会显示几秒钟，然后屏幕变黑，在 GUI 出现之前会有 15-20 秒的延迟。
仅供参考，更新包括从内核 5.8.0-43 到 5.8.0-44 的更新，以及许多其他内容。我不认为内核是问题所在，因为回滚内核并没有解决问题。此外，关闭蓝牙也无法解决问题。