我调查了这个问题在其他一些人 (开启和关闭 SO) 中寻找解决方案。
获得赞同（但是不是接受）回答该问题，建议熵可能存在问题。事实上，我从一开始就haveng安装rng-tools并启用了这两个，而且熵相当高（根据该答案的评论，它们建议接近 4000 是一个不错的值）。
$ cat /proc/sys/kernel/random/entropy_avail
$ 3703
我禁用了一些服务，比如 Docker、lxc 等，我认为这些服务可能会减慢启动过程。这是之后的关键链输出。我认为没有启动任何不必要的服务。
$ systemd-analyze critical-chain
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.
graphical.target @18.632s
└─multi-user.target @18.632s
└─ModemManager.service @12.750s +3.349s
└─polkit.service @9.288s +3.409s
└─basic.target @8.854s
└─sockets.target @8.854s
└─libvirtd-admin.socket @8.854s
└─libvirtd.socket @8.848s +5ms
└─sysinit.target @8.817s
└─systemd-sysctl.service @8.795s +21ms
└─systemd-modules-load.service @2.849s +5.941s
└─systemd-journald.socket @2.737s
└─-.mount @2.733s
└─system.slice @2.733s
└─-.slice @2.733s
这是我的 lightdm.log。
[+7.13s] DEBUG: Process 1994 exited with return value 0
[+7.13s] DEBUG: Seat seat0: Exit status of /sbin/prime-offload: 0
[+7.13s] DEBUG: posix_spawn avoided (fd close requested) (child_setup specified)
[+7.13s] DEBUG: Seat seat0: Display server ready, starting session authentication
[+7.13s] DEBUG: Session pid=1999: Started with service 'lightdm-greeter', username 'lightdm'
[+7.40s] DEBUG: Session pid=1999: Authentication complete with return value 0: Success
[+7.40s] DEBUG: Seat seat0: Session authenticated, running command
[+7.40s] DEBUG: Session pid=1999: Running command /usr/lib/lightdm/lightdm-greeter-session /usr/sbin/lightdm-gtk-greeter
[+7.40s] DEBUG: Creating shared data directory /var/lib/lightdm-data/lightdm
[+7.40s] DEBUG: Session pid=1999: Logging to /var/log/lightdm/seat0-greeter.log
[+30.54s] DEBUG: Activating VT 7
[+30.54s] DEBUG: Activating login1 session c1
[+30.54s] DEBUG: Seat seat0 changes active session to c1
[+30.54s] DEBUG: Session c1 is already active
[+48.16s] DEBUG: Greeter connected version=1.30.0 api=1 resettable=false
[+49.90s] DEBUG: Greeter start authentication for junaid
[+49.90s] DEBUG: Session pid=6578: Started with service 'lightdm', username 'junaid'
[+49.92s] DEBUG: Session pid=6578: Got 1 message(s) from
我已经尝试从amd 网站但这并没有什么改变。我恢复了开源驱动程序。
我还从 lightdm 切换到 sddm 和 gdm3。以下是其输出。
- 使用 lightdm
$ systemd-analyze
Startup finished in 7.564s (kernel) + 18.663s (userspace) = 26.228s
graphical.target reached after 18.632s in userspace
使用 lightdm 时，在欢迎界面出现之前我只会看到一个空白屏幕约 30 秒。
- 使用 sddm
$ systemd-analyze
Startup finished in 6.667s (kernel) + 16.169s (userspace) = 22.837s
graphical.target reached after 16.155s in userspace
关于 sddm 的有趣之处在于，鼠标光标（虽然冻结）几乎立即出现，但迎宾器在接下来的约 20 秒内不会出现。
- 使用 gdm3
$ systemd-analyze
Startup finished in 6.562s (kernel) + 52.061s (userspace) = 58.624s
graphical.target reached after 52.047s in userspace
$ systemd-analyze blame
41.779s plymouth-quit-wait.service
5.738s systemd-modules-load.service
5.519s udisks2.service
4.411s networkd-dispatcher.service
3.809s accounts-daemon.service
3.443s [email protected]
3.011s qemu-kvm.service
2.930s uml-utilities.service
2.614s dev-sdb5.device
2.459s ModemManager.service
2.205s polkit.service
2.158s avahi-daemon.service
2.136s NetworkManager.service
2.124s dundee.service
2.005s ofono.service
1.958s gpu-manager.service
1.920s grub-common.service
...
最后，Syslog 显示内核启动速度非常快（约 4 秒），直到出现以下问题，耗时 20 到 30 秒，这大约是登录屏幕出现之前屏幕保持空白且无响应的时间。
Dec 18 12:04:03 my-desktop NetworkManager[1057]: <info> [1639825443.5387] manager: NetworkManager state is now CONNECTED_GLOBAL
Dec 18 12:04:13 my-desktop systemd[1]: NetworkManager-dispatcher.service: Succeeded.
Dec 18 12:04:22 my-desktop systemd[1]: systemd-fsckd.service: Succeeded.
Dec 18 12:04:22 my-desktop systemd-timesyncd[996]: Initial synchronization to time server 91.189.89.199:123 (ntp.ubuntu.com).
Dec 18 12:04:26 my-desktop systemd[1]: systemd-hostnamed.service: Succeeded.
Dec 18 12:04:40 my-desktop systemd[1]: Created slice User Slice of UID 1000.
使用 gdm3 时，启动画面在登录欢迎界面出现之前会保持冻结约 30 秒。
我有一台几年前组装的还不错的系统，配备 Ryzen 7 处理器、32GB RAM、256GB SSD 作为操作系统，而且我正在使用最新的 Ubuntu 20.04 LTS。
因此，如果这个问题有解决方案的话，那么在过去的 2 到 3 个小时内我就找不到它了。
答案1
我在联想 Thinkbook 的 Ubuntu 20.04.3 中遇到了这个问题。该问题与指纹读取器登录选项有关，该选项无法正常工作。我删除了此选项，它运行正常。
您可以使用 验证它是否在终端中运行journalctl -f。然后锁定屏幕（在我的情况下是 Windows 键 + L）并再次登录并查看该过程的结果。这将显示登录过程中调用的元素。